The Software Engineer’s Guide to Interviewing Software Engineers

9 min readAug 1, 2018

Software engineers are often asked to jump into the interview process with a minimum of advance preparation or training. This post is a condensed guide for helping people get up to speed with technical interviewing. The insights and tips are based on the over 400 software interviews I’ve done since 2003 at five companies, including at Amazon.com as a ‘bar raiser.’

I’ll discuss what matters during interviews; how to think about high-signal questions; how interviews are typically structured; and I’ll end with some general observations. This post does not cover specific interview questions.

Ah, the Interview Process

Based on just a brief summary of someone’s professional history and few hours’ time with them, you’re going to decide whether you’d want work with them for several years. It’s like deciding to get married after a first date.

Yup, the stakes are high and it’s weird. Here’s a few thoughts that might help you make peace with this process.

Interviews happen by mutual agreement.

The candidate and your company already made a tacit agreement that this process is OK. Everyone involved wants you to pass judgement decisively!

Don’t panic!

Obviously, interviews are hugely stressful for candidates — but they can be stressful for the interviewer, too. It’s ok to acknowledge the elephant in the room, which is that interviews are weird for everyone. Many first-time interviewers struggle to be a bad cop or put on an “interviewer face.” Just be yourself and trust that things will work out.

You don’t need to be better than the candidate.

I take this as a guiding principle. You can absolutely interview people at a level above you. You might not be able to fully assess all their technical skills, but you can gain insight into their critical thinking, whether they work well with others, and if they can demonstrate a level of proficiency. Also, don’t be dazzled by pedigree; there are a lot of clowns out there who look amazing on paper and can bluster, but who can’t code their way out of a paper bag.

Yes, you’re a capable interviewer!

Interviewers often suffer imposter syndrome. “What right do I have to interview this person? What if they’re an expert and think I’m a fraud?” It’s normal to feel this way, but relax! An interview isn’t a battle of superiority, it’s a conversation. Just ask questions — and then ask follow-up questions.

First, Know the Job Level

Your organization should have documents that define the hiring bar, including the necessary skills and core values.

There should be an engineering job ladder that explains what characteristics matter and the difference between levels.
The hiring managers should be able to describe the necessary technologies and experience for a given role, and explain why it’s appealing.

General Interview Structure

Every organization has a different process for their interviews, but a typical pipeline looks like:

Recruiter phone call (45 minutes). Find if there’s a fit, determine the job level, sell the company.
Hiring manager phone call (45 minutes). Screen on technical skills and experience. Talk about the job details.
In-house interview (4–7 hours). A series of 45 minute or 1 hour sections, where one or two employees will interview the candidate. Each section should have an assigned topic area for assessment, e.g. a coding interview.
Team debrief (30 minutes). Decide whether to make an offer. Also, share notes and ideas to improve the interview process.

Your Goals For a Technical Interview

Your time with the candidate is limited. Make sure your interview does the following:

Gather hire/no-hire data points. You should walk out of the interview with a clear sense of whether to hire this person, and evidence that supports your conclusion. Curate high-quality interview questions that have possible good answers and bad answers. Ask lots of follow-up questions, and dig when answers are vague or evasive.
Sell your organization. Make sure the candidate knows what you do, and why they should be excited to be part of it.
Be nice. You always want candidates walking out of interviews feeling like they had a professional and fair experience. You don’t want a reputation for being rude or disorganized.

Things to avoid during an interview:

Cut off rambling digressions that aren’t telling you anything. It’s OK to step in and seize control of the conversation.
Don’t waste time getting chummy. “Is this a person I want to get a beer with?” shouldn’t be a priority.
Don’t dominate the conversation. Let the candidate do most of the talking until end of the interview, when you answer their questions.
Don’t waste time on softball questions. Questions that any candidate could answer acceptably are useless. (Exceptions: you’re deliberately trying to calm the candidate down or establish a friendly starting point).

I suggest transcribing as much of the interview as possible. Afterwards, review the conversation and think about which parts were the most useful. Put the wasteful stuff on the chopping block.

Form an Opinion: Hire or No-Hire

At the end of an interview you should have an opinion about the candidate:

Strong hire: the candidate was really strong overall, you’d be willing to go out on a limb to advocate for them.
Hire: the candidate did well, but didn’t knock it out of the park.
No-hire: the candidate didn’t do well. If it was just based on just this interview, you’d probably pass. However, you’re willing to be convinced that they could still be a viable hire.
Strong no-hire: the candidate did such a poor job that you cannot imagine working with them. You would fight to keep them out.

You’re not allowed to be on the fence. If you find yourself saying “I’m not sure. I liked them, BUT….” that means no-hire.

This opinion is non-binding, but it’s important to have an opinion. I suggest that immediately after the interview, you fill out a standardized feedback form to structure your evaluation by e.g. problem-solving, technical skills, etc. rather than a wobbly feeling. After writing this down, pick the “Hire / No-hire” recommendation.

You’ll share your experiences during the interview debrief. It’s OK for people to change their votes. Candidates with one or two “no-hire” votes could still be hired if folks feel like their weaknesses are explainable.

Hire at a Consistent Level

