How To Crack Machine Learning Interviews (Microsoft & Walmart Sr Data Scientists POV) - w/ Nirmal & Karun edited signal transcript

This episode is about how to crack machine learning interviews for roles like data scientist, machine learning engineer, applied scientist, and AI engineer. Naman frames the conversation around two guests: Nirmal, a senior data and applied scientist at Microsoft, and Karun, a senior data scientist at Walmart. They explain what ML interview loops actually test, why projects alone are not enough, and why their book Decoding Machine Learning Interviews focuses on 100 curated questions instead of flooding candidates with 500 scattered ones.

Naman starts by asking what a master's student or ML role aspirant should expect from a machine learning interview. He wants the lay of the land: what rounds show up, what questions candidates should expect, and how someone should prepare before jumping into specific ML concepts.

Nirmal says the first mistake is trusting the job title too much. Data scientist, ML engineer, applied scientist, and AI engineer can mean different things across companies. Candidates need to read the job description and understand whether the role is core ML, production ML engineering, applied science, analytics, or GenAI. For core ML data science roles, he expects strong statistics, ML foundations, deep learning basics, and enough awareness of current GenAI trends without pretending every role is a GenAI research job.

For core ML-focused data science roles, Nirmal says the interview loop usually includes a technical screen, coding fundamentals, data structures and algorithms, ML theory questions, and sometimes case-study or MLOps discussion. The coding is usually not as hard as a pure software engineering loop, but it still exists. Some teams also test how the candidate discusses an ML project from their resume, which lets the interviewer combine technical depth with behavioral signals.

Karun breaks the loop into a few buckets: Python or SQL screening, ML basics, deep learning basics, resume-project discussion, optional case study, ML system design for mid-level and senior roles, and behavioral or culture-fit rounds. In system design rounds, he expects candidates to define the ML formulation, choose metrics, think through deployment, and explain how they would monitor the model after launch.

Naman asks how candidates should prepare for the first technical screen, since failing that screen blocks them from ever reaching the machine learning portion. He specifically asks whether grinding LeetCode day and night is the right strategy for ML and data science candidates.

Nirmal says the right LeetCode depth depends on the role. If the title is machine learning engineer and the team expects production ownership, especially at top tech companies, the coding bar can be much closer to software engineering. If the title is data scientist or applied scientist, medium-level LeetCode is often enough. He says candidates should study the job description and infer how much engineering the role actually contains.

For ML engineering roles at companies like Google or Meta, Nirmal says there is no excuse to ignore coding. These roles often sit close to engineering teams and include putting models into production, maintaining services, and owning model health. For data science roles, the coding screen still matters, but the depth may be lighter and more balanced with ML, statistics, and business understanding.

Naman asks what students should do from day one of a master's program if they want an ML job. He is trying to avoid the common pattern where students wait until the last minute, then cram 20-hour days of interview prep when recruiting begins.

Karun says first-year students should focus on projects, assuming they already have some coding foundation. Guided projects on YouTube or similar sources are useful for learning the machine learning life cycle: problem formulation, metric selection, model fitting, tuning, and basic evaluation. He is clear that guided projects alone will not land the job, but they help students understand what ML work feels like before they try to build independently.

Once students understand guided projects, Karun recommends moving to real business problems. His favorite source is Kaggle, especially completed competitions sorted by prize money, because prize money roughly signals business relevance. He tells candidates to read the discussion boards, study how other people solved the problem, borrow ideas responsibly, and then build their own models around the data.

Karun separates project learning from interview prep. Projects teach the work of a data scientist or machine learning engineer, but interview prep is a separate mode that includes LeetCode, SQL, ML theory, and structured communication. He suggests switching into interview-prep mode roughly 90 days before the candidate needs to perform in interviews.

Nirmal agrees that projects should be the early focus because students often lack professional experience. A strong project lets a candidate advocate for their skills before they have a job title. He likes Kaggle because candidates can learn incrementally from existing notebooks and discussion boards, then redefine the problem statement or use the same dataset in a slightly different way to create a more original project.

