AI Engineer interviews are often described as conversations about LLMs, RAG, agents, and machine learning. In reality, the interview I experienced was much broader. It started with a formal introduction, moved into deep discussions about my projects, tested my understanding of AI systems and machine learning fundamentals, challenged several of the technical decisions I had made, included a coding problem, and ended with questions about internships, tools, Docker, and the company itself.
The biggest takeaway was simple: having AI projects on your resume is not enough. You need to understand every important decision behind them. The interviewer was not interested in hearing only what I built. He wanted to know why I built it that way, what alternatives I considered, what limitations existed, how I evaluated it, and whether I actually understood the system beyond the implementation.
It Started Like a Normal Interview — Then Went Deep
The interview began with a formal introduction, followed by the most predictable question: “Tell me about your top projects.” What looked like an easy opening quickly became the foundation for most of the interview.
For each project, the interviewer went beyond the usual “What does it do?” question. He asked about the problem being solved, the methodology, architecture, technology stack, why particular technologies were selected, how the components worked together, and what alternatives could have been used. Some questions were essentially variations of “Why this?”, followed immediately by “Why not that?” and “Why did you solve it this way?”
That pattern continued throughout the interview. It became clear that knowing a technology's name was not enough. If I mentioned a framework, database, model, vector store, or service in my project, I needed to be able to justify its presence.
This is one of the strongest lessons from the interview: every technology mentioned on your resume is potentially an interview question. Do not put a tool in a project simply because it sounds impressive. Be prepared to explain what problem it solved, why you chose it, what alternatives existed, and what trade-offs came with the decision.
The AI Engineer Round: Agents, Evaluation and RAG
Since the role was specifically for an AI Engineer Intern, the interviewer naturally moved toward the skills expected from the job description. One of the early questions was about AI agents and what I understood by them. The conversation was not limited to a definition; it focused on how these systems work and how they differ from a conventional LLM-based application.
The discussion then moved into evaluation, which was one of the more important parts of the interview. I was asked what kind of evaluation I had performed in my own projects. This is an area many candidates underestimate. Building an AI system and proving that it works are two different things. The interviewer wanted to know how I determined whether my system was actually producing useful results rather than simply generating output.
From there, the interview moved into the RAG pipeline. I was asked to explain a basic Retrieval-Augmented Generation pipeline and the responsibility of each stage. The expectation was not to recite a definition but to understand the complete flow—from the original document and data preparation through chunking, embedding, retrieval, context construction, and generation.
The same concepts were then connected back to my own projects. The interviewer asked how I had actually implemented RAG rather than how RAG works in theory. This is where project experience becomes important. Saying “I used RAG” is easy; explaining why retrieval was needed, how documents were processed, how relevant context was selected, and how the retrieved context reached the model requires genuine understanding.
Then Came the Deep Dive: Chunking and Embeddings
The RAG discussion did not stop at the basic pipeline. The interviewer went deeper into chunking, which is one of those topics that often looks simple until someone starts asking detailed questions.
The conversation covered how documents should be divided, why chunk size matters, and what can happen when chunks are too large or too small. Chunking directly affects retrieval quality because the system has to balance context preservation with retrieval precision. A poorly chosen strategy can either split useful information apart or create unnecessarily large chunks that make retrieval less focused.
The interviewer also asked about the embedding models I had used. That included questions around the dimensions of the embeddings, their use cases, and their limitations. This was a strong reminder that saying “we use embeddings” is not enough for an AI engineering interview. You should know what the embedding model is actually producing, what its vector representation means for your architecture, why that model fits the use case, and what trade-offs it introduces.
The questions were clearly designed to test whether I had worked with these systems practically or had only learned their terminology.
Resume Deep Dive: The Real-Time Communication Platform
After the AI-specific discussion, the interviewer moved directly into my resume. One of the projects listed was a real-time communication platform, and this became another detailed technical discussion.
He asked about the technology stack, but the more interesting questions were around system behavior. One question focused on latency: how I measured it and how I knew how long it actually took for a message to travel through the system.
That led naturally into edge cases. What happens when the connection is unstable? What happens when a message is delayed? What happens if something fails between the sender and receiver? What limitations existed in the original system, and which of those limitations had I tried to solve?
These questions exposed something important about project interviews: the interviewer is often less interested in the happy path than in what happens when things go wrong. A project that works perfectly in a demonstration is easy to explain. A real engineering system has failure cases, latency, unreliable networks, race conditions, scaling issues, and unexpected user behavior.
Why Cloudinary Instead of Storing Files in the Database?
One of the questions that stood out was about Cloudinary.
Because the communication platform handled files or media, the interviewer asked why I used Cloudinary and, more importantly, why I did not simply store those files in the database.
This is a classic architecture question because it looks simple but tests whether you understand the difference between application data and large media assets. The important part of answering such a question is not memorizing “Cloudinary is for images.” You need to explain the actual architectural reason for separating media storage from core application data and what benefits that gives the system.
The broader lesson is useful for almost every project: when an interviewer asks “Why did you use X?”, they are often testing architecture, not just familiarity with X.
The Machine Learning Project: From Dataset to Deployment
Another project on my resume came from my internship and involved machine learning. Here, the interviewer approached the project almost like an architecture review.
He asked about the overall system architecture, the features present in the dataset, the complete machine learning pipeline, the model I selected, how that model works, and why I chose it over alternatives.
The discussion then moved into one of the most important areas of any machine learning interview: data preparation and model evaluation.
I was asked about the cleaning process in detail and how I decided which columns or features should be removed. This is an important distinction. Saying “I removed irrelevant columns” is not enough. The interviewer wanted to know how I reached that conclusion. Was a feature duplicated? Was it leaking information? Did it have little predictive value? Was it noisy, incomplete, or unrelated to the target? These decisions should come from analysis rather than intuition.
The same applied to accuracy and precision. Instead of simply stating the final numbers, I had to explain how they were calculated and how I ensured that the evaluation represented the actual behavior of the model.
For machine learning roles, this is an important lesson: know the complete pipeline, not just the algorithm name. You should be comfortable explaining how the raw dataset became model-ready data, how the model was trained, what metrics were selected, why those metrics mattered, and what the final numbers actually tell you.
Deployment Was Part of the Interview Too
The discussion did not stop when the model worked locally. The interviewer asked about the deployed project, including how I deployed it and what problems I expected to encounter in a real environment.
This moved the conversation from machine learning into engineering.
How does the backend communicate with the model service? How does the frontend communicate with the backend? Where is the model hosted? What happens if the model service is unavailable? How are dependencies handled? What happens to environment variables, latency, requests, and errors after deployment?
These are questions that separate a notebook-based ML project from an actual AI application.
An AI engineer is not expected only to train models. The role sits at the intersection of models, backend systems, APIs, infrastructure, and product behavior. You need to understand how the pieces connect once users start interacting with the system.
Then Came the Coding Round
After the project and AI discussion, the interviewer gave me a coding problem:
Given a string
s, find the first character that appears exactly once and return its index. If no such character exists, return-1.
For example, with:
"swiss"
the answer is 1 because w appears exactly once and its index is 1.
The constraints were important: the string could contain up to \(10^5\) characters, it contained only lowercase English letters, and the expected solution was O(n) time and O(1) space.
I solved it in roughly 8–10 minutes.
The natural solution is a frequency-counting approach. Because the input contains only lowercase English letters, a fixed array of size 26 is enough. The first pass counts how many times each character appears. The second pass scans the string from left to right and returns the first index whose character has a frequency of one.
The key idea is that the problem should not be solved with repeated searching because that can become O(n²). The fixed-size frequency array keeps the auxiliary space constant, satisfying the expected O(1) space requirement.
This was a useful reminder that even an AI Engineer interview can still contain a standard data-structures-and-algorithms question. Working with LLMs does not eliminate the need for fundamental programming skills.
Internship Experience and Defending My Engineering Decisions
The conversation then returned to my internship experiences and projects. At this stage, the discussion became less about isolated technical questions and more about how I approach engineering problems.
I had to defend the approaches I had taken while designing AI systems. That meant explaining not only what I implemented, but why I thought that architecture or workflow made sense for the particular problem.
This part of the conversation reinforced something that had been visible from the beginning: the interviewer was trying to understand how I think as an engineer, not just how many technologies I know.
A technically correct project is one thing. Being able to defend your architecture when someone challenges it is a different skill.
Tools, Technologies and Daily Workflow
Toward the end, the interviewer asked about the tools and technologies I use regularly. This included the stack mentioned throughout my resume and the technologies I work with in day-to-day development.
There were also some basic Docker questions, including fundamental Docker commands. These were not exceptionally difficult questions, but they were a good test of practical exposure. If Docker is listed among your skills, you should at least be comfortable with the basics rather than knowing only the term.
This section of the interview was relatively broad, which makes sense for an AI Engineer role. Modern AI development involves much more than models. It includes Python, APIs, databases, containers, cloud services, version control, deployment, monitoring, and application development.
The Final Part Was About the Company
The interview ended with a discussion about the company itself—its work culture, its motivation, the kind of products it builds, and what the team is working toward.
This part can sometimes be treated as a formality, but it is actually useful for both sides. A technical interview should not only determine whether a candidate can solve problems; it should also help the candidate understand what kind of environment they would be joining.
The conversation eventually wrapped up after around 40–45 minutes.
What This Interview Actually Tested
Looking back at the entire conversation, the interview was not testing one isolated skill. It tested several layers at once.
At the project level, it tested whether I genuinely understood what I had built. At the AI level, it tested whether I understood agents, RAG, chunking, embeddings, evaluation, and model selection. At the ML level, it tested whether I understood data cleaning, feature selection, model behavior, evaluation metrics, and deployment. At the software-engineering level, it tested system design choices, latency, storage decisions, backend/frontend communication, Docker, and edge cases. And through the coding problem, it checked whether the underlying programming fundamentals were still strong.
The common thread across almost every section was “why?”
Why this model? Why this embedding? Why this chunking strategy? Why Cloudinary? Why this architecture? Why these features? Why this evaluation metric? Why not another approach?
That is probably the most important lesson I would take from the experience.
How I Would Prepare Differently for an AI Engineer Interview
I would prepare projects almost like they were technical case studies. For every major project on the resume, I would be able to explain the problem, architecture, data flow, technology choices, alternatives, limitations, metrics, deployment process, failure cases, and improvements.
For RAG projects, I would know the complete pipeline from ingestion to generation, along with chunking strategies, embedding models, vector dimensions, retrieval behavior, evaluation methods, and the reasons behind every major configuration choice.
For machine learning projects, I would know exactly how the dataset was cleaned, why features were retained or removed, how the model works, why it was selected, which metrics matter, and how the system behaves after deployment.
And for every technology on the resume, I would prepare at least one strong answer to three questions:
Why did you use it?
Why not an alternative?
What limitation did it introduce?
Those three questions alone can expose whether someone truly understands their project.
Final Takeaway
The most valuable thing about this AI Engineer interview was that it did not reward surface-level familiarity. It rewarded depth.
Knowing that RAG stands for Retrieval-Augmented Generation is easy. Explaining how your own RAG pipeline works is harder. Knowing the name of an embedding model is easy. Explaining its dimensions, limitations, and why it was suitable for your use case is different. Saying that you deployed an ML model is easy. Explaining the path from frontend request to backend service to model inference and back again demonstrates real engineering understanding.
The interview lasted only around 40–45 minutes, but it covered projects, AI agents, RAG, chunking, embeddings, machine learning, evaluation, architecture, deployment, coding, Docker, internships, and engineering decisions.
