As someone who has worked with hundreds of engineers and sat through just as many interviews (time flies when you’re having fun!), I have seen everything: broken processes, poor hires, great candidates rejected for the wrong reasons, and unnecessarily complex assessments that border on absurd.
After watching companies run on-site whiteboards, LeetCode brain-teasers, “build-our-product-for-free” take-home assignments, panel interrogations, and all sorts of questionable coding puzzles, I think I have a decent sense of what actually works.
Good news: it does not have to be complicated. Bad news: it does have to be intentional.
There is a thin line between over-engineering your process and being completely unprepared. Pick a strategy, stick with it, and design around one goal:
Help the candidate show their best work.
Your ideal funnel:
- Cultural fit
- Technical screen
- Final vibe check/team call
Let’s break it down.
1. Cultural Fit
A short sanity check.
- Can they communicate clearly?
- Do they listen?
- Do they ask questions?
- Do they seem positive and collaborative?
Do not overthink this part.
2. Technical Screening
This is where most companies mess up. There are a couple of approaches that work well.
Approach A: The Project Deep-Dive
This is a strategy narrated by Casey Muratori (legendary game engine / 3D programmer), and it is shockingly effective when done well.
The idea is simple. Instead of throwing artificial puzzles at a candidate, you ask them to walk you through a real project they have built. Ideally, you warn them beforehand so they can refresh their memory. Then, during the interview, you choose one part of the system — a module, a component, a service, anything — and you start exploring it together.
You begin at the high level: what problem were they solving, what constraints existed, and what tradeoffs they considered. As the conversation unfolds, you gradually move downward, peeling back layers until you reach implementation details. Sometimes this means talking about database schemas, concurrency issues, type-system limitations, or simply why they named things the way they did.
The strength of this approach is that candidates are operating in familiar territory. You’re not asking them to perform under artificial pressure. They are discussing something they actually built. Their confidence increases, their natural communication style comes through, and they can demonstrate depth rather than regurgitate trivia.
This method alone can replace most technical tests.
Approach B: The Coding Challenge (If You Must)
Most engineers hate coding challenges for good reason.
- They are often lazy outsourcing of interviewer effort.
- They measure the wrong things.
- They are often pointless now that AI exists.
If you insist on using one, do it this way:
Only use the challenge as material for a later conversation.
Two steps:
a) Give a small, self-contained problem. It must not be secretly part of your product roadmap. If you do this, shame on you.
b) After submission, schedule a discussion. Ask about decisions, tradeoffs, and what they would improve.
The value is in the conversation, not the code.
What About LeetCode, HackerRank, Codility, etc.?
These tools exist for:
- Big tech
- Massive hiring funnels
- Thousands of applicants per role
For them, it is a necessary first filter.
For you?
Do not use them. Unless you want to measure how well someone memorizes puzzles instead of how well they build real things.
3. The Final Vibe Check: Team Call or On-Site
This step is often awkward because everyone tries to be overly professional.
Set the tone:
“This is not about code. This is about getting to know each other.”
Talk like humans. Tell stories. Relax.
This step is only relevant when you are already about 80 to 90 percent sure they are a good fit.
(Very) Important Notes
— Research shows that live coding or LeetCode-style screening has a success rate (candidate passing probation) of less than 50 percent. In plain terms: flipping a coin to decide if you’re hiring someone or not is more reliable than these tests.
— When uncertain, I personally favor chemistry and communication over total technical coverage. Prior experience with every tech topic is not necessary.
— Even before AI, the most important skill was being able to find, digest, apply new information and communicate it clearly. Most roles are not research labs. We are building products and services.
A question I really like:
“Pick a technical topic and explain it to a non-technical stakeholder.”
This shows:
- Depth of understanding
- Clarity of thought
- Ability to collaborate across functions
Underrated skill.
Last Thoughts: Lessons from “Blink” by Malcolm Gladwell
I recently re-read Blink, a fascinating book about the power of intuition and rapid cognition.
Themes that stood out to me in the context of hiring:
- Create psychological safety
- Ask what energizes them
- Notice what people do well
- Trust your intuition (aka “gut”), but then verify
- Give room for authenticity
- Observe behavior over words
Hiring is human. Treat people like humans.
Happy hiring!