Job interviews.

[Nick]

What are your tips for nailing a job interview?



Relevant video. Funny video. Watch it.

 

[mangamusicfan]

Yust be yourself, And be honest.

 

[Kyrul]

Know a guy that works there. A hell of a lot easier when you know someone.

 

[Khoshi]

Keep eye contact, try not to sound like you're begging for employment. I haven't had a job yet, but I've been learning about what to do and what not to do. Basically, you gotta seem interesting, but not forcing the interview along.

 

[El Héroe Oscuro]

Yust be yourself, And be honest.

I have to disagree with this. Being yourself could actually be a deterrent in obtaining a job. Companies are constantly looking for a specific image for their employees to fit and if you don't fit that image than it will be more difficult to get the job. As such, identifying what the person is up to you.

A really good tip though when going for a job is following up on the application/interview. After the interview is over, sending an email thanking them for their time can actually put you above and beyond another applicant with similar qualities to yourself. It's the little things things like this that can actually make or break you in landing the job.

 

[Darkwing Ducklett]

Always have a question or two ready for the end of the interview, because you will probably be asked if you've got any. It shows you're engaged and interested, and that you've really thought about it. Obviously, make sure they're not about holiday or rate of pay, etc.

 

[Puddle]

I like to make things more personal. Instead of just answering the questions, I try and somehow revert it to their life, so that they know that I'm good with conversation and stuff.

 

[Raine]

Personally, I've never had a job interview myself, but I have learned a few things from my culture in the Canadian workplace course. I think dressing for the part you want; first impressions are lasting and no company in their right mind would want to hire someone who looks like a slob, to be honest \: Know the company profile or information about them; from their job posting, if they list any particular required skills, mention any that you believe you possess because that's what they're looking for.

 

[Shining Raichu]

Yust be yourself, And be honest.

Yeah that's pretty much the worst advice ever lol. While parents try to tell you that honesty is always the best policy, that has no place in a job interview. The secret to a job interview is that none of the applicants is what they actually want. The one who does the best job at pretending is the one that gets the paycheck.

So my advice: lie through your teeth. Accentuate whatever is good about yourself, mention no negatives or limits and if you have to, just make up complete untruths on the spot.

Also hygiene and appearance.

 

[Nick]

Yust be yourself, And be honest.

Just a friendly reminder that this is a thread on how to get a job, not how to get a date.

 

[El Héroe Oscuro]

Just a friendly reminder that this is a thread on how to get a job, not how to get a date.

Even on a date, that's still a big no in my book haha.

 

[Nick]

Even on a date, that's still a big no in my book haha.

If I'm myself around someone new it either ends in three ways:

1. They think I'm amazing and want to get to know me because I'm so deep and interesting and funny.
2. They think I'm annoying and want me to go away because I talk too much.
3. They think I'm weird - and in a bad way - and want nothing to do with me.

Those are the only three ways its ever gone for me.

So when I meet someone new I usually try my best to be a giraffe.

 

[El Héroe Oscuro]

If I'm myself around someone new it either ends in three ways:

1. They think I'm amazing and want to get to know me because I'm so deep and interesting and funny.
2. They think I'm annoying and want me to go away because I talk too much.
3. They think I'm weird - and in a bad way - and want nothing to do with me.

Those are the only three ways its ever gone for me.

So when I meet someone new I usually try my best to be a giraffe.

A giraffe that walks like a baby deer, don't forget about that part.

 

[Overlord Drakow]

https://www.pokecommunity.com/blog.php?b=14208

Having been back on the job search very recently and landing a new opportunity just days ago, I think I have a few extra things to share with you guys. I'd been looking for that big jump in my career and therefore I've had to experience multiple stages of interviews for each opportunity I applied for. And I targeted some big, international companies too. With all of my job hunting experience (and I assure you, it is quite extensive), I have come up with a general procedure that I tend to utilize. I'll break this down into two interview phases but the individual should pick apart and use what appeals most to them.

Preliminary interview: One of the primary purposes of this phase is to serve as an information gatherer. I want to try and learn more about the company I've applied for, try and get an understanding of the culture and see what kind of people work there. I generally try to control the flow and direction of the interview as much as I can. If there's certain topics that I know I would struggle more than others to answer, I'll try and give lengthy and detailed explanations (without waffling) on the questions they ask me, that I am comfortable with answering, therefore giving me leverage on providing short, succinct answers to areas that I am not as strong in. I try and ask questions throughout the interview, not just during the end (as appropriate, you can't just ask a random question in the middle of nowhere, it should relate to the context of the current conversation) as this is another means of directing the interview in a direction that is more under your control. And by getting them to talk more about themselves (employers generally love to do this), theoretically gives less time for them to probe into you and therefore less chance of you making a blunder.

