100 Interviews Later: What I Wish More AI & ML Candidates Knew

Hey, I’m Samin.

Today, September 17, 2026, is a little special for me.

I just completed my 100th interview as an interviewer.

Before I talk about interviews, candidates, AI, ML, careers, or anything technical, I want to start with a simple thank you.

Thank you to all the friends and people who have stood with me throughout my journey. The people who supported me when I was starting out, shared their knowledge with me, challenged my thinking, trusted me with opportunities, and helped me grow along the way.

Careers are never really built alone. Behind every opportunity, every lesson, and every milestone, there are people who helped us reach that point. I’m genuinely grateful to everyone who has been part of mine.

I’m currently working as a Senior Applied AI Engineer, and over the years I’ve had the opportunity to interview candidates for different roles, including Software Engineering Interns, Software Engineers, AI Engineering Interns, ML Engineering Interns, AI Engineers, ML Engineers, Applied AI Interns, and Applied AI Engineers.

Most of my interviews have been around AI, machine learning, and applied AI.

And after 100 interviews, you start noticing patterns.

Some candidates know a lot but struggle to communicate what they know. Some candidates may have less experience, but they are incredibly good at reasoning through problems. Some have impressive CVs but struggle to explain the projects written on them. Others may forget the exact technical term for something, but once they start explaining the concept, you immediately understand that they genuinely know what they are talking about.

Sitting on the interviewer side of the table has changed the way I look at interviews.

So I wanted to write down a few things I wish more candidates knew before walking into their next one.

This is not a guide to "hack" an interview.

It is simply what I have learned from 100 conversations with candidates.

1. Please Don't Let the Stress Take Over

This is probably the biggest thing I notice.

Candidates get nervous. Sometimes very nervous.

And I completely understand why.

You may have spent days preparing. You may really want the opportunity. Maybe this job could change your career. Then suddenly you join a call and someone starts asking you questions about things you studied months or even years ago.

Of course there is pressure.

But something candidates should remember is that most interviewers are not sitting there waiting for you to make a mistake.

At least, that is never how I approach an interview.

I want the candidate to feel comfortable because that is when I can actually understand how they think, what they know, and how they approach a problem.

I normally try to start interviews in a very friendly way. I would much rather have a good technical conversation with someone than make the interview feel like an examination.

If you don't understand my question, ask me to explain it.

If something is unclear, ask a question.

If you need a few seconds to think, take them.

If you give an answer and later realize that you made a mistake, correct yourself.

That is completely fine.

Sometimes I can clearly see that a candidate knows the answer, but stress prevents them from communicating it properly.

You don't need to be perfect during an interview.

You need to help the interviewer understand how you think.

2. Start the Interview Like a Human Conversation

The first few minutes of an interview matter more than many people realize.

Say hello properly. Introduce yourself. Smile. Listen when the interviewer is speaking. Be friendly.

You don't have to join the call and immediately switch into "exam mode."

A good interview should feel like a conversation between two people trying to understand whether working together makes sense.

Personally, I really enjoy interviewing candidates who communicate naturally.

You don't need to become a completely different person just because you're attending an interview. Be professional, of course, but still be yourself.

Good communication creates a much better environment for both sides.

3. Prepare Your Interview Setup Properly

This sounds small, but it matters.

Before joining a remote interview, check your camera, microphone, internet connection, screen-sharing permissions, and any tools you might need.

Dress properly as well.

You don't necessarily need to wear a suit, but presenting yourself professionally shows that you took the interview seriously.

One particular thing I notice quite often is candidates using a second monitor as their main screen throughout the interview.

Using multiple monitors is completely normal for engineers. I use them too.

But during an interview, if you spend most of the time looking somewhere away from the camera, it can feel strange from the interviewer's side.

Sometimes I genuinely cannot understand whether the candidate is looking at another meeting window, checking notes, searching for something, or reading an answer somewhere else.

Even if the candidate is doing nothing wrong, the experience can still feel unusual.

