Most Engineers Are Never Taught How to Interview. Here's the Cost.

Most engineers are never taught how to interview. One day, your manager says, "We need you to interview this candidate on Thursday," hands you a resume, and that's it. I've collected feedback from thousands of candidates. The pattern is clear: the quality of the interviewer matters as much as the quality of the candidate.

Before the interview

Read the resume. Actually read it.

Spending 5 minutes with the candidate's resume before the interview changes everything. I've heard candidates say: "The interviewer asked me to introduce myself, and when I mentioned my current company, they said, 'Oh, what does that company do?' It was on the first line of my resume."

Know what you're evaluating.

Before the interview starts, be clear on what you're testing. You can't test everything in 60 minutes, so pick 1–2 areas and go deep. If you're in the second round and the first round already tested coding, don't test coding again.

During the interview: coding rounds

Pick problems that match the role, not problems you think are clever

The purpose is to see if the candidate can write working code under moderate pressure. Good problems: a competent engineer can reach a working solution in 30–40 minutes. Bad problems: obscure dynamic programming variants, math-heavy problems, anything where the "trick" is the entire solution.

Give the candidate space to think

Silence is okay. When a candidate pauses for 30 seconds, they're thinking. Don't fill the silence with hints. If 2–3 minutes pass with no progress, offer a nudge — not the answer. "What data structure might help you look things up quickly?" is a nudge.

Watch the process, not just the output

A candidate who talks through their approach, considers edge cases, and codes it cleanly — that's a hire, even if they need a hint. A candidate who jumps straight to code, writes something that works, but can't explain why — that's a concern.

During the interview: system design rounds

Start with a real problem, not a FAANG classic

"Design Twitter" and "Design a URL shortener" are so commonly practised that you're testing preparation, not design ability. Better: describe a real problem your team faced.

Probe for trade-offs, not "the right answer"

There's no right answer in system design. Push the candidate to articulate trade-offs. The candidates who impress aren't the ones who draw the most boxes — they're the ones who can tell you what breaks and why.

Bias traps to watch for

• The "like me" bias: you naturally favour candidates who remind you of yourself

• The halo effect: a Google resume doesn't guarantee brilliance, a TCS resume doesn't mean mediocre

• The "great communicator" trap: don't confuse articulation with ability

• The "difficult question" bias: if only 1 in 10 candidates can solve it, you're testing recall, not ability

After the interview

Write your feedback immediately

Not tomorrow. Immediately after the interview ends. Your impressions are freshest in the first 10–15 minutes. Structure: what was the question, how the candidate approached it, what went well, what didn't, and your overall recommendation.

Don't anchor on one bad answer

An otherwise strong candidate who stumbles on one question shouldn't be rejected because of it. Some of the best engineers I know would fail a surprise DP question on a bad day.

The standard I use

The best answer I've heard to "What are you looking for? Can this person, in 3–6 months, independently own a significant piece of our system and make it better?"

That's the question. Everything in the interview is trying to answer that.