What I look for in engineers when the tools keep changing.
A job description captures who we think we need. A candidate with a different mix of skills may see an opportunity we missed, improve how the team works, or change what the business can achieve. I want our hiring process to leave room for that person.
The tools change. Judgment still matters
AI changes what I look for in technical ability. I want engineers who can direct it towards a useful, reliable result quickly: define the problem, choose constraints, and verify the implementation. Speed includes understanding failure modes and making a change safe to ship. The engineer remains responsible for the outcome, including knowing when to question the output, ask for help, or choose another approach.
Kindness belongs in the hiring criteria
Kindness can’t be automated. AI can help us find better words or explain a difficult idea. We still have to listen, make time for people, and follow through when helping takes effort. That means investigating a confusing user experience, answering a teammate’s basic question, or helping during an incident without looking for someone to blame.
Kindness also makes room for disagreement: challenging a design or pushing back on a deadline can be an act of care. I look for evidence in what people did, who they listened to, and how they shared credit. Interview charm tells us little; a reserved person may show extraordinary care through their actions.
Make room for a different route
When a candidate departs from the plan or structure we expected, ask what their approach achieves. If it meets the requirements just as well, it should carry no penalty. If it improves the outcome and they can explain why, that deserves credit. Recognising a better path is part of the judgment we hope to hire.
Real constraints, such as security or compatibility, still matter. Make them clear, and distinguish them from your preferred way of solving the problem. A candidate cannot reasonably be expected to follow a requirement you never stated.
Giving someone the benefit of the doubt means investigating an uncertain signal. Clarify the question, allow thinking time, or invite another example, and offer that support consistently across candidates. A different vocabulary or unfamiliar working style can hide relevant experience.
We can conclude that someone lacks an essential skill. We can also conclude that we did not gather enough evidence. Those are different findings. Name a genuine gap precisely; when the evidence is inconclusive, consider what small follow-up would resolve it.
CORE: four things worth looking for
And because we’re engineers, we probably need an acronym to remember all this. Here you go: CORE — Care, Ownership, Reasoning, and Enablement.
Care
Understand who the work affects, and change a technically sound solution when it fails the people who need it.
Ask When did understanding a user’s problem change what you built?
Ownership
Follow work through to its consequences, surface risks early, and help repair mistakes, including your own.
Ask When a decision of yours caused a problem, what did you do?
Reasoning
Make assumptions explicit, weigh tradeoffs, and keep learning when evidence challenges what you know.
Ask What technical belief have you changed recently, and what convinced you?
Enablement
Help others succeed by sharing context, improving tools, and removing obstacles that hold the team back.
Ask What did you do that made someone else’s work easier, and how did you know it helped?
Give people the benefit of the doubt. They may bring something your checklist never thought to ask for.