There are two main factors that I think contributed to my ability to line up 3 final stage interviews out of 6 applications.

1) The hidden weapon: Don't you hate it when interviewers spring some unexpected question / test during an interview, to try and catch you off guard? Yeah it sucks, but the truth is, you can use the same principle on them. At the end of the interview, what I did was reach into my briefcase and handed over a sheet of paper titled "Reasons to hire me for this role" and I took each of their criteria bullets and added an explanation as to how I meet / exceed each bullet point. I'll spoiler an example below.

Spoiler:

Reasons to hire me for this role

Data manipulation skills

I am currently a data analyst for the Quality / Assurance department, involved with producing both internal and external KPI reports, based on statistical analysis to identify insights and conclusions from complex data, for the senior management team. These reports monitor risk and compliance with Government regulations and the Government funding from SFA (Skills Funding Agency). Company A recently had an OFSTED inspection and my reports provided data to prove that the performance of Company A had improved since their previous visit. In the OFSTED report, they remarked that the data analysis at Company A had drastically improved since their last visit and Company A had been promoted to a Level 2 training provider. In essence, my role essentially safeguards the company's finances as well as the company itself.



Understanding of SAS and/or Business Objects, Visual Basic, and standard MS Office packages (or demonstrable ability to learn these packages quickly)

I have a proven track record of learning new systems quickly. I took an SPSS module during my final year of university and attained a First Class mark for that exam. Also have experience using Minitab which is another statistical computational package. Single-handedly developed and implemented an OFSTED approved Excel based electronic registration system for Company A. This involved visual basic macros, Excel formulas (including VLOOKUP) and pivot tables.


Understand the pros and cons of different data tools and methodologies

I understand that methodologies have their strengths and weaknesses. The tools used to solve one problem may not be used to solve others. At Company B, before I learnt the SQL language, I would export data from the front end of the CRM system I was working on and place it in Excel. From there, I would perform the data manipulation and then finally import the data back into the CRM system. Once I had gained a sound understanding of SQL, I was able to go directly into the back end and directly manipulate the data in the CRM system. This saved a lot of time because there was no need to export and re-import the data, not to mention, in general I found it easier to manipulate the data using a programming language as opposed to using Excel.


Ability to grasp the significance and meaning of a range of technical and complex issues

During my time at Company B, I have worked with client data stored in multiple different systems. I noticed severe discrepancies between the data listed between two different systems – their MIS and CRM. The solution I implemented, involved taking a copy of the data in each system and storing it in an offline database to prevent the possibility of modifying any live data. From the data dumps, I had to create new tables to display the data that would be analysed between the two systems. Then I ran an SQL cursor to loop through the records in one system to compare the matched and mismatched data in the other system. The end result is that by outlining the discrepancies between the two systems, the data can be unified which will prevent further confusion from occurring due to mismatched data.
Good quality, numerical or computing degree and strong mathematical / logical capability (generally A-Level maths minimum)
I have a First Class Honours Degree - BSc Mathematics from a top 20 university as well as an A grade in A-level Mathematics.

Demonstrating effective communications, ability to make technical concepts both accessible and interesting to non-technical people, and ability to collaborate on technical projects with peers

I am a great communicator towards all levels of business. I explain my statistical analysis to members of the senior management team as well as colleagues at Company A. I also had to present my reports to OFSTED during their inspection. During my time at Company B, I collaborated with the marketing manager to provide assistance with the manipulation of marketing data as well as customizing the Microsoft Dynamics CRM system to suit her requirements - which mainly involved modifying campaign templates.

Able to plan and prioritise own work when required

Throughout my career I have been given responsibility to simultaneously manage multiple tasks. I do this by sorting the tasks out in order of priority and/or relative difficulty. An example would be during my time at Company A; I had to change my priority from developing my electronic registration system to data analysis, during the monthly reporting period.


Can work under pressure and to deadlines whilst maintaining reliability and accuracy

During my time at Company A, I have always delivered rapid and accurate solutions to any issues users have had with using my electronic registration system. This has often involved me to be very resilient as some staff lack technical ability.