My suggestion is simple: keep the interview window close to your camera and make it your main focus.

You don't need to stare directly into the camera every second. Just make the conversation feel natural.

4. Prepare for the Role, Not for a Question List

One thing candidates often want to know is:

"What questions will they ask me?"

The truth is that you usually cannot know.

And I don't think trying to predict every possible question is the best way to prepare.

Prepare for the role instead.

If you're interviewing for an ML Engineer role, understand what an ML Engineer actually does.

If you're applying for an Applied AI role, understand how an AI solution goes from an idea to something that real users can actually use.

If you're applying for an internship, make sure your fundamentals are strong.

An interview can move very quickly between topics.

We might start with a machine learning model and suddenly move into data, evaluation, APIs, databases, deployment, system design, or something you mentioned on your CV.

You cannot memorize answers for every possible direction.

What you can do is build strong fundamentals.

When you understand the basics properly, you can reason through questions you have never seen before.

That is far more valuable than memorizing 200 interview answers.

5. Fundamentals Still Matter — A Lot

AI is moving extremely fast.

Every few months we get new models, frameworks, libraries, architectures, and tools.

It is exciting, but it can also create a problem.

Sometimes candidates learn every new tool they see online while skipping the basics underneath them.

That becomes very visible during interviews.

If you are interviewing for AI or ML roles, make sure you understand your fundamentals.

Understand how machine learning works.

Understand your data.

Understand evaluation.

Understand basic software engineering.

Understand APIs and databases.

Understand what happens before and after the model.

For modern AI roles, it also helps to understand the basics behind things such as embeddings, retrieval, agents, model evaluation, latency, cost, and the limitations of AI systems.

You do not need to know everything.

Nobody does.

But there should be a strong foundation underneath the technologies written on your CV.

Tools will change.

Fundamentals will stay with you much longer.

6. Know Everything You Put on Your CV

This is probably one of the most important things I can say.

Please read your CV before your interview.

Then read it again.

Anything written there is something the interviewer can ask you about.

If you say you built a recommendation system, I may ask you how it worked.

If you say you improved something by 30%, I may ask how you measured that improvement.

If you say you designed an architecture, I may ask you to draw it.

If you mention a framework or technology, I may ask why you selected it.

Your CV is basically giving the interviewer a map of where to explore.

You don't need to remember every single line of code from something you built years ago, but you should understand the work you are claiming as your experience.

When you talk about a project, be prepared to explain things like:

• What problem were you solving?
• What was your responsibility?
• Why did you choose that approach?
• What problems did you run into?
• How did you evaluate your solution?
• What would you change if you built it again today?

Those answers tell me much more than a long list of technologies.

7. Be Ready to Draw Your Ideas

This is something that surprises me quite often.

I give a candidate a design problem and ask them to share their screen.

Then suddenly the candidate has no idea what whiteboarding tool to use.

Now they are trying to solve the problem and learn a drawing application at the same time.

That creates unnecessary pressure.

If you're interviewing for engineering roles, especially roles involving system design, AI architecture, backend systems, or ML systems, be comfortable drawing your ideas.

Your diagram doesn't need to be beautiful.

Boxes and arrows are enough.

What matters is whether you can structure your thinking visually.

If I ask you to design an AI system, don't immediately start filling the screen with technologies.

Start with the problem.

What goes into the system?

What comes out?

Who is using it?

Where does the data come from?

What happens to that data?

Where does the AI component fit?

How will the system be evaluated?

What happens if something fails?

The whiteboard simply gives us a common place to discuss the solution.

So before your next interview, open a whiteboarding tool and practise designing a few systems.

Get comfortable sharing your screen and explaining while you draw.

8. Think Out Loud

This is probably one of my favourite qualities in a candidate.

When I give you a design question, don't become completely silent for several minutes while trying to build the perfect answer inside your head.

Talk to me.

Tell me what you're thinking.

You can say something like:

"Before I start designing this, I want to understand how many users we expect."

