I’m hiring mid-level devOps and engineers over the next few months. Not seniors because they are too expensive, too set in their ways and most won’t adapt fast enough (argue with me) — and the role I’d hire a senior for has been quietly unbundled out from under them anyway. Not juniors either because they’re too early to be useful in an AI-first and fast team; they need foundations I don’t have time to build right now. Mid-level — three to five years in, technically competent, willing to learn a new way of working — is where the sweet spot lies. This isn’t a guess; I’ve thought about all three levels and run the numbers. Mid is the answer.
That’s the easy part. The hard part is choosing them.
I know what I’m looking for. Five things, all of them necessary, all of them imperfect proxies for the underlying skill.
Adaptability — can they unlearn the habits that got them to mid-level and embrace the new way of working?
Judgement under ambiguity — can they sit with an unclear problem and shape it into something specific?
Communication — can they work with non-technical people and translate scenarios into specifications?
Curiosity — will they ask the next question, or just take the AI’s first answer and ship it?
Pattern recognition — do they have enough experience to spot when something’s wrong, even if they can’t yet say why?
Each of these is real. Each of these is testable to some degree. But you can’t really test for all five in a forty-five-minute conversation, and even if you could, you’d then have to rank them — because the candidate who scores brilliantly on three out of five but flat on the other two is still a stronger hire than the candidate who scores moderately on all five, and the interesting question is which three.
Here’s where it gets uncomfortable. Each of the five has a case for being the most important:
Adaptability is the strongest case on paper. The work is changing faster than at any point in my career. A candidate who can’t unlearn won’t survive the next two years regardless of what else they bring. The argument against: adaptability is the hardest quality to test for, because everyone at interview says they’re adaptable. You only find out when the role bends and the candidate either bends with it or stiffens. I have had new starters who tried to change the team around them rather than work with them, who tried to change our core architecture, rebuild from scratch, rather than adapt.
Judgement under ambiguity is what the new senior role is actually made of. If the mid-level engineer I hire today is going to be a senior in three years, they’ll be a senior whose value lives almost entirely in judgement. Hire for the destination, not the present role. Argument against: judgement is built from pattern recognition built from experience built from years of grinding through hard problems. A candidate strong on judgement at mid-level probably had the old grinding to thank for it, and the next generation won’t have access to that route.
Communication is the quality I see most in the people who are already thriving. The CTOs I know who’ve adapted well to AI tooling are the ones who could already sit in a room with a non-engineer and produce a workable shared understanding. The technical fluency was the easy half. Argument against: you can’t teach the part of communication that matters, and you can’t easily test for it in a structured interview — it lives in unstructured conversations with non-technical people. Getting a team who will communicate willing with each other and anyone that they are introduced to is tough, takes lots of coercion and effort that I don’t have time for any more.
Curiosity is the rarest of the five and the most predictive. The engineer who asks “what was the second-best fix you considered?” may, over time, become the engineer who catches the bugs nobody else catches or may become so bogged down in always checking alternatives that they never spot the wood in the trees. The balance is finding an engineer who understands when AI is right and focusses on when AI is going to need checking. So what if AI is right 90% of time? How do they target the 10% that needs curiosity? Argument against: curiosity at interview is performance. The candidate knows what to ask to look curious; you find out the truth six months in, by which point you’ve already hired them.
Pattern recognition is the only one of the five that you can verify quickly. Show the candidate a real codebase and kustomize file, watch them read it all, listen to what they say. Within twenty minutes you’ll know whether they can see what’s there or only what’s labelled. Argument against: pattern recognition at mid-level is shallow by definition, AI can spot a flaw in the pattern in 10% of the time and do a better job of not missing any. Candidates will have seen some patterns, not many. Hiring on this metric is partly hiring on what they were exposed to in their previous job, which isn’t really what you want to optimise for. I have had people argue that blue is green because of side projects they have been developing, those are easier spot than the ones that are more reserved and less eager to share big ideas.
So all five matter, and the interesting question is which two or three you’ll accept instead of the others. I haven’t fully worked out my answer to that yet. My current ranking — and this could be wrong — is communication first, adaptability second, curiosity third, judgement and pattern recognition tied for fourth. Reasoning: the first two are the hardest to develop and the most predictive; the last three can be developed if the candidate has the first two and a few years of the right work.
If you’ve thought about this and have a different ranking, I’d genuinely like to hear it. I’m hiring now and this is the part I’m still working out.
Even with the ranking, the interview is broken. I wrote a whole article about it a few weeks ago — the keyword filter, the live coding test, the take-home, the cultural fit round. None of these test the five things that matter. Most of them test for typing speed, idiomatic style, and the ability to perform under conditions nobody actually works in. If I run the conventional funnel, I’ll filter out the people I most want to hire. Worst of all, I could run an online automated test that is now obsolete by all AI scales.
So I’m changing the funnel. Roughly:
The keyword filter goes. JDs become invitations, not gates. I list the problems my team is solving and the trade-offs we’re making. Candidates self-select in or out. Yes, this means more noise. The signal is better.
The live coding round becomes a live scenario round. I air drop them in to an environment, describe a problem, give them an AI, give them an hour, and watch how they work. I don’t grade the output. I watch how they get there. What do they ask? When do they push back? When do they realise the brief is wrong? That’s the curiosity-and-adaptability test, and it’s roughly impossible to fake.
The take-home gets replaced with a conversation about something they’ve actually built. Walk me through your last project. Why did you make the calls you made? Not “we”, not “in my last team”, but “I”. What would you change if you started again? That’s the pattern-recognition test, and it filters out people who can do the work but can’t explain it and those that hide behind a team — which is the same filter the new senior role applies.
The cultural fit round becomes a session with a non-engineer on my team. PM, QA, designer, whoever’s available. I want to see them work with someone who doesn’t share their vocabulary. That’s the communication test.
I’m not saying this is the right funnel. I’m saying it’s the funnel I’m trying. Six months from now I’ll know what worked and what didn’t.
What makes them improve? How do they grow within our company?
Maybe it’s getting closer to the business needs and not waiting for a written spec that typical seniors used to. The judgement that used to come from debugging legacy work now has to come from sitting in product conversations and watching what users actually need. Nailing the requirements faster. That’s a different apprenticeship.
Maybe it’s learning to argue with AI — making round-trip dialogue with the model a deliberate practice, not just a way to get faster output. The skill of recognising when a confident answer is narrowly correct but generally wrong is something you can develop, but only if you’re being asked to develop it.
Maybe it’s pairing with other colleagues on the parts of the work that haven’t been automated — architecture, trade-offs, judgement about what to build. Less time on implementation, more time on decisions. The mentor relationship is real; it just has a different surface — and they need to not be afraid of it. Afraid of looking silly, afraid of wasting time, afraid of looking weak.
But honestly, I don’t know yet. The article I keep meaning to write — how do you develop a senior engineer when the work that used to develop them has gone? — is the article I haven’t written because I don’t have an answer. Maybe one of you reading this does. If so, please tell me.
Three to five mid-level engineers. Three to five years in. Willing to learn. Eager to communicate. Curious enough to ask the second question after the AI gives them the first answer. Comfortable with non-engineers. Adaptable enough to do work in three years that doesn’t currently exist. That’s what I’m looking for. I haven’t fully worked out how to find them. But I’m writing this down now because writing it down is the first half of working it out — and because the people I’m trying to hire might recognise themselves in this description and reach out.
If that’s you, I’d like to hear from you.