Hiring in the AI era, and the change in paradigm
There’s one claim I think is right, that hiring, the whole approach and the whole system, is going to change over time, especially now in the AI era. Because coding by hand the old way pays less and less, while the skills the old Team Leaders had are worth more and more. What is that core skill? Verification.
AI is very strong at generating, and generating is exactly what programmers mostly did before. So our traditional hiring and interview system leans toward checking your ability to generate, with whiteboard problems, quizzes on all kinds of knowledge, or a question about some syntax detail.
But the most important part of the work in the AI era has already moved from generating to verifying. The crux is this: I generated ten thousand lines of code today, so are those ten thousand lines sound, can they run in production? Are there traps hiding in them? A good AI-native engineer, I think, should have verification as his core skill. Whether that means designing a system that keeps the output sound through process, or having taste and structural instinct strong enough to see at a glance that the AI’s design needs changing and which direction it should change in. He’s doing verification work the whole time.
This kind of verification work also means the way we learn knowledge and skills now has to turn in another direction. For the overly specialized tasks I think we should put in less energy; the highly transferable knowledge is what we should be learning for the future. Which is to say, in this era, to some degree, breadth really does beat depth.
That’s not to say depth doesn’t matter. It’s that breadth gives us one big advantage, an advantage in indexing. What do I mean by an indexing advantage? When I hit some problem, I can immediately recall: “oh, I’ve seen this thing somewhere before.” I don’t understand it deeply, but I know it exists. For example, I know you’re supposed to do evals when you build an agent. If I’d never touched that area at all, would it even occur to me to run evals? Breadth is exactly what gives you that ability, to pull up, in a specific situation, a concept you don’t actually understand in depth. And that’s often the key that unlocks the problem.
The advantage of the index is that I can take that topic straight to the AI. The typical thing about AI is that it may not volunteer anything when you don’t ask, but once you ask, it can answer in real depth. As long as I know the thing exists, I can go look it up and get to know it, and depth can be filled in fast that way. How much you fill in depends on how much the engineering situation calls for, of course. For an engineer, enough is what counts.
Breadth also gives you an advantage in verification. What verification comes down to is knowing where you got it wrong. The Team Leader of the past could see at a glance that some piece of the design was off, so why can’t a junior engineer see it? Because he doesn’t have the breadth, he doesn’t know what he doesn’t know. If I fill in the breadth now, I can also spot which blind spots I still have. I’m not as deep as a real senior yet, but I can go ask the AI. Before I didn’t know what to ask, now I do. That’s what the index buys you.
So the more transferable a piece of knowledge is, the more it’s worth learning today. In computer science that means the fundamentals underneath, standard system design, algorithms, data structures and so on. As for grinding LeetCode, the return on that doesn’t look great to me. Unless you’re going for one of the big companies where it’s a hard gate and you have to grind through a pile of Hard problems, and the payoff once you’re in is high, then it might be worth it. But if all you want is a small or mid-size company, or a median salary, then piling up structural, transferable knowledge matters more than grinding problems blindly. Filling in CS fundamentals, software engineering design, architecture, distributed systems, that kind of thing.
These used to be things only architects and leads had to learn, but today even a junior should have them. Our whole school system, the engineering-oriented ones especially, should shift this way too, and put weight on students’ architectural design ability and breadth of knowledge. AI assists us, but judging whether the assistance is actually right is exactly what takes that breadth.
On the other side, deep knowledge matters just as much, but it depends on the scale and the tier of the project. On a project that really matters, depth is still necessary; for most ordinary consumer products you probably don’t need to go that deep. Say you’re doing a project for a small or mid-size company, do you really have to think at the depth of a million concurrent users? You don’t. Learn it when you need it. And depth comes in steps. On the normal career ladder, traffic goes from ten thousand to a hundred thousand to a million, and if you stay on that road the depth accumulates on its own.
As for algorithm problems, my position is that Easy and Medium, the frequently asked ones especially, a few dozen to a hundred is about enough. No need to grind a thousand of them, the return on that is too low.
There’s another core point here, which is that a lot of the time what a company needs is just a signal, a cheap way to tell that you’re someone usable. For a company, the cost of hiring the wrong person is much higher than the cost of missing a good one. The wrong person subtracts, while missing a good one at worst means no extra gain. So companies lean toward avoiding mistakes, destructive ones especially.
In this era that kind of legible signal is going to matter more and more. That’s why I write a blog. I want to get my views and my understanding written down, to make my knowledge easier for the outside world to read, including how I understand AI and how I understand architecture. At the least it lets a company align on some information and get a quick read on what I’m made of technically.
Besides the blog, project code on GitHub is itself a mark of quality. I’m not going to advertise that “I hand-wrote the whole project”. Who still hand-codes the old way these days, and advertising it comes off a bit fake; plenty of the code is AI-generated, obviously. But precisely because it’s AI-generated, you can read the code and see the quality right away. Someone who knows how to use AI and someone who doesn’t will get completely different results out of the same cc. Is there enough test coverage? Is the overall architecture clear? Has anyone actually thought about the drift you get after AI has been in the codebase for a long time? In other words, back to what I said earlier, did you do the verification part well or not.
The classic multi-agent coordination problem is this: I tell the AI to change module A, or add a small feature, and it ends up breaking the whole rest of the project. The isolation in the code alone tells you the level someone is at, and if it isn’t there, chances are they haven’t been burned yet, which means their AI technique is still at a fairly early stage. The key to using AI well, as I see it, is whether you can bound the range it’s allowed to act in. A harness, taken literally, is the tack you put on a horse; but tack alone isn’t enough to get the horse running, the rider needs enough skill of his own. Only once the range is bounded can we verify each of its modules reliably afterward.
So it all lands back on verifiability. That’s roughly what I’ve been feeling today.
Translation note. I wrote this in Chinese. This English version is an LLM translation, so the wording is not mine even though the thinking is. Original: AI 时代的招聘与范式转换.