You've sat through another interview where the candidate talked a great game. They dropped the right buzzwords, referenced popular frameworks, and their resume looked impressive. Three months later, they're stuck on basic debugging and your senior devs are doing their work.

The problem isn't that candidates lie—it's that our methods for spotting genuine skill are fundamentally broken. Here are the real warning signs I've learned to watch for.

They explain the "what" perfectly but fumble the "why"

A developer who's actually built systems can tell you why they made specific choices, not just what those choices were.

Ask them about a past project and listen carefully. If they say "we used Redis for caching," that's surface level. A real engineer will tell you "we used Redis because our read-to-write ratio was 100:1 and our cache hit rate needed to stay above 95% to keep response times under 200ms."

The fake will recite documentation. The real one will talk about constraints they faced and tradeoffs they considered.

When someone describes their architecture decisions without mentioning a single constraint or limitation, they probably weren't the one making those decisions.

They can't walk you through a failure

Every developer who's shipped real code has broken production. If they claim they haven't, they're either lying or they've never touched anything that mattered.

But here's the key: genuine engineers remember their failures in detail because they learned from them. They'll tell you exactly what broke, why it broke, how they debugged it, and what they changed afterward.

The faker will give you vague stories about "system issues" or blame external factors. The real engineer will own it and explain the second-order effects they didn't anticipate.

I once asked a candidate about their worst production bug. He spent ten minutes walking me through a race condition in their payment processing system, the specific lock ordering that caused it, and why their initial fix actually made it worse. That level of detail only comes from living through it.

They struggle to justify technology choices

Ask why they picked Kubernetes over plain Docker, or Postgres over MongoDB for a specific use case. A developer who actually made that choice will have concrete reasons tied to specific requirements.

The warning sign isn't wrong choices—it's no reasoning at all.

"Everyone uses Kubernetes" or "MongoDB is more scalable" are red flags. Real engineers will tell you things like "our deploy frequency was 20+ times per day and we needed zero-downtime rollbacks, which ruled out our previous setup."

They'll also tell you what they gave up. Every technical decision has a cost. If they can't articulate what they sacrificed, they didn't make the decision.

They reference scale they've never operated at

This one's subtle but deadly. A developer will mention they "built a system that handled millions of requests per second" but then can't explain basic distributed systems concepts like eventual consistency or partition tolerance.

Real scale teaches you specific lessons. Someone who's actually dealt with high-traffic systems will talk about database connection pooling limits, the pain of debugging across multiple instances, or that time they learned about TCP TIME_WAIT states the hard way.

The faker talks about scale as an achievement. The real engineer talks about it as a constraint that shaped every decision they made.

They can't debug on the spot

Give them a production error log or a failing API response and watch what they do. A real developer will start asking questions and forming hypotheses immediately.

Red flags here:

• They jump to solutions before understanding the problem

• They suggest "restart the server" without investigating

• They can't form a hypothesis about root cause

• They don't know what additional information they'd need

Strong engineers have a debugging process. It might not be formal, but it exists. They check logs, reproduce locally, isolate variables, and form theories they can test.

Someone faking it will either freeze or throw out random suggestions hoping one sticks.

Their AI usage is backwards

Here's the controversial one: in 2025, I'm more worried about developers who refuse to use AI than those who use it too much.

The red flag isn't using ChatGPT or Copilot. It's using them without understanding the output.

A competent developer uses AI to speed up boilerplate, explore unfamiliar APIs, or generate test cases. They read what it produces, verify it makes sense, and modify it to fit their context.

The faker copies AI-generated code wholesale, can't explain what it does, and doesn't know how to fix it when it breaks. When you ask them to modify the code, they go back to the AI instead of editing it directly.

Real skill in 2025 is knowing when AI output is wrong and being able to fix it. That requires understanding the fundamentals the AI is automating.

They've never questioned their own code

Ask a developer what they'd change about code they wrote six months ago. If the answer is "nothing," they're either lying or they haven't grown.

Every engineer I respect looks back at their old code with at least mild embarrassment. They see the abstractions they got wrong, the edge cases they missed, or the complexity they should have avoided.

This isn't about self-deprecation. It's about continuous learning. Developers who are actually good know how much they still don't know.

The faker will defend every choice they've ever made or claim their old code was perfect. The real engineer will tell you exactly what they'd refactor and why.

The real problem

These red flags exist because most technical interviews test the wrong things. We ask people to write algorithms on whiteboards or answer trivia about framework internals, then act surprised when we can't tell who's actually competent.

You can't spot fake expertise by asking questions someone could have memorized last week. You spot it by watching how they work through real problems with incomplete information and conflicting constraints.

That's not something you can fake. Not yet, anyway.