July 15, 2014 • 3 min read
I recently had the chance to give a technical interview. I’d like to document how I set up the interview. These steps are mostly directed at hiring a junior or mid-level developer.
Technical interviews are an important stage in the hiring process. For the candidate, it’s your chance to show your skills and converse with your future coworkers. For the company, it’s your best shot to determine a fit.
I actually enjoyed going through this process myself as a candidate. Having come from a non-technical background, it’s refreshing to be evaluated objectively (as much as any interview can be objective) on my skills and knowledge. I either have the skills and answers they want, or I don’t. I find it low-pressure compared to an interview for, say, a management position.
After reading Jeff Atwood’s great post How to Hire a Programmer, I decided to structure my technical interview to be:
After ‘breaking the ice’ to make us both comfortable, we got started.
I love the whiteboard. It reveals much about a person, from how they work under pressure to their ability to explain an abstract idea.
I asked the candidate to use the language she felt most comfortable with, with a preference for Ruby. She chose Ruby and worked through the problem on the board. When finished, we walked together through each iteration of the method with her in the lead, explaining, and me asking questions.
I had three or four questions prepared in a couple of different subject areas. I like to ask a broad question, take notes, and then ask any follow-up questions that come to mind. It’s much more fun to have a discussion.
The first subject area was Rails. A sample question: What are the strengths and weaknesses of the Rails platform, and of the Ruby language? If you are a newer programmer and mention ‘convention over configuration’, as this candidate did, you get points from me.
The second subject area was Object Oriented Programming (OOP). A sample question: What is the difference between a class and module? In the future I’d like to work this into a series of questions where the candidate explains the different components of Ruby (classes, modules, methods, instantiated objects, etc.) as physical objects.
The third subject area was Testing. A sample question: Do you use TDD? Why or why not? This can reveal a lot about how the candidate works.
The fourth area was General Programming. Anything relevant is fair game here. I want to know what the candidate thinks about working at a small startup. Will they thrive in the uncertainty? Have they developed self-reliance and a strong professional voice? What do they think about the current debates going on within our field?
At the end, I open up for questions. Having any questions at all is an essential indicator of mutual interest for me. Provided those questions show interest and a basic understanding of what we do, and I can answer them, then this phase is successful.
Hiring is all about information. You can’t eliminate risk, and the more information you have, the less risk you take. With that in mind I plan to A/B test my interviewing style over the next few months. What questions yield the best information? Those are the questions I want to ask.
Each week, I write an email about React. It's a collection of quotes, news, conference talks, and documentation curated be me to help you get up to speed on this exploding ecosystem. Join my subscribers today by subscribing to React Explained.