Hiring for a Specific Technology in the AI Era

Every few weeks someone sends me a job description to review, and it almost always opens the same way: five years of this framework, three years of that cloud, hands-on with a particular database. I understand the habit. For most of my career, ramping up on an unfamiliar stack took months, and the wrong hire could stall a team.

But I'm a principal solution architect who now works with AI assistants every day, and I've watched capable engineers pick up a new language well enough to be useful in days rather than months. So the question I keep coming back to is a fair one: should we still hire for a specific technology background?

My honest answer is: sometimes — but far less often than our job descriptions suggest. AI has changed the price of different kinds of knowledge. Hiring should follow those prices.

What AI made cheap, and what it didn't

Cheaper now: syntax, framework conventions, boilerplate, looking up APIs, translating a pattern from one language to another, getting a first working version of something standard.

Not cheaper: knowing which design will survive production. Debugging something nobody has seen before. Understanding the business well enough to notice a requirement is wrong. Knowing a platform's deep failure modes. And — the one people forget — judging whether generated code is actually correct, secure and maintainable.

That last one deserves a moment. AI shifts effort from writing code to checking it, and checking needs more expertise, not less. You only catch a subtle race condition or an insecure default if you know what one looks like.

The data is starting to say the same thing. In Stack Overflow's 2025 developer survey, 84% of respondents said they use or plan to use AI tools — but more of them distrusted the accuracy of the output than trusted it, and the most common frustration was answers that are "almost right, but not quite." Google's DORA research found that teams adopting more AI reported higher individual productivity, yet saw software delivery stability go down. Speed of writing went up. The cost of verification didn't go away.

How I think about it: five layers

The layers I hire for, from most durable (top) to most perishable (bottom). AI tools have made the bottom layers far cheaper to acquire. The top ones still take years — and that's where most of the hiring signal now lives.

For most roles, the top three layers should carry most of the weight. Platform depth matters enormously for some roles and barely at all for others. Framework fluency is now a tiebreaker.

When the specific background really matters

I don't want to overcorrect. There are real cases where I would absolutely hire for a particular stack:

Deep platform work. Database engines, runtimes, compilers, networking, high-performance systems. The knowledge lives in internals and edge cases that no summary captures.
Scarce legacy expertise. In April 2020, as unemployment claims surged during the pandemic, a US state publicly appealed for volunteers who knew COBOL to help keep 40-year-old mainframe systems running. The US Government Accountability Office has documented federal systems that are decades old and depend on skills that are getting harder to find. AI tools are weakest exactly where public examples are thin — and modernization programs live or die on people who know how these systems really behave.
Security- and safety-critical systems. When a subtle mistake is expensive, I want people who have seen the failure modes before.
On call from week one. If someone will be carrying the pager for a complex platform almost immediately, ramp-up time is a real operational risk.
Very small teams. In a large team, a strong generalist learns from colleagues. In a team of three, the missing expertise might not exist anywhere else.

Role	Weight on specific technology	What matters more
Product feature engineer	Low	Foundations, domain, judgment, reviewing AI-assisted code
Platform / SRE	Medium–high	Operability, debugging, the platform's failure modes
Database or runtime specialist	High	Internals, performance analysis
Modernization engineer	Medium (the legacy stack)	Reading unfamiliar code, preserving behavior, test discipline
Architect	Low–medium	Trade-offs across stacks, domain, communication
Data / ML engineer	Medium	Data semantics, evaluation, pipeline reliability

What I look for instead

When the stack isn't the deciding factor, these predict success far better in my experience:

How fast they learn. I ask about something they learned recently, how they learned it, and what surprised them once they used it for real.
How they debug. I give them a broken system or a confusing log and watch how they narrow it down. It's very hard to fake.
How they verify. How do they check that code — theirs, a colleague's or an assistant's — is right? Tests, reading the diff, edge cases, questioning assumptions?
Curiosity about the business. Do they ask what the system is for, or only what it's built with?
How they explain trade-offs. Can they explain a choice to an engineer and to someone who isn't one?

How the interview should change

If engineers will use AI at work, an interview that bans it tests a skill the job no longer uses — and an interview that ignores it misses the skill the job needs most. A few things I've changed:

Test reviewing, not just writing. I hand over a piece of AI-generated code with one or two realistic defects — a missing authorization check, a race condition, an unbounded query — and ask for a review.
Allow the tools, then go deeper. Use an assistant for the task, then walk me through every line and tell me what you'd change before shipping it.
Let them design in their own stack. For most roles I'm evaluating reasoning, not vocabulary.
Ask for experience, not definitions. "What is a circuit breaker?" tests recall. "Tell me about a time a dependency failure took your service down" tests experience.

The risks of getting this wrong

Hiring less for specific technologies has its own dangers, and I'd rather name them:

Too much trust in generated code. Teams that accept AI output without strong review pile up defects and security issues fast. The fix is review culture and tests, not banning tools.
A hollow junior pipeline. This one worries me most. Stanford's Digital Economy Lab found that, after generative AI spread, employment for workers aged 22–25 in the most AI-exposed occupations fell noticeably relative to other groups, while experienced workers in the same jobs held steady. The authors are careful to call it early evidence. But if we stop hiring and developing juniors because an assistant can write their first drafts, we won't have the seniors we need in five years.
Losing scarce knowledge. Generalist hiring can quietly drain expertise in legacy and specialist platforms. Map where that knowledge lives and protect it — especially during a modernization program.
Everyone thinking alike. When everybody uses the same assistants, designs drift toward the same defaults. Different backgrounds help catch what the defaults miss.

So, should you?

Hire for durable capability — foundations, judgment, domain understanding and the discipline to verify — and treat framework experience as a bonus for most roles. Pay a premium for specific technology depth where the knowledge lives in internals, where it's genuinely scarce, or where learning on the job means learning during a production incident.

AI has made it much cheaper to learn a technology. It hasn't made it any cheaper to understand a system. I try to hire with that difference in mind.

If you're wondering how to spot real experience in the interview itself, I've written about that in AI Knowledge Talkers vs. Real Experience.

Sources

Should You Hire for a Specific Technology Background in the AI Era?