What a Resume Cannot Tell You About an Engineer

Note: This story was written with AI assistance and edited by me. An earlier version of this piece was published on DEV.

A resume tells you what someone wrote. An interview tells you how they think.

Most technical hiring still starts with the resume. A recruiter spends a short time on it, looks for the right keywords and logos, and moves on. That is not a signal. That is a filter on formatting and luck.

I took a firm from $6M to $60M in under three years.

Hiring was part of that work, and it is why I care about this problem. Here is how I think about it.

Resumes are noise

Two engineers can write the same bullet: "Built and scaled a payments service." One of them designed it. The other fixed a bug in it. The resume cannot tell you which is which.

A simple interview question settles it in two minutes: "Walk me through how you designed that service. What did you decide, and what did you throw away?" The person who designed it will talk about tradeoffs, constraints and mistakes. The person who fixed a bug will describe the bug. No keyword filter can see that difference.

Strong people with unusual paths get dropped. Polished resumes with thin experience get through. You end up interviewing the wrong people and missing the right ones.

There is a second problem. A resume rewards people who are good at writing resumes. That skill has almost nothing to do with debugging a production incident or explaining a design to a teammate who disagrees with you.

A structured interview gives you signal

When every candidate answers the same questions, in the same format, you can finally compare them. Video adds what text cannot: how someone explains a tradeoff, how they handle a question they did not expect, how they communicate.

For remote teams that last part matters most. If someone cannot explain their thinking clearly on camera, they will struggle to do it in a design review across time zones.

Here is a hypothetical example. Imagine two candidates for a backend role. The first has a polished resume with well-known company names. The second has a short resume from a small company. Both get asked to describe a migration that went wrong. The first gives a general answer about "lessons learned" and cannot say what they personally decided. The second names the specific failure, what they changed, and what they would do differently. On paper the first wins. On video the second does. That is the gap a structured interview is built to expose.

Where AI helps

AI is good at the boring, consistent parts:

• Asking every candidate the same questions in the same order

• Capturing the answers so nobody relies on memory

• Summarizing what was said so a hiring manager can review in minutes, not hours

• Letting candidates interview when it suits them, not only during office hours

That saves recruiter time, and it makes the process fairer because every candidate gets the same experience.

Where AI falls short

It helps to be honest about the limits, because they decide how you should use the tool.

• Summaries can be wrong. A summary may smooth over a hesitation, miss a caveat, or mishear a technical term. Treat it as an index into the recording, not a replacement for it.

• Transcription is uneven. Accents, background noise and unusual product names can trip up speech to text. If you score the transcript instead of the answer, you may penalize people for things unrelated to the job.

• It cannot judge depth on its own. A confident, fluent answer can still be shallow. A person who knows the domain has to ask the follow-up.

• Recorded answers are not a conversation. Some of the best signal comes from a live follow-up. Use the recorded round to decide who deserves a live one.

• Candidates may be uncomfortable. Some people dislike talking to a camera. Offer a live alternative and do not read anything into a stiff delivery.

Where humans still decide

AI structures the interview. A person makes the hire. I would never hand the final decision to a model, and I would not trust a vendor who suggests it. The review, the follow-up questions and the offer all belong to your team.

How to start

1. Pick the three or four skills that actually predict success in the role.

2. Write one clear question for each.

3. Write down what a strong answer and a weak answer look like before the first interview.

4. Run every candidate through the same set.

5. Have two people review the answers independently before anyone is rejected.

6. Compare the two reviewers' scores. Where they disagree, discuss why, and tighten the rubric.

7. Later, check which signals matched real performance on the job, and adjust.

A sample set for a backend role: describe a system you owned, explain a time you disagreed with a teammate, and walk through how you would debug a slow endpoint. Score each answer from 1 to 4 against a written description of a strong answer. Agree on that description before the first interview, not after.

For the slow endpoint question, a strong answer might start by measuring before guessing, separate the database from the application and the network, and say what evidence would change the diagnosis. A weak answer jumps straight to a favorite fix. You do not need the candidate to land on the right cause. You need to see how they narrow it down.

What to watch for in your own process

Run a small check on yourself. Take five past candidates you rejected on resume alone and five you hired. If you had asked all ten the same questions, would the order have changed? You cannot know for certain, but asking the question honestly tends to show how much weight the resume was carrying.

You do not need a big program to begin. You need consistency.

The takeaway

Pick one open role, write three questions and a rubric, and run the first five candidates through them with two reviewers. Within a couple of weeks you will see whether the format gives you information the resume never did.