The Interview Problem

My team has been hiring lately — mostly new grads and engineers with a couple years of experience. The process is still the same old thing: background chat, then LeetCode.

Every time I run a phone screen and pull up a LeetCode question, I feel absurd. The people who pass might have just memorized the problem, or gotten help from an AI tool somewhere along the way — and I have no reliable way to verify it. The people who fail aren’t necessarily less capable. Maybe they didn’t memorize that particular problem. Maybe they were nervous. Maybe they just refused to cheat.

This bothers me.

Of course I want to find the right people for the team. Especially for entry-level candidates, I don’t think domain knowledge itself matters that much. Whether a fresh graduate knows a particular framework or API — that’s really not the core issue. Character, learning ability, communication, collaboration style, how they react to the unknown — those are what determine whether someone survives and shines on a team.

So what I can do is spend more time talking about their background, their projects, their knowledge structure, the choices they made and why. But here’s the problem: if they don’t solve the LeetCode question, I still can’t write a strong enough interview report to move them forward.

A lot of people treat interviews as an exam. I think that’s a classic test-taker mindset. An interview should be a two-way evaluation: the company is assessing the candidate, and the candidate is assessing whether this company and this team are right for them. Failing an interview doesn’t mean you’re inferior — it just means you’re not a match. That’s not a platitude. It’s objective fact.

Think about it: if an interview process makes you deeply uncomfortable, if it feels like a fraternity hazing ritual, do you really want to work there?

I understand that more offers mean more leverage, more peace of mind. But those are strategy, not the answer to what an interview should actually be about.

My personal interview criterion comes down to one question: if this person were your colleague, would you want to work on a project with them?

You could call that subjective, even arbitrary. But if I’m hiring for my team, this person will be one of the people I interact with most outside of my family. I have to choose someone who meets my subjective standards. Every team — every interviewer — will be different, because no two teams are the same, and no two people share the exact same preferences.

I look for people who are smart and open.

By “smart,” I mainly look at one capability: abstraction.

The ability to thoroughly understand a concept, strip away everything extraneous and meaningless attached to it, and see the essence — that’s abstraction. People with strong abstraction often encounter a situation: they perceive deep similarities between things that others completely miss. This isn’t mysticism. It’s a real gap in abstraction ability.

People with strong abstraction carry a conceptual map in their heads. They may not “grasp” a new concept as quickly as others do, because if they can’t break it down, abstract it, and place it in their knowledge system, they struggle to absorb it. But once they truly understand it, they wield it effortlessly and make connections naturally.

Openness determines a person’s capacity for collaboration and exploration.

Closed people can only execute within prescribed boundaries. Worse, they don’t like it when others step outside. “The industry does it this way — there must be a reason.” The moment that sentence becomes the endpoint of thinking, creativity dies. If that sentence were always correct, there would be no innovation in human history: we wouldn’t need steam engines, just horses. We wouldn’t need high-level programming languages, just more punched tape.

Open people are confident enough, while always holding one question in mind: what if I’m wrong?

I love a frequently-cited line: the mark of a first-rate intelligence is the ability to hold two opposing ideas in mind and still retain the ability to function. However that quote should be precisely attributed, I like what it means: truly open people aren’t without convictions — they just know their convictions might be wrong.

What AI Changed

The arrival of AI has changed a great deal in the software industry.

In the past, a lot of people came into this field. Everyone has the title “software engineer,” but people define the role very differently. Some see themselves as tools that translate requirements into code. Others came to this industry with genuine passion for making the world better through software.

I’ve always hated the Chinese term “码农” — literally “code peasant.” The more it’s used, the more people start to actually believe that what we do is just writing code, just typing. In reality, writing code has never been the hardest part of software engineering. One of the key insights from The Mythical Man-Month is this: the real difficulty of software projects isn’t usually how to type out the code — it’s the complexity that arises from people, modules, concepts, communication, and boundaries.

How to model data properly. How to express business logic with clear control flow. How to handle edge cases. How to make judgments under uncertain requirements. This is what software engineers actually do. We are engineers first, software engineers second.

