Thinking beats coding: How to hire the right engineers in the AI era

I’ve been thinking a lot about how we hire engineers. It’s always been a big part of my job, but I think it’s time to reconsider old patterns and focus on what we think will make people successful as the profession advances.

Part of that is the obvious reason: AI is changing how software gets written. Tools that generate code are improving quickly, and they’re starting to take over a lot of the mechanical work that used to occupy engineers. But the more I think about it, the more I realize this isn’t actually a new problem.

I’ve seen a lot of industry change in my 25ish years as a software engineer (which includes the last 15 or so as an engineering leader).

Software engineering has always been a profession defined by changing tools. Every decade brings a new abstraction layer that supposedly makes engineers less necessary. And every decade, the opposite ends up being true: the engineers who thrive are the ones who can adapt their thinking to the new layer.

Recently, Gergely Orosz of the Pragmatic Engineer wrote something on X that resonated with me: the best engineers aren’t the ones who know the most frameworks. They’re the ones who can reason about problems and figure things out.

That distinction matters more now than it ever has. Because if your hiring process is optimized around implementation knowledge, you’re hiring for skills with a very short shelf life.

Let’s dive into how industry changes have changed the software development skillset. I’ll also share how leaders like you should adjust your hiring process to continue bringing in engineers who can adapt to the next wave.

The industry keeps moving the goalposts

If you zoom out, the job of “software engineer” has already changed dramatically several times:

• The mainframe era: Engineers lived close to the machine. Memory constraints, assembly languages, and hardware limitations defined the work.
• High-level languages: In the 80s and 90s, higher-level languages shifted the focus. Engineers spent less time managing memory directly and more time building applications.
• Explosion of the web: Suddenly, every engineer needed to understand networking, distributed systems, and stateless architectures.
• Cloud platforms arise: Then, infrastructure became programmable. We stopped thinking about servers and started thinking about services.

Now, AI tools are starting to assist with the implementation layer itself.

At each step, something interesting happened: the mechanical work decreased, but the thinking work increased. The engineers who succeeded weren’t the ones who memorized the previous generation of tools. They were the ones who could pick up the next generation quickly.

Implementation knowledge ages fast

One of the most common mistakes I see in hiring is over-indexing on specific technologies. You see it in job descriptions:

• Must know React.
• Must know Kubernetes.
• Must know Terraform.
• Must know X cloud platform.

These things matter, but they’re not what make someone a great engineer. Framework knowledge decays quickly. Entire ecosystems rise and fall in less than a decade. The industry moves too fast for any particular tool to be the defining skill.

What lasts longer are the thought processes behind the work:

• Understanding systems
• Reasoning about tradeoffs
• Thinking through failure modes
• Identifying the real problem hiding behind the request

The engineers who have those instincts tend to learn new tools very quickly. The engineers who only know how to operate a specific stack often struggle when the ground shifts under them. And the ground always shifts.

AI pushes engineers toward the problem layer

The conversation about AI in software usually focuses on productivity. But the bigger shift is where engineering effort lives.

Every abstraction layer in our industry has removed some category of mechanical work: Compilers removed assembly. Frameworks removed boilerplate. Cloud platforms removed infrastructure management.

AI is simply the next step.

If code generation keeps improving, the limiting factor in software development won’t be writing code. It will be:

• Understanding the problem
• Designing the system
• Validating correctness
• Managing complexity

Those were always the hard parts anyway. They’re just becoming more visible. Which is why the engineers who will thrive in the next decade are the same ones who thrived in the previous ones: the people who are good at thinking through messy problems.

How to hire the right engineers in the AI era

When hiring processes focus too much on specific tools, they end up selecting for the wrong thing. It’s easy to test whether someone knows a framework. It’s much harder to evaluate how someone thinks. But that’s the part that actually matters.

When I interview engineers, the signals I care about most are things like:

• Do they clarify the problem before proposing solutions?
• Do they think in terms of tradeoffs?
• Do they ask questions that reveal deeper system understanding?
• Do they reason through unfamiliar territory in a structured way?

At its core, though, what I truly look for is someone who loves to solve problems and wants to solve the kind of problems we’re solving where I work.

This could be being engaged by the technical domain. Or in the case of Scripta, wanting to make a difference in helping people navigate the pharmacy ecosystem. At the end of the day, though, I want someone who’s curious and passionate about the work they’re doing.

---

Over 200k developers use LogRocket to create better digital experiences

Learn more →

---

Those behaviors tell you much more about someone’s potential than whether they can recite an API lifecycle from memory.

The best engineers I’ve worked with can usually pick up a new stack in a matter of weeks. What differentiates them isn’t their familiarity with a particular tool. It’s how they approach problems.

The harder question: What to look for when hiring junior engineers

The AI conversation gets trickier when we talk about junior engineers.

Historically, a lot of early engineering experience came from implementation work. Writing boilerplate, fixing small bugs, building small components. These tasks gave people time to develop intuition.

AI tools can now handle a lot of that mechanical work. So the obvious question becomes: how do juniors learn if the entry-level tasks disappear?

I don’t think the answer is “stop hiring juniors.” That would be a mistake for the industry. But it probably does mean we need to be more deliberate about what we’re looking for. For junior engineers, the most important signals may become:

• Curiosity
• Learning velocity
• Problem-solving instincts
• The ability to break down unfamiliar systems

In other words, the same traits we value in senior engineers, just earlier.

At Scripta, we even look for people in non-computer science domains at this phase. With AI lowering the learning curve for mastering the underlying technologies, people with diverse opinions or good intuition are more valuable. What’s important is the desire to learn and the ability to think through complex situations.

Because the junior engineers who will succeed in an AI-assisted environment are the ones who treat tools like collaborators, not crutches. They’ll use them to move faster, but they’ll still understand the system they’re building.

That mindset matters far more than whether someone can write perfect code from memory.

Complex problem solving: The skill that never goes out of date

Technology will keep changing. New languages will appear. New frameworks will dominate. AI will automate parts of the work we once considered core to the profession.

But one skill keeps surviving every shift in the industry: the ability to think clearly about complex problems.

That was valuable in the mainframe era. It was valuable during the rise of the web. It’s valuable in the age of AI, and if you’re hiring engineers today, it’s probably the most durable signal you can look for.