Most engineering interviews test whether someone can perform under artificial pressure, not whether they can do the job. The loop I run is deliberately closer to the real work: a clear baseline bar, a pairing session on a problem instead of a whiteboard puzzle, and a few questions that reveal how a person learns when no one is watching. The goal is signal, not a gauntlet.

When to use this play#

Use it when you are hiring for the baseline engineer role rather than a narrowly specialized seat. The bar below describes a generalist software engineer who can be productive on a real team. Hiring well below that baseline, for example an apprentice who needs heavy mentorship, is a deliberate exception that you should only make when you actually have the capacity and a person committed to mentoring them. Decide that on purpose, not by accident in the middle of a loop.

How to run it#

Start with a screening bar, not trivia. Before anyone spends an hour on a panel, confirm the candidate clears a small set of baseline expectations. I treat these as the minimum to be considered an engineer on the team. If most of the answers are no, this is probably not a fit, and that is fine to learn early:

• Can they build a working solution in at least one tech stack on their own?
• Do they have real experience with at least one programming or design paradigm?
• Have they written automated unit tests, not just read about them?
• Can they name a few architectural patterns and the problems each one solves?
• Can they spot a couple of common code smells and refactor them away?
• Do they show genuine ambition and an eagerness to keep learning?

Pick one technical format and commit to it. I run one of two formats per candidate, never a mix. They are alternatives, not stages stacked on top of each other.

The default is a live pairing exercise. The candidate does no coding on their own time. Instead they pair with the interviewers on a problem you have prepared in advance. Tell them exactly how to show up: bring a laptop, an editor or IDE they like, a fresh empty project in the language of their choice with a unit test framework wired up, and one trivial passing test so you all know the setup works before the clock starts. Then the session goes: get to know them and their background, pair for about thirty minutes on the prepared problem, and leave the rest of the time open for their questions. Be explicit that you are not expecting them to finish. You are watching how they problem-solve, their fluency in the language they chose, and how they communicate while working.

The alternative is a take-home coding exercise reviewed in the interview. Offer the candidate a choice of a few well-scoped katas, let them complete one in any stack they like, and walk through it together when they are done. I keep the deep mechanics of designing and grading those exercises in a separate play, code katas for hiring, so the format here stays a single decision: live pair, or take-home review.

Probe for learning, not just current skill. A baseline of competence gets someone considered; how they grow is what makes them worth hiring. Work a few open questions into the conversation and listen for specifics rather than slogans:

• Tell me about a skill or technology you taught yourself recently and how you put it to use.
• What corner of engineering are you itching to go deeper on right now?
• Describe something you took on independently to improve your team or workplace.
• How do you go looking for feedback, and what did you do with the last hard piece you got?
• Walk me through a mistake on a project and what you changed so it would not happen again.

Protect the candidate experience. Send a clear prep note before the technical session so nobody arrives guessing. It should cover what to set up, the shape of the session, and the honest framing that you are looking at how they think and communicate, not whether they sprint to a finished answer. A candidate who knows the rules can show you their real work.

Common traps#

• Treating the take-home as both a filter and a panel. Pick one technical format per candidate. Asking for a take-home and then re-litigating it across a whole loop wastes everyone's time and double-charges the candidate.
• Optimizing for puzzle speed. The pairing exercise is a window into reasoning and collaboration. If you grade it on whether they finished, you will hire fast guessers and miss thoughtful builders.
• Letting the bar drift mid-loop. If you find yourself rationalizing past several no answers on the screening questions, you are probably hiring an exception without admitting it. Name it and make sure the mentorship capacity is real.
• Skipping the prep note. An underprepared candidate fumbling their environment tells you nothing about their engineering. Set them up to show their best work.

Signals it's working#

• Interviewers come out of the pairing session talking about how the candidate reasoned and communicated, not just whether the tests passed.
• Your screening questions are catching mismatches before the full panel, so panel time is spent on genuine maybes.
• Candidates describe the process as fair and representative of the actual job, even the ones you pass on.
• New hires behave on the job the way they did in the room, because the room looked like the job.