How to Interview a Developer When You Can't Judge Code

You're going to hire someone whose work you cannot check. Say that sentence out loud, because it's the actual situation, and most founder hiring advice tiptoes around it.

You'll ask a candidate to describe their experience with your stack. They'll answer fluently. You have no way to know if the answer is accurate, because you can't read the code they're describing, and you can't tell a well-rehearsed explanation from a true one. So you fall back on things that feel like signal but aren't: confidence, a good resume, a portfolio site that looks polished, the fact that they went to a school you recognize. None of it predicts whether they'll build the thing you need, on the timeline you need, without quietly making decisions that cost you six months later.

I've run over a thousand technical interviews, on both sides of the hiring decision, most of them for candidates with 5–10 years of experience who could talk circles around anyone in the room. Here's what I've learned that has nothing to do with reading code: the interview signal that predicts performance is available to you too, and it's not technical at all.

The question you're actually equipped to ask

Stop trying to evaluate their answer to "explain the difference between SQL and NoSQL." You can't score it, and honestly, neither can most people asking it — they're pattern-matching against a memorized correct response, which any competent candidate can produce whether or not they've ever made a real database decision under pressure.

Ask this instead: "Tell me about a project that went wrong. Not a project with a hard bug — a project where the outcome was actually bad. What happened, and what was your part in it?"

Then stop talking. Let the silence sit. What you're listening for:

• Do they name a specific decision, or a vague circumstance? "The requirements kept changing" is a circumstance. "I decided to skip writing tests because we were behind schedule, and it cost us three weeks of rework two months later" is a decision. You want the second kind of answer, because it means they know which choices are theirs to own.
• Does the story have a number in it? Time lost, money spent, users affected, a specific date. Vague failure stories ("it just didn't go well") are usually failure stories that haven't been examined. Specific ones have been thought about, which means the lesson actually landed.
• Who do they blame first? Everyone eventually mentions a difficult manager or an unreasonable deadline. What matters is the order. If the first sentence is about someone else's failure, you're hearing an excuse rehearsed for exactly this question. If the first sentence starts with what they did, you're hearing someone who has actually metabolized the mistake.
• Do they tell you what changed afterward? Not "I learned to communicate better" — that's a platitude, and platitudes are what people say when they haven't actually changed anything. You want something concrete: "I started writing a one-page plan before starting any feature over a day of work, because that project taught me I was skipping the thinking step." A concrete behavior change is evidence the lesson survived contact with the next project.

This works because none of it requires you to evaluate their technical competence directly. You're evaluating their relationship with their own mistakes — and that relationship is a better predictor of whether they'll tell you the truth about your project's problems than any resume line.

On the engineering side of the table I run a longer version of this — a conversation instead of a whiteboard test, five questions deep. The founder version is the same instrument with one question instead of five, because you only need the one that doesn't require you to score code.

Why this beats a coding test you can't grade anyway

Most non-technical founders solve the "I can't judge code" problem by outsourcing the judgment: a friend reviews the take-home, a platform runs an automated test, a vetted marketplace pre-screens for you. These aren't wrong, exactly, but they solve a narrower problem than the one you actually have.

A coding test tells you whether someone can solve a bounded problem in isolation, under artificial time pressure, on a problem they know is being graded. That's a real skill. It is not the skill you're buying. You're buying someone's judgment on ambiguous decisions, over months, without anyone checking their work in real time — the exact thing a take-home test cannot measure, because a take-home test has no ambiguity in it. Someone else already decided what "done" looks like.

The failure-story question measures something closer to what you're actually hiring for: how they behave when a decision they made turns out to be wrong, weeks or months after they made it, with no test suite around to catch it. That is the entire job of building software for a company that doesn't yet know what it's building. Requirements will be vague. Your feedback will be inconsistent because you're learning what you want as you go. The candidate who can hold that ambiguity, make a call, and tell you honestly when the call was wrong is worth more than the candidate who aces a LeetCode problem you can't independently verify anyway.

The mistake that taught me this the expensive way

Early in my time as the most senior technical person at a startup, I ran every engineering interview and owned the hiring call alone. A candidate came in with a rough run of circumstances — the kind of story that makes you want to root for someone. The technical signal was mixed. Not bad, but not the bar I'd have held for anyone else that week.

I said yes anyway. I told myself I was betting on trajectory, on someone who'd work harder because they had something to prove. What I was actually doing was letting sympathy stand in for a signal I didn't have the discipline to demand.

It didn't close. The gap between what the role needed and what showed up in the work stayed open, and the team carried it — quietly, and for longer than I should have let them. Nobody acted in bad faith. I made an unvetoed decision: in that seat there was no one to check my read except me, and I didn't check it hard enough.

