Every company I talk to says it wants to hire AI-native people. Very few can tell me what that phrase means when it's sitting in front of them as a resume. The skill is genuinely new, new enough that it doesn't map cleanly onto a traditional CV, and the mismatch is sharpest for the strongest candidates, the ones with fifteen or twenty years of experience whose careers were built before any of this existed. Their resume is a record of a world that changed underneath it. So "AI-native" gets used as a vibe, and hiring for a vibe is how you end up with a team that can talk about agents but can't ship one.
When I'm building a team to actually put AI-native products into production, I stop looking for the buzzword and screen for five concrete capabilities. None of them is "has used ChatGPT."
1. Can they work with data?
This is the unglamorous foundation, and it's the one people skip. I want evidence that someone has lived in the messy part: scraping or sourcing data, doing the analysis, and (the part that separates real practitioners from tourists) interrogating the quality of it. Do they check whether the data is what it claims to be? Have they cleaned a dataset that fought back? Do they have real database experience?
One clarification I have to make constantly in interviews: cloud experience is not data experience. "I've used GCP" answers a different question. Knowing your way around a cloud console tells me you can host things; it tells me nothing about whether you can tell a trustworthy dataset from a poisoned one. Keep those two boxes separate on the scorecard.
2. Do they understand modeling, and know when it's the wrong tool?
A lot of people moving into agent-building arrive from classical machine learning. That background is valuable: Python, pandas, PyTorch, the discipline of taking a dataset (public or your own) and building it out to predict some X. If your product needs an actual model, that experience is gold.
But I'm screening for judgment as much as skill here. The classical-ML instinct is to reach for a trained model; the AI-native instinct is to know when a model is overkill and an API call plus good context engineering does the job faster and cheaper. The strongest candidates can hold both. They can build the model when it's warranted, and they can tell you (unprompted) when it isn't.
3. Are they cloud-native, with an actual opinion?
There's still a live debate about whether you should be running your own models locally or leaning on hosted, cloud-based ones. I don't need a candidate to have settled that debate. I need them to know it exists and to argue both sides. Someone who can walk me through the trade-offs (cost, latency, privacy, control, the operational tax of self-hosting) and who has enough hands-on time with AWS, GCP, or Azure to know where the sharp edges are, is someone I can trust to make that call in context. A candidate with no opinion, or a dogmatic one-line answer, is a flag either way.
4. Have they actually automated a workflow, not just written a script?
This is the one where the market is fuzziest, because "I built an agent" now means almost nothing. Everyone says it. ChatGPT will happily set up a scheduled task for you these days, and people call that an agent. It isn't; it's a beginner's script on a timer. Useful, but not the skill I'm hiring for.
What I'm actually looking for is workflow-automation experience: the ability to compose systems of agents. Agent one hands state to agent two, which hands state to agent three, which feeds a fourth, and somewhere in that chain there's a loop, where an agent looks back at what the others did, learns from it, and makes a different decision next time. That's the difference between a person who can run a prompt on a cron job and a person who can design an autonomous pipeline that improves itself.
The reason this matters for an AI-native product portfolio is that the products worth building live in that second category. The single-prompt automations are already commoditized. The defensible work is in orchestration, and orchestration is a skill you can only demonstrate by having done it, not by having a certificate that says you understand agents.
5. Can they measure whether it works?
Ask a candidate how they know their AI system is any good. The weak answer is that they ran it a few times and the output looked right. That's a vibe, not an evaluation, and it falls apart the first time the model changes underneath you or a real edge case shows up in production. I've watched teams ship on three hand-picked examples and then have no idea why quality drifted a month later.
What I screen for is someone who builds the measurement in from the start: an evaluation set with known-good answers, metrics that map to what the product needs, and a way to catch a regression before a user does. Sometimes that's a golden dataset and an accuracy number; sometimes it's an LLM-as-judge rubric for outputs that have no single right answer; sometimes it's a live metric watching real usage. The specific method matters less than the instinct, which is to treat "is this working?" as a question you answer with data, not with a demo. Classical ML made that instinct second nature. A lot of people arriving from prompt-first tooling never had to learn it, and it shows the first time their agent quietly gets worse.
If I compress the five into one filter: I'm not hiring people who can use AI tools. Those are everywhere now. I'm hiring people who can reason about data, models, infrastructure, orchestration, and evaluation well enough to build the tools other people will use. That capability doesn't announce itself on a resume, which is exactly why the companies that learn to screen for it directly are going to out-hire the ones still waiting for the perfect CV to show up.