Duolingo Machine Learning Engineer Interview: Questions, Experience & Prep (2026)

Duolingo runs some of the most data-rich personalization and learning-science ML systems in the consumer app world. Their engineering interviews for ML Engineer roles typically cover four areas: applied ML and modelling concepts, system design for large-scale personalization or experimentation, coding in Python, and behavioral questions about past projects. With 77 open roles at Duolingo visible in the job snapshot as of July 2026, competition is real but so is the volume of hiring. Candidates report that Duolingo interviewers care most about whether you can connect ML decisions to product outcomes, not just whether you know the algorithms. Knowing their spaced repetition system, their approach to notification optimization, and their published research on learner engagement will give you an edge in every round.

Below are 10 questions that candidates report seeing frequently in Duolingo ML Engineer interviews. They reflect Duolingo's product focus on personalization, experimentation, and learning outcomes.

1. How would you design a model to predict which Duolingo users are at risk of abandoning their streak in the coming days?
2. Walk us through how you would set up an A/B test to evaluate a new lesson recommendation algorithm.
3. Duolingo uses spaced repetition to schedule vocabulary reviews. How would you improve or redesign this system using ML?
4. How would you build a personalization system that adapts lesson difficulty to each learner's individual pace and history?
5. Describe how you would handle class imbalance when training a churn prediction model for a freemium app.
6. How would you optimize the timing and content of push notifications to maximize re-engagement without raising unsubscribe rates?
7. How would you use NLP to automatically generate or evaluate new exercise content when Duolingo adds a new language to the platform?
8. How would you measure whether a new ML-driven feature genuinely improves learning outcomes, not just engagement time?
9. Walk us through a time you debugged a model that performed well in offline evaluation but poorly after deployment.
10. How would you design a system to distinguish users who are genuinely trying to answer correctly from those who are randomly guessing?

Q: Walk us through a time you debugged a model that performed well offline but failed in production.

*Situation:* At a previous role, I built a content recommendation model for a mobile app. Offline evaluation showed strong precision metrics, but after deployment, user engagement with the recommended items dropped noticeably compared to the baseline.

*Task:* I needed to identify the root cause and fix it without forcing a full rollback that would disrupt other teams depending on the same pipeline.

*Action:* I started by logging feature distributions at serving time and comparing them to the training dataset. I found that one key feature (average session duration) was computed differently in the serving pipeline: the training job used a rolling window over historical sessions, while the serving code used only the most recent session. I fixed the computation to match training, added automated distribution-drift monitoring so any future skew would alert the team, and ran a shadow test before re-deploying.

*Result:* After the fix, production metrics aligned closely with offline evaluation results. The drift-monitoring setup was adopted as a standard practice for all subsequent model launches on the team.

---

Q: How would you handle class imbalance when training a churn prediction model?

*Situation:* I was building a churn prediction model at a subscription product where churned users made up a small fraction of the total dataset, creating a highly imbalanced training set.

*Task:* I needed a model that would be actionable in practice, not one that simply predicted 'no churn' for every user and looked good on accuracy alone.

*Action:* I evaluated three approaches: oversampling the minority class using SMOTE, adjusting class weights in the loss function, and calibrating the model's output probabilities. I compared each using precision-recall curves rather than overall accuracy. The class-weight approach preserved the original data distribution and gave the best recall on the minority class at a precision level the business team considered acceptable for targeted outreach. I also built in a configurable decision threshold so the product team could tune recall vs. precision based on their capacity for intervention each cycle.

*Result:* The model was adopted by the product team for prioritizing at-risk users. The configurable threshold proved particularly valuable: the team adjusted it each cycle based on available resources, which they said made it far more practical than a fixed-output system.

---

Q: Describe how you would set up an A/B test to evaluate a new lesson recommendation algorithm.

*Situation:* My team had built a new collaborative-filtering model for lesson recommendations and needed to validate that it improved learning outcomes, not just time-in-app.

*Task:* I was responsible for designing the experiment so stakeholders could make a confident ship-or-rollback decision based on criteria agreed in advance.

*Action:* I defined the primary metric as a learning outcome proxy (quiz pass rate on new vocabulary after one week of exposure), with guardrail metrics covering session length and user retention. I randomized at the user level to avoid contamination between groups, ran a pre-experiment power analysis to determine the sample size needed to detect a meaningful effect, and set up daily monitoring to catch any early harmful signals. I documented in advance what a null result would mean for the decision, so there was no ambiguity at read-out.

*Result:* The experiment ran for the agreed period. The new algorithm showed a statistically significant improvement on the learning metric with no regression on guardrails. It was shipped to all users, and the decision-criteria document I wrote became a template for future experiments on the team.

