Three things I look for when hiring engineers in the AI era.

A junior who works for me asked last month what I'd be looking for if I were her, looking for her first job, today. She knows I've been the hiring lead at our company for three years. She also knows the last twelve months scrambled most of what I used to grade for.

I owed her a straight answer. This is roughly what I told her.

<circle cx="300" cy="40" r="8" fill="#34d399"/>
<text x="300" y="22" text-anchor="middle" font-weight="600" font-size="13">Ships end-to-end</text>
<text x="300" y="68" text-anchor="middle" font-size="11" opacity="0.7">From requirements to prod.</text>
<text x="300" y="82" text-anchor="middle" font-size="11" opacity="0.7">Not just the fun middle.</text>

<circle cx="540" cy="300" r="8" fill="#34d399"/>
<text x="540" y="328" text-anchor="middle" font-weight="600" font-size="13">Reads carefully</text>
<text x="540" y="346" text-anchor="middle" font-size="11" opacity="0.7">Other people's code. Specs.</text>
<text x="540" y="358" text-anchor="middle" font-size="11" opacity="0.7">The AI's own output, especially.</text>

<circle cx="60" cy="300" r="8" fill="#34d399"/>
<text x="60" y="328" text-anchor="middle" font-weight="600" font-size="13">Talks to humans</text>
<text x="60" y="346" text-anchor="middle" font-size="11" opacity="0.7">Asks. Confirms. Pushes back.</text>
<text x="60" y="358" text-anchor="middle" font-size="11" opacity="0.7">Knows when not to ship.</text>

<text x="300" y="195" text-anchor="middle" font-weight="600" font-size="14">All three</text>
<text x="300" y="216" text-anchor="middle" font-size="12" opacity="0.7">= the engineer I'd hire today,</text>
<text x="300" y="232" text-anchor="middle" font-size="12" opacity="0.7">AI tools or not.</text>

What I stopped caring about

It's faster to say what I no longer care about than to list what I do.

I don't care if you can implement a binary tree traversal from memory. I never really cared, honestly. But it used to be a useful filter for "has done a real CS course at some point". It isn't anymore. The model can do it. You can do it with the model. It tells me nothing.

I don't care if you can write a perfect leetcode solution in 25 minutes. The mental shape of competitive programming is not the mental shape of building software. It barely was before. It really isn't now.

I don't care if your GitHub has a lot of green squares. I look, but mostly to confirm you're not blagging. If your green squares come from ten LeetCode submissions a day for a month, that's actually a slight negative now. I'd rather see four pull requests to an OSS project where you debated the design with maintainers.

I don't care about the language on your resume in the way I used to. If you can use one well, you can pick up another in a week. The model levels that field.

I really, deeply don't care that your resume has been edited for executive polish. See the resume piece for why.

Thing one: taste

I want to know if you have taste. I want to know if, when you look at two solutions, you can tell which is better and articulate why without falling back on style-guide trivia.

In the interview, this looks like: I show you a piece of working but ugly code. I ask what you'd change. The good answers are specific, prioritised, and acknowledge that some of the changes aren't worth making. They distinguish between this is wrong and this is not how I would have written it. The bad answers are either silent or rewrite everything.

Taste isn't something you fake. It's downstream of how many other people's code you've read in your life, especially code written by people more experienced than you. You can practise it. Reading open-source codebases you didn't write, on purpose, slowly, is the most underrated junior-engineer activity in 2026.

Thing two: debugging without help

This is the one that's gotten harder to test for. Everyone has Claude. Everyone can ask. So how do I learn whether you can debug something when the model can't help you?

I pick a bug whose root cause is two levels below where it presents. I make the call stack look misleading. I give you the test that fails and the code, but I pick a problem where pasting it into a model returns a confident, wrong answer.

What I'm watching for: do you read the code carefully before you start hypothesising? Do you have an instinct about what kinds of bugs are common in that part of the stack? Do you write small experiments to confirm or rule out theories? Can you tell when your current theory is wrong and you should back up?

The answers to those questions don't come from the model. They come from years of being lost in a system and finding your way out. They are the most expensive thing to develop and the easiest to spot in an interview. The single best thing a junior can do for their career is be the person who debugs the hard one on their current team. Volunteer for it. Sit with it. Get the experience.

Thing three: the question of motivation

Here's the one that's actually changed the most.

When AI made building cheaper, it also raised the question of why anyone would still be doing this. If you can sit in a chair and let a model write your CRUD app and ship it on Friday, the meaning of being an engineer becomes a real question, not a rhetorical one.

I find myself asking, in interviews now, some variant of: what are you working on right now where the model can't really help? It's a soft question. It's also the most diagnostic one I ask.

Some candidates light up. They talk about a side project they care about, or a class of problems they're obsessed with, or a hard part of their current job they want to keep doing themselves because they love it. Those are the candidates I want.

Some candidates look at me blankly. They tell me they've been "doing AI projects" or "exploring agents" and can't really name anything specific they care about. I don't blame them. The whole industry is in a weird, mid-transition mood right now. But the candidates I'd bet on are the ones who still want to do this when the easy version is freely available.

What this means if you're job-hunting

If you're a junior reading this and feeling a little doomed: don't.

The hiring bar at the median has gone up. The hiring bar at the top has stayed about the same. The signal that gets you above the median is mostly the same set of things it always was: read other people's code, debug hard problems with as little help as you can stand, and figure out what specifically you care about doing.

The AI didn't take the job. It compressed the timeline. The 22-year-old who would have become useful at 24 might now have to find a different shape of useful. But useful people will keep being hired, because we have not run out of hard problems and we have not made the human kind of judgment cheap.

That's the rubric. I hope it's useful.