My Technical Interview Process
I don’t really do technical interviews anymore, I am lucky to be able to rely on a great VP of engineering and team that take care of the process. I still meet with the candidates but I do that more as a way for us to get to know each other and to answer their questions from both a CTO and founder.
I took some time to write down my thought process when interviewing candidates. Of course, the process changes based on the candidate, position and how the interview goes, but this is a decent albeit generic break down of how I’m approaching the experience. You should also take a look at this great document talking about how to prepare to interview technical candidates. This was a good exercise for me, forcing me to be explicit about my thought process during the short amount of time I meet with a candidate. It was also a great way to share with the team the kind of expectations I have about interviews.
Initial technical question
Please describe the lifecycle of a web request going from the browser back to the browser.
Expect the candidate to understand what a web request is, the concepts of DNS, ips, web server/app dispatch. Often candidates with less experience see the web app as a black box and can’t really explain routing and template/response rendering as well as returned responses.
Pay attention to the level at which the candidate starts, based on that, ask them to go deeper or shallower and see how comfortable they can explain technical concepts. Don’t try to trick them, but listen to the vocabulary they use as well as their comfort level. Do they go in the nitty gritty details of what happens inside the trackpad when pressure is detected or do they skip entirely the request processing when it hits an application server.
Follow up technical question
Let’s pretend our web app is now getting a lot of traffic, how can we handle more loads, ideally without increasing cost?
Expect the candidate to **** understand the concepts of caching and load balancing.
Make sure to bring up HTTP caching and make them explain how it works, if they worked with it, dig a little around status codes etc.. Bonus points if they understand and can explain pro/cons of HTTP/2. If they bring up technologies such as memcached, varnish, squid or other caching solutions, ask them about pros/cons.
Pay attention to how they react when they get to a place they don’t know. For instance don’t hesitate to ask about HTTP/2 push and how the headers are different than HTTP 1.1 or if they know that, ask about DNS load balancing or whatever they might not know. Check if the candidate is defensive or interested in learning during the interview. Do they feel bad or curious. Don’t push too hard but get a sense of how you might interact with them when they are faced to something they don’t know yet. After all, the goal is for the candidate to become your coworker.
Getting a glimpse of the candidate technical world view
What’s the hardest technical problem you ever solved? Why was it so hard, what did you learn?
No specific expectations, listen and try to understand how the candidate shares a hard moment and talk about something you have little context about. As a few questions to see how they respond to you digging a little in a potentially hard memory. Imagine you are sitting with this candidate in a post-mortem. Is their answer helping the team move forward?
Pay attention to see if they bring up a hard technical problem or a difficult to debug situation. Can they explain in depth what the problem was, did they learn anything? Think about the role you are hiring for and how you’d be expected to answer the same question.
Getting a glimpse of the candidate generic world view
What’s the hardest non-technical problem you ever solved that you’d be comfortable sharing?
No specific expectations, listen to the problem the candidate is bringing up to your attention. Do they over communicate or under communicate. Do they pick a problem that is easy to talk about or a problem that is unique? Be sensitive that the candidate might not want to share and that’s totally ok. In that case, diffuse by asking how they dealt with the first time they got stuck learning programming. Make sure the candidate understands that this isn’t about any kind of personal problems, but more of a generic non-technical situation and how the solution was debugged/solved.
Pay attention to the maturity of the candidate. Do they have an optimistic or a pessimistic worldview, do they spend more time talking about the problem or the solution. Are they humble or show offs?
Cocky candidate special question
Come up with a question that you don’t expect the candidate to know the answer. Maybe something not related to tech such as the mother sauces, the capital of Mali or the country of Georgia.
Expectation here is to ask a question that confuses the candidate because it’s poorly asked and not on topic (about food, geography, anything not technology). An arrogant candidate will probably make things up instead of admitting they don’t know. A humble candidate will admit they don’t understand or are surprised by the question, or even better they might admit they don’t know the answer. Don’t aim to make the candidate feel bad, just find a way to get passed their attitude. Be supportive.
Pay attention to see if the candidate is asking for an answer or wait for you to move on. If the candidate doesn’t ask for the answer, volunteer the answer so they can see it was a bit of a trick question.
Shy candidate special question
Besides programming, do you have any passions? Maybe sport, music, craft, TV/movies, games? Can you please share your passion with me?
Expected behavior is that the shy candidate should be able to find a way to communicate why and how they consume their passion.
Pay attention to not cutting them off, spend more time listening. Ask questions if they seem to be stuck. Make sure they see you are interested in what they are sharing.
Going deeper on the technical level of the candidate
I like to take concrete examples of problems we actually encountered. Depending on the position we are hiring for, I pick a different problem we already solved and present the situation to the candidate and ask them to talk it through with me.
It’s important to note that I ask our candidates to do a technical exercise on their own as a first step. The exercise is meant as base to discuss technical topics and approaches, not to really evaluate the solution provided by the candidate. So at this point of the interview, I should have amore or less good understanding of their skillset. That said, sometimes a candidate can totally miss the point of the exercise or just have had a bad day. That’s why I have this optional step to see how deep they can go while being comfortable and where their safe technical zone is at.
Conclusion
There aren’t any magical recipes for a good technical interview. As an interviewer, you should certainly be well prepared and your team and you must have defined the kind of profile you are interested in hiring for. Too often, the interviewer is looking for a candidate matching their interests and values. They are looking for a clone and that’s usually a bad idea. Sharing the same philosophy around how to tackle technical problems is critical but you also want diverse skillsets and perspectives. Having a discussion with your team about why you think the candidate will do well and what kind of assistance they will need should also really help you make a decision quickly.