I’ve done over 200 job interviews in just less than a decade, just as an interviewer.
I’ve used for all of them the STAR technique.
Here’s how that works, so you can ace your next interview.
An job interview typically includes two parts: a skill assessment, and a person assessment.
The skill assessment is where I try to figure out your actual technical chops. This will be something like a coding question or a systems design question or something like that. We’re not talking about this bit, today.
The person assessment is about your behaviours and your experiences. And how that all relates to the job.
Sometimes these questions come in the form of “how would you…”. For example, “how would you organize a project to maximise your chances of success?”, or “what do you think is the best way to complete your tasks under a tight timeline?”
This opens up the “book answer” for the candidate: “typical project management techniques are Agile, Waterfall, and Prince 2, depending on the constraints and the size and complexity of the project.”, “prioritization, and avoiding interruptions and context switching are important techniques to manage tasks under a tight timeline.”
All I learn here is that you have “read the book”: you have some theoretical knowledge related to the question asked. What I don’t learn is if you actually know how to prioritize tasks when everything seems important, or if you actually understand how to work in high ownership – high ambiguity Agile frameworks.
Don’t even get me started on the other type of “behavioural questions”: “what’s your biggest strength?”, “where do you see yourself in five years?”
So instead, the questions you’ll get will be about your own personal experiences: “Tell me about a time when you had to organize a critical project”, “Can you give me an example of a project you had to deliver on a tight timeline?”
This forces you to look into your experiences and can start a deeper conversation about your own behaviours in the real world.
Here’s what we’re looking for as interviewers, and how you can structure your answer so it’s super smooth and you look like the slick professional you are.
It boils down to telling me a story. Stories are great, and humans love them and parse them easily at many levels of meaning.
Start with setting the stage. We call that the Situation.
You don’t need to give me the whole history of the company, and how you acquired that specific customer, and who was the technical point of contact, and what they always had for lunch.
Instead, give me the pain. What was the issue? What problem you had to solve?
So now we have the situation you were in. You then move to the thing you had to do: the Task. This is the activity you had to complete to solve your “situation”.
What’s the “solution” to the “problem”?
You’re doing great so far. Let’s get into details. What Actions did you actually have to perform to complete the Task?
And finally, what was the outcome? After all those Actions to complete the Task to solve the Situation, were you successful? Were you not? What did you learn? How did it go? What was the Result?
There, that’s a cool story you wrapped up there. And you did it by giving me Situation, Task, Actions, and Result. In short, STAR.
Let’s have an example, Mr. Wile E. Coyote!
“Tell me about a time when you had to organize a critical project”
Situation: When I was working at ACME ltd., I was part of the Roadrunner Hunting technology development. A critical customer asked for a special paint that could look like a train tunnel when used on a rock wall. We didn’t have anything like it.
Task: I discussed with management about the priority and feasibility of the project, and we decided we would give it a try. I was assigned to the job as lead, with a junior “CSE” (that’s a Cartoon Science Engineer). We were given one month to develop a prototype to test in production for the select customer.
Actions: We approached the project in an iterative way, first brainstorming potential approaches. We considered both Vanta black as a potential “off-the-shelf solution”, as well as building it in house.
We decided we could raise the bar on “tunnel looking paint”, and organized in fast daily iterations where we would report to each other advancements on ideas we tested, dropping options that didn’t work, and iterating on the work that was more promising.
After two weeks, we found three potential options and changed gears to work in refining those. We wrote a document describing the approaches, and got consensus with leadership and the Principal Paint Engineer on the options. At that point we also proposed that one of the options was the preferred approach.
Once we incorporated the feedback, and reached consensus, we went on to implement the solution. We found that we could use quantum tunneling black to make train tunneling black. The advantage of that is that a fake tunnel painted with our paint would occasionally transform through quantum tunneling, in an actual train tunnel, adding to the realism.
We produced the prototype paint bucket with less than a week of delay on the original commitment.
Result: The test was successful, as the paint made a completely realistic tunnel. The tunnel flipped back and forth between being a black spot on a rock and being an actual tunnel. The TC (tester coyote) was even hit by a steam train, creating comic relief, which is a key business metric we maximise. The paint is now in production, and many customers successfully build train tunnels.
Let me know if you use this technique at all, or if you’re working on quantum train tunnels for road runner hunting.