Interviewing engineering candidates is hard. It takes a lot of practice to get comfortable with it. Moreover, interviewing is a necessary skill for your career as an engineer. You have a limited amount of time and there are many questions you can ask.

Read on to learn how to manage your time, and think about good interview questions and coding challenges.

Preparation

For many years I was usually as nervous as the candidate I was interviewing. A couple of years ago my manager gave our team training before a series of upcoming interviews. He gave us advice on how to prepare for the interview and how to manage our time. In this post, I’ll share the advice from my manager and a few of my insights from interviewing other engineers.

I cannot stress this enough, prepare for the interview in advance. Review their resume and formalize your questions in writing, a day or two before the interview. You never know when you might be called to deal with some urgent matter or a critical bug. It could happen right before the interview leaving you no time to prepare. This event has happened to me — it’s a bummer.

The hiring manager should inform the team on the role we want to fill and what skills each interviewer is evaluating.  Each interviewer should focus on a different skill set: back-end, front-end, communication, etc. This separation gives the team a broad understanding of the candidate’s skills. If this is not clear the day before the interview, contact the hiring manager for guidance.

Time Management

Your primary goal is to walk out of the interview with a clear decision on whether to hire the candidate or not. It’s that simple. Don’t feel bad about judging them, that’s the deal here, everyone understands this. Budget time to prepare for each interview in advance. During the interview, do your best to keep on eye on the clock and stay on schedule.

Here is how I set the agenda for a 45-minute interview:

1. I introduce myself and offer them a bio-break (i.e., bathroom, water, coffee). You want the candidate to feel comfortable, so they perform their best. Maybe they had a tough coding challenge with the previous interviewer or hit bad traffic getting in. Give them the opportunity to regroup before diving in.
2. I give a brief overview of my role, the team, what we do and how we operate. I spend about 5 minutes on this. Sometimes questions come up which lead to further discussions, that’s ok, but keep an eye on the time. You may need to cut it short and move on.
3. I ask specific questions about their resume. These 15-20 minutes are crucial to evaluating the candidate. We’ll discuss this more below.
4. I give them a coding challenge. Another 15-20 minutes. This step likewise is critical.  We’ll discuss good coding challenges below.
5. I close with a Q/A session. About 5 minutes on this depending on how much time we have. This period gives them an opportunity to ask any follow-up questions. Be sincere and honest with your answers. This is also about making sure the job is a good fit for them.
6. End on a positive note. Introduce them to the next interviewer or escort them out.  They are your guest, treat them as such.

It’s not easy making this evaluation. You have a lot to cover in a short period. Keep an eye on the clock, stay on task and get good at politely interrupting. Sometimes we get caught up in a conversation, but it’s essential to cover all the bases.

The main things I’m looking to walk out of that room with are:

• Does this person have programming skills?
• Are they curious and can they learn?
• Can they communicate effectively?

Resume Questions

Read through their entire resume —it contains nuggets of information. Find a few items that are interesting or relevant to the job and write down questions that allow you to assess the candidate’s skills in this area.  Be specific: “Explain how you used Technology X to connect these two applications?”  Don’t be vague: “Tell me about your time at Company Foo?” Specific questions allow you to get into the details and gain insight into their understanding. Ask follow-up questions if necessary to assess their skill.

If there is anything on their resume that doesn’t seem quite right, make a note of it and ask them. For example, they have a bullet point saying a project took 2 years to ship. But you notice they were only at the company for 9 months. Ask them about it; often there is a simple explanation.

I always print out a copy of their resume and write directly on it, ideally in a red Sharpie. I circle key words, put question marks or write notes in the margins. In the end, it looks like a graded homework assignment my kids bring home from school. I bring this marked-up resume into the interview and keep it in front of me so I can refer to it as we talk. It’s ok if they see it, I want this to be an open dialog.

I do bring a laptop into the interview for the programming challenge, but I keep it closed most of the time. I intend to speak directly at the candidate and do my best to listen.

Coding Challenge

