The Hiring Bar Is a Lie You Tell Yourself

It was 2:47 on a Tuesday — interview day — and I was staring at my calendar with the quiet resignation of a man who’d done this to himself. Eight interviews. Every Tuesday. For a year. My department at Agoda was hiring so fast and furious that the following year leadership told us to stop entirely — we’d doubled the team in twelve months. The only mercy was that roughly one in eight candidates cancelled, which meant I got a single hour each Tuesday to walk the floor and check if my actual teams needed anything. My coffee was cold. It had been cold since 9 AM.

That year was intense, but it was just one chapter. Over the decade-plus before and after — across companies, countries, and countless hiring cycles — I’ve watched the same dysfunctions play out again and again. Sometimes it’s the process itself that’s broken. Sometimes the process is fine but the people ignore it, substituting gut feel for the structure that’s supposed to protect them. Sometimes it’s interviewers who’ve never been taught how to interview, running on instinct and pattern-matching to people who remind them of themselves. The common thread isn’t one dramatic failure. It’s a slow, persistent realisation: most interview processes are remarkably good at identifying people who are good at interviews.

The Comfortable Lie

Here’s the thing about “maintaining a high bar” — it’s the most reassuring phrase in engineering management. It implies rigour. Standards. Selectivity. It sounds like something a serious company does. But when you peel back what most interview processes actually test, you’ll find something uncomfortable: they test performance under artificial pressure, the ability to recall algorithms on demand, and a particular flavour of cultural conformity that has very little to do with building software.

As the sociologist William Bruce Cameron observed, “Not everything that can be counted counts, and not everything that counts can be counted.” We’ve built interview processes that are spectacularly good at counting the wrong things.

We learned this the hard way. In those early hyper-growth days, we focused heavily on algorithms and platform knowledge. The result? We hired a bunch of incredibly smart people with virtually no soft skills. They could invert a binary tree in their sleep but couldn’t navigate a disagreement without escalating it to their manager. A few years later, Facebook started hiring with the same algorithmic focus, and guess what happened? They poached half of them. It turns out that when you select for a narrow set of technical parlour tricks, you end up with people whose loyalty is to whoever offers the next, slightly harder parlour trick.

What You’re Actually Testing

Let’s be honest about what the standard engineering interview measures. You bring someone into an unfamiliar environment, sit them across from a stranger with a laptop, and ask them to solve problems they’d never solve this way in their actual job. Nobody writes code on a whiteboard at work. Nobody implements a red-black tree from memory in production. Nobody solves algorithmic puzzles while someone watches them and takes notes.

What you’re testing is composure under surveillance. You’re testing how well someone performs when they’re anxious, observed, and stripped of every tool and resource they’d normally have. You’re testing whether they practiced LeetCode last weekend.

Your tech lead with fifteen years of experience might not be able to tell you off the top of his head how the event loop works in Node. But when you’re in a war room at 2 AM troubleshooting an obscure JVM error, you want him in the room. You want the person who’s seen enough systems fail in enough ways that they can pattern-match their way to a diagnosis while everyone else is still reading stack traces. Your interview process should account for this. Test people’s knowledge of your tech stack, absolutely — but that shouldn’t answer “should I hire this person?” It should answer “what is their starting level and salary.” Your tech stack is something someone can learn.

Which brings us to the most important thing you can hire for: the ability to learn.

Don’t Discount What You Don’t Recognise

Years ago, we interviewed a guy whose entire background was essentially IoT — before anyone was calling it IoT. Embedded systems, microcontrollers, sensor networks. He went through our React and frontend platform round and failed it. On paper, that should have been the end of the story.

But my boss picked up the CV, looked at it for a while, and said, “I want to talk to this guy.”

After a long conversation with him, my boss came back and explained what he’d found. This engineer had everything we needed. The principles he’d been applying to microcontrollers — redundancy, fault tolerance, graceful degradation, even patterns that mapped directly to service discovery — were the same principles we used in production for web-scale systems. He nailed every one of them. He just knew them in a different context. The vocabulary was different, the platforms were different, but the thinking was identical. The only thing we actually needed to teach him was C#.

The lesson stuck with me: just because someone can’t tell you where a reducer and an action go in Redux, don’t discount them yet. Your tech stack is a dialect. The underlying engineering language is what matters, and that language transfers across contexts in ways that a platform-specific checklist will never reveal. If my boss hadn’t looked past the failed frontend round, we’d have missed someone who understood distributed systems at a level most of our “passing” candidates didn’t.

Testing for Curiosity

How do you test curiosity in an interview? How do you measure someone’s capacity for growth in sixty minutes? You can’t do it with a checklist. But you can create situations that reveal it.

I’ll give you one of my favourite techniques. Over the years, I’ve learned at least one obscure detail on most platforms — something that roughly eighty percent of engineers who work on that platform will get wrong. For example, if someone tells me they use Docker to deploy their applications, I’ll ask them what a multi-stage Dockerfile is and where they’d use one. Infrastructure engineers will nail this. Regular engineers who use Docker daily? Maybe twenty percent.

What I’ve done is simple: I’ve given them a question they don’t know the answer to, but I do. And there are exactly three responses that matter:

They make something up. Immediate red flag. This isn’t just about Docker knowledge — it’s about what they’ll do after a production incident. You’ve just discovered someone who will fabricate explanations to save face rather than admitting uncertainty. That behaviour doesn’t stay in the interview room. It follows them into post-mortems, into architecture discussions, into every moment where honesty matters more than ego.

