7 signs a candidate can actually code vs. just talk about coding

Jun 1, 2026

Contents

Key Takeaways

The strongest engineers distinguish themselves through judgment, not coding speed—they seek context, clarify constraints, and understand the problem before choosing a solution

Debugging ability is one of the most reliable indicators of real engineering skill; strong candidates investigate systematically, form hypotheses, and use evidence rather than guessing or making random changes

Great engineers can explain the tradeoffs behind their decisions, balancing complexity, maintainability, performance, and business constraints instead of defaulting to “best practices” without context

The ability to navigate unfamiliar codebases, modify existing systems safely, and understand code written by others is often more valuable than writing new code from scratch, yet rarely tested in traditional interviews

AI has shifted the hiring signal from code generation to judgment—what matters is not whether candidates use AI, but whether they can evaluate, adapt, and verify its output while making sound engineering decisions

Real-world work simulations reveal these behaviors far more effectively than algorithmic tests, whiteboards, or theoretical discussions because they expose how candidates think, debug, communicate, and execute under realistic conditions

Most technical interviews are optimized to find people who are good at technical interviews. That's not the same thing as finding people who can actually build software. After years of hiring engineers across multiple teams, here's what actually separates the builders from the talkers.

The core problem

Talking about code is easy. Writing it under artificial constraints, with artificial problems, while someone watches? Also manageable with enough practice.

But sitting down with a real codebase, real logs, and a real problem that doesn't have a clean answer? That's where the separation happens.

7 signs someone can actually code

1. They ask about constraints before writing a single line

A candidate who immediately starts typing is often performing. A candidate who asks "what's the expected load?" or "are we optimizing for read or write latency?" is engineering.

Real problems have context. Strong engineers surface it before they commit to a direction.

2. They read error messages instead of guessing

Watch what happens when something breaks. Weak candidates start changing random things. Strong candidates read the stack trace, identify the failure boundary, and form a hypothesis before touching anything.

Debugging is a skill entirely separate from writing code. Most interviews never test it.

3. They can explain the tradeoff they chose—not just what they chose

Anyone can pick Redis over Memcached. The question is whether they can articulate why, under these specific constraints, with these tradeoffs in mind.

Strong engineers say: "I went with this because X, even though it means we'll have to deal with Y later." Weak engineers say: "This is the standard approach."

4. They know when to stop over-engineering

Junior engineers add abstraction. Senior engineers ask if the abstraction is worth it.

If a candidate is building a factory pattern for a service that handles three use cases, they're optimizing for their portfolio, not your codebase. Real experience teaches you that the best code is often the boring code.

5. They can work with code they didn't write

This one is underrated. Most engineers spend the majority of their careers reading and modifying existing code, not writing greenfield systems. But almost no interview assesses this.

A candidate who can orient themselves in an unfamiliar codebase, identify the relevant module, and make a targeted change—without breaking unrelated functionality—is demonstrating a skill that takes years to develop.

Quick diagnostic: Drop a candidate into a real codebase with a failing test. Observe these five things:

Behavior	Strong Signal	Weak Signal
First action	Reads logs, explores structure	Starts writing immediately
When stuck	Forms a hypothesis, tests it	Changes random things
Communication	Explains reasoning out loud	Goes silent
Constraint handling	Asks questions	Assumes defaults
Completion	Ships something functional	Over-engineers or stalls

6. They use AI as a tool, not a crutch

In 2024, a developer who doesn't use AI tooling is leaving productivity on the table. But a developer who can't evaluate the output AI gives them is a liability.

The signal isn't whether they used Copilot or Claude. The signal is whether they understood what came back, caught the edge case it missed, and integrated it with judgment.

Banning AI from assessments doesn't test coding skill anymore. It tests who memorized the most syntax.

7. They slow down at the right moments

Experienced engineers have a sense for where the risk is. They move fast through low-stakes decisions and slow down when they're touching something that could cascade.

A candidate who deploys a schema migration without mentioning rollback, or who refactors a core service path without asking about test coverage, is missing something that experience usually teaches the hard way.

The uncomfortable gap in most hiring processes

The reason these signals are hard to observe is structural. Most technical assessments are designed to be evaluated at scale—multiple choice, algorithm puzzles, or whiteboard sessions that can be scored consistently.

But consistency at scale isn't the same as accuracy. You can run a hundred HackerRank tests and still not know if any of those candidates can debug a production incident at 2am.

The closest proxy to real job performance is watching someone do the actual job, or something close enough to it that the environment is honest.

What to actually take away

You're not looking for someone who can explain Dijkstra's algorithm. You're looking for someone who, when handed a messy system and a vague problem, can figure out what's actually wrong and fix it without making things worse.

Those are not the same person. Your hiring process should be able to tell the difference.