Question time: It's not the amount of questions you ask, it's the quality that employers will be more impressed with. Here are a couple of my favourite questions I like to ask a prospective employer.

How did you end up in this role?

What kind of training and career progression do you offer?

What kind of challenges is your area of the business currently facing?

The first question is a conversation starter really. Some interviewers have boring stories, some have interesting ones. The real purpose of the question is to demonstrate your soft skills, to show an interest in engaging with other people.

The second question is an information gatherer for yourself but it also gives the impression to the prospective employer that you are thinking long term about this career opportunity which will put their mind at ease a little as no employer wants to hire someone for the short term unless we're talking about temporary / contractual work.

The final question is the nuclear missile if you launch it correctly and then capitalize on the impact during the final interview, which I'll get onto shortly. At this stage of the game, you are asking this question to gather more information about the business. Be attentive and make a note (mental or otherwise) of any issues the interviewer shares with you.

Final interview: Generally speaking, the first interview tests you on your suitability for the role while a final stage will test to determine whether you will fit in with the company culture. I tend to find a final stage interview easier than an initial one but dropping your guard would be foolish as in fact, the final stage interview for the position I accepted was tougher than I had anticipated. At any rate, let's get back to the nuke. So between the first and final interview, what I did was research into one of the problems I found out about the company and compiled some recommendations on how the company could potentially take to try and resolve their issue. I'll spoiler an example below.

Spoiler:

Overview
Agile is a methodology that focusses on iterative sprints (cycles) in order to implement requirements (user stories) to the system quickly and therefore swiftly provide business value. It is not a rigid methodology and in fact, is akin to developing and implementing on the fly with little regard to any control procedures and/or system functionality in place. Agile teams (called scrum teams) are small, often consisting of around 5-7 people including a scrum master, who is akin to a project manager but on a smaller scale. Agile assumes that each member is capable of fulfilling any role in the software life-cycle (developers, testers, implementers), rather than having people who specialize in only one aspect and therefore if one member is not available then another member can readily step in to do the work. This assumption is rather difficult to meet.

Each user story is given story points based on the Fibonacci series. Based on the team size, capability, and duration of a sprint and also using past experience, number of story points that can be delivered by the team is estimated during sprint planning session(s). This is not an exact science, rather an educated guess. Also every team would function differently and therefore using another team's delivery statistics could be inaccurate. Once the capacity (i.e. number of story points that can be delivered by the team in a sprint) is established then number of user stories is selected to be delivered within that sprint based on the priority and the dependency.

Agile makes business responsible for prioritising work (user stories). Negotiations as to what can be delivered in a sprint occur, up front in sprint planning sessions and need to be accepted by the team. Once this is done the whole team is collectively responsible for the sprint deliverables. This does not mean that individuals can avoid or take their responsibility lightly; rather it forces individuals to be more responsible as they would otherwise be letting the team down. This is a typical scrum philosophy. Agile uses "scrum of scrums" to manage multiple scrum teams within a project.


Implications
The traditional Agile methodology is not suitable for large, complex systems for various reasons. Typical duration for a sprint is a month. This is almost always insufficient for a team to implement deliverables with significant business value. It is difficult to deliver a user story with significant business value in a single scrum, therefore user stories may have to be artificially broken-down which is contrary to heart of agile.

In a large organisation like COMPANY X where team sizes would consistently be greater than 20, having to create scrum teams of 5-7 users as per the agile methodology means you would end up having a huge number of teams which may be counter-productive. It will become increasingly difficult to communicate between teams because there are so many, therefore teams don't know what other teams are doing and it also becomes tricky for the end-to-end solution to flow together smoothly. It's that much harder to integrate the work delivered by each team into an end-to-end cohesive solution. It also becomes tough to stick to the ideal of having every team member capable of fulfilling any role in the software life-cycle. Where there are gaps of knowledge within the team, the overall efficiency depreciates.
If the system has a lot of complex control procedures in place, this takes away from the freedom and flexibility that the Agile methodology promotes. All systems and hence their deliverables have dependencies but Agile tries to make these dependencies as "independent" as possible and delivery is based on the Fibonacci ranking and what the team wants to focus on delivering rather than system functionality.

