Interviewing for an AI Engineer Role? Tips From the Other Side of the Table

I recently spent a good amount of time on the other side of the table, interviewing candidates for an AI Engineer role. After enough interviews, patterns start to show up. The same small things that make a candidate stand out, and the same avoidable mistakes that sink otherwise strong people.

None of this is secret. But most candidates only ever see interviews from their own side, so here is what it looks like from mine.

1. Know every single line on your resume

This is the most important one, and the one I saw go wrong most often.

Anything on your resume is fair game. If it's there, expect questions on it, and expect follow-up questions on your answers.

• No metrics you can't defend. If you wrote "improved retrieval accuracy by 37%", be ready for: accuracy measured how? On what dataset? Compared to what baseline? How many samples? A number you can't explain is worse than no number at all.
• No projects you didn't actually build. If an internship project was mostly done by your mentor or teammate, and you were "helped" through most of it, it shows within two or three questions. Be honest about your part: "I owned the evaluation pipeline, the retrieval layer was built by a teammate" is a perfectly good answer.
• No buzzwords you can't go one level deeper on. If "fine-tuning", "LoRA", "vector databases" or "multi-agent orchestration" are on the page, I will ask how they work and why you chose them.

Here is the key point: a shaky item on your resume hurts you more than if it wasn't there in the first place. A missing skill is a gap. An item you can't defend is a credibility problem, and it makes me doubt everything else on the page too.

Before the interview, go through your resume line by line and ask yourself: "If they ask me to explain this for five minutes, can I?"

2. Ship a deployed version of your project

Wherever possible, have a live, deployed version of your project. This helped candidates more than almost anything else.

A link I can click and use in 30 seconds beats a paragraph of description every time. It proves the thing actually works end to end, not just in a notebook on your laptop.

It has never been easier or cheaper to do this. Free tiers cover most portfolio projects:

Need	Options
Frontend / full-stack apps	Vercel, Cloudflare Pages, Netlify
Backend services, workers, APIs	Railway, Render, Fly.io, Cloudflare Workers
Database, auth, storage	Supabase, Neon, Firebase
ML demos	Hugging Face Spaces, Streamlit Community Cloud

And make the GitHub link count too

If you're adding a GitHub link, assume I will open it. So:

• Clean code. Sensible structure, meaningful names, no giant final_v2_working.py, no committed API keys or .env files.
• A proper README. What the project does, why you built it, the architecture, how to run it, and what you'd improve next.
• Screenshots or a short GIF of the UI, right at the top of the README.
• Explain your decisions. Why this model? Why this chunking strategy? Why this vector store? A short "Design decisions" section tells me more about how you think than the code itself.

A good README is often the difference between me spending 10 seconds or 10 minutes on your repo.

3. Build projects with real complexity

Please, no more simple RAG chatbots over a PDF. I saw a lot of them, and they all start to look the same. They don't tell me much anymore, because anyone can build one in an afternoon by following a tutorial.

Writing code is easy now. With AI coding tools, anyone can produce a working app. What's harder to fake, and what I'm actually looking for, is:

• Creativity: did you pick an interesting problem?
• Problem solving: what broke, and how did you fix it?
• Engineering judgment: how did you evaluate it, handle failures, manage cost and latency?

Some directions that stand out much more:

• Replicate a new or interesting AI startup. Pick a product you find impressive and build your own version of its core idea. Then talk about what was hard.
• Multi-agent systems with a real workflow: planning, tool use, handoffs between agents, human-in-the-loop approval, and clear handling of failures.
• Build for the company you're applying to. Look at the company and its industry and build something relevant. Interviewing at a fintech? Build a transaction dispute assistant or a document extraction pipeline for financial statements. Healthcare? Something around clinical notes or claims. This shows initiative and makes the conversation much easier, because we're suddenly talking about our problems.
• Add evaluation. Even a small eval set with clear metrics puts you ahead of most candidates. "Here's how I know it works" is a rare and very strong answer.

Complexity doesn't mean a bigger codebase. It means real problems you had to think through.

4. Test everything before you demo

If you plan to show something during the interview, make sure it works before the call. That includes:

