Interviewing engineers in the age of AI
When every candidate has a world-class assistant in the next tab, the interview stops measuring memory and starts measuring judgement. Most processes haven't noticed yet.
When every candidate has a world-class assistant in the next tab, the interview stops measuring memory and starts measuring judgement. Most processes haven't noticed yet.
The danger of AI isn't that it makes engineers less productive. It's that it quietly removes the exercise that kept them sharp in the first place.
Lead time, deployment frequency and change failure rate tell us a great deal about delivery systems. They tell us surprisingly little about the performance of individual engineers.
Every technology generation promises to transform how software gets delivered. Most of them eventually rediscover that organisational structure shapes the outcome far more than the tools the engineers happen to be holding.
Shared components promise consistency and speed. They also quietly centralise risk. What it takes to run a single UI platform across brands that genuinely want to look different.
The interesting question is no longer whether engineers use AI tools, but where they belong in the workflow and where they quietly make things worse.
The hardest part of AI adoption isn't choosing tools. It's changing how engineers, leaders and organisations work around them.
Code rarely becomes hard to maintain because engineers wanted it that way. More often the architecture is just a faithful record of the incentives, constraints and decisions of the organisation around it.
The problem isn't that engineering metrics are useless. The problem is that we often ask them to answer questions they were never designed to answer.