My interactions with many students preparing and giving interviews have made me realise that students do not prepare enough for behavioral questions in general. They treat these categories of questions as secondary but fail to realise that a good leadership answer can change the interviewers perspective towards them as a prospective new hire. A good response can be a decisive factor if there is confusion in the mind of interviewers regarding your technical prowess. It is extremely important to realise that apart from assessing the technical abilities, the interviewers also assess your ability to understand the culture and the values of the company. They want to see how you tackle different situations and how well you can gel into the company as a prospective employee. Hence, this category demands a thorough preparation. While this seems like a wastage of time at first, the benefits are immense. A good preparation of only about a week can prepare you for the long term. Once you get a knack for answering these questions, not enough practise is required to maintain this skill, and you can ace the leadership round of pretty much every company. Companies like Amazon stress too much on their leadership principles. In fact, for interns, the final round is more of a behavioural than a technical round. Hence, good preparation is required.
A general mindset of students is to know just the intricacies of the projects they have worked on in college and the company and knit a story during the interview. While that is a plausible approach, the resultant answers are usually not well structured and fail to impress the interviewers. To them, instead of the technologies and the intricacies of the project, the approach, the mindset, and the learnings are far more important, which we as interviewees sometimes fail to address. I agree that there are so many different types of leadership questions that it is virtually impossible to prepare for all such questions. But the good news is, just like DSA, we can segregate these questions into categories and then smartly target those categories. I will be talking about some patterns that I have seen, some tips I have found useful, and then address how to structure your answers.
The categories:
Data: Many times, the interviewer wants to know how you handle the data. Data is unarguably one of the major factors to devise solutions, and the interviewer wants to know how your decision making is affected by different amounts of data. Your approach when you have say, a large amount of data, just enough data, or not enough data available tells a lot about your problem-solving skills. While answering such questions, you need to make sure that you leverage the data to come up with a robust and scalable solution that does not exploit much of the company's resources. You should talk about general trends, observations, insights, and outliers.
Related questions:
Decision: This category includes questions where you have to take key decisions based on different situations. Those decisions can be instinctive, quick, risky, etc. The interviewer wants to know how you handle pressure and take important decisions when a lot is at stake. Make sure your decisions are sound, scalable, and have solid data backing.
Related questions:
Innovation and hard work: This is a general category of positive questions where the interviewer wants to know more about how you think and how curious you are to learn more about new technologies and culture. Curiosity drives innovation which along with hard work improves your chances of succeeding at a company. It would be great if you have some projects where you have solved a problem using a not so usual approach and solved a pain point of the customers. The qualities you want to show while answering such questions are curiosity, hard work, inquisitiveness, and modesty.
Related questions:
Deadline: It is a very important category of questions. Working in a company, deadlines keep the engineers on their toes. Many times to fulfil the deadlines, the quality of the code might get compromised. Sometimes a last-minute bug or a late dependency resolution results in a deadline shift. Instead of playing the blame game, you need to take ownership of the mistakes and ensure that the customer impact is minimal. Some viable reasons for missing the deadlines are late dependency resolution, short-term sacrifices for long-term gain like developing a scalable and a more robust solution, an insufficient case study resulting in incorrect time estimates. An important aspect of this category is learnings. What steps did you take to mitigate the damage (for instance, keeping the manager in the loop instead of informing him at the last moment that the deadline might be missed), and what measures did you take so that such a thing is never repeated. How you learnt from your mistakes and grew as an engineer is something you should address.
Related questions:
Mistakes: It is a category of negative questions that should be answered with care. Just like the deadline category, you should take ownership of the mistakes committed and focus more on how you mitigated the damage. Ensure that the customer impact is minimal. You can also talk about why the approach you took seemed right then and what went wrong. Understanding where you went wrong and the steps you took to avoid such mistakes from happening in the future is crucial.
Related questions:
Motivation: Just like innovation, it is a positive category of questions that in a way is coupled with innovation. While innovation is mostly about your tangible impact on the project, motivation is more about your psychological impact on the team. You can motivate others around you by being a leader or even an intern. Having a sense of empathy, collaboration, taking initiative, helping fellow employees, and leading by example are some of the qualities you should try to portray while answering such questions. In this category, apart from projects, you can also talk about organising team-bonding activities to improve the cohesion between team members.
Related questions:
Conflict: Conflicts are a common phenomenon in any group project. There might be conflicts about work division, who committed a mistake, conflicts about technology choice, and designs. It is important to resolve the conflicts as soon as possible in the most practical way taking into account the well being of the project and eventually the customers. We need to understand that it's not a personal battle between engineers about who is right but what's best for the company. Many times, there is no correct answer, but an answer that suits a particular situation in the best possible way. A balance between the company's resources and customer satisfaction needs to be established.
Related questions:
The approach:
First of all, it seems intimidating to come up with situations/ stories/ projects for so many different questions I have mentioned above. What you need to understand is that you only need to be thorough with 3-4 projects you have worked upon in your company/ college. Most of the categories can be addressed by talking about a single example. For instance, describing the same project, you can talk about innovation, raising the bar, or say missing the deadline. It is always better to talk about different projects answering different questions as most companies will not ask more than three questions. Other questions would be the follow-ups. You just need to decide which project fits the best in the above categories. For all the questions, you need to be well-versed with the situations/ projects you would be talking about, and everything else would be easy following the category guidelines I have mentioned above and the structure and tips I would be writing below. Try to incorporate the company's ideologies, principles, and values in your answers. It is a bonus to know how the company's goals are aligned with yours.
Coming to the structure, all of us might have heard about the STAR method of answering leadership questions promoted by Amazon. I believe that, with minor tweaks, it is a very structured way of answering leadership questions irrespective of the company.
The STAR methodology:
Situation: Like first impressions, the beginnings are important. A good beginning acts as a hook and decide how the rest of your answer unfolds. A good beginning immediately grabs the interviewer's attention which increases his involvement, which in turn boosts your confidence while answering. I should mention that students are not very good at describing their projects. You need to understand that there are a plethora of software technologies and domains. Hence, it is hard to be well-versed with everything even for the interviewers. Since you have worked extensively in a particular domain, it does not mean the interviewer has the required expertise in it as well. Students rush into the technicalities of the project instead of discussing the managerial aspects of it. In this part, we should address why the project started, why the project was important, what was your role in the project, and what was the impact of the project. After that, you start setting the pretext. Depending on the question, start talking about say the scope of innovation, a situation where a morale boost of the team was required, a situation where you needed to abide by the deadline or a key decision was to be made.
Task: The tasks are just like the JIRA tasks. In this part, you need to talk about what was needed to be done and not how. Focus on your tasks and not that of the entire team. Focus on the goals needed to be accomplished in order to address what was asked in the question.
Action: In this section, you talk about the "how". How the task was completed and what actions you took. In this section, you talk about the technical details of your tasks. You also talk about how your technical and personal actions impacted the team and the project. Again focus on your actions and not that of the team's.
Result: In this section, you talk about the quantitative and qualitative results of your actions. How your actions given a particular situation impacted the project. Talk about the accomplishments, the metrics and the consequences of your actions.
Conclusion: To me, conclusions are the second most important part after the beginning. This is where you want to leave a lasting positive impact on the interviewer. You essentially wrap up your answer and try to show your positive outlook towards the entire situation as a whole. Both positive and negative situations pose a scope for learning and you should discuss it with the interviewer. While positive situations reinforce your faith in the right process, facing negative situations with the right mindset helps you grow as an engineer and as a person.
Important tips: