I ran the technical interview for about twenty candidates. Here's why the capable ones got turned down.

I've sat on the hiring side of about twenty technical interviews at a startup, for backend, AI, automation and web roles. Twenty is a small number by a recruiter's standards and a large one for how much it changes your view. We were never really testing what you knew. We drilled into whatever you claimed until we found the edge of it, because everybody has an edge and it doesn't take long to find. What we were watching was what you did once we got there.

Most of the rejections I was part of were decided in that moment. None of those candidates were ever told so.

What the technical interview was actually doing

Fifteen to twenty minutes. Sometimes a basic LeetCode question, mostly not. The rest was questions about whatever the candidate said they knew, then questions about their answers, until the answers ran out.

Usually two of us. One asks, the other watches. Worth knowing if you're on the other side of it: the person who isn't talking is listening to how you answer, not only what you answer, and can pick up a thread the first one let go.

Nothing was written down. No scorecard, no form, no weighted criteria. What stayed the same from one candidate to the next was the method: find the edge of what somebody claims, then watch what they do there. My colleague and I talked for a few minutes afterwards and produced one judgement, can this person do the job or not. A team lead speaks to them after us, but the two of us were about ninety per cent of the decision.

That matters because it explains what candidates get wrong. People walk in braced for a knowledge test and treat every pause as a mark against them. They stutter, they apologise for thinking, they rush to fill the silence. None of it was ever the thing. We were hiring someone to do a job, not a reference manual. Take a moment to think, as long as it's visible that thinking is what's happening.

Getting into the room is a separate problem, and I wrote about how a referral got me into mine.

The answer that ended it

A candidate for a backend engineering role had a data analytics pipeline on his CV, handling analysis over millions of records. That's a strong claim, so we asked about it.

What did the pipeline look like?

He said you apply a filter and fetch the data from the database.

That isn't an answer. It's the shape of one. So I made it concrete: say a million orders come in every month and you need to show analysis on returns and revenue across all of it. How do you handle that?

Just pull from the relevant table, he said.

I told him a query like that gets very slow at that size and wouldn't hold up in production. He had nothing after that.

So I told him about aggregation tables. You precompute the rollups you need on a schedule, instead of scanning the raw rows every time somebody opens a dashboard. Postgres has materialised views for exactly this.

I told him because I wanted to see what he'd do with it. A backend engineer who hasn't met aggregation tables is normal and easy to fix, and handing somebody a concept mid-interview is the quickest way to see how they take one on. What came back was "yeah, we can do that." Nothing else. No question of his own, no request to say more. We moved on.

That second part mattered more than the first. Not knowing was survivable. Being handed the answer and showing no interest in it was not. He was rejected.

What to say when you don't know the answer

Everybody reaches the end of what they know in a technical interview. That's the design. The only question is what you do when you get there.

The version that works is unglamorous:

1. Ask a question to clarify what's actually being asked.
2. Get to a partial answer if you have one.
3. Say plainly what you've worked with and what you haven't.

Say you're asked the difference between webhooks and polling and you don't have the distinction ready. Tell me what a webhook is, you probably know that. Then tell me you've never integrated polling anywhere. That's a complete answer, and it costs you nothing.

Most people have already done the thing being asked about and just don't know the word for it. They've written the code that checks an endpoint on a timer. Nobody ever called it polling in front of them. Go quiet when the term lands and a vocabulary gap looks exactly like a knowledge gap from where I'm sitting. Describe what you built and let me match it to the term, and we both find out you knew it. That only works if you talk.

The candidate who knew the most and did not get the job

The strongest technical fit I've interviewed was rejected. That interview taught me more than any of the others.

He knew automation thoroughly, better than anyone else we saw for the role. Then we got onto concepts he hadn't worked with, which happens to everyone, and instead of saying so, he made answers up. We corrected him. He responded as though the correction had been his point all along.

I wouldn't file that under rudeness. Almost nobody thinks of themselves as rude, so you'd skip the section. It's narrower than that. He couldn't concede. Every correction came back as something he'd meant all along, and after a few rounds of it the useful part of the conversation was over. If I can't tell you you're wrong, I can't work with you. That isn't a personality preference. It's most of what code review is.

We hired someone else, the weaker automation engineer on the day. He was honest about where his experience stopped, asked sensible questions, and was straight about what he could and couldn't do. He picked things up fast once he started, and the team is very happy with him.

The gap between those two outcomes wasn't technical. It cost the stronger engineer a job he was qualified to do.

Why nobody tells you why you were rejected

This is the part I'm least comfortable defending.

A rejected candidate hears that we'll discuss it and get back to them. What usually follows is silence. I don't have a good answer for that, and I'm not going to pretend the place I work is an exception, because almost nowhere does this well.

The automation candidate walked out with no idea the reason was how he handled being corrected. Nothing stops him doing it again in the next interview, and the one after. He'll decide the market is brutal, or that he got unlucky. The real reason was specific, fixable, obvious to both of us within a few questions, and nobody will ever mention it to him.

I don't think the decision was wrong and I'd make it again. But the decision and the silence are two different things, and only one of them is defensible. The cost of the second lands entirely on the person who least deserves it.

So assume you'll never be told, and work backwards. If you're reaching final rounds and not converting, the problem probably isn't what you've been revising. Nobody rejected you for pausing before an answer. They rejected you for claiming something you couldn't support, or for what you did when that got found out.

Claim only what you've actually done. When you hit the edge of it, say so out loud. When someone corrects you, let the correction stand. The interview isn't testing whether you know everything. It's testing whether you can be told.