The Engineering Interview That Actually Predicts Who Ships

The senior hire who argued about Prettier for ninety days

Picture the offer letter you were thrilled to send. Eight years of experience, a recognizable logo on the resume, and an interview loop where they reversed a binary tree in O(n) and talked microservices like they invented the pattern. Slam dunk.

Then the first quarter happens. By day 90 they have shipped nothing that moved your roadmap. They have, however, opened a thread to migrate the team off your linter config, rewritten a working payments helper because it "wasn't elegant," and left a 14-comment review on a junior's PR over naming. Your two-week feature is now three weeks late and the team is tiptoeing around them.

You did not hire a bad engineer. You hired a candidate who was excellent at the thing you tested and mediocre at the thing you needed. The test and the job were two different jobs.

Algorithmic puzzles were built to reject people, not to find shippers

The whiteboard loop comes from companies screening tens of thousands of new grads, where the goal is cheap rejection at scale. That is a wildly different problem than yours. At Series B or C you are not filtering a flood — you are betting a feature line on one person who has to walk into a messy, half-documented codebase and make it better by Friday. Leadership IQ's study of 20,000 hires found 46% fail within 18 months — and only 11% of those failures trace to a lack of technical skill. The other 89% wash out on coachability, temperament, and the ability to deliver inside real constraints. None of which a sorting-algorithm question can see.

It gets worse: the format itself is measuring the wrong variable. When NC State University and Microsoft watched engineers solve problems on a whiteboard versus in private, public-watched performance dropped by more than half. So your highest scorers are partly self-selecting for one trait: comfort performing under a stranger's gaze. Useful for a conference talk. Irrelevant to whether someone can read a stack trace at 9am and have a fix in review by 11.

Run the candidate's actual first Tuesday

If you want to know how someone performs in their first 90 days, stop asking them to invent algorithms and have them do a small slice of the job. The cleanest way is a 60-to-75-minute work sample built to feel like a normal morning on your team — not a take-home that eats their weekend and quietly filters out the senior people with kids and lives.

This is not a vibe call. Schmidt and Hunter's 85-year meta-analysis put work-sample tests at roughly 0.54 predictive validity versus 0.38 for the unstructured interview most loops still lean on. That gap is the difference between a coin flip with extra steps and an actual signal.

Build the sample, concretely

• Hand them a real codebase, not a blank file. Fork a non-proprietary service that mirrors your stack — a tangled React component, a Flask endpoint with a known footgun. The cold start of orienting in unfamiliar code is half the test, because that is what day one looks like.
• Give them a ticket with a real shape. "Customers get a 500 when this form submits with an emoji or an apostrophe. Logs are attached. Reproduce it, write a failing test, then fix it." Notice this rewards reading logs and writing a regression test — the exact muscles your codebase needs.
• Sit beside them as a teammate, not a proctor. Tell them out loud: "We're pairing. I'm your colleague and I have context you don't — if you're stuck, ask me." Then watch what they do with that permission.

The signals only this format surfaces

A whiteboard cannot show you any of these, and all of them predict day-90 friction:

• Debugging method. Do they read the error and form a hypothesis, or start mutating lines hoping the red goes away? The second pattern is how legacy code rots.
• What they do when stuck. You offered help. Do they take it and say "good catch," or grind in silence and burn fifteen minutes of ego? In a hybrid team, the silent grinder is a slow leak.
• Pragmatism under a deadline. Do they fix the customer's bug, or pause to relitigate the library choice? The "greenfield architect" who only thrives building from scratch will drown in your existing repo.

Grade it, then run it next week

The output of the simulation is not "did the code pass." It is a short scorecard that turns those live signals into a hire/no-hire you can defend in a debrief. Four lines:

1. Root cause. Did they isolate the actual bug and ship a regression test, or patch a symptom? Pass/fail.
2. Narration. Did they think out loud and ask clarifying questions, or go dark? Silence under a teammate today is silence in a stuck sprint later.
3. Fluency. Are they at home in their editor and the standard library, or Googling basic loop syntax? Speed in the boring parts frees attention for the hard parts.
4. The deliberate poke. Mid-session, question one of their choices on purpose. If a minor suggestion makes them combative, you have just previewed every code review for the next two years.

You can change this for the next candidate without a single meeting

No HR sign-off, no committee. Before your next loop: fork a small service that looks like your architecture, plant one logical bug (not a typo) and one missing feature, and replace the algorithm round with the pairing session. That is the whole lift.

At your stage every engineering hire either compounds velocity or quietly taxes it, and you usually do not learn which for a quarter. A work sample moves that discovery into 75 minutes you control, before the offer goes out. If you want to widen the lens beyond the technical seat, the same evidence-over-impression discipline runs across the org in The Non-Technical Audit. Hiring is the most expensive thing your company does. Stop grading it on riddles.