Or:

"I'm thinking about two possible approaches here."

Or:

"I'm assuming this needs to respond in real time. Is that correct?"

Now I can follow your reasoning.

I can understand why you are making certain decisions.

And sometimes, if you are moving in the wrong direction, I may even give you a small hint that helps you get back on track.

When you stay completely silent, the interviewer has no idea what is happening.

Maybe you're developing an excellent answer.

Maybe you're stuck.

Maybe you misunderstood the question.

We simply don't know.

In technical interviews, the final answer matters, but the way you reach that answer is often just as important.

9. Ask Questions — Please

Some candidates seem afraid that asking questions makes them look weak.

It usually doesn't.

In fact, it can show the opposite.

Real engineering problems are rarely perfectly defined.

Requirements can be unclear. Constraints can change. Data can be messy. Budgets exist. Deadlines exist. Existing systems exist.

So when I give someone a design problem and they immediately start designing without asking a single question, I sometimes become more concerned than impressed.

First understand the problem.

Ask about the users.

Ask about the scale.

Ask about the data.

Ask about latency.

Ask about cost.

Ask about existing systems.

Ask what success looks like.

A good engineer does not just produce solutions.

A good engineer first makes sure they understand the problem they are solving.

10. Don't Stay on the Surface

This is especially important in AI and ML interviews.

Imagine I ask you:

"What is RAG?"

Giving me the definition is fine.

But that is usually only the beginning of the conversation.

Why would you use it?

When would you not use it?

What happens if retrieval returns poor results?

How would you evaluate it?

How could you improve it?

What problems might appear in production?

This is where the difference between knowing a definition and understanding something becomes very clear.

The same applies to almost every technical topic.

If I ask about a database, don't only tell me what it is. Tell me why you would choose it.

If I ask about a model, don't only explain how it works. Tell me when you would use it.

If I ask about something you built, explain the decisions behind it.

Definitions can be memorized.

Understanding is much harder to fake.

11. Don't Panic If You Forget the Exact Technical Term

I've seen candidates clearly understand something but suddenly become nervous because they cannot remember the exact technical word for it.

Don't worry too much about that.

If you remember the correct term, great.

But if you don't, explain the concept.

Tell me what it does.

Tell me how it works.

Give me an example.

Explain where you have used it.

If you can explain the idea clearly, that already tells me something important: you understand it.

Technical vocabulary is useful because it gives engineers a common language, but vocabulary without understanding doesn't mean much.

I would rather speak with someone who understands a concept deeply but temporarily forgets its name than someone who remembers every buzzword but cannot explain what any of them mean.

12. It's Completely Fine to Say "I Don't Know"

You are not expected to know everything.

Especially in AI.

The field is simply too large.

If I ask you something you genuinely don't know, don't create an answer just because you feel like you need to say something.

Be honest.

You can say:

"I haven't worked with that directly, but based on what I know, this is how I would approach it."

That answer can actually lead to a very interesting conversation.

It shows honesty.

It also shows whether you can reason from the knowledge you already have.

Trying to confidently fake an answer is usually much worse than admitting that you don't know something.

13. Build Things — Don't Only Study Them

One pattern becomes very clear after interviewing enough people.

You can often tell when someone has actually built things.

They know that real datasets are messy.

They know systems fail in unexpected ways.

They understand that the most accurate model is not always the best production solution.

They have encountered bugs that tutorials never mentioned.

They have changed architectural decisions halfway through projects.

They understand trade-offs because they have actually experienced them.

And importantly, that experience doesn't have to come only from a full-time job.

Build personal projects.

Take internships.

Contribute to open-source projects.

Work seriously on university projects.

Build something for yourself.

Deploy it.

Let real users try it.

Watch it fail.

Then fix it.

That experience becomes extremely useful when someone asks you a real problem during an interview.

14. Start Building Your Career as Early as You Can

This is something I personally believe strongly.

You don't have to wait until graduation to start your career.

