Let’s take a step back: why are we interviewing? To hire someone good at building working software in our team.

The interview process, then, should be precise, intently focused on hiring people who can build software, and not hiring people who can’t. And it should be fast: to save our team’s time, and to hire them before anyone else does. 

That’s it, really. Hire good candidates with a reasonable precision / time ratio.

If this sounds trivial, then why do some interviewers seem to take delight in making the process as difficult as possible?

Some interviewers aren’t well prepared, asking seemingly random questions, questions that a glance at your resume would answer, or technical questions that even solid developers would likely Google the answer to anyway.

Others don’t help a struggling candidate as they would a struggling teammate, and seem to intentionally make the hiring process unnecessarily cumbersome — scheduling  four or more interviews where one would suffice, or conducting large group interviews that are largely ineffective.

In these situations, interviewers have lost sight of the goal to be achieved behind the ritual. In this article, I go over the major sources of my frustration with interviews, and share some advice for improving your interviews.

1. Looking to teach or preach, not to learn

You can’t do much worse when interviewing than adopt a “me smart — you stupid” mentality. Sure, feeling smart is nice. The interviewer has all the answers, while the candidate doesn’t. It’s tempting, in such a power dynamic, to show off. 

This approach obviously misses the whole point of interviewing. We’re trying to learn from that person, so that we can decide whether to hire them. Grandstanding doesn’t help us achieve that objective.

I also call these interviews exam-like. To pass, you need to give a correct answer to each question, so the interviewer can check off a list. Not a good model for an exam either, but it’s what many of us grew up with. Anyways, an interview is certainly not an exam. The examiner is much more knowledgeable than the student, which is often not true for interviews (especially not middle / senior-level ones). Most exams cover specific known topics, while strict developer curricula don’t exist. Finally, while both exams and interviews can be a selection mechanism, exams have an extra goal of giving the student an objective overview of his abilities. You see, different things.

Interviewers would do best to never assume they are smarter or somehow better than the candidate. But this is just the first step away from exam-like interviews.

2. Focusing on hearing the right answers, rather than on asking the right questions.

A common feature of exam-like interviews is the checklist approach. The interviewer asks the question, the candidate answers, we up the score if the answer fits, and move on. 

The questions therefore tend to be very closed, to facilitate checking correctness, and the difficulty level is tuned by choosing more esoteric topics: a junior JS developer tells about let vs const, while the senior developer discusses… the event loop.

Real software development is rarely about quickly answering very specific questions. In fact, “how to check browser support for server-sent events” is the most minute detail usually fixed by Googling at the final stage of problem-solving. What is it about, then? Many things:

• Brainstorming possible approaches
• Decomposing a task into bite-sized subtasks
• Iterating on the idea to find weak points
• Collaborating with teammates

And I haven’t even touched the actual coding yet. Not saying code interviews are worthless, but you get more bang for your buck, and test several skills at once, by focusing on assessing the problem solving rather than finding the right answer to what might be the wrong question in the first place.

Problem solving naturally favors more open-ended questions like “design a slider gallery,” over “what touch events exist,” because they have more process, and thus, avoid most of the pitfalls I described in my earlier article on bad interview questions.

One caveat: answer-centric questions do work well for screenings. A non-technical recruiter can ask a few simple questions, like, “What are some React hooks?” All I have to do is say“useRef, useMemo, useEffect”, and we know I’m qualified. 

3. Not giving any hints

The final problem with “exam-like” interviews is leaving the candidate alone with the problem, and not helping where it’s due. The thinking is that a senior-level developer must know this, and if they don’t, then obviously they aren’t qualified. But again, that’s not how development works.

Do you immediately fire or report your teammate who misses a corner case, has room for improvement, or is completely lost? Hopefully not. Collaboration is a key development skill. 

Why, then, should the interview be any different? Sure, it’s best to plan for edge cases in advance, and acceptable to identify them yourself and iterate. But it’s also the sign of a good teammate (and candidate) if they can make a mistake, admit it, and recover from it.

4. Poor planning

I suspect that most interviewers drop into interviews with just a few minutes of preparation, without a true question list, and end up only making one after quickly searching “best lists of interview questions” online. I suspect this because I’ve done it myself (and I’m sorry…planning really does make a difference!). 

Ideally, you want to use your questions to cover several topics related to the role. In a front-end interview, these are probably related to JS/TS, CSS, and some React (or whatever you use) / algo / deployment / performance. 

One can improve their interviewing by asking a few closed questions, followed by an open one, and then a full-on software design task. 

Locking yourself into a very strict script is no better than having no plan at all. If the question sparks some interesting discussion, don’t end it prematurely just to ask more low-level stuff. If you were looking for a senior developer, but happen to have a good junior before you, you’d better adapt — a good junior is still useful and often hard to come by. If the candidate tells you they have never worked on performance optimization, there’s no use asking in-depth about TTI measurement. Open-ended tasks give you more flexibility in all these cases than “senior-only” questions.

