Confession time: I used to quiz people on FizzBuzz on their job interview when I started interviewing people for my own company five years ago. I no longer do that—instead, I try to create an environment where people can strive and show their best: on production code, on their machine, with me navigating.
Last year marked the first year since 2014 I did technical interviews again. When the CTO approached me and asked me to do the technical interviews for the front-end team, I was excited to pick the topic up again after such a long time.
With the interviews quickly approaching, I reflected on the interviews I have been to in the past as an interviewee, sitting on the other side of the table, being nervous, excited, very insecure or - on other occasions - at peak-Dunning-Kruger. With the CTO’s permission, I tried to create an interview process that mitigates all of the above.
Opening a can of worms
After the first interview I conducted that year, which ultimately lead to hiring the first permanently-employed front-end developer at that client 🎉, I started drafting this post summarizing my ideas back then.
Armed with lots of feedback from Benjamin, Samir, Sandro and the people who joined my session at SoCraTes 2017, it quickly grew from laying out the process of Pair Programming in interviews to a more exhaustive explanation of how I’m conducting interviews.
In the meantime, Benjamin and I recorded the first episode of his podcast, CTO.coffee, where we talked about Hiring & Interviewing in general and how to approach the interview from a more compassionate perspective.
My interviewing process
The result is a two-part series about how I conduct technical interviews, each covering a different phase of the whole process.
The first post covers all the decisions that have to be made before having someone over for a technical interview: What role are we actually looking for? Do we have enough capacity for mentoring someone intensively? What are the expectations of everyone involved?
It further covers picking an exercise, writing the invitation and establishes the mood I want to set in an interview.
Part two covers the day of the interview. Starting with setting your priorities and getting into the right mindset, I’m walking you through the way I do technical interviews. I’m explaining my role in the day, my obligations and the things to look out for. We’re talking about the importance of understanding power balances, unconscious bias and the necessity for timeboxing.
Thank you @benjamin for your invaluable feedback on my ideas, the chance to record the first CTO.coffee episode on Hiring & Interviewing and for being the first person to show me how a good hiring process can look like.
Furthermore, thank you Markus and Jean-Louis, for trusting me in allowing me to try out the methods I’m laying out in these blog posts in your companies.
Finally, thank you @samirtalwar for proofreading all of this 🤗.
If you want me to bring this process to your company, send me a mail at email@example.com so we can talk about the specifics over a coffee or via video chat.
📖 Further Readings
- @benjamin’s excellent feedback on an early draft of this article. 💗
- @catehstn’s amazing blog Accidentally in Code, in particular:
- How I interview
- 12 challenging steps to being a better interviewer, especially the section on Understanding Bias
- The Medium Hiring Guide for interviewers
- The session result from one of my sessions at SoCraTes 2017 about Pair Programming Interviews