Recommendations
In order for Agile to work in a large organisation, there are some suggestions that I would like to make. An Agile / Kanban methodology works very well and this is what was used when I was an IT Consultant at Company B. The Kanban board provides a series of phases along the x-axis and a list of user stories down the y-axis. Each user story can then progress along the phases (design, development, test, implement etc.) until completion, which provides numerous advantages. For a specific user story, the story points can be further broken down into each phase. For example, a user story of ranking 8 can be split into [1 3 2 2] for design, develop, test and implement respectively. This means that even if a user story does not reach completion in a given sprint, it can still contribute points towards the total target unlike in the traditional Agile methodology where the achievement is zero until the user story is fully delivered. Also the phases give a lot of lenience towards people who do not have the full software life-cycle experience, as they can focus on promoting all user stories within their phase of expertise, which therefore increases overall team efficiency. The Kanban board approach also allows for easy tracking and monitoring of progress, making life easier for scrum masters. Kanban effectively provides a mechanism to break a user story into phases and deliver them in different scrums.

While it is true that the COMPANY X business would require a lot more management staff due to the increased number of teams, I would advise against hiring external Agile scrum masters to make up the numbers. They have Agile knowledge and know how to scrutinize and monitor people but they would most likely lack business understanding and therefore add no actual value or credibility to the team. Unlike the Waterfall methodology where ultimately the blame for a failed project would land on project manager(s), Agile places emphasis on bringing the business, IT and technology together and promote team mentality and joint ownership. If an Agile project fails, the blame gets placed upon the entire team.

User stories are ranked by each member of the team and allocated a number in the Fibonacci series based on the relative size in comparison to other user stories. Otherwise, discussion takes place until a majority agreement is made. For complex systems in large scale organisations, this method which completely disregards system functionality does not provide proper size for the user story and thereby the delivery of the user story may not be estimated properly. Therefore I would advise a modification to the ranking system to place some emphasis on the system architecture, functionality and complexity. Even though this goes against the traditional Agile methodology, I believe this to be a necessity for COMPANY X.

Conclusion
Agile has a lot to offer by providing fast business value and promoting interactions, communications and bringing the business together. This methodology works best in SME's but with some adjustments, it can succeed in large scale organisations like COMPANY X, by taking the best aspects of the methodology and finding ways to work around the drawbacks. Ultimately it is the methodology that should adapt to suit the business - not vice versa.

Same as before, hand the sheet of paper to them from your briefcase. Do you understand what this does? What do you think is going to be racing through an employer's head when he reads a list of suggestions to solve / improve the company's business? Probably something along the lines of "wow, this guy took his own time and used his own initiative to try and help my business. He's given me a list of suggestions and clearly he should be the best person to hire in order to try and put these ideas into practice". But this hidden weapon is not for the lazy or easy going person. It requires a good duration to set it up but if you take the time to do this properly, you would gain a pretty tremendous advantage against your competition. Finally, I think it's good practice to send a thank you E-mail to your interviewer(s) if possible, as a show of courtesy.


And that is how I pretty much doubled my market value.

 

[Puddle]

https://www.pokecommunity.com/blog.php?b=14208

Having been back on the job search very recently and landing a new opportunity just days ago, I think I have a few extra things to share with you guys. I'd been looking for that big jump in my career and therefore I've had to experience multiple stages of interviews for each opportunity I applied for. And I targeted some big, international companies too. With all of my job hunting experience (and I assure you, it is quite extensive), I have come up with a general procedure that I tend to utilize. I'll break this down into two interview phases but the individual should pick apart and use what appeals most to them.

Preliminary interview: One of the primary purposes of this phase is to serve as an information gatherer. I want to try and learn more about the company I've applied for, try and get an understanding of the culture and see what kind of people work there. I generally try to control the flow and direction of the interview as much as I can. If there's certain topics that I know I would struggle more than others to answer, I'll try and give lengthy and detailed explanations (without waffling) on the questions they ask me, that I am comfortable with answering, therefore giving me leverage on providing short, succinct answers to areas that I am not as strong in. I try and ask questions throughout the interview, not just during the end (as appropriate, you can't just ask a random question in the middle of nowhere, it should relate to the context of the current conversation) as this is another means of directing the interview in a direction that is more under your control. And by getting them to talk more about themselves (employers generally love to do this), theoretically gives less time for them to probe into you and therefore less chance of you making a blunder.

There are two main factors that I think contributed to my ability to line up 3 final stage interviews out of 6 applications.

