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

OneShot AI is an AI-first company with 8 open Machine Learning Engineer roles as of July 2026, making it one of the more active ML hirers right now. The company builds production-grade AI systems, and the ML team works close to both research and product, so interviews typically test depth in core ML alongside the ability to ship models fast.

The broader market context: there are 803 ML Engineer openings tracked across India as of July 2026. Bangalore leads with 165 roles, followed by Delhi (50), Hyderabad (27), Mumbai (15), Pune (14), and Chennai (14). OneShot AI's 8 open roles signal active expansion, so this is a good window to apply.

Candidates report the interview process typically runs 3-4 rounds: a screening call with HR or a recruiter, one or two technical rounds covering ML fundamentals and coding, a system design round focused on ML infrastructure, and a final round with a hiring manager or senior team member. The full process can take 2-4 weeks end to end. Strong preparation across fundamentals, applied ML, LLMs, and clear communication of past project work is what separates strong candidates.

These questions come up frequently at AI-first companies like OneShot AI, based on candidate reports and the nature of the ML Engineer role:

1. Walk me through how you would design an end-to-end ML pipeline, from raw data to a deployed model in production.
2. How have you handled class imbalance in a real project? What techniques did you use and why?
3. Explain precision and recall. In a business context, when would you prioritise one over the other?
4. How do you detect and respond to data drift or model degradation after a model goes live?
5. Tell me about a time you had to improve model latency or reduce inference cost. What trade-offs did you make?
6. How would you approach fine-tuning a large language model for a domain-specific task when labelled data is limited?
7. What MLOps practices do you follow? How do you version datasets, models, and experiments?
8. Describe a situation where your model performed well offline but failed in production. What was the root cause?
9. How do you decide when a model is ready to deploy versus when it needs more iteration?
10. How would you design a feature store for a recommendation system that needs both real-time and batch features?
11. What is your approach to evaluating generative AI output when there is no single correct answer?
12. If traffic to your model serving endpoint spikes many times over during a peak event, how do you keep the system running without downtime?

Q: Describe a situation where your model performed well offline but failed in production.

*Situation:* At my previous company, we built a churn prediction model that hit strong accuracy scores on our held-out validation set. Within two weeks of deployment, the model's predictions became unreliable and the business team flagged a drop in actionable alerts.

*Task:* I was responsible for diagnosing and fixing the issue without rolling back the feature entirely.

*Action:* I set up monitoring on incoming feature distributions and quickly spotted that a data pipeline upstream had changed the encoding of a categorical feature, 'subscription_type', without notifying the ML team. I added schema validation at the ingestion layer, set up alerts for feature drift, retrained the model on a refreshed dataset, and documented the incident. I also proposed a cross-team change-management process for shared data pipelines.

*Result:* Model performance recovered within a week of the fix. The schema validation layer caught two more silent upstream changes in the following quarter before they could affect production.

---

Q: How have you handled class imbalance in a real project?

*Situation:* I worked on a fraud detection model where legitimate transactions outnumbered fraudulent ones by a wide margin, making the minority class hard to learn reliably.

*Task:* I needed to improve recall on the fraud class without creating so many false positives that the ops team could not keep up with manual review.

*Action:* I tried three approaches: oversampling the minority class using SMOTE, tuning the decision threshold based on the precision-recall curve rather than using the default threshold, and adjusting class weights in the loss function. I evaluated each on a consistent held-out set and ran a small A/B test on live traffic to measure real-world impact.

*Result:* The combination of class weighting and threshold tuning gave the best outcome. Recall on fraud cases improved meaningfully and the ops team's false-positive review load stayed at a manageable level. I documented the methodology so the team could repeat it during future model updates.

---

Q: How would you approach fine-tuning an LLM for a domain-specific task with limited labelled data?

*Situation:* Our product team needed a model to classify customer support tickets into intent categories. We had only a few hundred labelled examples to work with.

*Task:* I had to build something accurate enough for production given that data constraint and a tight timeline.

*Action:* I started with a pre-trained model and used few-shot prompting to establish a baseline. I then created a small but high-quality labelled set using active learning, directing annotation effort toward examples the model was most uncertain about. I used parameter-efficient fine-tuning (LoRA) to adapt the model without full retraining, keeping compute costs low, and iterated on the prompt format and label taxonomy based on evaluation results.

*Result:* The fine-tuned model outperformed the few-shot baseline by a clear margin on the held-out set. The annotation process also surfaced ambiguous ticket categories, which led to a cleaner label taxonomy that the product team adopted going forward.

