Most (tech) interviews are conducted using Behavioural Questions. These questions are used to explore your work experience and determine your ability to be successful at the role you're interviewing for. While they can be used to filter out exaggerated claims and other red flags, they are also useful to highlight potential areas for growth if you were to join the company. This clarifies to the hiring manager what potential a candidate has for long term hire, and this will also inform the compensation decision.
It's easy to bomb these questions if you haven't thought of their purpose before. The best indicator for future performance is past performance (note: not a guarantee, but an indicator). Interviewers need data to make those determinations, and this technique is a reliable mechanism to collect it. In most companies, the results of the behavioural interview are added to technical screening data in a "de-briefing" session, in which stakeholders make the hiring decision.
- Tell me about (a time when)...
- Give me an example of (a situation)...
- Can you share (an experience of)...
- How do you (action, e.g handle a problem) when (situation)...
... And as you answer each of these, the interviewers usually follow up with clarifying short questions, digging down into an aspect of your example or story, until satisfied. If you've seen this pattern before, you likely faced behavioural questions.
Can you tell me about a time you were facing a difficult deadline in a project?
- When did you first talk to your leadership about the problems?
- What actions did you take?
- Were you able to finish on time?
- Was the launch successful (irrespective of meeting the date)?
Can you describe an example of you disagreeing with your manager, or a co-worker? What was it about? What happened after that?
- How did you solve the disagreement?
- Did you agree with the end result? Why, or why not?
Can you tell me about a time you delivered a project against all odds?
- Why was the project at risk?
- What was the outcome, from a customer perspective?
- Did you have any help from colleagues?
And so on. You get the idea.
With honesty. That's the key part - draw examples from past experience. Often, people improvise (when not straight lying) to deliver an answer they believe makes them look good. Do not do this. Experienced interviewers are skilled in picking up your exaggerations; They are themselves experienced professionals, having delivered multiple real-world problems. They can tell when you're polishing your story.
Instead, understand that companies are not looking for "perfect examples" but realistic ones. Be honest about your own shortcomings, focusing on what you learned and what you'd do differently with your newly-gained knowledge. Absolutely highlight your accomplishments and talk about how you are raising the bar in different aspects of your work, but do so by making claims accompanied with data. Companies want to see that you have consistent positive behaviour at work, and an ability to learn and develop new skills as you progress in your career.
Let's look at an example:
At Amazon on 2020, my team was tasked with delivering a new feature on the payment service; By Q4, we should accept a new payment method, with complete integration with reconciliation and fraud services. I was tasked with integration to the fraud services. My first challenge was in consuming their APIs without incurring into throttling limits and other non-functional concerns; We expected a high throughput due to ramped up adoption of the new payment method, and had to provision capacity to adequately handle customer traffic. I conducted weekly sync ups with Frauds team to, at first, clarify our requirements, and then track deliverables on their end to ensure our launch could happen on time and without issues. I had to escalate two issues to principal engineers in order to resolve minor technical conflicts, but otherwise the reviews happened on time and on schedule. The project was launched in October 2020, on time, and adoption of the new payment method was 7% above expectations. Despite this, our capacity planning ensured that we did not incur into throttling issues, leading to a 5% below average number of incidents, compared to other popular payment methods.
Why is this an acceptable answer?
I strongly favour the SBI method: Situation, Behaviour, Impact. It is also commonly known as STAR (Situation, Task, Action, Results). It's a technique to answer behavioural questions. It offers a simple structure that is easy to remember and works for the majority of questions you may be asked. It consists of the following:
- A "situation" block, which describes the context necessary to understand your actions;
- A description of the actions you've taken, or your "behaviour", within that context, enabling the results of the project;
- The "impact" of your actions to the project, and its end results.
With that in mind, let's review that answer:
At Amazon on 2020, my team was tasked with delivering a new feature on the payment service; By Q4, we should accept a new payment method, with complete integration with reconciliation and fraud services.
This is our situation. The reader understands the importance and scale of the project we were assigned to.
I was tasked with integration to the fraud services. My first challenge was in consuming their APIs without incurring into throttling limits and other non-functional concerns; We expected a high throughput due to ramped up adoption of the new payment method, and had to provision capacity to adequately handle customer traffic.
This is also part of the setup. Here, we are outlining our own responsibilities in the project. Everyone wants to be a team player, and that's a great thing. In an interview, however, we're interested about you. What was your role at this project?
I conducted weekly sync ups with Frauds team to, at first, clarify our requirements, and then track deliverables on their end to ensure our launch could happen on time and without issues. I had to escalate two issues to principal engineers in order to resolve minor technical conflicts, but otherwise the reviews happened on time and on schedule.
And here we have our actions, demonstrating our behaviour. The decisions you have made, the difference you have made in the project. You can outline what is considered "common sense", but you also want to make sure they hear about what you did that is "above and beyond" what you'd fairly expect for your role. Remember, you're selling your skills here, so be a good salesperson!
The project was launched in October 2020, on time, and adoption of the new payment method was 7% above expectations. Despite this, our capacity planning ensured that we did not incur into throttling issues, leading to a 5% below average number of incidents, compared to other popular payment methods.
And here we talk about results, showing data. It's not enough to say "and we were happily ever after", you need to demonstrate how success was measured and why and how you've reached this conclusion.
- Study your resumé, reviewing your work experience for examples
- Consider other sources as well: community work, other things you do outside of 9-5 work
- Practice behavioural interviewing on both sides if you can
- Learn about metrics and how to outline data in a narrative
- Avoid unnecessary words that don't add quality to your narrative: E.g "The project was delivered quickly" instead of "The project was delivered on time".
Inconsistent narrative
Your answer should read like someone "describing the room" if you couldn't see it. You should be consistent in the use of passive or active narrative (e.g don't switch back and forth between 1st and 3rd person). Ideally, you adopt a neutral but light tone - it's OK to show enthusiam when you talk about how "things went well", just don't overdo it; And on the other end of the spectrum, try not to sound lifeless or "robotic", as if reading from a prompt. I like to pretend that I'm just having coffee with a friend and we're talking about work, or that I'm being interviewed at a TV show. Another way to put it is, if you were to write your answer down, it would read a little like an article on a magazine - a balance between a "report" and a "conversation" with the reader.
Be concise
Do more with less. For example:
"We achieved outstanding results with a motivated team, leading to a successful launch"
This is a drag to say and even worse to hear. It's also vague, subjective to interpretation (are results really outstanding? was the team really motivated?). Instead, prefer:
"The project was launched by X with Y impact."
Ditch the poetry. We are looking for direct answers higlighting important facts.
I love this Mark Twain's quote:
"I didn't have time to write a short letter, so I wrote a long one instead."
The takeaway here is that it's hard to be concise, but the effort pays off.
Vocabulary
Avoid repetition, buzz words, stuttering ("like... Uh... Like... So..."). Avoid complicated technical statements and jargon, unless strictly necessary. Your answer should be readable by anyone with basic background in your domain. You can introduce some explanation to your answer, when you can safely assume the reader is unfamiliar with the technical domain; But even then, remember the rule about being concise.
Categorize your examples
You are going to be asked questions on multiple topics: your (technical) competencies, your ability to work "under pression", to handle conflicts, to advise managers and upper leadership, to mentor younger peers, and so on. Have examples ready for different "categories" like this. One useful hint: certain companies (like Amazon) have guiding principles (Amazon has Leadership Principles) that outline the culture they hope to foster. These are usually available online for further reference, and are a great way to categorize your examples.