How I'd Actually Prepare for an AI Engineer Interview

10 questions worth answering honestly, with free resources for each

Author

Vishakha Sadhwani
November 10, 2026

AI can write the code now. That part is settled. What it can't do is understand your system for you, notice when it quietly got something wrong, or tell you whether the thing you shipped actually works for real users.

That gap is what I'd focus on if I were preparing for an AI engineer interview today. Whatever the interviewer actually asks, they're usually checking one of the ten questions below. I wouldn't expect a perfect answer to all of them. I'd go through them honestly, notice which ones make me uncomfortable, and spend my prep time there.

For each question you'll find the line from the video, what to keep in mind when you answer it, and free courses, docs, blogs and crash courses to close the gap.

1. How deep are your technical fundamentals?

"How deep do your fundamentals go? DNS, TCP, TLS, HTTP? Where does your knowledge stop?"

Keep in mind when answering:

  • Don't stop at "I know what DNS is." Find the exact layer where your understanding turns into "it just works," and be honest about it.

  • A good test: can you explain what happens between typing a URL and seeing the page, without skipping a step?

  • Fundamentals don't go out of date. Frameworks and AI tools change every year, but TCP doesn't.

Free resources:

2. Do you know where systems actually break?

"Do you know where systems break? Database, cache, network, or your own code?"

Keep in mind when answering:

  • Think about specific failures, not abstractions: a slow query, a stale cache, a timeout with no retry, a connection pool that ran out.

  • When something is slow, can you work out which layer it's in before you start guessing?

  • Read other teams' postmortems. You can learn from outages without having to live through them.

Free resources:

3. Can you explain the code AI generates?

"Can you guide the tool, catch its mistakes, and explain the final code as if you wrote it?"

Keep in mind when answering:

  • If you couldn't explain a line in a code review, you don't own it yet. Merging it means signing off on something you don't understand.

  • Guiding the tool well depends on knowing what good looks like, so you can say "no, do it this way."

  • Review AI output the way you'd review a new teammate's pull request: check the logic, naming, error handling, tests and anything it assumed.

Free resources:

4. Do you understand how your entire system works?

"Do you understand the full path here? Frontend, API, auth, model, database, and back. Where would it slow down?"

Keep in mind when answering:

  • Trace one request end to end on paper. Every box you can't explain is a blind spot.

  • For each hop, ask what it costs in time, money or possible failures.

  • "Where would it slow down?" is the interview-grade version of this question. Have an answer for every layer.

Free resources:

5. Can you connect what you don't know to what you do?

"If yes, how deep? If no, can you connect it to something you do know?"

Keep in mind when answering:

  • "I don't know" is a fine answer. "I don't know, but it's probably like X because..." is a great one.

  • Most new tech is old ideas in new packaging: a vector DB is an index, an agent loop is a while loop with tool calls, and a KV cache is still a cache.

  • Practice reasoning by analogy, then check it. The connection gets you started, but you still have to verify it.

Free resources:

6. Are you using AI to accelerate learning or avoid it?

"Do you use them to go faster, or to skip understanding? Can you review what it produces?"

Keep in mind when answering:

  • Here's the honest test: if the AI went away tomorrow, would you be slower, or would you be stuck?

  • Use AI as a tutor, not a ghostwriter. Ask it to explain, quiz you and poke holes in your understanding, not just to hand you the answer.

  • Every so often, build something small without AI, just to see where your understanding actually is.

Free resources:

7. Are you curious beyond your job requirements?

"Are you curious on your own, or only when your job forces you to learn?"

Keep in mind when answering:

  • Look at your last three things you learned. Did a ticket make you learn them, or did you go looking?

  • Curiosity compounds. The side topic you read about this month often becomes next year's job requirement.

  • Building toy versions of real tools (your own Redis, your own shell) teaches more than any course.

Free resources:

8. Do you check edge cases and security issues?

"Did you check the edge cases, security issues, or things it quietly assumed?"

Keep in mind when answering:

  • AI code tends to handle the happy path well. Its gaps are empty inputs, huge inputs, missing permissions, unexpected nulls and concurrent requests.

  • Watch for its quiet assumptions: the user is trusted, the input is clean, the API never fails, the secret is fine to hardcode.

  • If you ship LLM features, you now have new attack surfaces too: prompt injection, data leakage and agents with too much access.

Free resources:

9. Do you know when to use AI agents?

"Do you really know when an AI agent actually makes sense, versus a simple script, an API, or a deterministic workflow?"

Keep in mind when answering:

  • Start with the simplest thing that works. If you can write the steps down ahead of time, you probably need a workflow, not an agent.

  • Agents earn their keep when the path can't be predicted in advance. They cost more in latency, money and debugging.

  • Being able to say "this doesn't need AI" is a skill, and a valuable one.

Free resources:

10. Do you measure real-world performance or just trust the demo?

"Do you track real metrics or just trust the demo? Do you know where your costs come from: model, tokens, compute, memory, cache?"

Keep in mind when answering:

  • A demo is a handful of inputs you picked yourself. Production is thousands of inputs you didn't. Evals are how you close that gap.

  • Look at real outputs before building dashboards. Most AI quality problems show up in plain error analysis.

  • Know your cost per request: input and output tokens, model choice, GPU time, memory and what caching saves you.

Free resources:

Crash Course Quick List

Every crash course from this article in one place:

How to Use This

Read through the ten questions once and mark each one as confident, shaky or no idea. Skip the confident ones. Pick one shaky question and spend a week on its resources, then come back and answer the question out loud as if an interviewer asked it.

The goal isn't to stop using AI. It's to use it the way a senior engineer would: faster at the things you understand, and never a substitute for understanding them.

All links are free courses, docs, books, labs, or crash courses. If a link has moved, search the title and you'll usually find the current version.