A bad junior hire costs time. A bad senior hire costs direction.
That's the difference nobody puts in the spreadsheet. When you get a senior person wrong, you don't just lose their salary and the months until it becomes obvious. You lose the architecture decisions they made along the way, the debt they left in the system, the rest of the team's time spent on reviews and rework, the quiet exit of someone good who got tired, and, the most expensive item of all, calendar months that don't come back.
The problem gets worse as seniority rises, because the process we use to evaluate senior people is essentially the same one we use for juniors, with more conversation attached. We read a résumé, ask technical questions, and trust that a couple of well-run conversations will tell us whether this person will make good decisions under pressure for the next three years.
We built Hura because we had that problem ourselves first. The interesting part isn't what we learned about the tool, it's what it forced us to admit about our own judgment.
Three structural reasons, none of which involve candidates exaggerating.
A résumé measures exposure, not judgment. A line reading five years in a stack tells you what someone was exposed to. It doesn't tell you whether those were five years of learning or one year repeated five times. Above all, it says nothing about the variable you care about most: how they decide when the problem has no known answer.
The classic technical interview rewards a skill you barely use. Solving a bounded problem, alone, out loud, against a clock, in front of someone judging you. That resembles real work in no relevant dimension: real problems are underspecified, context has to be hunted down, colleagues exist, tools exist, and there's time to think. You're measuring performance under a kind of pressure your team will never reproduce.
The interviewer is part of the instrument. Two senior engineers interview the same candidate and come away with different readings. Each asked what struck them as important, on their own scale. Without a prior definition of the signal you're looking for, an interview mostly measures rapport between interviewer and candidate, and rapport carries a well-known bias toward hiring more of who you already have.
Add that coding assistants are now part of everyone's working environment, and the question shifts again. Testing whether someone remembers exact syntax was a weak signal five years ago; today it's close to noise. The useful question is no longer what a person can write, but what they can judge.
We didn't work that out on a whiteboard. We learned it by reviewing machine-written code every day.
We work with AI agents inside the flow. Hura's first working prototype took two weeks, and keeping it alive afterward changed our sense of what makes an engineer valuable.
When code arrives fast, well formatted, and sensibly named, every surface signal a reviewer uses to judge quality ships included. What's left as human work is everything else: deciding whether the problem was framed correctly, whether the solution goes after the cause, what breaks when this grows, and what needed verifying before calling it good. Our review rule puts it bluntly: "the AI wrote it" is never an accepted answer in a code review.
That shift is what makes half a technical interview obsolete. You're testing the part the machine already does well, and not testing the part that became the job.
Look at how we work, and the things we do deliberately to produce reliable software turn out to be the same things that distinguish a reliable engineer. Four signals:
1. How they define the problem before solving it. We write a spec before the code, with explicit scope and acceptance criteria, because the expensive mistake is rarely a bad implementation: it's a flawless implementation of the wrong problem. The equivalent signal in a person is easy to observe. Given an ambiguous brief, do they ask or assume? Do they name what's out of scope? Can they state what "correct" looks like before starting? An engineer who dives straight into code is fast in an interview and expensive in production.
2. How they verify they're right. In our process, no bug gets fixed without a test that first fails against the unfixed code, because that's the only objective proof you understood the cause rather than the symptom. Translated to evaluation: how does this person establish that their solution works? Do they distinguish between "I tried it and it looked fine" and "I designed a check that would have failed if my hypothesis were wrong"? That distinction separates people who debug from people who guess in good handwriting, and it's invisible on a résumé.
3. What they rejected, and why. We document the rejected alternatives in every design decision, and over the years that section turned out to be the most valuable one. The same signal applies to a person: ask them to explain a technical decision they made and listen for whether they can articulate the option they didn't take. Someone who can only defend their solution probably never compared anything. Someone who can describe the trade-off has exercised judgment, which is what you're buying in a senior hire.
4. Where they draw the line with AI. The signal worth watching isn't whether someone uses assistants, since everyone does, but what they accept unreviewed, what they always verify, and whether they can explain why there. It's an unusually clean read on someone's risk judgment, and today it's probably the single most informative question in a senior interview.
Notice what all four share: none is answered by knowledge, all are answered by behavior. And none can be read off a résumé.
Hura is our technical assessment platform, built by engineers and designed for recruiters. A recruiter pastes in the job description, and the platform generates the test from that role, grades it, and compares candidates, with nobody having to ask an engineer for a favor to write the exam or to review it. Under the hood the evaluation runs two models in parallel, and everything a user sees ships in Spanish and English. In our own hiring process it cut screening time by roughly 60%.
The product idea that follows from all of the above is the same as the process idea: evaluate work under conditions as close to real as possible, against criteria defined before you look at the candidate.
That carries three implications we consider more important than any particular feature:
The assessment derives from the actual role, not from a generic exercise bank. What you measure comes from what the person will do.
The criteria are set first. Like a phase gate: an objective checklist agreed in advance, not an impression formed during the conversation. It's the only practical defense against interviewer bias.
The human decides. Automation exists to surface more signal, more consistently, with fewer engineering hours burned on screening. Hiring is an irreversible, expensive step, and like every irreversible step in our process it carries explicit human approval.
And the part this article would be worthless without: no structured assessment predicts performance with certainty. What it does is raise signal quality and cut variance between interviewers. Context, team fit, and luck remain. Anyone promising otherwise is selling you something.
Stop assessing what people know and start assessing how they decide. Four signals you can add to your process this week without buying anything: ask every candidate to scope an ambiguous problem before solving it; ask how they'd prove their solution is correct; make them explain the alternative they rejected and why; and find out where they draw the line between what they delegate to an AI assistant and what they always verify. Then define your bar before the first interview, not during it.
About Aztia. We're a software development firm. We build Hura, our technical assessment platform (huraapp.com), holding ourselves to the same process we describe in this series: spec before code, a failing test before every fix, and a person approving every irreversible step. More at aztia.co.
Thirty minutes, no pitch. Tell us what you're building.
Talk to us →