If you are part of a small engineering team, you’re more than likely going to end up interviewing another engineer at some point in your career. We all know that being an interviewee is a boondoggle of scheduling, phone screens, code tests, and communication breakdowns. What no one talks much about is that once you’re hired, you’re going to end up on the other side of the interview table, prepared or not.

Below are the top five mistakes I’ve made or encountered:

Mistake #1: Being unprepared

Look, it happens. Engineers are busy people, and interviewing isn’t part of our day-to-day. You will eventually find yourself neck-deep in a really big issue when you get reminded that you have to interview someone in ten minutes. Maybe you won’t even have looked at their resume or prepared at all.

However, if you’re often finding yourself in the situation where your manager or corporate recruiter is coming up to you with a resume and saying, “Can you talk to this candidate in the conference room?” that is an error condition you should address to help your company interview more efficiently.

If you are just busy and forgetful, create a backup plan. I personally have an interviewing notebook where I keep a technology-agnostic list of general challenges I deal with in my job as a front-end engineer (examples: “optimizing for page load time and performance” and “working with client-side templating engines”). If I’m interviewing another front-end engineer, I can ask about a time when he or she encountered one of those challenges, hoping the candidate segues into telling me about relevant past projects. It keeps the interview relevant to my expertise, and it’s a great way to get around asking awkward general questions like, “Tell me about a time you used a new technology to solve a problem.”

Mistake #2: Apologizing for being unprepared

Did you just get handed a candidate’s resume five minutes ago, right when you got out of a meeting? Do not go into that interview room and say, “Ugh, I’m sorry I’m so flustered, I just got out of a meeting and I haven’t read your resume yet.”

Think about what you are saying! This candidate is important; he or she has made it to the end of a long recruiting funnel. Don’t make this person feel unvalued.

It’s ok, I know you didn’t mean it. You’re just being honest, or maybe a bit shy. You really are flustered, and you need a minute to context-switch from the problem you were just working on.

But you’re an ambassador of your company, and it’s just as much your job to make your workplace look good as it is the candidate’s job to make him or herself look good. Put a smile on your face, grab a copy of the resume and a notebook, get in there and just start asking questions. “Tell me about yourself” will buy you about five minutes to read the resume.

Mistake #3: Asking bad technical questions

Every engineer has been asked ridiculous technical interview questions. Most of us have actually gotten jobs based on the strength of our abilities to do impractical things like generate palindromes or build poker-scoring algorithms. It’s fine to demand that candidates demonstrate technical excellence, but please…

• Don’t: ask a candidate to demonstrate technical mastery outside of the scope of the position. I had a friend who was asked a puzzle question that essentially had him deriving the Fourier series. It was a mobile developer position. Have mercy and don’t punish your fellow human beings like this.

• Don’t: ask puzzle questions. I don’t find candidates’ answers to them insightful at all; if you want to know if someone is qualified to write code, have them write some code.

• Don’t: ask the same questions you had to answer. Is this candidate interviewing for precisely the same job you interviewed for? It’s a noble goal to try and hire people who are as skilled as or better than you are, but be prepared for very few people to be able to answer your more esoteric questions. If your questions are drawing blanks, read on:

Mistake #4: Not revising your approach

It is in your best interest to ask one or two questions that absolutely any entry-level coder should be able to solve. We’re talking FizzBuzz-level easy; if you’re getting candidates that can’t solve FizzBuzz, go to someone further up the interviewing chain and complain, because someone is dropping the ball on determining if these candidates are qualified.

From there, I usually ask the candidate to build a very simple slideshow loop in Javascript (appropriate because I’m interviewing front-end engineers almost exclusively).

But I didn’t always do this; I used to start by asking candidates to calculate Fibonacci numbers (both iteratively and recursively, if they were doing well). I scrapped it for several reasons:

• Not everyone knows what the Fibonacci series is. This can add 10-15 minutes to the answer just so the candidate can make sure they’ve got the concept and the math down.

• I’m way more interested in a candidate’s ability to build something quickly in Javascript that works than in their ability to derive a Fibonacci algorithm. Too many candidates got bogged down in how to write out the algorithm and never got around to demonstrating that they were good front-end engineers.

So I changed my approach. If a candidate can hide and show images in a loop, I’m happy. We can move on to harder questions from there if the position calls for it. You have to be willing to identify where candidates get bogged down and really ask yourself if that question no one’s getting right is just a bad question.

Mistake #5: Handing the candidate off to one more interviewer

There comes a point in every interview where you don’t have much more to ask. If you’re very lucky, you have a clear idea of whether this candidate is a hire or a no-hire. Many times, though, you won’t be totally sure. You might like a second opinion. Now would be a good time to introduce the candidate to your coworker and have them do their own half-hour interview, right?

Unless there is a predetermined interview schedule, please do not do this. First of all, you perpetuate the cycle of handing yet another engineer a resume and shoving them into an interview room, where they will apologize to the candidate for being unprepared and ask them half of the same questions you just asked.

If there is no predetermined interview schedule, I encourage you to talk to your HR staff about setting one up before each interview. Less redundancy wastes less of your team’s time and less of the candidate’s time.

Now breathe. Even if you’re not an experienced interviewer, a little forethought and a focus on the job requirements should help you discover what you need to know about another engineer’s skills.

Bright Recruiter, Human Resources, Talent Acquisition, Workplace Methods