With AI generating code, it suddenly feels like the “code peasant” has become worthless overnight. The statement stings, but it’s not entirely wrong. People who define themselves purely as “translators of requirements into code” will indeed have less and less leverage.

But many of those shouting that “engineers don’t matter anymore” don’t understand where the real difficulty of software engineering lies.

It’s true — we no longer need to memorize vast amounts of syntax and API contracts. AI can complete our code, look up documentation, generate boilerplate, and even produce a decent first draft. But that doesn’t mean the work has gotten smaller. On the contrary, a lot of the judgment that used to be buried in implementation details is now pushed to the surface faster than ever.

AI can assist with modeling, but it can’t bear the consequences of a modeling mistake. AI can generate architectural suggestions, but it doesn’t know whether your team will be crushed under that abstraction three months later. AI can satisfy a requirement based on a prompt, but it has no instinct for whether the requirement itself should be rejected.

Even vibe coding — there’s still a non-trivial barrier for regular people. Watch how someone without a technical background uses AI: often, the problem isn’t that they can’t express what they want — it’s that they don’t know how to decompose a problem, what “verifiable” means, or how to tell whether a result “looks like it runs” or is “actually maintainable.” There’s still a significant gap between “AI can build products” and ordinary people.

So here’s my take: the pure “code peasant” will be eliminated, and real software engineers will become a more versatile profession.

This profession will de-emphasize how many details you’ve memorized and emphasize whether you understand the business, the product, how to attract users, and whether you have good enough judgment about aesthetics, interaction, and system complexity.

I have a mental model: from user need to actual implementation is a spectrum. On the far left are fuzzy user pain points and needs. On the far right is concrete code. Operations, PMs, Engineering Managers, ICs — they all sit at different positions on this spectrum, each covering part of it.

This model has three implications:

1. If any segment of the spectrum goes uncovered, the product suffers.
2. Communication is only effective between people whose segments overlap.
3. The larger the segment one person can cover, the more important they are to the product.

AI’s emergence isn’t so much about directly covering a huge chunk of the spectrum. It’s more like a gap-filler. It can fill the part closest to implementation. It can also fill parts like user communication, interaction design, documentation, and prototyping.

When you try to let AI cover a large portion of the spectrum, it will make mistakes and may go off the rails. But even then, it’s still cheaper and faster than hiring another person. A PM can vibe-code. An engineer can vibe-design. The human cost of turning ideas into products has dropped dramatically. Individual developers can complete projects more easily than ever. A product manager who doesn’t code can build a proof of concept.

This is a very big deal.

The New Chaos

On top of all this, the software industry is chasing a vision: what if one day, people don’t need to write code at all — what if “programming” becomes describing things in natural language?

Imagine a 4-6 person team shipping 10-20 features per month through AI. That’s an intoxicating number. There’s enormous commercial interest behind it, so pioneers are already experimenting. Vibe, spec, plan mode, harness — new buzzwords keep appearing. Big tech companies are forcing their employees to burn tokens, trying to produce a breakout star through sheer volume.

In this FOMO environment, all kinds of AI chaos have emerged: mountains of AI slop, open-source projects drowning in AI-generated PRs, code headed for production that was AI-generated, AI-reviewed, AI-tested — with no human actually taking responsibility.

This isn’t an AI problem. It’s a people problem.

I once saw a discussion: if someone on your team uses AI irresponsibly — doesn’t review, doesn’t care, produces piles of slop — what do you do? Someone said: fire them.

That’s one approach. If you care, if you don’t want the slop to pile up until it’s unmaintainable, you can remove that person from the team. But you can’t solve this by endlessly hiring and firing. Team experience never accumulates. The team stays unstable. Hiring is expensive. This is clearly not sustainable.

The real long-term solution is to find a way to assess whether someone can responsibly use AI in the AI era.

Which brings us right back to the original question: what kind of people should we actually be hiring?

The Paradigm Hasn’t Settled Yet

AI’s code generation capability — and its unreliability — has thrust the software industry into a phase where the paradigm hasn’t stabilized.