They admit they don’t know. Green flag. You’ve found an honest person. They can be wrong and own it, which means they can grow. They won’t waste your team’s time defending a bad decision because they’re afraid to look fallible.

They admit they don’t know and ask you to explain it. Big green flag. You’ve found someone who is genuinely curious. These are the people who will read the documentation nobody else reads, who will ask the question in the architecture review that everyone else was too embarrassed to ask, who will go home and learn about multi-stage Dockerfiles because now they’re bothered that they didn’t know. It’s not definitive — nothing in hiring is — but it’s directional.

As Maya Angelou put it, “When someone shows you who they are, believe them the first time.” In an interview, the how of someone’s response tells you infinitely more than the what.

Stop Giving Exams, Start Having Conversations

Another common flaw I see everywhere: the checklist interview. You have a list of things you need, you check them off, and you hire the person who ticks the most boxes. This is comfortable. It feels objective. It’s also a terrible way to discover what someone can actually bring to your team.

Here’s what I do instead. I ask them about what they’re currently working on.

First: “Explain to me at a high level what you’re building and what it does.” How they answer this is as important as what they say. Do they start drawing me a UI? That tells me something about where their mental model lives. Do they immediately jump to the tech stack? That tells me something too. Do they explain the business case, how it adds value to the company, why it matters? That’s a big green flag — they understand context, not just code.

Second: “Now that I understand this, draw me a diagram of what pieces it has and how they talk to each other.” Do they start with the internals of a single system? Do they draw a cylinder and a square and then stall because they’ve never thought about what exists beyond their service boundary? Or do they draw a complete picture — every system, the infrastructure, load balancers, message queues — and then we can have a real conversation about trade-offs, failure modes, and improvements?

The more they explain, the more I push for details. I ask questions that dig into decisions. If they draw a line to a payment gateway, I’ll ask: what happens if the call fails? Do you retry? How do you avoid duplicate transactions when the failure was a timeout? Deduplication tokens? Green flag. Every layer of depth they can go tells me where their knowledge actually sits — not where their LeetCode practice sits.

Gregg Popovich, the winningest coach in NBA history, describes his approach to evaluating players this way: “I want to know about the fiber of an individual.” The Spurs’ scouting philosophy centres on a single question: has this person “gotten over themselves?” They watch how draft prospects react to coaches and teammates in practice, not just how they perform in the showcase. Popovich didn’t build a dynasty by selecting the most athletically gifted players in controlled tryouts — he built it by finding people whose character could survive the pressure of a real season. Your interview should work the same way.

The AI Elephant in the Interview Room

Now, about the elephant that’s been growing steadily larger in every interview room since 2023: AI.

If you come to an interview with a checklist of questions, yes, someone using AI can destroy your process. They can memorise perfect answers. They can generate flawless code. They can sound like they understand architectural patterns they’ve never implemented. Your carefully constructed technical gauntlet becomes theatre.

But the approach I’ve described — asking people about their own work, digging into their own decisions, having a conversation rather than administering an exam — doesn’t have that vulnerability. Nobody can use ChatGPT to explain why their team chose eventual consistency over strong consistency for their specific use case. Nobody can prompt their way through a follow-up question about a failure mode in a system they actually built.

In our coding interviews, sixty percent of the evaluation is talking: why did you implement it this way? What if you did it another way? Did you consider this trade-off? Choose whatever language you like — we’re not testing syntax memorisation, we’re testing thinking. Your greatest defence against AI undermining your interview process is to stop giving people exams and start talking to them about what they know.

The Culture Question Nobody Wants to Ask

Here’s the part that makes people squirm: you need to test for culture. Not “culture fit” in the Silicon Valley sense of “would I want to grab a beer with this person” — that’s how you build homogeneous teams that can’t handle disagreement. I mean the hard questions about how someone operates under real working conditions.

What are they going to do when they face an argument? Can they disagree and commit? If they can’t get their way, how will they react? Are they comfortable giving feedback? Speaking up in large groups? These aren’t nice-to-haves. These are the difference between a team that can ship under pressure and a team that fractures the moment someone’s approach gets challenged.

When we focused purely on technical brilliance and ignored these questions, we hired people who could individually outperform anyone in the room but couldn’t function as part of a team. You don’t want a collection of solo virtuosos — you want a band that can improvise together when the set list goes out the window.

The Bottom Line

Your interview process is a mirror. It reflects not what you value, but what you’ve optimised for — and those aren’t always the same thing. If you’ve optimised for algorithmic recall, you’ll get people who are good at algorithms, and possibly memorizing LeetCode. If you’ve optimised for composure under artificial pressure, you’ll get people who perform well in artificial settings. If you’ve optimised for checklist completion, you’ll get people who tick boxes.

But if you optimise for curiosity, honesty, contextual thinking, and the ability to communicate about real work — you’ll get people who can actually build things. People who can learn your stack, grow with your team, and contribute in ways that a LeetCode score could never predict.

Google’s own research found that structured, conversational interviews are significantly better at predicting job performance than the brainteaser-style questions they were once famous for. They abandoned the clever puzzles. They stopped asking how many golf balls fit in a school bus. They started asking people to talk about their work, their decisions, their thinking. The data was unambiguous: conversations predict performance; exams predict exam-taking ability.

The hiring bar isn’t a lie because standards don’t matter. It’s a lie because the bar is measuring the wrong thing. You’ve built a high-jump competition and you’re confused about why the winners can’t play basketball.

Now, if you’ll excuse me, I’ve got a Tuesday coming up. Only six interviews this time. Progress, I suppose — though I still haven’t figured out how to keep my coffee warm past the second one.