1) The hidden weapon: Don't you hate it when interviewers spring some unexpected question / test during an interview, to try and catch you off guard? Yeah it sucks, but the truth is, you can use the same principle on them. At the end of the interview, what I did was reach into my briefcase and handed over a sheet of paper titled "Reasons to hire me for this role" and I took each of their criteria bullets and added an explanation as to how I meet / exceed each bullet point. I'll spoiler an example below.

Spoiler:

Reasons to hire me for this role

Data manipulation skills

I am currently a data analyst for the Quality / Assurance department, involved with producing both internal and external KPI reports, based on statistical analysis to identify insights and conclusions from complex data, for the senior management team. These reports monitor risk and compliance with Government regulations and the Government funding from SFA (Skills Funding Agency). Company A recently had an OFSTED inspection and my reports provided data to prove that the performance of Company A had improved since their previous visit. In the OFSTED report, they remarked that the data analysis at Company A had drastically improved since their last visit and Company A had been promoted to a Level 2 training provider. In essence, my role essentially safeguards the company's finances as well as the company itself.



Understanding of SAS and/or Business Objects, Visual Basic, and standard MS Office packages (or demonstrable ability to learn these packages quickly)

I have a proven track record of learning new systems quickly. I took an SPSS module during my final year of university and attained a First Class mark for that exam. Also have experience using Minitab which is another statistical computational package. Single-handedly developed and implemented an OFSTED approved Excel based electronic registration system for Company A. This involved visual basic macros, Excel formulas (including VLOOKUP) and pivot tables.


Understand the pros and cons of different data tools and methodologies

I understand that methodologies have their strengths and weaknesses. The tools used to solve one problem may not be used to solve others. At Company B, before I learnt the SQL language, I would export data from the front end of the CRM system I was working on and place it in Excel. From there, I would perform the data manipulation and then finally import the data back into the CRM system. Once I had gained a sound understanding of SQL, I was able to go directly into the back end and directly manipulate the data in the CRM system. This saved a lot of time because there was no need to export and re-import the data, not to mention, in general I found it easier to manipulate the data using a programming language as opposed to using Excel.


Ability to grasp the significance and meaning of a range of technical and complex issues

During my time at Company B, I have worked with client data stored in multiple different systems. I noticed severe discrepancies between the data listed between two different systems – their MIS and CRM. The solution I implemented, involved taking a copy of the data in each system and storing it in an offline database to prevent the possibility of modifying any live data. From the data dumps, I had to create new tables to display the data that would be analysed between the two systems. Then I ran an SQL cursor to loop through the records in one system to compare the matched and mismatched data in the other system. The end result is that by outlining the discrepancies between the two systems, the data can be unified which will prevent further confusion from occurring due to mismatched data.
Good quality, numerical or computing degree and strong mathematical / logical capability (generally A-Level maths minimum)
I have a First Class Honours Degree - BSc Mathematics from a top 20 university as well as an A grade in A-level Mathematics.

Demonstrating effective communications, ability to make technical concepts both accessible and interesting to non-technical people, and ability to collaborate on technical projects with peers

I am a great communicator towards all levels of business. I explain my statistical analysis to members of the senior management team as well as colleagues at Company A. I also had to present my reports to OFSTED during their inspection. During my time at Company B, I collaborated with the marketing manager to provide assistance with the manipulation of marketing data as well as customizing the Microsoft Dynamics CRM system to suit her requirements - which mainly involved modifying campaign templates.

Able to plan and prioritise own work when required

Throughout my career I have been given responsibility to simultaneously manage multiple tasks. I do this by sorting the tasks out in order of priority and/or relative difficulty. An example would be during my time at Company A; I had to change my priority from developing my electronic registration system to data analysis, during the monthly reporting period.


Can work under pressure and to deadlines whilst maintaining reliability and accuracy

During my time at Company A, I have always delivered rapid and accurate solutions to any issues users have had with using my electronic registration system. This has often involved me to be very resilient as some staff lack technical ability.

Question time: It's not the amount of questions you ask, it's the quality that employers will be more impressed with. Here are a couple of my favourite questions I like to ask a prospective employer.

How did you end up in this role?

What kind of training and career progression do you offer?

What kind of challenges is your area of the business currently facing?

The first question is a conversation starter really. Some interviewers have boring stories, some have interesting ones. The real purpose of the question is to demonstrate your soft skills, to show an interest in engaging with other people.

The second question is an information gatherer for yourself but it also gives the impression to the prospective employer that you are thinking long term about this career opportunity which will put their mind at ease a little as no employer wants to hire someone for the short term unless we're talking about temporary / contractual work.