Naman asks how much of the knowledge gained from projects carries into interviews. He wants to know whether self-directed projects prepare someone for the actual questions, or whether interview questions are too niche and require a separate study path.

Nirmal says projects are relevant when they teach multiple approaches to the same problem. If Netflix publishes a recommendation problem, for example, one candidate might try collaborative filtering, another might try a hybrid recommender, and another might rely on matrix factorization. Reading and building across those approaches gives the candidate real mental hooks for answering recommendation-system questions in interviews.

From the interviewer side, Nirmal can tell when someone is only reciting theory. Interviewers are not always looking for extreme depth, but they are also not satisfied with surface-level definitions. He disagrees with the advice that ML candidates only need breadth. They need enough depth to survive follow-up questions and case-style probes.

Karun gives his own failure story. During his master's, his projects focused on language models and fine-tuning LLMs, so he assumed interviews would focus there. In his first Amazon interview, the first question was about the assumptions of linear regression, and he fumbled. That experience convinced him that candidates need a fast way to refresh fundamentals, not only deep familiarity with their favorite niche.

Karun says Decoding Machine Learning Interviews is designed to fix that gap. It covers the most common fundamental topics candidates are likely to see, based on publicly posted FAANG-style questions and their own conversations with mentees. The book is not trying to replace project work; it is meant to clarify which fundamentals matter and how deeply a candidate should know them.

Nirmal says the internet does not lack ML information. The hard part is identifying the proper signal. He and Karun deliberately chose 100 questions because they wanted an optimized resource for someone who might have two or three weeks before an interview. They could have included more, but a 500-question book would recreate the same overload problem candidates already face online.

Nirmal says candidates should not wait until they are interviewing to practice coding. They can do one or two coding questions a day as a baseline habit. For ML theory, he sees more room for focused ramp-up when an interview is coming, as long as the candidate uses a concise resource that covers the right topics without too little or too much detail.

The book's questions are grouped by patterns that show up repeatedly in public interview reports and common mentee experiences. Some questions are tagged with company names only when those questions are already public online, not from Nirmal's Microsoft interviews or Karun's employer-specific confidential experience. The goal is to capture repeated patterns, not disclose private interview loops.

Karun lists the book's core scope: statistics and probability, machine learning fundamentals, metrics and metric comparison, linear regression, other regression models, KNN, K-means, support vector machines, and deep learning basics. He says the book purposely focuses on ML fundamentals rather than GenAI, though a future version could expand into that area.

Karun remembers interviewers running rapid-fire ML theory rounds to test foundations. They might ask one question after another for ten minutes to see where the candidate breaks. He says many questions in the book reflect similar experiences, where the interviewer is not asking for exotic novelty but wants to know whether the candidate really owns the basics.

Nirmal draws the line between basic and slightly-beyond-basic with linear regression. Knowing the assumptions is table stakes, but candidates should also understand residual plots, R-squared, the weakness of R-squared, and why adjusted R-squared exists. He says many candidates know that R-squared is popular, but miss the problem that adding features can make it look better even when the model is not meaningfully improved.

Nirmal says their goal is to go beyond definitions. A weak resource asks what PCA is. A stronger resource asks where PCA fails, what its disadvantages are, and what alternatives exist. He says candidates often study what a concept is and what it does, but forget the flip side. In interviews, those edge cases are often what expose shallow preparation.

Karun says the book is future-proof because the fundamentals remain useful even as models change. Once a model is built, a practitioner still needs error analysis, metrics, bias-variance trade-offs, hyperparameter tuning, regularization, and evaluation. If the goal is core ML work, understanding how models are built and evaluated does not disappear just because the field moves quickly.