The lesson wasn't "don't be kind to candidates." It's that sympathy and signal are different inputs, and the moment you let one substitute for the other, you've stopped hiring and started reassuring yourself. A candidate's circumstances are real and worth acknowledging. They are not evidence of how the work will go. Ask the failure-story question of everyone, including the candidate you already want to hire — especially that one, because that's exactly when your discipline is weakest.

What a good answer actually sounds like

A senior engineer, describing a real failure, might say something like this:

"I shipped a feature that let a customer bypass a rate limit because I didn't think through an edge case in how the auth token expired. It ran in production for about two weeks before someone on the customer's side noticed and mentioned it, and by the time we found and fixed it, they'd racked up an unusual amount of unbilled usage. I owned the fix and wrote the retro. What changed for me: I now write out the failure modes of anything touching auth or billing before I write the code, not after — it's a fifteen-minute habit that's caught two more issues since."

Notice what's in there: a specific mechanism, a real cost, ownership stated plainly, and a durable behavior change you could ask about again in six months to check it stuck. You didn't need to understand what a rate limit is to hear the difference between this and "we had some bugs, but we fixed them and moved on."

A weaker answer sounds like this instead: "Honestly, most of the issues came from unclear requirements from the product side. I did what I could with what I was given." That may even be true. It's also unfalsifiable, blame-first, and tells you nothing about what this person will do the next time a requirement is unclear on your project — which it will be, repeatedly, because you're a founder without a fully specced roadmap.

What this doesn't replace

This isn't a full hiring process on its own, and treating it as one would be its own mistake. You still need:

• A reference check with a specific question, not "would you hire them again." Ask their last manager the same failure-story question about the candidate, from the other side: "Tell me about a time this person's work didn't go well — how did they handle it?" The answers should roughly rhyme. If they don't, that's worth a follow-up.
• A small paid trial before a full commitment, if the engagement size allows it. A week of real, scoped work reveals more than any conversation, and it costs you a week's pay instead of a bad quarter.
• Someone to sanity-check the technical parts you genuinely can't evaluate — the architecture choices, the estimate, the stack decision — because the failure-story question tells you about judgment and honesty, not whether the specific technical call they're about to make is sound.

That last one is the actual gap. You can learn to run a hiring conversation that surfaces honesty and ownership. You cannot, in one weekend, learn to evaluate whether a proposed architecture will hold up, or whether an estimate is realistic. That's a different kind of read, and it's the one most founders go without because they don't know who to ask.

Two of those reads you can partly do yourself, because they're behavioral like this one: whether the build you already have is in trouble, and whether a cleanup request is debt worth paying down or gold-plating. The architecture call and the estimate aren't. Those need someone technical who isn't selling you the build.

Your next step

Before your next interview, write the failure-story question at the top of your notes and ask it of every candidate, in the same words, before you look at anything else. Score the answer on one thing only: did they lead with their own decision, or with someone else's failure.

If you're mid-decision on something bigger than one hire — a proposal you can't evaluate, a build that feels off, a technical hire you're not sure about — I do a few free second opinions a month for founders in exactly this spot. No pitch, nothing to buy afterward, just an outside read from someone with no stake in which way you go. hello@ruchitsuthar.com.

Frequently asked questions

How do I interview a developer if I don't know how to code?

Ask about a real failure instead of a technical trivia question you can't grade. Have them walk through a project that went wrong, in specific detail — what happened, what they decided, and what changed afterward. That signal doesn't require you to evaluate their code; it requires you to notice whether they own their decisions or blame their circumstances.

What questions should a non-technical founder ask a developer candidate?

The core question: "Tell me about a project that went wrong, and what was your part in it." Follow with a reference check that asks the candidate's last manager the same question from the other side, and — for any hire above a small scope — a short paid trial before a full commitment.

Can I trust a coding test if I can't review the answer?

Not on its own. A coding test measures whether someone can solve a bounded, graded problem under artificial time pressure — a real but narrow skill. It doesn't measure the judgment you're actually buying: how they behave on ambiguous decisions, over months, when nobody is checking their work in real time.

Should I hire based on a candidate's personal story or hardship?

No. A candidate's circumstances are worth acknowledging as a person, but they are not evidence of how the work will go. Evaluate on the same signal for everyone — a specific, ownership-first answer to a real failure — and be most careful about this exact substitution with the candidate you already want to hire.

Do I need a technical cofounder to hire developers well?

No. You need one disinterested technical read before a hire or a build decision goes through — not equity, not a full-time technical partner. A short outside review of the harder calls (architecture, estimates, the stack) covers the gap that a good interview process alone can't close.