The most important interview of my career happened over a paper cup of coffee, in a quiet corner, with a man who told me only his first name. I did not know it was an interview. That, it turned out, was the entire point.
The invitation had come from an event-management company, so it took me a while to work out who was really behind it: one of the MAANG companies, hosting a hiring event in Tokyo. I had always been curious about the giants, how they actually run, how the people inside them think. So I went, to network, to see the inside, and maybe to find a role that fit.
The office was exactly what you picture. Glass walls, digital displays, the quiet hum of expensive air conditioning, and a room full of engineers all hoping to break into the tech elite. We moved through a few rounds of interviews and introductions, and then we were given a short break. I took a coffee to a quiet corner. A little while later an older gentleman with a calm, unhurried way about him sat down nearby, and we started to talk.
The small talk did not stay small for long. We drifted into the theme of the event itself, search engines, and I told him how much I admired the complexity hiding inside them, especially the language side. We pulled on that thread for a long time: how you teach a machine to handle ambiguity, how context bends meaning, and the particular cruelty of a language like Japanese, where a single sentence can flip on a point of syntax. I had spent years building search systems in Japan, so none of this was theory for me, and he could tell. He nodded, pushed back, added insights of his own. It felt less like networking and more like two people who had found the same puzzle fascinating and could not put it down.
As we stood to go, he smiled and said something I did not expect. "You understand search deeply, especially the language part. Have you thought about our senior engineering roles? You would be a good fit." And that is when it landed. He was not another attendee waiting his turn. He was a hiring manager, and for the better part of an hour I had been making the strongest possible case for myself without once feeling like I was being judged.
The interview had not looked like an interview. It had looked like a good conversation, which is the only kind I have ever been any good at.
I applied, of course. A few days later the next step arrived: a coding challenge, a single dynamic-programming problem, on a timer. And despite the better part of two decades solving real problems in production, I struggled with it. The challenge was built for someone who had spent the previous three months drilling algorithmic puzzles, not for someone who had spent two decades understanding how systems actually behave. It was disconnected from almost everything the job itself would ever ask.
I did not get the role. I want to be honest about both halves of why. Part of it was on me. I knew these gauntlets existed, I knew how to prepare for them, and I had chosen not to spend my evenings grinding through practice problems. That was a choice, and choices have costs. But part of it was the process, and that part is worth naming carefully. A standardised coding puzzle is a filter built for scale. When thousands of people apply, it is cheap to run and easy to defend, and I genuinely understand why companies reach for it. What it measures, though, is recent and narrow practice. What it cannot see is judgment, domain depth, and how a person reasons when a problem is ambiguous and underspecified, which is to say, all the things the conversation over coffee had just revealed.
That is the part I keep turning over. Talking to me as one engineer to another, the hiring manager saw exactly the person he wanted to hire. The automated gate his own company had built screened that same person out within the week. Both were that company's hiring process. They simply did not agree with each other. I have written elsewhere about what actually makes an engineer excellent, and almost none of it shows up on a timed puzzle.
I do not tell this as a complaint, and I am wary of the version of it that is only sour grapes. I walked away with something more useful than the job: a clear view of the gap between how we talk about evaluating engineers and how we actually do it. So if you are early in your career and a coding gauntlet has just told you that you are not good enough, take it from someone it also turned away. Learn the puzzles if the door you want is locked behind them, by all means. But do not mistake passing the filter for being good at the work. So much of an interview is decided before you walk in, and this was the rare time it had already been decided, in a hallway I had not realised was the room.
Understand your domain first. The turnstile you can learn to walk through later.