Timing is not as important as you think. Finishing early is fine — whether the candidate aces all the questions in 10 minutes, or fails even the most basic ones, the interviewer should hopefully be confident that they have the information needed to make an educated hiring decision.. Running badly over time, however, is worse, because something might be scheduled right after the interview — but it can be easily fixed by baking extra time — say, an extra 15 or 30 minutes — into the original interview invite (for example, an interviewer could propose an hour-and-a-half time slot while knowing it could end early.

So, do prepare the list of questions that cover the topics you care about in a reasonable time, but don’t obsess over that plan too much.

5. Ignoring the resume

Interviews represent precious face time with the candidate, and are best used to get to know each other, and judge social and problem-solving skills. Why waste this opportunity on reiterating things that are evident from the resume?

I worked on large-scale products in big tech companies, got a degree from a top university, and even have a blog and some open-source work — it’s all on my resume, and learning it takes 15 mins before the interview. Interviewers have a right to be skeptical, and it’s fine for them to ask a low-level questions like “sum numbers in an array.” But why spend an hour on “now, write a FUNCTION” and “have you ever worked in a team”? when you could be focused on obtaining deeper-level information about me? 

6. Overstretching

Big tech companies are famous for their lengthy interview processes: Google has about eight interviews, and other tech giants are not far behind. 

So, as a three-person startup that wants to be the next Google, you need to have many interviews, right? 

Not so fast. Large companies have many factors that let them get away with (and even require) lengthy interview processes:

1. The candidates are motivated to work in this particular company, and so are less likely to accept faster offers from others while still being interviewed.
2. A steady stream of candidates justifies high rejection rates and requires ranking precision only achieved by collecting additional data.
3. They have many employees available for interviews. It’s fine to spend 80 hours on 10 candidates when it’s 0.02% of your team’s time, not so much when it’s 67%.
4. They have many teams that are hiring at any time, and they reasonably want to have some personal time with the candidates.

I’m fine with two interviews and a phone screening, as long as I genuinely like your place, and you can schedule them within a week or two. I’m a lot less enthusiastic about spending four hours with a very talkative team lead in your average outsource agency when I can get a comparable offer in a day. Requiring a larger time commitment suggests you believe you are worth it, and you will need to back it up to compete with those offering shorter hiring processes. 

Having too many interviews is not the only way to overstretch the process. Two interviews, scheduled too far from each other, is also a challenge for a candidate, as is being extraordinarily slow in organizing them. If the goal is to hire people, it’s important to make sure your interview process allows you to do so before they accept another offer.

So only add more interviews if you really need them and your offering justifies the extra time required. Also, remember that extra interviews are not free for you — or your team.

7. Poor group dynamics

Luckily, 1-on-1 interviews are the standard. There can be some good reasons to have more interviewers (the biggest one being that you get a second opinion: As we say in Russia, “one head is good, but two are better”). 

However, I often see problems with group dynamics. Several interviewers, competing and interrupting each other, can easily get messy. This might work if it’s conducted as a more casual conversation (rather than a question-then-answer quiz), but these informal interviews have their drawbacks, namely that they often prioritize social skills and making it hard to compare candidates against each other. In a traditional Q&A format, it’s better to have one interviewer in charge at any time, with others observing. You can switch roles by section or by answer if you like. But still, there remain dangerous spots.

One pitfall is follow-up questions. Every interviewer wants to ask one, until each additional follow up question feels less and less valuable. 

One time, I interviewed with eight (yes, eight) people at once. As soon as they were done with their follow-ups to the first question, the time was up. Nobody seemed happy. 

Another problem that arises with having additional, often “passive,” interviewers is boredom. 

Listening to the same answers for the 10th time is rarely exciting for the interview … but that visible boredom isn’t very reassuring for the person being interviewed. The worst I’ve seen from a bored interviewer do is reach into his pants, take something out, and chew on it. I hope it was a candy. I needed time to accept this experience.

If you bring buddies to the interview, make sure to agree on who asks what in advance, avoid useless follow-ups that assert your smartness, and make sure not to fall asleep when it’s not your talking time.

Many things can make interviews a horrible experience. Here are some tips to be a better interviewer:

• Focus on finding out what the candidate is good at, not on showing off how smart you are. 
• Seeing how the candidate approaches problems is better than getting some particular answer you expect. Open questions suit this style better.
• If the candidate struggles, help out! People will get stuck in real life, and it’s useful to see how they receive feedback (and, accordingly, how they act on it). 
• Prepare a question plan that reasonably covers the topics you care about — it’s hard to come up with questions as you go.
• However, make sure the plan is flexible enough to allow for unexpected turns. 
• Get as much data on the candidate as possible beforehand — resume, open source work, shared acquaintances and previous interview results are your friends. 
• Don’t make the interview process longer than it needs to be, whether by having too many or through poor scheduling.
• If you have several interviewers, agree on who asks what, and make sure the follow-up questions add value.

Above all, keep your end goal in mind — to hire someone who’ll help you build your product, quickly, and efficiently.

*This post originally appeared on https://blog.thoughtspile.tech/. We’ve republished it here on the G2i blog, with significant edits to align it with our guidelines (you can read the original here). 

‍