The final question is the nuclear missile if you launch it correctly and then capitalize on the impact during the final interview, which I'll get onto shortly. At this stage of the game, you are asking this question to gather more information about the business. Be attentive and make a note (mental or otherwise) of any issues the interviewer shares with you.

Final interview: Generally speaking, the first interview tests you on your suitability for the role while a final stage will test to determine whether you will fit in with the company culture. I tend to find a final stage interview easier than an initial one but dropping your guard would be foolish as in fact, the final stage interview for the position I accepted was tougher than I had anticipated. At any rate, let's get back to the nuke. So between the first and final interview, what I did was research into one of the problems I found out about the company and compiled some recommendations on how the company could potentially take to try and resolve their issue. I'll spoiler an example below.

Spoiler:

Overview
Agile is a methodology that focusses on iterative sprints (cycles) in order to implement requirements (user stories) to the system quickly and therefore swiftly provide business value. It is not a rigid methodology and in fact, is akin to developing and implementing on the fly with little regard to any control procedures and/or system functionality in place. Agile teams (called scrum teams) are small, often consisting of around 5-7 people including a scrum master, who is akin to a project manager but on a smaller scale. Agile assumes that each member is capable of fulfilling any role in the software life-cycle (developers, testers, implementers), rather than having people who specialize in only one aspect and therefore if one member is not available then another member can readily step in to do the work. This assumption is rather difficult to meet.

Each user story is given story points based on the Fibonacci series. Based on the team size, capability, and duration of a sprint and also using past experience, number of story points that can be delivered by the team is estimated during sprint planning session(s). This is not an exact science, rather an educated guess. Also every team would function differently and therefore using another team's delivery statistics could be inaccurate. Once the capacity (i.e. number of story points that can be delivered by the team in a sprint) is established then number of user stories is selected to be delivered within that sprint based on the priority and the dependency.

Agile makes business responsible for prioritising work (user stories). Negotiations as to what can be delivered in a sprint occur, up front in sprint planning sessions and need to be accepted by the team. Once this is done the whole team is collectively responsible for the sprint deliverables. This does not mean that individuals can avoid or take their responsibility lightly; rather it forces individuals to be more responsible as they would otherwise be letting the team down. This is a typical scrum philosophy. Agile uses "scrum of scrums" to manage multiple scrum teams within a project.


Implications
The traditional Agile methodology is not suitable for large, complex systems for various reasons. Typical duration for a sprint is a month. This is almost always insufficient for a team to implement deliverables with significant business value. It is difficult to deliver a user story with significant business value in a single scrum, therefore user stories may have to be artificially broken-down which is contrary to heart of agile.

In a large organisation like COMPANY X where team sizes would consistently be greater than 20, having to create scrum teams of 5-7 users as per the agile methodology means you would end up having a huge number of teams which may be counter-productive. It will become increasingly difficult to communicate between teams because there are so many, therefore teams don't know what other teams are doing and it also becomes tricky for the end-to-end solution to flow together smoothly. It's that much harder to integrate the work delivered by each team into an end-to-end cohesive solution. It also becomes tough to stick to the ideal of having every team member capable of fulfilling any role in the software life-cycle. Where there are gaps of knowledge within the team, the overall efficiency depreciates.
If the system has a lot of complex control procedures in place, this takes away from the freedom and flexibility that the Agile methodology promotes. All systems and hence their deliverables have dependencies but Agile tries to make these dependencies as "independent" as possible and delivery is based on the Fibonacci ranking and what the team wants to focus on delivering rather than system functionality.

Recommendations
In order for Agile to work in a large organisation, there are some suggestions that I would like to make. An Agile / Kanban methodology works very well and this is what was used when I was an IT Consultant at Company B. The Kanban board provides a series of phases along the x-axis and a list of user stories down the y-axis. Each user story can then progress along the phases (design, development, test, implement etc.) until completion, which provides numerous advantages. For a specific user story, the story points can be further broken down into each phase. For example, a user story of ranking 8 can be split into [1 3 2 2] for design, develop, test and implement respectively. This means that even if a user story does not reach completion in a given sprint, it can still contribute points towards the total target unlike in the traditional Agile methodology where the achievement is zero until the user story is fully delivered. Also the phases give a lot of lenience towards people who do not have the full software life-cycle experience, as they can focus on promoting all user stories within their phase of expertise, which therefore increases overall team efficiency. The Kanban board approach also allows for easy tracking and monitoring of progress, making life easier for scrum masters. Kanban effectively provides a mechanism to break a user story into phases and deliver them in different scrums.

