Insights
Hiring for a company where the technology changes every quarter
Standard hiring advice says define the skills the role needs and hire for them. It's reasonable advice for a stable role. It falls apart when the technology underneath the role changes every few months, which is the situation in AI services right now.
If I hire someone for their command of a specific tool or model or framework, I've hired for something with a shelf life measured in months. The tool gets superseded, the approach that was best practice becomes the thing we tell new people not to do, and I'm left with someone who was excellent at a thing that no longer matters — and who may have tied their professional identity to it, which makes the update harder, not easier.
So the question I've had to actually answer, running delivery at a company where this is the daily reality: what do you select for when the specific skills won't last?
Adaptability is the wrong word for what matters
Everyone says hire for adaptability. It's true and it's useless, because "adaptability" isn't observable in an interview — everyone claims it and most people believe it about themselves.
What's actually underneath it, and is observable if you look for it, is a couple of more specific things.
A track record of having changed. Not the claim that they adapt — evidence that they already have. Someone who has switched domains, learned something genuinely outside their training, or held a strong technical opinion and then publicly abandoned it when it stopped being right. That last one is rare and valuable. Most people defend positions past their expiry to protect their credibility. Someone who can say "I was confident about this and I was wrong, here's what changed my mind" has demonstrated the exact muscle the job requires.
Comfort with not knowing yet. In a fast-moving field, the honest state most of the time is "I don't fully know, I'll need to find out." People who are miserable in that state — who need to be the expert in the room — burn out or bluff, and bluffing in this work is expensive because it's hard to catch until it ships. The people who do well are oddly comfortable being temporarily incompetent, over and over, as the ground shifts. It's a strange trait to select for and it matters more than almost anything on a résumé.
Depth still matters — just not where you'd think
This isn't an argument that skills don't matter, or that you should hire generalists who know a little about everything. That fails differently but just as badly — you get people who can talk about anything and deliver nothing.
The resolution is that depth matters, but in the durable layer rather than the surface layer. Someone who deeply understands why systems fail, how data actually behaves, what makes a process fragile, how to reason about a problem from first principles — that depth transfers across every tool change. Someone whose depth is entirely in the current toolset has depth with an expiry date.
So the thing to probe isn't "do you know today's tool" — it's "how deeply do you understand the layer beneath the tools." You test that by going one level down. Not "can you use this framework" but "why does this class of approach work, and when does it break?" The answers separate people fast, and they separate them on the thing that lasts.
What this means for how you actually hire
A few practical consequences:
Weight learning history over current skill inventory. What has this person taught themselves, from what starting point, and how recently? A steady record of acquiring genuinely new capability is the single best predictor of staying useful as the ground moves.
Interview for reasoning, not recall. Give a problem slightly outside their stated expertise and watch how they approach not knowing. Do they reason toward it, ask good questions, stay comfortable — or do they freeze or bluff? That's the actual job, performed live.
Be honest in the hiring process about the instability. Some strong people want a stable, masterable domain, and that's a completely legitimate preference — they'll be unhappy here and it's kinder and cheaper to establish that early. Tell candidates the tools will change under them constantly. The ones who lean in at that are the ones you want.
The uncomfortable summary is that in a field moving this fast, you're not really hiring for what someone can do. You're hiring for how fast they can become able to do the next thing, repeatedly, without it costing them their equilibrium. That's harder to assess than a skills checklist. It's also the only thing that stays relevant.
Entrepreneur, Co-Founder & COO of BoostMySites, associated with BoostMySites Global (Hong Kong). He writes about AI automation, operations, scaling and working with early-stage founders. More about Darshan →