For ML system design questions, use a four-step structure: (1) define the problem clearly (what are you predicting, what is the label, what is the business goal?), (2) describe data collection and feature engineering, (3) choose and justify a model family for the given constraints, (4) address serving, monitoring, and iteration. Duolingo questions reward candidates who think about the feedback loop: does showing a recommendation change what data you collect next, and how does that affect future model training?

For 'how would you measure X' questions, separate short-term proxy metrics (click-through rate, session length) from long-term outcome metrics (vocabulary retention, streak length over time). Candidates report that Duolingo interviewers push back when you mention only engagement metrics without connecting them to actual language learning.

For debugging and diagnosis questions, follow a structured approach: check for training-serving skew first, then data pipeline issues, then model drift over time. Show that you work from hypotheses rather than randomly trying fixes.

For behavioral questions, use STAR (Situation, Task, Action, Result) and keep Situation and Task concise. Go deep on the Action step: what specifically did you decide, what did you trade off, and why? Results should be concrete even if you round or approximate the figures you cite.

Product sense tied to learning outcomes. Duolingo's mission is language learning, not just app engagement. Candidates who frame every ML problem around 'does the user actually learn better?' tend to stand out. Optimizing only for time-in-app or push notification open rates without connecting to learning is a common gap interviewers notice.

Comfort with experimentation. A/B testing, statistical power, metric selection, novelty effects, and experiment integrity are all topics candidates report coming up frequently and in detail. You should be able to discuss experiment design trade-offs without being prompted, not just mention A/B testing as a generic step at the end.

Strong ML fundamentals applied in context. Gradient boosting, neural networks, regularization, precision vs. recall: these come up in product scenarios, not as trivia. Interviewers want to see you apply the concept to the situation at hand, not recite a textbook definition.

Clear communication of trade-offs. 'I used XGBoost because it handles missing values' is weaker than explaining the full decision: the data size, latency requirements, interpretability needs, and alternatives you considered. Duolingo engineers work on real production systems and expect candidates to think at that level of specificity.

In the first week, focus on core ML concepts: classification, regression, and ranking models. Practice explaining precision, recall, AUC-ROC, and when each metric matters for a given business problem. Work through at least one churn prediction and one recommendation system case study end to end. Be able to explain spaced repetition as a system and articulate where ML can improve on rule-based scheduling.

In the second week, practice ML system design. Build up a mental framework for end-to-end pipelines: data ingestion, feature engineering, model training, serving, and monitoring. Focus on Duolingo-relevant scenarios: personalization, notification timing optimization, and vocabulary retention prediction.

In the third week, refresh your knowledge of A/B testing: hypothesis testing, statistical power, p-values, multiple comparisons, and novelty effects. Practice explaining experiment design decisions out loud. Candidates report that Duolingo treats experimentation as a first-class engineering skill, not an afterthought.

In the fourth week, do applied coding practice in Python (pandas, scikit-learn, model evaluation pipelines) and prepare three to five STAR stories covering debugging, experimentation, and cross-functional collaboration. Read Duolingo's engineering blog and any published ML research to understand their actual product priorities before your rounds.

Duolingo has 77 open roles in the July 2026 job snapshot. The broader ML Engineer market in India shows 803 openings as of that date, with Bangalore leading at 165 roles, followed by Delhi at 50 and Hyderabad at 27.

Optimizing for the wrong metric. Defaulting to accuracy, click-through rate, or session length without connecting to learning outcomes is one of the most commonly reported gaps in Duolingo ML interviews. Always ask: does this metric tell us whether users are actually learning?

Skipping the data question. Jumping straight to model choice without asking what data is available, how it is labelled, and whether it might be biased signals shallow thinking. Interviewers who work on real data pipelines notice this quickly.

Vague STAR answers. Saying 'I improved model performance' without explaining what you specifically decided, what you traded off, and why is a missed opportunity. The Action step is where you demonstrate engineering depth.

Treating A/B testing as an afterthought. Many candidates outline a full system and then add 'and then we would A/B test it' as a single closing line. Duolingo interviewers expect you to treat experimentation as a core part of the design, with thought given to metric choice, randomization, and stopping criteria.

Not clarifying scope before diving in. In system design rounds, jumping into a solution without scoping scale, latency requirements, data availability, and what success looks like signals that you might build the wrong thing in practice.

Ignoring the feedback loop. In personalization and recommendation problems, your model's outputs influence user behavior, which then changes future training data. Not acknowledging this is very visible to interviewers who manage live ML systems every day.