How to interview an engineer when you are not technical

The uncomfortable version of this problem: you are screening a senior backend engineer, they are explaining why they chose one database over another, and you have no way to tell whether what you are hearing is expertise or confident nonsense.

The common advice — "just ask the hiring manager for a question list" — fails in practice, because a list of questions does not help you evaluate the answers. You end up transcribing responses you cannot assess and passing the problem downstream, which is exactly what the screen was supposed to prevent.

There is a better method, and it does not require you to learn the technology.

Evaluate the shape of the answer, not the content

You cannot verify whether sharding by tenant ID was the right call. You can absolutely evaluate whether the person reasoned like someone who has made that decision before. Those are different skills, and the second one is not technical.

Strong answers from experienced people share a recognisable structure, whatever the domain:

• They name a trade-off. Every real engineering decision costs something. Someone who presents a choice as purely upside either did not make the decision or did not understand it.
• They mention the alternative they rejected, and why. Expertise includes knowing what else was on the table.
• They can say what would change their mind. "If our write volume had been ten times higher we would have gone the other way" is the sound of someone who actually owns the decision.
• They separate what they did from what the team did. Inflated ownership is the most common résumé failure, and it surfaces here.
• They admit a limit. "I don't know" from a senior candidate, followed by how they would find out, is a strong signal, not a weak one.

Four questions that work in any technical domain

These are domain-agnostic, they cannot be answered generically, and the quality of the answer is legible to a non-specialist.

1. "What was the hardest technical decision you made in the last year, and what did it cost you?"

The follow-up is the real question: what did it cost. Listen for a specific, concrete cost — build time, a slower endpoint, a migration nobody enjoyed. Vague costs mean a vague decision.

2. "Something you built broke in production. Take me through it."

You are listening for a debugging narrative: what they thought first, why that was wrong, how they narrowed it down. Someone who jumps straight to the answer is either simplifying for your benefit — ask them to slow down — or did not do the debugging.

3. "Explain that to me like I don't know the technology."

This is not a courtesy, it is a test, and it is the most useful question on this list. People who genuinely understand something can explain it without jargon. People operating on borrowed vocabulary cannot, because the jargon is all they have.

It also directly predicts on-the-job performance: your engineers will have to explain their work to product managers and executives, and this is that skill.

4. "What do you disagree with most engineers about?"

Senior people have opinions formed by scar tissue. The specific opinion does not matter — you are checking whether one exists and whether they can defend it without contempt. Both matter for how they will behave in a design review.

The follow-up problem

Here is where non-technical screening usually falls apart. You ask a good opening question, get a dense answer, and cannot generate the follow-up — because the right follow-up depends on understanding what they just said.

Three fallbacks that work without domain knowledge:

1. Ask about the number. Any figure they mention — latency, team size, request volume, timeline — invites "why was that the number that mattered?" Real experience has reasons behind its metrics.
2. Ask who disagreed. Every significant decision had a dissenter. Asking who, and what their argument was, gets you a second perspective on the same decision and reveals how the candidate handles opposition.
3. Ask what happened next. Did it work? What broke? What did they change six months later? Candidates who only tell you about the launch and never the aftermath usually were not there for the aftermath.

None of these require you to have understood the technical content of the previous answer. All of them produce information a hiring manager can act on.

Write the handoff so the hiring manager can use it

Your screen is only as valuable as what survives it. A summary that says "strong technical background, good communicator" is worthless — the hiring manager has to redo the entire conversation.

A useful handoff contains:

• The candidate's own words on the two or three decisions they described, quoted rather than paraphrased.
• Which claims you could not evaluate, named explicitly, so the manager knows exactly where to dig.
• Anything inconsistent between what they said and what the résumé claims.
• Your read on the non-technical signals you are genuinely qualified to judge: clarity, ownership, how they handled being pushed.

Know where your screen legitimately stops

A non-technical screen can reliably establish that a candidate has genuine depth somewhere, communicates clearly, owns their decisions honestly, and is not inflating their role. That is a great deal of value, and it is enough to protect your hiring managers' calendars.

It cannot establish that they are good at the specific thing you are hiring for. Do not let anyone pretend otherwise, including yourself. The screen filters; the technical interview decides.

Tooling closes part of the gap. Hiriso follows the conversation live and suggests the domain-specific follow-up you could not have generated — the question a staff engineer would have asked at that exact moment — and flags where an answer went thin. You keep running the conversation; you stop being limited to the questions you already knew.