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

Naman opens the episode with the problem most machine learning candidates run into: interviews do not only test whether someone has touched models. They test whether the candidate can explain fundamentals, code under pressure, discuss projects, and handle follow-up questions without hiding behind buzzwords. He introduces Nirmal Budhathoki, a senior data and applied scientist at Microsoft, and Karun Thankachan, a senior data scientist at Walmart, as the guests for a practical conversation on cracking machine learning interviews.

Naman also sets up their book, Decoding Machine Learning Interviews, as the backbone for the conversation. The book is framed as a one-stop resource with 100 curated machine learning interview questions and answers. The reason that matters for SEO and for candidates is simple: the episode is not an abstract AI career chat. It is a focused answer to searches around ML interview prep, data scientist interviews, machine learning engineer interviews, applied scientist interviews, and technical screens at Microsoft, Walmart, Amazon-style loops, and other large tech companies.

Naman starts with the question a master's student, data science student, or ML role aspirant would actually search: what is the structure of a machine learning interview? He asks what rounds show up, what kinds of questions candidates should expect, and how someone should prepare before jumping into individual machine learning concepts.

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

Nirmal's practical advice is to reverse-engineer the responsibilities instead of reacting to the title. If the job description talks about building ML models, evaluating models, applying statistics, and understanding foundational machine learning and deep learning, the candidate should prepare for a core ML-focused data science loop. If the role is explicitly AI engineer or GenAI-heavy, the prep has to tilt more toward generative AI systems, but that is not the default for every machine learning role.

For core ML-focused data science roles, Nirmal says the interview loop usually includes a technical screen, coding fundamentals, data structures and algorithms, machine learning 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 companies also test the candidate by asking them to walk through an ML project from their resume, which blends technical depth with behavioral signals.

Karun breaks the machine learning interview loop into clear buckets: Python or SQL screening, machine learning 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. This gives candidates a concrete preparation checklist instead of a vague instruction to study everything.

For ML system design rounds, Karun says candidates are expected to figure out the machine learning formulation, choose the right evaluation metrics, think through deployment, and explain how they would monitor the model after launch. That answer is important because many candidates treat ML system design as architecture trivia, while Karun frames it as end-to-end model ownership: problem, data, metric, model, deployment, monitoring, and iteration.

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. His rule is to study the job description and infer how much core engineering the role actually contains.

For machine learning 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.

Nirmal uses recommender systems and social networks as examples of roles where the engineering bar can move up. If the team owns production infrastructure, ranking systems, recommendation layers, or high-scale ML services, the candidate should expect deeper coding and engineering evaluation. That is why the same phrase, machine learning interview, can mean very different preparation plans depending on the company and team.

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 master's 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 lifecycle: 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. For a candidate searching how to build ML projects for internships, his advice is to avoid toy work forever and move toward datasets attached to actual business value.

Karun says the value of Kaggle is not only the dataset. Completed competitions have discussion boards where candidates can see how strong participants approached feature engineering, model selection, optimization techniques, data cleaning, and evaluation. After doing guided projects, a student can read those discussions, understand the modeling decisions, and then build their own project around the data instead of copying a notebook line by line.

Karun separates project learning from interview prep. Projects teach the day-to-day work of a data scientist or machine learning engineer, but interview prep is a different 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 candidates 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 recommendation-system interview questions.

Nirmal's deeper point is that projects should prepare candidates for edge cases. The discussion board around a real problem exposes tradeoffs, failures, and alternate approaches that a tutorial usually hides. That is the bridge from self-learning to interview readiness: the project needs to teach why a model choice was made, what else could have worked, and how the answer changes when an interviewer pushes on constraints.

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 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 machine learning 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.

Nirmal is careful about sourcing. 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 a popular regression metric, but miss the problem that adding features can make it look better even when the model is not meaningfully improved.

The adjusted R-squared discussion is a perfect example of the kind of follow-up that exposes shallow interview preparation. A candidate may know the definition of R-squared, but if they cannot explain why adding features can create a misleading improvement, or why adjusted R-squared penalizes unnecessary features, the interviewer learns that the candidate memorized the first answer but did not understand the model evaluation tradeoff.

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 tradeoffs, 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. That is exactly why a class imbalance answer should not stop at synthetic oversampling. Candidates need to talk about the data distribution, the cost of false negatives or false positives, which metric they will optimize, and whether the minority class examples are clean enough to oversample safely.

Nirmal gives concrete alternatives for class imbalance: 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. Across tools like ChatGPT, NotebookLM, Jobright AI, and Interview Master, his broader rule is to avoid generic prep and make the tool reason from the real interview context. 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.