Most hiring processes are optimized for confidence, not signal.
A candidate sounds sharp. They've used the right tools. They can talk through past work in a way that feels convincing.
They pass.
Then they join, and something feels off.
They need more direction than expected. They solve what's asked, but not what matters. They move, but they don't drive.
Nothing is obviously wrong. They're just not who you thought you hired.
That gap is the problem.
Why most hiring signals are weak
Resumes are curated.
Portfolios are selective.
Interviews reward articulation more than judgment.
So you end up measuring proxies.
How well someone explains a system they already built. How comfortably they solve a familiar problem. How confidently they speak.
All useful. None sufficient.
Because the work is different.
Real work is ambiguous. Constraints are unclear. Trade-offs are messy.
You're not hiring for an answer. You're hiring for how someone thinks when there isn't one.
What we're actually trying to see
We're not looking for perfect code.
We're looking for three things that show up under pressure:
- How someone frames a problem
- How they make decisions with incomplete information
- How they handle being wrong
Everything in our process is designed to surface that.
The three parts of our vetting
1. Live problem solving
We give a problem that looks familiar on the surface.
It's not.
There's just enough ambiguity to force decisions.
What we watch is not speed. It's how they start.
Do they clarify the problem? Do they define constraints? Do they rush into code?
Strong candidates slow down first. They shape the problem before touching it.
Then we watch how they move.
Do they test assumptions? Do they notice edge cases early? Do they adjust when something breaks?
The code matters. The thinking matters more.
2. System design under constraint
This is where most candidates lean on patterns.
They've seen similar questions. They know how to structure an answer.
So we change the conditions.
We introduce trade-offs that don't resolve cleanly. We limit resources. We shift requirements midway.
Now it's not about knowing the "right" architecture.
It's about judgment.
What do they prioritize? What do they ignore? How do they explain the trade-offs they're making?
We're not looking for the best system.
We're looking for a system that makes sense given the constraints.
3. The question nobody expects
At the end, we ask something simple.
"Tell me about something you built that didn't work."
No framing. No hints.
Just that.
Most candidates try to recover quickly. They reframe the failure as a success. They explain it away.
The strongest ones don't.
They sit with it.
They walk through what they thought would happen. What actually happened. Where their assumptions were wrong.
And most importantly, what they changed after.
This tells you more than anything else. Because in real work, things break.
You want someone who notices early, adjusts fast, and doesn't hide from it.
What we don't optimize for
We don't optimize for trivia.
We don't care how many frameworks someone can list.
We don't reward memorized answers.
Those signals decay quickly.
What stays is how someone thinks, decides, and adapts.
What "top 5%" actually looks like
It's not brilliance in isolation.
It's consistency under uncertainty.
They ask better questions. They make cleaner decisions. They recover faster when things go wrong.
They don't need perfect specs to move.
They create clarity as they go.
That's what compounds over time.
The TL;DR
- Most hiring processes measure confidence, not capability.
- Real work is ambiguous. Interviews should reflect that.
- Look for how candidates frame problems, not just solve them.
- Force trade-offs to surface judgment.
- Pay attention to how someone handles failure.
- Optimize for thinking, not memorization.
You're not hiring for the interview.
You're hiring for what happens after it.