Nirmal agrees that the book stays relevant because companies are unlikely to stop asking ML fundamentals anytime soon. He jokes that coding rounds would probably disappear before ML rounds do, and coding rounds are still here. Because the book is concept-heavy rather than framework-version-heavy, it avoids the problem of technical books that age badly when a library or JavaScript framework changes.

When Naman asks for each guest's favorite or most underrated question, Karun chooses the assumptions of linear regression because it is the question that originally caught him off guard. He now uses it as an example when discussing interview prep, and he wants other candidates to avoid making the same mistake.

Nirmal chooses class imbalance as his memorable question. He works in security, where normal behavior massively outnumbers anomalous behavior, so class imbalance is always present. When he asks candidates how to handle class imbalance, most answer only with SMOTE. He says SMOTE is one method, but the interview gets interesting when he asks what else can be done and what the drawbacks of SMOTE are.

Nirmal explains that SMOTE can amplify noise if the minority class has noisy examples. Candidates can also use class weights, penalize errors on the minority class more heavily, and inspect package parameters in libraries like scikit-learn instead of only using defaults. For him, this question separates people who memorized one tactic from people who understand the modeling tradeoff.

Karun says AI can help candidates practice, but it should not be used passively. He mentions tools that simulate behavioral interview practice and coding follow-ups. Interview Master, for example, can analyze a candidate's current SQL or Python code and provide hints or follow-up questions. That matters because real interviews do not end when the candidate solves the first version of a problem; interviewers often ask follow-ups.

Karun also recommends using ChatGPT-style prompts for fundamentals practice. For a topic like linear regression or logistic regression, a candidate can ask for ten interview questions and often get six or seven useful ones. The candidate should then answer those questions themselves, identify weak concepts, and use the model to keep probing rather than just reading an answer.

Nirmal says candidates should customize AI tools to the actual role. He recommends feeding the model the job description, recruiter notes, role responsibilities, and any specifics from the hiring conversation, then asking for a structured preparation plan and edge cases around likely questions. The more creative and specific the prompt, the more useful the reasoning from the model.

Nirmal mentions Jobright AI for resume automation and job recommendations, and NotebookLM for turning notebooks or project material into a more digestible learning format. Naman adds that NotebookLM's mind-map feature helps him see relationships between concepts visually, which can be useful for students trying to connect ML topics rather than memorize them as isolated definitions.

Naman suggests using voice mode in ChatGPT as an interactive tutor. Instead of asking for a monologue, candidates can prompt it to assume normal intelligence, ask them questions, and quiz them through concepts. For ML interview prep, they could provide the job description and role title, then practice answering out loud as if it were a real interview.

Nirmal says mock interviews are underrated because they simulate the pressure of the real conversation. He has seen the value of mocks while mentoring candidates and says they provide extra confidence, especially when the mock interviewer understands the field. Paid mocks can be more expensive than resume reviews because they require real-time simulation and detailed feedback.

For finding mock interviews, Nirmal recommends using platforms with mentors and checking reviews carefully so the candidate gets the right value for the money. He and Karun both offer mentoring and mock interview support through platforms like Topmate, but the broader point is that candidates should practice with people who can challenge them like strangers, not only friends who already know them.

When asked why someone should buy the book, Karun says it is the most concise way to refresh ML fundamentals. He previously recommended two core books: Introduction to Statistical Learning in Python and Deep Learning by Ian Goodfellow. Many concepts he learned from those books show up in the answers here, but Decoding Machine Learning Interviews is now the resource he would send candidates to for interview prep.

Nirmal says the book brings together two people who have both taken and given interviews and who have mentored many candidates. His pitch is simple: do not fall into the trap of too much information. If a candidate wants a practical ML interview resource, this book is priced so they should not regret trying it, and the sample questions give them a way to judge the style before buying.

Karun adds that candidates who are unsure can read five sample questions on the book's website and review the interview questions he and Nirmal have been posting online for more than a year. The book is meant to consolidate that public teaching into a focused prep path.