You've been here before: three rounds in, the candidate has sailed through system design, impressed your senior devs, and articulated trade-offs like they wrote the CAP theorem themselves. You extend an offer. Two months later, they can't ship a basic feature without hand-holding. The resume said Netflix and AWS. The interviews were flawless. The output is junior at best.

Here's what changed: the barrier between appearing competent and being competent has collapsed.

The résumé is now a creative writing exercise

Résumés were always a weak signal, but they had some correlation to reality when you could verify claims through basic questioning. That's gone.

Today's job seekers have fine-tuned their profiles using ChatGPT, optimized for ATS keyword density, and mirrored language from senior engineering job descriptions. A mid-level developer who refactored one microservice now lists "Led architecture overhaul of distributed systems at scale." A contractor who used Kubernetes in production for three months becomes "Principal DevOps Engineer specializing in container orchestration."

It's not dishonesty in the traditional sense. It's optimization. And your screening process is selecting for the best optimizers, not the best engineers.

The same applies to portfolios. GitHub contributions can be fabricated, side projects can be copy-pasted from tutorials, and open-source contributions might be trivial documentation fixes presented as core maintainer work. The surface looks identical whether someone is legitimately senior or has spent two weekends polishing their online presence.

Interviews now select for performance, not capability

The second filter, your interview loop, has been similarly compromised.

Candidates now prep using Blind, Leetcode討論區, and even services that provide real interview questions leaked from your own company. They've memorized system design templates: "First I'd use a load balancer, then partition by user ID, add Redis for caching, maybe Kafka if we need event streaming." It sounds right. It checks the boxes. But it's a script, not synthesis.

Pair programming and whiteboarding sessions? Same issue. Candidates practice these formats explicitly. They know the rhythm, the pacing, when to "think out loud," when to ask clarifying questions to seem thoughtful. They've learned the performance of engineering, which is not the same as engineering itself.

And smooth talkers dominate here. The developer who can't debug a null pointer in production but can eloquently discuss the philosophical implications of microservices versus monoliths. The architect who's never actually migrated a database but can whiteboard a flawless multi-region failover strategy.

Your interviews are now testing communication and pattern recognition under controlled conditions, which is why they correlate poorly with on-the-job success.

AI made this exponentially worse

Pre-ChatGPT, faking competence required effort. You had to actually learn enough to bluff convincingly. Now the effort is trivial.

A candidate can paste your take-home assignment into Claude, get a working solution with tests and documentation, and submit it as their own work. They can have an LLM generate answers to your technical screening questions in real-time during a phone call. They can even use AI to simulate the "thought process" you're looking for, complete with false starts and debugging narration.

The result: your signal-to-noise ratio is inverted. You're now getting hundreds of applications per role, most of which look credible on the surface because AI smoothed out the rough edges that used to separate strong candidates from weak ones.

What you're actually selecting for

When you optimize your hiring process around résumés and interviews, you're not selecting for engineering ability. You're selecting for:

• Time availability to prep: Candidates who can spend 40 hours grinding Leetcode and system design problems. This biases against experienced engineers who are employed and can't dedicate evenings to interview prep.

• Interview-specific skills: Fast talking, whiteboard comfort, the ability to recall memorized patterns under pressure. These correlate weakly with shipping production code.

• Presentation over substance: The developer who can sell their past work effectively, not the one who actually did the hardest technical lifting but doesn't know how to package it.

You end up hiring people who are good at interviewing, not good at the job.

The depth problem

Here's the real risk: polished candidates are optimized for breadth, not depth. They know the right words for everything—eventual consistency, idempotency, circuit breakers—but collapse when asked to implement any of it under real constraints.

Try this experiment: instead of asking a candidate to explain how they'd design a caching layer, give them a slow API, a database, and 20 minutes. Tell them to actually implement a fix and walk you through it. Watch how many can't.

The smooth talker knows caching exists. The effective engineer knows when not to cache, how to invalidate correctly, and what happens to your cache during a deployment. Those are different kinds of knowledge, and your current process can't distinguish between them.

The cargo cult effect

There's a second-order problem here: polished bad hires create more polished bad hires.

They get through your process, join the team, and then participate in hiring the next batch. They select for people like themselves—others who interview well and speak fluently about engineering without necessarily doing it effectively. Over time, your bar drifts downward while your interview performance metrics stay high.

You realize this six months later when velocity drops, incidents increase, and your best engineers start quietly looking for exits because they're spending more time cleaning up messes than building.

What actually works

If résumés and interviews are compromised, what's left?

Watch them work. Not in a fake whiteboard setting, not on a toy problem, but doing something as close to the actual job as possible.

Give them a real bug in a real codebase with real logs and see if they can isolate the root cause. Give them a slow database query and see if they can optimize it. Give them a deployment that's failing and see how they debug it. Then watch their process: do they ask about constraints? Do they consider edge cases? Can they explain their trade-offs clearly?

This isn't a take-home assignment where they disappear for a week and return with something that may or may not be their own work. It's a short, observed task that shows how they think, how they use tools, how they handle ambiguity, and whether they can actually do the job.

The candidates who look great on paper but can't perform? They disqualify themselves in 20 minutes. The ones who are rough around the edges in interviews but can ship? They reveal themselves as exactly who you need.

Polished résumés and smooth talkers aren't just noise anymore. In a world where AI can fake the surface-level signals you've been relying on, they're actively dangerous. The only reliable signal left is watching someone do the work.