• Your application: is it deployed and up? Free-tier services often sleep after inactivity, so open it a few minutes before to wake it up. Are your API keys still valid? Do you have credits left?
• Your mic and camera: test them in the actual meeting app you'll be using.
• Your internet: have a backup, like a phone hotspot, ready to go.
• Screen sharing: close unrelated tabs, mute notifications, and know exactly which window you're going to share.

A broken demo eats into your interview time and leaves you flustered for the rest of it. A short screen recording as a backup is also a good idea, in case something fails anyway.

5. Look the part on video

For online interviews, first impressions still count.

• Dress neatly and formally. You don't need a suit, but treat it like an in-person interview.
• Use a clean background. If you can't, use a virtual background or background blur.
• Get the basics right: decent lighting on your face, camera roughly at eye level, a quiet room.

None of this will get you the job on its own. But it removes distractions, so the interviewer can focus on what you're saying.

6. During the conversation itself

How you answer matters almost as much as what you answer.

Know the company before the call

Spend some time on what the company builds, who its customers are and what it has shipped recently. Asking "so, what does the company do?" in an interview is a bad sign. It tells me you didn't spend even ten minutes preparing. (And if you followed point 3, you'll have already built something relevant to them.)

Think out loud

When you're stuck on a question, don't go silent for two minutes and then come back with an answer. Talk me through your reasoning: what you're considering, what you're ruling out and why. I'm assessing how you think, not just whether you land on the right answer. A clear line of reasoning that ends slightly off gets more credit than a correct answer with no visible path to it.

"I don't know" is a perfectly fine answer

Nobody knows everything, and I don't expect you to. What I'm looking for is what comes next: "I don't know, but here's how I'd find out" or "I haven't used that, but I'd guess it works like X because of Y." That's a good answer.

Bluffing is not. It almost always comes apart after one follow-up question, and then I start doubting the answers you did know.

Keep your answers short

Answer the question first, then add detail if I ask for it. Long, rambling answers use up the limited time I have to assess you, and I may not get to the questions where you would have shone. If I want more depth, I'll ask. A good pattern is: direct answer, one or two sentences of why, then stop.

Ask good questions at the end

When I ask "do you have any questions for us?", use it. Good questions show genuine interest and how you think:

• What does the team's stack look like?
• How do you evaluate your models or LLM features before shipping?
• What would a first project look like for someone in this role?
• What's the hardest technical problem the team is dealing with right now?

What to avoid in the technical round:

• Leave, salary, benefits: these belong to HR, not the technical interviewer.
• "What are the next steps?" or "When will I hear back?": HR will almost always bring this up themselves. Asking the technical interviewer usually doesn't get you a real answer anyway.

7. The funny ones (that are very real)

These sound obvious, but they come up more often than you'd think.

Don't ask about doing a Master's

Asking during the interview about leaving to do a Master's, or how the company supports people who want to go study, signals that you might not be around for long. The team is investing time to onboard and train you. Save these plans for a later conversation, if at all.

Don't push for a specific department or project

It's fine to have a preference, and if I ask, tell me. But don't keep steering the conversation back to "I only want to work on X" or "I'd only be interested if I'm on the Y team."

Here's the reality: placement is usually not in the candidate's hands. People get assigned based on:

• The kinds of projects you've done before
• Your internship or work experience
• Simply where there are vacancies across departments at the time you join

Insisting on one specific project can come across as inflexible, and it can make you a harder hire, even when everything else went well. Show that you're excited about the role and the company, and that you can learn whatever the team needs.

TL;DR

1. Know everything on your resume. If you can't defend it, remove it.
2. Deploy your projects and make your GitHub repos clean, documented and visual.
3. Build something with real complexity and creativity, ideally relevant to the company.
4. Test your demo, mic and internet before the call.
5. Dress well and keep a clean background for online interviews.
6. In the conversation: know the company, think out loud, say "I don't know" instead of bluffing, keep answers short, and ask good questions at the end (leave salary, benefits and next steps to HR).
7. Don't bring up a Master's, and don't insist on a specific department or project.

Good luck. The bar is not as mysterious as it seems. Be honest, show real work, and make it easy for the interviewer to say yes.