Note: This is an opinionated guide. While it is most effective for on-site, the same pattern can work with remote candidates.

How To Interview Engineers

Interviewing is hard. It's not easy to find good people, and once you do, it's often difficult to find out what they can do and how they work. A badly-run interview can pass over a great engineer. Conversely, some engineers are good at passing traditional tech interviews, but bring major problems with work habits or team fit.

The first priority of any manager is to hire the best people. Everything else must wait.

Screening

• Do phone screenings first. They help filter out people that don't fit, and save a lot of time and frustration.
• Always involve the team where the candidate will work, aim for a concencus from the whole team on a hire
• Spend the time to read each candidates CV and review their work in detail. Do your homework, involve the team.
• A bad CV can hide a good candidate, and a bad candidate might have a great-looking CV.

Interview Planning

• Candidates can tell when you did not prepare. Be prepared.
• Make people feel welcome and comfortable. Be very efficient and professional during every step of the process.
• Don't rely on puzzles, tricks, or trivia to judge engineers. Focus on problem solving, critical thinking, team and work skills.
• Avoid group interviews, they often are stressful and ineffective. Aim for one-on-ones in succession.
• On the interview day, don't discuss results until they leave. A hallway chit-chat might change a critical opinion, or throw the interview off.
• Keep track of all interviews with a clear system (shared folder, Google sheet, or an app), and keep everyone organized.

The Phone Screening

A phone screening might only need 10-20m, but can save hours of time for you and your team. Make sure the person doing the phone screen is technically competent, a good communicator, and experienced in interviewing.

Ask the candidate about things in their CV. What do they want to do in their carreer? What is their expectation of the job? Do they have a permit, need to relocate, or have special requirements? When are they available to start work? Ask some personal questions: interests, family, etc.

Ask them to explain some technical details about their skills and projects. Get opinions on why tech, libraries, protocols, databases, solutions. Consider some simple tech questions about code, but keep it general. Make them explain how they think stuff works, and ask for examples. If you let the candidate talk more, you will learn more. Don't do all the talking.

If the candidate passes the phone screening, have them send any additional info to help you prepare: sample work, github profile, past projects or links, etc.

Interview Day

• Try to find a date with the candidate, and immediately send a nice invitation by email.
• Plan the day with enough time for several interviews, including breaks, and time for chit-chat.
• Include a detailed schedule for the day, numbers to call, what to bring, address/map, what to wear, etc.
• Ask the candidate to bring their laptop and sample work (for remote interviews, screensharing can work)

If on the day of the interview, the candidate is clearly not working - a total asshole, or an obvious problem - just end the interview politely. Don't waste your team's time if it's clear you made a mistake.

The Pairing Sessions

Technical interviews benefit from a real, work-like environment. Don't use whiteboards, use computers. Don't give them silly puzzles or tech trivia questions, but realistic tasks (even simple ones!).

Have them show you a project they have been working on, and explain it with a code walk-through. Then ask them to change something, or add a small feature. How would they do it? Did the tests fail? How would they fix it?

If they didn't bring an appropriate project for this, ask them to create a small app or script to perform a simple task. Watch how they use their tools, editor, command-line. Can they type well, use shortcuts? What do they do when they are stuck? Google, Stack Overflow, talking through a problem? Do they ask useful questions? Can they focus on a task or do they get lost in the code? The best way to judge a developer is to observe them: see how they code and solve problems.

You can (and should) do more than one pairing interview. For instance, a frontend developer might have one session with a focus on javascript, and then another for HTML/CSS. A backend developer might write a simple REST API, or create a stream processing library. A mobile developer might be asked to boot a basic web container app, or modify an existing native interface.

Even if they don't finish a working, valid solution, that's ok. The goal is to see how they work.

The Planning Session

For this interview, a candidate is given a fictional product or feature to develop. They don't write any code here, but instead work with you to plan how it could be done. Identify the components, how would it work? Architecture, services, libraries, testing, etc. How would they approach the problem, and what about the users? What other resources or team members might be needed? Have them break down the steps that would be required to build it, test it, validate it. This helps give a view of how the candidate views end-to-end development, sprints, involving the user and UX, data, architecture and planning in general.

The Team Fit Session

This interview is about how to work effectively with a team. The questions cover things like code reviews, conflicts in implementation, opinions about documentation, sprints, standups and so on. It helps to give some sample scenarios, for example when one developer reverts the commits of another, or when there's two possible ways to solve a problem and it's not clear which solution is better. Tabs vs. spaces, handling operational emergencies, a team member who refuses to write tests. It can also be useful to talk about how to build team trust, events, eating lunch together, coaching, going to conferences, sharing ideas. Ask the candidate to tell stories about the best or worst team experiences, and what in their view makes a team successful.

The Wrap-Up

The candidates future boss should do the last interview, and ask for feedbak about the day, and how they think they did. This is a chance to talk about personal topics, concerns they have, questions about the job and company. Make sure they have a good understanding of what the position requires, the mission of the company, and try to judge how committed they are to the job. End the interview with a clear view of next steps, when they will be contacted, and in what time frame. Confirm salary expectations, starting date, and workplace requirements. Finally, thank them, be polite and personal. Make sure they leave with a good feeling about the company and the people, even if they don't get the job.

Homework

Depending on the position, it might make sense to ask the candidate to build something: a standalone app, service, web page, etc. This could happen before the interview (so it can be discussed and used), or after (as a way to help decide on skills). Give them a task that is not too big, something that can be done in a day. Offer to answer questions, or even change the task if they have a good idea or need to pivot. Set a clear deadline, and check in with the candidate if they are too quiet. Sometimes, people will run from a job when given this kind of task. Other times, they will over-achieve, maybe badly. When they are done, have them post the code (hopefully on Github or similar), and let the team review it as part of the process. I generally don't prefer giving candidates assignments, but I've seen it can work, and for full-stack developers or mobile engineers, it can really help to judge how they build things.

The Decision

Each interviewer should write down a short summary of how the candidate did, strengths and weaknesses. Then, the team comes together for a meeting in private. Up until this point, it's important that as little judgement and discussion has taken place. Honest and objective opionions are critical. Ask each member to read their feedback, and let others ask questions or challenge them. After all the input is voiced, ask the question: "Does anybody have objections to hiring this person?" If there are concerns, work them out. Let people try to challenge or convince each other. And hopefully, you can reach a concencus - that the whole team is comfortable with the decision to hire or move on.

If you're not sure, or something went wrong. Consider a second interview.

🔗 original gist - J.Seitz