The candidate is interviewing for an engineering position: writing code is a must-have skill. They should write code on a laptop or diagram software architecture on a whiteboard. The format is up to you, but they need to be able to demonstrate this skill. Coming up with good coding challenges can be stressful, but try not to worry about it too much. The challenge doesn’t have to be super complex. It shouldn’t be. It also doesn’t need to be as trivial as FizzBuzz. Your goal is to make sure they can think through a problem and write sensible code to solve it.  Do your best to come up with a good challenge. After the interview re-evaluate how effective it was in measuring their skills.

Good coding challenges:

• Are easy to set up and explain. The goal is to get them coding, problem-solving and talking through their solution. If you’re doing most of the talking, you need to simplify your challenge.
• Lead to good conversations. These could be discussions about different possible solutions, architectural choices, or performance optimizations.
• Relate to the work they would do if they get the job.
• Ideally, start simple, you can always expand if the candidate completes the basics.

Focus on a real task, related to your team’s actual work, as best you can. I’ve even taken code snippets out of our repository, stripped it down and asked the candidate to extend it to add some new functionality. Most candidates appreciate a real-world example. It gives them further insight into the work they could expect if hired.

Here is an example question I’ve given in the past:

“Our team needs to build a new back-end for storing user account information for people signing up on our platform. Tell me what information you would collect from each user and how you would store it in the database.”

Several questions come up during this exercise:

• What data types do we store different fields as?
• Do we store first and last names as separate columns?
• What character length limits do we choose?
• How do we validate fields?
• Will this work for international users?

There are many design decisions required to implement the code. A data model and a 20-minute conversation gives me valuable insight into their engineering skills.

Have a few interview questions prepared and tailored to each candidate’s skill set. I generally evaluate back-end programming skills, so I have SQL, Python, and some data modeling challenges. When reading their resume, I determine which is most appropriate based on their experience and skills.

Don’t be afraid to let them write code in a language they know better than you. This gives you an opportunity to ask detailed questions and evaluate their understanding of the language. Communication is an essential skill in any job, this is an excellent way to evaluate that skill.

Be prepared to throw away your programming challenge after using it for a while. Experiment, try different questions and different approaches.

Soft Skills

Pay attention to soft skills too. Don’t just focus on problem-solving skills. Are they able to answer your questions sufficiently? Can they explain a complicated topic? Do they ask good follow-up questions? Do they have experience or skills they can teach you? The best teams are ones where every individual brings some expertise to the group.

Legal Stuff

Don’t ask questions about their personal life; these topics can get into a legal no-go zone. If they bring it up, it’s ok, but direct the conversation back to the purpose of the interview. For example, I have kids, on a few occasions this has come up in the interview. Once a candidate was late due to an issue with their child that morning. We exchanged a few words about the challenges of raising kids and having a career, standard small-talk from two people with something in common.  However, then I moved the discussion back to the interview. Again, they are your guest, be polite, be sincere, but also be professional and keep on task.

After the Interview

As soon as possible, write up your thoughts while the experience is still fresh. I find it difficult to be both an active listener and a good note taker, so I rarely take any notes during the interview. After the interview, I open up Vim (I said I was a back-end engineer) and do a complete brain dump. I don’t worry about spelling or complete sentences. I’m concerned with capturing my thoughts. Later that afternoon or the following day, I formalize these notes into Lever for feedback to the hiring manager.

Attend the interview debriefing with your team, if you have them. You will learn something from your peers, questions they asked you didn’t think of or observations they made you didn’t notice.  This meeting is a great opportunity to learn from your coworkers and refine your interviewing skills.

In Closing

Do your homework, prepare in advance and keep on task during the interview. Each interview is a learning experience, re-evaluate after each one and adjust your process. Also, remember to have fun with it and enjoy meeting new people!

I’d love to hear your experience with interviewing fellow engineers. How do you balance your time during the interview? What kind of programming challenges to you find most informative?  Let me know in the comments below or reach out to me at @tophburns on Twitter.

Thanks to Nick Popoff for his interview training and to Sahar Bala for all her feedback on this post. And special thanks to Marcos Iglesias for all his work on our engineering blog.