This phase feels a bit like the early days of software engineering. Structured programming, the Unix philosophy, object-oriented design, agile development, TDD — these things that feel natural today weren’t consensus from the start. They emerged through years of practice, debate, failure, and revision.

Many principles we take for granted today — abstraction, modularity, avoiding unchecked gotos, protecting behavior with tests, composing complex systems from small tools — were all once proposed, questioned, and debated. The software industry didn’t start out knowing how software should be built. It grew out of chaos.

Over the past 10-20 years, the software industry has enjoyed a stability dividend: rapid growth on a stable foundation with no paradigm shift. A lot of people could enter this industry with a worker’s mindset and still enjoy generous compensation. Follow the process, write code by ticket, solve problems within established paradigms — this worked for a long time.

But as AI breaks the old way of building software, the rule-following “worker” mindset becomes increasingly mismatched to the times. What this era needs isn’t just executors. It needs pioneers.

Ken Thompson, Edsger Dijkstra, Dennis Ritchie, Grace Hopper, Alan Turing — they’re huge names, of course. But my point isn’t to mythologize them. It’s to emphasize a state: they all stood on ground that was unstable and uncertain, and kept exploring forward — proposing new ideas, constructing new tools, even changing how people understand computation.

Some pioneers got their names in history. Many failed pioneers didn’t. But what drove them forward was, at least in significant part, more than just money or a better life. A large portion of that drive was intense intellectual curiosity — curiosity about unknown systems, a desire to find out what would happen if we tried this.

I believe that in our era, this quality is what’s most needed.

Software 3.0 teams should be hiring pioneers. Because we are in the process of, and need to be, developing new paradigms.

The Qualities of Pioneers

What qualities do pioneers have?

First: know the how, and know the why.

Understanding can’t stay at the surface. Without understanding the essence, you can’t transfer knowledge or connect ideas. Thorough understanding of a problem, with the ability to transfer laterally and vertically — that’s a classic path to innovation. It takes sustained curiosity about internal structures and preconditions to actually bring this capability to life.

Second: learn paradigms, and question them.

Following rules isn’t the problem. Learning established paradigms is nothing to be embarrassed about. The problem is knowing only “this is how it’s done” without knowing “why it’s done this way.”

A paradigm is essentially compressed experience. What’s actually valuable isn’t “this paradigm is always correct” — it’s “under these conditions, this paradigm is the best choice.” It’s just that those conditions were so universal in the past that everyone defaulted to assuming they’d always hold.

Pioneers are sensitive to changes in preconditions. When conditions change, previously correct paradigms may begin to fail. The people who can see this are the ones who can open new paths.

Third: wide and intense curiosity.

Cross-disciplinary fusion is where innovation most often emerges. Today’s AI field is full of people from biology, mathematics, physics, and cognitive science. Software engineering has always had people from theoretical physics, cybernetics, linguistics, and design. The key to cross-disciplinary innovation isn’t simply putting two nouns together — it’s abstracting, deconstructing, and mapping the structures of different systems.

This requires curiosity. Not performative curiosity. Real, genuine wanting-to-know.

Closing

If you’ve read this far hoping I’d propose a new interview method, you’ll be disappointed. I don’t have an answer yet either.

But I’m certain of one thing: the current interview process cannot find these people for us.

LeetCode can filter out some people who don’t code at all. It can also surface some skilled test-takers. But it’s terrible at judging whether someone has abstraction ability, whether they’re open, whether they can learn under uncertainty, whether they’ll use AI responsibly, whether they’ll keep moving forward when paradigms shift.

And in the AI era, the places with more of these people will, almost certainly, get more things done.

I also hope that people currently struggling or making a living in this industry won’t feel fear. I’m not trying to comfort anyone or serve up platitudes. I just think the world has always been dynamic and uncertain, and output has always required input.

That stable, comfortable life of the past — that may never have been the norm. Chaos and uncertainty are closer to the world’s true baseline.

If you feel afraid, I’ll say: many people do. Tomorrow is another day. You, like everyone else, still have the chance to discover an idea that changes how many people work and live.