Last week I wrote about getting rejected from a job for "relying on AI" in the coding round — by an interviewer I'd watched read an AI answer off his own screen forty minutes earlier. I thought the story was about hypocrisy.
Then a reader replied with something sharper, and it reframed the whole thing for me.
He'd been through the opposite version. Told "please, no AI," so he stuck to it — and blanked on a manual code review of a file that couldn't even compile, because of external calls he was never shown. He walked out certain he'd be lowballed. And buried in his comment was the sentence that's been rattling around my head since:
The interview isn't for judging competence. It's for judging value — and for seeing how far they can degrade your perceived value before they name a number.
I read that and something clicked into place that my own rejection had only hinted at.
So I did the thing the rejection process never lets you do: I put it on the table and interrogated it. Not the interviewer — the machine. Two rounds, mine and his, treated as evidence about what the whole apparatus is really built to do. Here's what their hiring process is actually optimizing for.
Both of us walked into our rounds thinking the same thing: this is a competence test. Prove you can do the work.
The company already believes you can probably do the job — your résumé got you in the room, your GitHub is right there, they can read. What they don't know yet is the one number that decides whether hiring you is a good deal: how little you'll accept. And the interview is the instrument they use to find it.
Once you see it that way, a lot of otherwise-baffling interview behavior snaps into focus.
The ideal interview outcome for the company is not "flawless candidate." A flawless candidate is expensive. If you sail through every stage, you walk into the offer conversation with leverage, and you'll refuse a lowball because you have every reason to.
The ideal outcome is a candidate who is clearly good — good enough to hire — but who fumbled exactly one thing. Not zero (then they can't discount you). Not everything (then there's no offer). One clean, legible stumble. Because that one stumble is the whole negotiation:
"You're strong. Really. But you're not quite as senior as you think — remember that code review? So here's what we think you're worth."
And you, still stinging from the one thing you got wrong, nod and accept a number well under where you walked in. The stumble wasn't a bug in the interview. It was the product.
You want to know whether an interview is measuring your competence or pricing your floor? Listen to how they ask about money. "What are your salary expectations?" asks for your ceiling — the most you think you're worth. "How much do you currently earn?" asks for your floor — the least they can get away with.
Guess which one gets asked. Nearly every time, it's the second. They are not trying to find out what you're worth. They're trying to find out what you'll settle for — and anchoring the entire offer to a number from your past instead of the value in front of them.
That single swap tells you which game is being played. It was never "can you do this." It was always "how little can we pay you to."
Walk in and bring real value — spot the bottlenecks their own team hasn't named out loud, demo something that plugs straight into their stack and beats what they're running now, watch the interviewer get visibly taken aback by how much you see. That's the entire job. That's the thing that's supposed to be rare and worth paying for.
Then fumble one manual code review — reading a file cold that can't compile because of calls you were never shown — and that gets to veto all of it. Not because it revealed you can't do the work. Because it handed them the discount they needed.