She interviewed really well.

Knew the frameworks. Talked confidently about past projects. Everyone on the panel came out of the debrief saying the same thing: strong hire.

Three months in, the work wasn’t landing.

Tickets were slow. PRs needed more back-and-forth than expected. The team started quietly routing work around her.

The hiring manager was confused. The interview had gone so well.

That was the problem.

The interview was designed to find out what she knew. Nobody had actually asked her to do the work, not even a version of it. No take-home task. No code review. No real scenario to work through. Just questions. Good questions, answered well.

You can get very good at describing how you’d approach a problem without being able to solve it under real conditions, with real constraints, on a real codebase.

The interview said she understood the work.

It didn’t test whether she could do it.

That gap between knowing and doing is one of the most expensive gaps in tech hiring. It’s also one of the easiest to close before the search starts, not after the person’s already in the seat.

If your last hire surprised you once they started, it’s worth looking at what the interview was actually measuring.