So you have an interview with your potential new manager, or the company CTO, how do you efficiently share what you have accomplished with impact and clarity?
Interviews can be fun. Or not. Being prepared is immensely helpful and the most effective way is to Know Your Stuff.
I don’t mean “Know your programming language” or “know your technical domain” I mean, “Know what you have done in the past and how it is relevant to the job you are interviewing for.”
Just like a good biographer, you have to study your past and be able to talk about your skills as a story.
Now this is not really anything new — in fact there is a method that’s been around for a long time that helps you structure you skills and project accomplishments with a little bit of a story arc:
It’s called S.T.A.R. and it is an acronym mnemonic to help you remember how to assemble a meaningful response to an interviewer’s question:
SITUATION
What was going on, where were you, what was the company up to? What sequence of events led to the start of the story that involves YOU:
TASKS
You may have been a cog in a bigger machine, and you had specific responsibilities within the bigger SITUATION you just outlined. What was your part in the play, your title and what assignment you were given (or what assignment you took!)
ACTIONS
Under the authority of your TASKS in the SITUATION, what actions (verbs like I did, managed, brokered, designed, implemented etc) did you take to complete your TASKS and achieve and goals that those tasks were designed to get you to
RESULTS
Did it work? Did it put out the fire? Did the goals get achieved? Was something new discovered? Were some illusions dispelled? Did you get promoted or level up in some way? How was the SITUATION and YOU different after the events of this STAR story?
But S.T.A.R. is not really technically minded enough for software interviews or engineering interviews, so I’ve come up with another Mnemonic to help out: E.N.I.M.
EXISTING ARCHITECTURE
What was already there? What were its shortcomings and strengths? For example: Our existing REST API did not have granular enough endpoints to query our new data structure.
NEW ARCHITECTURE
How did you decide to adapt the existing architecture to meet new requirements?
IMPLEMENTATION
Who did you work with, what tools did you use? How did you organize the work?
MONITORING
How did you make sure in an objective way that the new functionality met requirements? Anything from unit tests to dashboards and logging.
Technical interviews really benefit from some block diagrams, process flow diagrams, any sort of diagram really. When dealing with architecture, structures and processes, it helps to lay out things as physical boxes and arrows of data flow. Be ready to draw and even have diagrams on hand for each project you contributed to.
So that’s it. If you are doing a technical interview, think ENIM, not just S.T.A.R.
Top comments (0)