Two engineers. Same years of experience, same rough technical profile, strong performances in the same interview process. You hire both.
Six months in, one of them is operating with tools and practices the other hasn't started learning yet. The gap isn't talent. It's not raw intelligence. It's a habit of early adoption — a specific, observable behaviour that compounded quietly over the past year before they ever walked into your office.
Most interview processes never surface it. Most job descriptions don't mention it.
The tooling landscape now changes faster than hiring cycles
Consider what's changed in the last twelve months alone. Tools that are standard practice on engineering teams today were experimental or fringe a year ago. Workflows that didn't exist eighteen months ago are now the default at some of the most effective teams.
An engineer who finds useful tools before they're mainstream has a structural advantage. Not because early adoption is inherently virtuous, but because of what it produces: months of practice with something before their peers have formed an opinion on it. That compounds.
Six months of real experience with a tool before it becomes mainstream is not a marginal edge. In a field moving at this speed, it's the difference between fluency and familiarity. Fluency changes what you can build. Familiarity changes what you can discuss at standup.
What early adoption actually looks like
It's important to be precise here, because the term attracts a lot of noise.
Early adoption is a behaviour, not a personality trait. It doesn't mean chasing every hype cycle. It doesn't mean switching tools every three weeks or having strong opinions based on a blog post. That version is actually a liability.
The real version looks like this: active but selective monitoring of what's happening at the frontier. Regular low-cost experimentation — trying things in small ways before committing to them. Forming opinions from use, not from articles. And critically, being willing to decide something isn't worth it.
That last part is the distinguishing detail. A genuine early adopter has tried things that didn't pan out. They can tell you specifically why. "I tested it for two weeks on a side project, the latency was fine but the context handling was too inconsistent for our use case" is a real answer. "I heard it wasn't great" is not.
The questions
These are the ones we've found most useful. They sound simple. That's intentional.
"What have you started using in the last three months that nobody told you to?"
"What are you currently experimenting with?"
"Tell me about something you tried and decided wasn't worth it."
"Where do you find out about things before they're mainstream?"
A strong answer is specific. It names actual tools. It contains opinions formed from use, not reputation. It references specific communities — not "I follow tech news" but the Discord server, the researcher's GitHub, the niche newsletter with four thousand subscribers that happened to be right about something important.
The weak answer sounds like keeping up. "I try to stay current." It names tools that have been mainstream for two years. Or it lands on the most honest version: "I haven't really had time."
Why the weak answer is a real signal
"I haven't had time" is the answer worth sitting with.
In a field changing at this speed, not making time to understand what's changing is not a capacity problem. It's a priority problem. The hours exist. Other things filled them. That's a choice, even when it doesn't feel like one.
For roles that involve building with AI tools, making architectural decisions in this environment, or working with AI-assisted workflows — this is close to a disqualifier. Engineers who wait to be told what to learn will always be learning yesterday's curriculum.
Here's the arc we've covered in this series.
Part 1: most of what technical interviews test has lost its predictive value. The job changed and the questions didn't. We cleared the table.
Part 2: we replaced those questions with something that tests what the job actually requires now — specifying clearly, working with AI under observation, evaluating output critically, reasoning about failure, and debugging from a mental model.
Part 3: we added the signal nobody was measuring. Not what someone can do today, but whether they have the habit of staying a step ahead of what's required of them.
Together, these three categories form an interview that's actually aligned with what you're hiring for. Not performance in an artificial environment. Not recall under pressure. Judgement, in conditions that resemble the real job.
That's a harder interview to run. It's also the one worth running.
The interview is only half the problem. The harder question is what happens after you've hired differently — when those engineers arrive at an organisation that wasn't designed for how they work. The next article is about what this environment demands of engineering leaders: not more AI tools, but a clear-eyed look at what your organisation is actually amplifying before you invest further in AI. That article is coming next.
© Gabor Mayer. Licensed under Creative Commons Attribution 4.0 (CC BY 4.0). Free to share and adapt with attribution.