What "AI-native" means when we screen an engineer

“AI-native” is on every resume now. Here’s what it has to mean before someone reaches your shortlist.

Direct answer: An AI-native engineer has shipped AI features to real users and can explain how quality, latency, cost, failure modes and user trust were handled. Familiarity with ChatGPT, Cursor or a model API is not enough. The bar is production judgment.

The five gates

1. Shipped-AI screen. Evidence of LLM features shipped to real users - not tutorials or side projects. Show us what you built and what broke.
2. Eval & quality review. Can they measure model quality, or do they eyeball it? We probe how they build evals, catch regressions, and reason about edge cases.
3. Live technical deep-dive. A working session in their specialism - retrieval, agents, inference, security - with senior Viitor Cloud engineers, not a recruiter quiz.
4. Cost & failure reasoning. Production AI lives and dies on latency, token cost and graceful failure. We test for it directly, because most candidates have never had to.
5. Communication & ownership. They’ll sit inside your team, so we screen for clear writing, honest status updates, and the instinct to own outcomes rather than tickets.

The gates are intentionally practical. We do not care whether a candidate can recite every model benchmark. We care whether they can pick the right test set, explain why a model output regressed, protect sensitive data, recover from a failed tool call and tell a product manager what tradeoff they are making.

What does not count

The phrase gets abused, so it helps to name what does not qualify:

• Building a chatbot tutorial does not prove production AI judgment.
• Using an AI coding assistant does not prove the engineer can ship AI products.
• Knowing prompt patterns does not prove they can design evals.
• Calling a vector database does not prove they can make retrieval trustworthy.
• Saying “agent” does not prove they can handle state, tools, permissions or human review.

Those skills may be useful signals at the edge. They are not the core. The core is whether the engineer can make model behavior dependable enough for a customer-facing workflow.

Why most resumes don’t survive it

A generic coding screen tells you someone can write software. It tells you nothing about whether they can ship an evaluated, grounded, cost-aware LLM feature that holds up against real users. So we screen for the AI stack specifically - and reject the large majority of candidates who only look the part on paper.

The point of a hard bar isn’t to be exclusive for its own sake. It’s so your shortlist is two or three people, not twenty - and so the trial is a formality, not a gamble.

How buyers should evaluate the claim

Ask for specifics:

1. What AI feature did you ship, and who used it?
2. What broke after launch?
3. What eval or monitoring told you it broke?
4. How did you control latency and token cost?
5. What was the fallback when the model was wrong?
6. How did you decide the feature was safe enough to release?

Good answers are concrete. Weak answers drift into vague language about innovation, leverage and productivity. A strong engineer can talk about the exact failure cases, the metric they watched, the tradeoff they made and the code they changed. That is the difference between “AI-aware” and AI-native.