Use STAR for behavioural questions. Situation and Task should be brief, 2-3 sentences each. Action is where you show real depth: name the specific techniques, tools, and decisions you made. Result should be concrete, but only use numbers you actually have from your own work.

For technical design questions, use a structured walkthrough:

1. Clarify the problem scope and constraints (latency, scale, data availability) before proposing a solution
2. State your high-level approach before diving into component details
3. Walk through data, model, training, and serving as distinct layers
4. Call out trade-offs explicitly rather than presenting one option as obviously correct
5. Describe how you would monitor and iterate post-launch

For 'explain a concept' questions, lead with a plain-English definition, give a concrete example, then connect it to a real decision you have made. Interviewers at AI companies want to see that you can explain ML concepts clearly enough to work with product managers and engineers who are not ML specialists.

For 'tell me about a failure' questions, do not skip past the failure too quickly. Spend real time on what went wrong and why, then show what you changed as a result. A response like 'I would choose approach A because of constraint B, but if B changes then approach C becomes better' signals the kind of trade-off thinking interviewers at production AI companies are looking for.

At a company like OneShot AI, which is building AI products at pace, interviewers typically look for a few things above all else.

Production mindset over research mindset. They want engineers who have shipped models, not just trained them. Be ready to talk about serving infrastructure, monitoring, rollback strategies, and the messiness of real data as naturally as you talk about model architecture.

Clear reasoning under uncertainty. ML involves a lot of 'it depends' decisions. Interviewers want to hear you articulate trade-offs rather than recite a single correct answer. Showing that you weigh constraints before committing to a design signals genuine engineering maturity.

Collaboration with non-ML teammates. Early-stage AI companies need ML engineers who communicate well with product and business stakeholders. Expect scenarios where you have to explain a model decision clearly or push back on an unrealistic request from a product manager.

Comfort with LLMs and modern tooling. Given OneShot AI's focus on AI products, familiarity with large language models, fine-tuning approaches (LoRA, PEFT), prompt engineering, and evaluation methods for generative outputs is likely to be tested directly. You do not need to be an LLM researcher, but you should be fluent in practical deployment considerations.

Week 1: Core ML fundamentals

Review supervised and unsupervised learning, bias-variance trade-off, regularisation, ensemble methods, and evaluation metrics (precision, recall, AUC, F1). Practice explaining each concept out loud in plain English, not just equations. Being able to teach a concept is a strong signal.

Week 2: Applied ML and MLOps

Study the ML model lifecycle end to end: data pipelines, feature engineering, experiment tracking (MLflow or similar), model versioning, CI/CD for ML, and production monitoring. Revisit or build a project where you deployed a model to a real endpoint and monitored it.

Week 3: LLMs and generative AI

Given OneShot AI's focus, prepare specifically for questions on transformer architecture basics, fine-tuning methods, prompt engineering, RAG pipelines, and evaluating generative outputs. Focus on practical deployment considerations rather than deep theory.

Week 4: System design and behavioural prep

Practice 2-3 full ML system design walkthroughs covering areas like recommendation systems, fraud detection, and semantic search. Write out 5-6 STAR stories from your experience covering: a production failure, a performance improvement, a collaboration challenge, and a project where you had real ownership from start to finish.

knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so your applications to OneShot AI and similar roles keep moving while you are deep in prep.

Treating the interview as a theory exam. Reciting definitions without connecting them to real work is a common failure mode. Every answer should have a concrete example, even a small one from a personal project.

Skipping the 'why' on design choices. Saying 'I used XGBoost' tells the interviewer nothing. Saying 'I used XGBoost because the dataset was tabular, training time was a constraint, and the business needed feature importances for regulatory reasons' shows real engineering judgment.

Not asking clarifying questions on design problems. Jumping straight into a solution before pinning down scale, latency requirements, and data availability suggests you design without real constraints. Interviewers at product companies see this as a red flag.

Underselling production experience. Many candidates spend most of their answer on model training and rush through deployment and monitoring. At a company shipping AI products, the production side of your experience is at least as valuable as the modelling side.

Being vague about results. Saying 'the model improved a lot' is much weaker than describing the direction and scale of improvement and the business outcome it led to. If you do not have exact numbers, explain why and give qualitative evidence instead.

Ignoring the final round. Candidates often over-prepare technical content and walk into the final round without a clear answer for why OneShot AI specifically. Research the company's product and mission and prepare a genuine, specific answer rather than a generic 'I want to work in AI.'