You are not hiring for just one particular team. Make the hire/no-hire decision based on the job level as it applies across the whole company. The candidate should be able to switch teams later and still be successful. Never let a hiring manager cajole you with “even if they’re not great across the board, they have this one skill we really need” — that’s a no-hire.

A good question is: “how does this candidate compare to our current engineers at this same level?”

In-House Interview Topics

As much as possible, the interview should cover areas that accurately predict whether a candidate will be a successful software engineer at your organization. Avoid interview questions that over-index on topics that don’t matter. For example, sorting algorithm questions are mostly just a measure of how recently someone was in school, not whether they’ll write good software.

I like to assign in-house interviews on:

Can they write code? You’re hiring software engineers to write code, so a big chunk of the interview should involve hands on a keyboard.
Can they make sensible design decisions? At the end of the day, an engineer is being hired to solve problems. Can they translate a problem statement to technical requirements? Can they make reasonable decisions that balance simplicity with future needs? Would you trust them with a big initiative?
Can they work well with other people? Do they advocate reasonable process? Can they communicate clearly? Is there critical thought? Do they accept feedback?

Common Antipatterns

Poor communicator. I have no idea what they just said, or how they reached a conclusion. Or I ask a direct question and they evade it or talk endlessly without answering.
Poor code quality. Bad choices, poorly organized, etc.
Doesn’t explore the problem before jumping into a solution. I expect engineers to validate their assumptions and identify edge cases upfront.
Broad knowledge gaps. This isn’t about arcane trivia or gotchas, but big areas that someone should have at least been curious about during their career. E.g. a senior candidate who has never thought about using key-value stores.
Not self-motivated. Needs excessive hand-holding to move to the next step.
Not detail-oriented. Misses obvious edge cases, didn’t understand the problem in the first place.
Veers into the weeds. Makes up crazy requirements or assumptions.
Solutions are overly complicated.
Doesn’t interact with the interviewer. No back-and-forth of questions, doesn’t respond to feedback or hints.
Condescending.
Unnecessarily dogmatic.

Preparing for your Interview

Give yourself 15–30 minutes to prepare for each interview.

Make sure you know the job level (“Engineer Level 2”) and team (“Merchant APIs”) the candidate is being considered for. If the role is unclear, ask the hiring manager what this person is expected to do.
Review the résumé (CV); in particular, pay attention to the past 2–3 years for what kind of work they were doing and their role.
Make sure you know what topic you’ll be interviewing for (which coding problem, etc). If this is your first time asking that question, ask to be paired with a mentor and get a copy of any materials they use. Double-check that you won’t be overlapping with other interview areas.
Skim the phone screen notes, looking for any areas of particular strength or areas flagged for follow-up.
Double-check the logistics. What room will the candidate be in? Who is interviewing before, and where will they go after? If you’re doing a coding interview, test the computer setup.

The Interview Script

I follow pretty much the same script for each interview:

Say hello to the candidate. Tell them my name and title.
Ask the candidate if they need water, or if they could use a restroom break.
Explain what I do. Let the candidate ask questions about my job or the company (these questions can be excellent signal!) but cut off after 5 minutes.
Jump into technical questions.
If the candidate did well, spend a few minutes at the end selling the company. Let them ask questions. If the candidate didn’t do so well, use the remaining time to ask follow-up questions to let them either redeem themselves or solidify that opinion.
Escort the candidate to the next interview (as needed).

Time management is important! Be punctual. It’s OK to politely cut the candidate off and move questions along.

Other Points

“How Did I Do?”

Sometimes at the end of an interview, a candidates will ask point-blank whether they did well. This really puts you on the spot! My advice is to dodge this and give a generically bland statement “you’ll be hearing back from our recruiter in a day or two.”

If I do really like the candidate, I may add “if you have any questions, here’s my email…”

Avoid Personal Questions

There are a bunch of important legal details about interviews, too — mostly about questions you’re not allowed to ask. Ask your HR department! But as a rule of thumb, just don’t ask any personal questions unless the candidate brings it up first. Kids, age, pregnancy, religion, health status, etc. are minefields. Focus on technical questions.

Bias in Interviews and Hiring

Bias exists (gender, race, age, sexual orientation, disability, family status, and more). Even if it’s unintentional or may seem like a non-issue, it’s a topic that should be kept in mind and not swept under the rug. This is of course a much bigger topic than can be addressed here. Insist that your organization actively recognizes and engages with this crucial topic.

Interviewing is a Worthy Skill

Interviewing doesn’t come naturally. It’s a skill that improves with practice. Review past interviews to think about ways to improve the back-and-forth flow of conversation, and to increase the hire / no-hire signal.

A great way to get started is to buddy with a fellow interviewer so there will be three people in the room (the two interviewers plus the candidate). Not only can the interviewers coach each other about what to say, but also they will have different observations about the candidate’s responses.

I take interviewing very seriously, and enjoy it. I realized pretty early on that it’s not about passing judgement on candidates per se, but about creatively trying to find the best fit between people and roles. Interviews are also an opportunity for me to become a better engineer because candidates teach me about new technologies and methodologies. I relax, enjoy the conversation, and meet some interesting people.

More where this came from

This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.