Sep

14

How to pick a Technical interview question

Filed Under teknolojia by  

September marks the end of Summer Intern season and the beginning of next year’s recruiting season. This is usually the time when recruiters would be sending schedules for on-campus visits. Its also a time when interviewers brush up on their skills and we train new interviewers. One of the questions I regularly get from new interviewers is “how do I pick the questions to ask?”.

My take on this is that the interview is an information transfer process. There is some information (how well the candidate would do on the job) that the candidate holds and the interaction is meant to discover this. There is a limited transfer window – as the interviewer you only get 1hr worth of data. You can influence how much of that data is signal (candidate could work well on the team) vs. noise (candidate was nervous or intimidated).

Preamble

The first step to maximizing signal transfer is to make sure that the candidate is comfortable. Interviews are stressful, and the candidate will be more nervous than they would be in their day-to-day job. Get them settled and as close to their “resting state” as possible. This is where you ask ice-breaker questions about what areas they find interesting, or projects that they have worked on in the past.

Main

The bulk of time in a technical interview is spent on the problem-solving session. It may involve asking the candidate to solve a coding challenge, a design challenge or a series of behavioral questions. I prefer to make this a collaborative process so that its clear to the candidate that they can ask questions and pitch alternatives, just as they would working with someone on the team.

The choice of question here is very important. For most engineers, I find the signals we want to extract are:

  1. Do they have a systematic problem-solving approach?
    1. Is the candidate actually able to describe a solution to the problem?
    2. Once they have an understanding in their mind, are they able to translate this into code?
    3. How do they react if they get stuck at some point?
    4. Do they think of how their code would be tested? Do they account for edge cases?
  2. How well do they understand the underlying mechanisms of computing?
    1. Do they have an understanding of computing fundamentals (data structures and algorithms, complexity theory)?
    2. Do they understand the trade-offs (e.g. time vs. space)?
    3. For more senior candidates, do they understand how the underlying runtime works?

The best way I’ve found to get these signals is to ask a problem which, based on the candidate’s profile, they can describe a solution in words within less than 5 minutes. That way we reserve the rest of the time on the actual coding, testing etc. For an intern candidate, you may ask “Given a tree, write a function to tell whether its balanced”. This is solvable on paper pretty easily, as long as they know the definition of “tree” and “balanced”. Translating that into code will exercise multiple skills.

You also want a question that is can be solved in multiple ways. The key is to avoid questions that have a “gotcha” moment where the candidate has to realize the ONE way of solving this. If they do not reach that realization in a few minutes, a significant portion of the interview is spent trying to guide them to that point.

For senior candidates, the ideal question has natural extension points. That way, if the candidate is able to solve the basic version of the problem, you can dig into the extension points.

Once you’ve identified a good question, you should re-use it for multiple candidates. This will help you calibrate how hard the problem is for candidates at various levels. It also helps you understand what areas candidates are likely to get stuck.

Comments

Comments are closed.