Architect in the Cloud

Most technical interviews test memory, storytelling, and luck. None of those predict job performance.

I've sat through hundreds of technical interviews — from both sides of the table. As a candidate, as an interviewer, as the architect brought in to "grill them on the technical stuff." And somewhere along the way, I stopped believing the format actually works.

We've built an interview industry around questions that feel rigorous but mostly reward people who are good at interviewing. That's not the same thing as being good at the job.

"Tell me about a time" is a memory test

Behavioral interviewing became the default because it promised something useful: real evidence of past performance. In theory, if someone has actually done the thing, they'll have a story for it.

In practice, you're testing something else entirely. You're testing whether the candidate can remember a relevant situation under pressure, compress it into a tidy narrative, and deliver it in under three minutes without stumbling. That's a storytelling skill. It's a real skill — some jobs genuinely require it. But it's not the skill most engineering roles actually need.

Worse, the format actively rewards embellishment. Give a strong candidate a question they don't have a clean answer for, and they'll either freeze or quietly upgrade a past experience into something more impressive. I've watched people do both. I've done both. The person with a slightly weaker real story who tells it honestly loses to the person with a slightly stronger fake one who rehearsed it.

If you want to know how someone thinks, ask them how they'd think about something. "How would you handle…" does the work "Tell me about a time" pretends to do. It lets you see their actual reasoning, in real time, on a problem you control. You can probe. You can push. You can tell the difference between someone who's worked through problems like this before and someone who's guessing.

Scenarios aren't perfect — a candidate can talk a good game without being able to execute. But at least you're evaluating how they think, not how well they tell a story.

Don't ask them to write code cold

The on-the-spot coding question is the worst offender. You open a shared document, paste in a problem the candidate has never seen, and wait for them to produce clean, working code while you watch.

I'm genuinely not sure what this is supposed to measure. The odds that the candidate has encountered your specific problem before are slim, and writing unfamiliar code in front of strangers bears no resemblance to the job. Nobody on your actual team works this way. Nobody.

What you get in return is one of two bad outcomes. Either the candidate spends most of their time anxiously mapping syntax to the problem — which tells you how well they memorize language quirks, not whether they can solve problems. Or they've quietly prepared with an AI tool in another window and are feeding it your prompt. You don't know which one you got. Neither tells you what you wanted to know.

And the candidates who can produce elegant code from a cold start on an unfamiliar problem? They're rare — and rarely rare for the reasons you think. Often it's because they've seen the exact problem before, on a prep site, in a previous interview, or in a different codebase. What you mistook for brilliance was recognition.

If you genuinely need to see someone write code, send the problem ahead of time. Give them a few days. Let them work the way they'd work at the job — tools on, references available, thought applied. Then talk about what they did. That's a conversation worth having.

Ask them to walk you through the problem

When I'm actually trying to evaluate someone's engineering ability, my favorite prompt is some version of: "Walk me through how you'd get to an answer."

Notice what I'm not asking for. I'm not asking for the answer. The answer, honestly, doesn't matter much. What matters is the shape of the thinking.

How do they frame the problem? Do they ask clarifying questions or charge ahead on assumptions? What resources do they reach for — documentation, a colleague, an AI assistant, a Stack Overflow search, a quick prototype? How do they validate that their approach actually works? When they hit something they don't know, do they shut down or route around it?

This is the job. This is what the work actually looks like. Nobody sits in a quiet room writing perfect code from memory. They use their tools. They talk to their team. They search, they read, they prototype, they ask. The best engineers I've worked with aren't the ones who know the most — they're the ones who can navigate toward a well-reasoned solution fastest, using every resource available to them.

If your interview process punishes candidates for using those same resources, you're screening against the very skill you most want to hire for.

The bottom line

The technical interview isn't broken because it's too hard. It's broken because it's measuring the wrong things. It rewards rehearsed storytelling over clear thinking, cold recall over resourcefulness, and performance under artificial pressure over the kind of work people actually do.

If you want to hire well, ask questions that reflect the job. Show candidates scenarios and see how they reason. Give them coding problems ahead of time and talk through their choices. Focus on process, not polish. And stop pretending that a stressed person at a whiteboard is a meaningful preview of what they'll bring to your team on a Tuesday afternoon.

The goal isn't to find the candidate who interviews best. It's to find the candidate who'll do the best work.