Hiring Without the Theatre
How to run interviews that actually assess skills instead of performance ability
Most technical interviews are performance art. The candidate studies LeetCode problems they will never use. They practise writing code on a whiteboard in front of strangers. They memorize answers to behavioural questions. None of this tells you if they can actually do the job.
You end up hiring people who are good at interviewing, not good at engineering. Then you are surprised when they struggle with real work.
This playbook walks you through running interviews that assess actual skills instead of interview performance ability.
Define What You Actually Need
Before you write a job description or schedule an interview, get clear on what skills matter for this role. Not a generic list of requirements. What will this person actually do in the first six months?
Write it down:
What systems will they work in?
What problems will they solve?
What decisions will they need to make?
Who will they work with?
If you cannot answer these questions, you are not ready to hire. Figure out what the role is first, then build the interview around it.
Skip the Algorithmic Puzzles
LeetCode-style algorithm questions test whether someone has studied LeetCode. They do not test whether someone can build software.
Unless your engineers spend their days inverting binary trees, stop asking candidates to do it in interviews. It wastes everyone’s time and filters out people who would be excellent at the actual job.
If you need to assess problem-solving skills, give them a problem that resembles real work. Not “reverse a linked list.” Something like “we have an API that is timing out under load, how would you investigate?”
Use Take-Home Assignments (But Keep Them Short)
Take-home assignments let candidates work in their own environment, on their own time, without the pressure of someone watching them type. This is closer to how they will actually work.
Keep it short. Two to three hours maximum. If it takes longer than that, you are asking too much. Pay them for their time if you can. At minimum, respect that they have other things going on.
Make the assignment relevant. Not a toy problem. Something that touches the actual work they would do. If they are building APIs, give them an API problem. If they are working on frontend, give them a frontend problem.
Provide clear requirements. What does success look like? What are you evaluating? Do not make them guess.
Review Their Work Together
Do not just score the take-home and move on. Schedule a follow-up session to review it together. This is where you see how they think.
Ask them to walk through their solution. What decisions did they make? What trade-offs did they consider? What would they do differently with more time?
This conversation tells you more than the code itself. You see how they communicate. How they handle feedback. How they think about quality and maintainability.
Test Real Collaboration Skills
Engineering is a team activity. You need to know if this person can work with others.
Include a pairing session in your interview process. Not “solve this algorithm while I watch.” Actual pairing on a real problem. You write some code, they write some code, you talk through it together.
This shows you:
Can they communicate technical ideas clearly?
Do they ask good questions?
Can they take feedback without getting defensive?
Can they give feedback without being a jerk?
These matter more than whether they can implement quicksort from memory.
Ask About Real Situations
Behavioural questions are fine if you ask about real situations, not hypotheticals.
Not “How would you handle a conflict with a teammate?” That is a prompt for a rehearsed answer.
Try “Tell me about a time you disagreed with a technical decision on your team. What happened?” Then follow up. What was the disagreement about? How did you handle it? What was the outcome? What would you do differently?
Listen for specifics. If they give vague answers, probe deeper. Real stories have details. Rehearsed answers do not.
Involve the Team
The people this person will work with should be part of the interview process. Not just the manager. Not just the senior engineers. The actual team.
They will spot things you miss. They will ask different questions. And if the candidate is going to work closely with them, they should have a say in whether this person joins.
Make sure everyone knows what they are evaluating. Do not have five people all asking the same coding questions. Split it up. One person focuses on technical skills. Another focuses on communication. Another focuses on cultural fit.
Debrief together after the interview. What did everyone see? Where do you have concerns? Where are you confident?
Watch for Red Flags
Some things should disqualify a candidate immediately:
Arrogance. If they talk down about previous teams or dismiss questions as beneath them, do not hire them. Skill does not make up for being insufferable.
Dishonesty. If they claim credit for work they did not do or exaggerate their role, do not hire them. Trust matters.
Rigidity. If they insist there is only one right way to do things and refuse to consider alternatives, do not hire them. Engineering requires flexibility.
Move Fast
Good candidates have options. If you drag out your process for weeks, they will take another offer.
Aim for one to two weeks from first interview to offer. This is doable if you are organized. Schedule all interviews in a short window. Debrief immediately after. Make a decision within 24 hours.
Speed signals that you respect their time and that you are competent. Delays signal the opposite.
Make the Offer Clear
If you want to hire someone, make an offer that is clear, fair, and competitive.
Do not lowball them and hope they negotiate up. Do not play games with equity or benefits. Tell them what the job pays, what the benefits are, and what they can expect.
If they have questions, answer them. If they need time to think, give it to them. But do not make them chase you for information.
What Not to Do
Do not test trivia. Asking someone to recite the syntax of obscure language features is not useful. They can look that up.
Do not make them interview with ten people. More interviewers does not mean better decisions. It means more time wasted and more inconsistency.
Do not ghost candidates. If someone is not moving forward, tell them. Do not leave them wondering.
Do not hire someone just because they interviewed well. Interviewing is a skill. Engineering is a different skill. Make sure you are testing the right one.
Why This Matters
Hiring is the most important thing you do as a manager. Every person you bring onto the team changes the team. Hire well and everything gets easier. Hire poorly and everything gets harder.
Most interview processes are broken because they optimize for the wrong things. They test performance under pressure instead of actual ability. They reward people who are good at playing the game instead of people who are good at the work.
Fix your process. Hire people who can do the job, not people who can pass your tests.