While it is true that the COMPANY X business would require a lot more management staff due to the increased number of teams, I would advise against hiring external Agile scrum masters to make up the numbers. They have Agile knowledge and know how to scrutinize and monitor people but they would most likely lack business understanding and therefore add no actual value or credibility to the team. Unlike the Waterfall methodology where ultimately the blame for a failed project would land on project manager(s), Agile places emphasis on bringing the business, IT and technology together and promote team mentality and joint ownership. If an Agile project fails, the blame gets placed upon the entire team.

User stories are ranked by each member of the team and allocated a number in the Fibonacci series based on the relative size in comparison to other user stories. Otherwise, discussion takes place until a majority agreement is made. For complex systems in large scale organisations, this method which completely disregards system functionality does not provide proper size for the user story and thereby the delivery of the user story may not be estimated properly. Therefore I would advise a modification to the ranking system to place some emphasis on the system architecture, functionality and complexity. Even though this goes against the traditional Agile methodology, I believe this to be a necessity for COMPANY X.

Conclusion
Agile has a lot to offer by providing fast business value and promoting interactions, communications and bringing the business together. This methodology works best in SME's but with some adjustments, it can succeed in large scale organisations like COMPANY X, by taking the best aspects of the methodology and finding ways to work around the drawbacks. Ultimately it is the methodology that should adapt to suit the business - not vice versa.

Same as before, hand the sheet of paper to them from your briefcase. Do you understand what this does? What do you think is going to be racing through an employer's head when he reads a list of suggestions to solve / improve the company's business? Probably something along the lines of "wow, this guy took his own time and used his own initiative to try and help my business. He's given me a list of suggestions and clearly he should be the best person to hire in order to try and put these ideas into practice". But this hidden weapon is not for the lazy or easy going person. It requires a good duration to set it up but if you take the time to do this properly, you would gain a pretty tremendous advantage against your competition. Finally, I think it's good practice to send a thank you E-mail to your interviewer(s) if possible, as a show of courtesy.


And that is how I pretty much doubled my market value.

That's definitely something that I'm going to do when I am looking for a Job Opportunity that can result in a career. I don't want to go in there all willy nilly knowing jack ♥♥♥♥. I want to know the specifications and what it takes to get to the higher rank. I'm not gonna be in a business as a stupid person reading off a script calling companies. I want to work up to that CEO rank.

Also, at the end, I always say "Thank you for this opportunity" or something and then a couple days later follow-up with an email or a phone call. That extra initiative always helps. I haven't had many interviews, but they always seem successful. I always get the call back for a second interview, and some places, I just wasn't old enough. A lot of my Job Hunting was when I was 16, so I wasn't really qualified. I finally nailed a job with a company called Publix which is a Grocery Store. And once I nailed it, I heard good things about college opportunities, and now basically, when I go to major in Business Financing, I get re-imbursed for every business class I take.

 

[Goo]

I've learned this in the past two years, don't be foreign. There's more hoops to jump through when being hired so an equally qualified person will get the job if they arnt foreign every time.

 

[Belldandy]

Be prepared. Guess what kind of questions they're going to ask, and have the answer they want to hear. When asked about what you need to improve on, mention something that could be on-the-fence. I typically go with: "I'm a perfectionist. It may take me a bit longer to accomplish a task, but when I do, the quality justifies the extra effort."

And as Catholic Nun mentioned, hygiene and appearance. You can't change someone's opinion of you with words if you show up stinky and wearing overalls or something. First impressions last. Give a firm handshake. Be confident. Eye contact. Interviews are a set of well-thought rules that if you abide by them perfectly, should land you the position. I've always received call backs :)

 

[Sir Codin]

If they ask you what the ideal pay is, your best bet it to lowball it near minimum wage, unless you know (And you need to know this for sure) they don't pay that low. That way, they'll think you're not just in it for the money, and they won't think you're incredibly greedy

Why would anyone think you're not in it for the money? The whole reason most people work in the first place is to make an income.

 

[King Kū]

Nail the interviewer.

Lie. Make sure your resume is tailored just to that job too. A bike mechanic isn't going to want to know about your PhD in paleontology. My point is to make your resume as specific to the job as possible so they think that you're the ideal candidate.