Technical Interview Questions for AI Engineers

Key facts, with sources

• The median time-to-hire in the engineering sector is 41 days, and the slowest 10% of hires take up to 82 days. (Genius)
• Filling senior and staff software roles typically takes 60 to 90 or more days because senior candidates are rarely actively job hunting and require sourcing and longer negotiations. (Talmatic)
• Outsourced app development in 2025 ranges from about $25,000 to $250,000 or more depending on complexity and region, and offshoring to India, Vietnam, or Eastern Europe cuts costs 40 to 60% versus US or Western European teams. (Creole Studios)
• Development rates run $110 to $230 per hour in North America and Western Europe versus $20 to $50 per hour in Eastern Europe, a spread that dominates total project cost comparisons. (Topflight Apps)
• React Native shows stronger hiring demand than Flutter in the US, with about 6,413 React Native job postings on LinkedIn and 1,990 on Indeed versus 388 Flutter postings on Indeed. (TECHSY)

What You Are Actually Screening For

You are not hiring someone to explain transformers. You are hiring someone to ship a system that gives correct answers, stays inside a budget, and fails gracefully when the model does something strange. So the trait to screen for is production judgment: has this person lived through the gap between a demo that works in a meeting and a system that works for real users?

Every question below is designed to separate those two populations. Candidates who have only built demos give answers about models and prompts. Candidates who have shipped give answers about evaluation, data quality, latency, cost, and what they did when accuracy dropped after launch. Weight the second group heavily, even if their answers are less polished. The polish gap closes in weeks; the judgment gap takes years.

Questions About RAG and Retrieval

Ask: "Walk me through how you would decide chunk size for a document set, and how you would know your choice was wrong." A good answer mentions that it depends on document structure and question type, and — critically — describes measuring retrieval quality rather than guessing. Ask: "When retrieval returns the wrong documents, what is your debugging process?" Strong candidates describe inspecting actual retrieved chunks, checking embedding quality, and testing hybrid search; weak ones jump straight to swapping the model.

Also ask when they would NOT use RAG. Someone who has real experience will readily name cases — small stable knowledge bases that fit in a prompt, tasks that are really classification, problems where a database query is the honest answer. A candidate who presents RAG as the universal solution is pattern-matching from tutorials.

Questions About Evaluation and Hallucination

This is the highest-signal area, because evaluation is what tutorial-level candidates skip entirely. Ask: "How do you measure whether your system's answers are actually correct?" You want to hear about a test set of real questions with known-good answers, run before and after every change — whether they call it an eval suite, golden set, or regression tests. If the answer is "we tried it and it seemed good," that is how their system will be validated for you too.

Then ask: "A user reports the assistant confidently stated something false. Walk me through your response." Good answers cover tracing which sources were retrieved, whether the model ignored or lacked the right context, grounding the answer with citations, and adding the case to the eval set so it cannot regress silently. The specific techniques matter less than whether they have a repeatable process at all.

Questions About Cost, Latency, and Operations

AI features have a property most software does not: every user interaction has a marginal cost, and a naive implementation can be dramatically more expensive than a careful one. Ask: "How would you estimate the monthly API cost of this feature before building it, and what levers reduce it?" Strong answers mention token counting, model tiering (cheap models for easy steps, expensive ones only where needed), caching, and truncating context. Ask about latency too: what they do when responses take too long, and whether streaming is appropriate for your use case.

Finally, ask what they monitor after launch. Someone who has operated an AI system in production will mention tracking cost per user, error and refusal rates, and drift in answer quality over time. Someone who has not will describe monitoring as an afterthought — which typically means you discover problems from angry users and surprise invoices.

Red Flags in Otherwise Fluent Answers

The most dangerous candidate is articulate and current on terminology but has never carried a system past a demo. Watch for these patterns. Every answer names a tool or framework but never a measurement — real practitioners talk about how they knew something worked. They cannot describe a failure: ask "tell me about an AI feature that did not work and what you did," and a candidate with genuine experience has a story immediately, usually a slightly embarrassing one. They promise accuracy numbers before seeing your data — nobody honest guarantees precision on documents they have not examined.

Also be wary of candidates who resist starting small. If you propose a scoped pilot and they push for a large multi-month commitment up front, that is a business-model preference, not an engineering recommendation. The people I would hire tend to push in the opposite direction: shrink the first milestone so both sides can verify fit cheaply.

How to Run the Interview If You Are Not Technical

You can still get strong signal without being able to judge technical correctness, because the tell is in the structure of answers, not the content. Ask every question twice in different forms and check consistency. Ask "what would make this project fail?" — experienced engineers give specific, unflattering answers (bad source documents, unclear success criteria, no test data); inexperienced ones say it will go fine. Ask them to explain their approach to a non-technical stakeholder: if they cannot, you will be paying for that gap every week of the project.

If the project is significant, consider paying a second senior engineer for an hour to sit in on one interview or review the candidate's proposal. It is typically one of the cheapest risk reductions available, and honest candidates welcome it. Someone who bristles at expert review of their plan is telling you something important.

When to hire senior help

Senior help is most valuable at inflection points: the initial architecture and framework decision, the first store launch, and any moment where velocity has stalled or quality metrics like crash-free rate are slipping. Given that hiring a senior full-timer takes two to three months, a contractor engaged for a bounded audit or delivery sprint is often the fastest way to de-risk while a permanent search runs in parallel. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Cross-Cutting — Hire Intent & Comparisons projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Waiting until after a failed or stalled build to seek senior help, instead of buying a few hours of expert review at the architecture stage
• ✕Interviewing mobile candidates on web React questions only, leaving native modules, offline sync, and store release experience completely untested
• ✕Accepting portfolio screenshots as proof of ability instead of verifying live store listings and asking which parts the candidate personally built
• ✕Comparing offers on hourly rate alone while ignoring management overhead, timezone friction, and rework, which routinely erase paper savings from the cheapest bid

Frequently asked questions

Sources

• Genius
• Talmatic
• Creole Studios
• Topflight Apps
• TECHSY