Something never felt right#

I’ve always had a problem with technical interviews. They feel artificial, disconnected from reality, and frankly unfair. Judging someone’s abilities based on a few minutes of puzzle-coding under pressure? That’s never sat right with me.

Where it started#

Early in my career, I interviewed at a company for a C++ position. The experience conversation went well. The technical questions went well. Then, just as I thought we were wrapping up, the interviewer announced there would be a coding test.

I didn’t panic. I simply told him I wouldn’t do it—not in these conditions. I don’t code in a suit and tie (yes, showing up to interviews dressed like that was expected back then—times have changed). I didn’t have any of my usual tools on his machine. And I had just traveled 500 kilometers to be there—not exactly peak mental condition for solving puzzles. If he wanted a coding test, I’d be happy to do it from home, on my own computer, whenever he wanted. But not here, not now.

To my surprise, he didn’t just accept—he asked me to stay and made me an offer on the spot.

What’s wrong with technical interviews#

The problems with coding interviews are well documented, so I won’t belabor them. But a few things stand out.

Having someone watch over your shoulder while you code is uncomfortable at best, distracting at worst. Doing it without your own tools and environment adds to the friction. And being asked to “code under pressure” in a time-limited setting runs counter to what good programming actually requires: calm and concentration.

I’ve seen two flavors of technical interviews, and neither works particularly well. The first is when the interviewer presents a problem they encountered at work—something that took them days to solve properly—and expects the candidate to produce something meaningful in an hour. The second is the leetcode-style puzzle: interesting in isolation, but unlikely to resemble anything the candidate will ever encounter on the job. And easily gameable by anyone willing to grind through practice problems the week before.

Neither situation reflects the actual work. So what are we really measuring?

A better approach#

Over the years, I’ve conducted hundreds of interviews. What works best, in my experience, is far simpler—and far more revealing.

Ask candidates to describe two or three challenging or interesting problems they’ve worked on recently. Pick one yourself—ideally the one that intrigues you most or where you sense depth. Then dig in.

This approach tells you several things at once. First, you learn what they find challenging and interesting—which says a lot about their level and their taste. Second, by exploring the details together, you can probe the decisions they made, especially the ones you might have done differently. How do they justify their choices? How do they talk about mistakes? Do they own them or deflect?

This kind of conversation reveals how someone actually thinks, where their strengths lie, and whether they’re being genuine or embellishing. Yes, it’s more demanding for the interviewer—you have to engage deeply, follow threads, and think on your feet. But the signal you get is incomparably richer than watching someone fumble through a binary tree traversal on a whiteboard.

Does this scale as well as standardized coding tests? No. It requires more experienced interviewers, and there’s an element of subjectivity. But I’d argue there’s subjectivity in technical interviews too—it’s just hidden behind the illusion of objectivity.

The honest question#

I’ll be honest: at some point, I had a moment of doubt. What if I hated technical interviews simply because I couldn’t pass them? It’s a fair question—and one worth confronting honestly.

So I swallowed my pride, steeled myself, and applied to a GAFAM-tier company. I went through the gauntlet: the leetcode prep, the system design rounds, the whole thing.

Still here? Want to know how it went?

I got hired. And I still hate technical interviews.