And by "start your career," I don't mean that everyone needs to get a full-time job while studying.

I mean start gaining exposure early.

Build things.

Take internships when possible.

Join projects.

Work with people who know more than you.

Talk to engineers.

Explore different areas.

Make mistakes while the cost of making those mistakes is still small.

The earlier you expose yourself to real problems, the more context you build.

Then when someone asks you a question during an interview, your answer does not come only from something you read in a blog yesterday.

You can connect it to something you have actually experienced.

That makes a huge difference.

And if you're reading this later in your career, don't worry.

There is no single correct timeline.

The important thing is to start creating real experience from wherever you are today.

15. Don't Prepare Only by Memorizing Answers

Practicing interview questions is useful.

But don't turn your entire preparation process into memorization.

Because one follow-up question can completely break a memorized answer.

Instead, practise understanding topics.

Take something you are learning and ask yourself:

• Why does this exist?
• What problem does it solve?
• How does it work?
• When should I use it?
• When should I avoid it?
• What alternatives exist?
• What could go wrong?
• Have I actually used it?

If you can answer those questions, you are not only preparing for interviews.

You are actually becoming better at the subject.

16. Use the Interview to Learn About the Interviewer and the Team Too

Near the end of an interview, candidates are usually given an opportunity to ask questions.

Please use it.

Ask about the role.

Ask about the problems the team is currently solving.

Ask what your first few months might look like.

Ask how technical decisions are made.

Ask what makes someone successful in the team.

Ask what the interviewer enjoys about the work.

The questions you ask also tell the interviewer something about you.

They show what you care about.

And remember that the interview is not only the company evaluating you.

You are also evaluating whether this is somewhere you want to work.

17. Remember That Interviews Are Not Perfect

This is something I have learned very clearly after interviewing 100 candidates.

Interviews are not a perfect measurement of someone's ability.

An excellent engineer can have a bad interview.

Someone who performs very well in interviews can still struggle with real engineering work.

People get nervous.

People have bad days.

People communicate differently.

Sometimes the interviewer asks a bad question.

Sometimes the candidate misunderstands a good one.

Sometimes the interview format simply does not allow someone to demonstrate what they are best at.

So if you have been rejected from an interview, don't immediately translate that into:

"I'm not good enough."

Treat it as one piece of feedback.

Look at what you can improve.

Improve it.

Then move forward.

One interview is a very small part of what could be a 20- or 30-year career.

What Have I Learned After 100 Interviews?

When I think about the candidates I've enjoyed interviewing the most, they are not necessarily the people who answered every question perfectly.

They are the people who can have a real conversation.

They listen.

They ask questions.

They understand their fundamentals.

They know the things written on their CV.

They can explain what they built.

They are curious.

They are willing to go deeper.

They communicate their thought process.

They admit when they don't know something.

And they are willing to learn.

Technology changes incredibly quickly, especially in AI.

None of us can know everything.

But the ability to think, communicate, learn, adapt, and stay curious will remain valuable for a very long time.

Finally, Thank You

To every candidate who has sat on the other side of one of these 100 interviews: thank you.

Every interview has taught me something too.

Some candidates introduced me to approaches I hadn't considered before.

Some conversations taught me about technologies I hadn't explored deeply.

Some reminded me how difficult interviews can feel from the candidate's side.

And some simply turned into really enjoyable technical conversations.

Being the interviewer doesn't mean I have all the answers.

I'm still learning too.

I'm still improving the way I interview people.

And maybe when I reach interview number 200, I'll look back at this article and realize that some of my thinking has changed again.

That is part of the journey.

So if you have an interview coming up, prepare well.

Know your fundamentals.

Know your own work.

Practise explaining how you think.

Build real things.

Ask questions.

Stay curious.

And most importantly, try to enjoy the conversation.

Because if someone invited you to that interview, they already saw something worth talking to you about.

100 interviews completed — and hopefully many more conversations, lessons, and people to learn from.