sarvam Data Scientist Interview: Questions & Prep (2026)

Sarvam AI is one of India's most closely watched AI startups, building large language models and speech systems for Indic languages. With 68 open roles as of July 2026 and a mission to make AI work natively in Hindi, Tamil, Telugu, Kannada, and many other Indian languages, the company attracts candidates who want foundational AI research to have real-world reach.

The interview process typically runs 3-4 rounds, candidates report. Expect an initial screening call, followed by technical rounds on ML fundamentals, NLP depth, and a coding exercise, then a final team or culture conversation. Because Sarvam sits closer to a research lab than a product company, interviewers probe your thinking process as much as your final answers.

Data Scientist roles here are not about dashboards or business analytics. They are about training data curation, model evaluation, fine-tuning for Indic languages, and helping advance what is possible for low-resource language AI.

These questions appear consistently in Sarvam data science interviews, based on candidate reports and the company's public research focus.

1. Walk us through how you would fine-tune a pre-trained LLM on a low-resource Indic language dataset.
2. What is the difference between BPE and SentencePiece tokenization, and which would you prefer for Hindi or Tamil text? Why?
3. Explain LoRA and QLoRA. When would you choose parameter-efficient fine-tuning over full fine-tuning?
4. How would you build and evaluate a benchmark for an Indic language task where no standard benchmark currently exists?
5. Describe how attention mechanisms work and how transformers handle long-range dependencies.
6. How do you handle noisy, code-switched text such as Hinglish in a classification or generation pipeline?
7. Your speech recognition model performs well on clean audio but poorly in real-world Indian environments. What is your approach?
8. How would you design a data collection pipeline to gather high-quality training data for a low-resource language?
9. What trade-offs do you consider when quantizing a model for deployment on low-bandwidth or low-compute devices?
10. Tell me about a time you worked with a dataset that was messy, small, or biased. How did you handle it?
11. How do you evaluate a language model beyond perplexity? What metrics matter for real-world Indic NLP tasks?
12. What do you know about Sarvam's models and research? How does your background connect to our mission?

Q: Walk us through how you would fine-tune a pre-trained LLM on a low-resource Indic language dataset.

*Situation:* At my previous role, we needed to adapt an English-centric LLM to answer customer queries in Marathi, but our labeled dataset was very small.

*Task:* My responsibility was to produce a fine-tuned model that outperformed direct prompting of the base model on a domain-specific QA task.

*Action:* I first analyzed the tokenizer's Marathi coverage and found the base BPE tokenizer was over-segmenting Devanagari tokens, hurting performance. I switched to a SentencePiece tokenizer trained on a combined Hindi-Marathi corpus. I then used QLoRA with 4-bit quantization to fine-tune on our small dataset, applying learning rate warmup and early stopping based on validation loss. I also augmented the training set with back-translated English data.

*Result:* The fine-tuned model showed a clear improvement in task-specific accuracy over the baseline on a held-out evaluation set, and inference cost dropped significantly due to quantization.

---

Q: How do you handle noisy, code-switched text like Hinglish in a classification pipeline?

*Situation:* I was building a sentiment classifier for social media comments that mixed Hindi and English in the same sentence.

*Task:* I needed a model that would not collapse on code-switched input, since most pre-trained models had seen very little Hinglish during training.

*Action:* I ran a language identification model at the token level to understand the switching patterns. I chose a multilingual base model publicly reported to handle code-switching well, then curated a small set of human-labeled Hinglish examples for domain adaptation. I also wrote augmentation scripts that introduced synonyms from both Hindi and English vocabularies.

*Result:* Evaluation on a held-out Hinglish test set showed a clear improvement over the English-only baseline, and the pipeline was later adopted by another team in the same org.

---

Q: Tell me about a time you worked with a dataset that was messy, small, or biased.

*Situation:* I was asked to build a named entity recognizer for a regional Indian language where annotated data was scarce and labels had inconsistencies introduced by multiple annotators.

*Task:* I needed to deliver a usable model despite poor data quality and a very small sample size.

*Action:* I ran inter-annotator agreement analysis to surface the most conflicting label types, then held a short calibration session with the annotation team to resolve ambiguities. I applied cross-lingual transfer from a high-resource related language as a starting point, then fine-tuned on the cleaned subset. I maintained a strict validation split to avoid leaking noisy labels into evaluation.

*Result:* The transfer-learned model outperformed training on the raw noisy data, and the annotation guidelines we produced became the standard for future labeling work on the project.

For technical ML or NLP questions, lead with your reasoning before your answer. State the trade-offs first ('it depends on X and Y'), then give your recommendation. Research-oriented companies like Sarvam want to see that you understand the 'why', not just the 'what'.

For system design questions such as 'build a data pipeline' or 'design a benchmark,' use a clear structure: clarify the constraints, outline the components, justify your choices, then discuss failure modes. Draw on concrete past experience wherever you can.

For behavioral questions, use STAR: Situation (brief context), Task (your specific responsibility), Action (what you actually did, in detail), Result (measurable or observable outcome). Keep Situation and Task short. Spend most of your time on Action and Result.

For 'what do you know about Sarvam' questions, do not recite facts from a press release. Speak to a specific model, paper, or product they have released, explain why it interests you technically, and connect it to something in your own background. This signals genuine research engagement rather than last-minute preparation.

Deep NLP and LLM fluency. Sarvam's core work involves training and evaluating large models. Interviewers expect comfort with transformers, tokenization, fine-tuning strategies including PEFT methods like LoRA, and evaluation design. Surface-level familiarity is not enough.

Genuine curiosity about Indic languages. You do not need to speak every language Sarvam supports, but you should understand why low-resource NLP is hard, what makes Indic scripts and morphology challenging for standard ML pipelines, and have a considered opinion on approaches to these problems.

Research mindset paired with engineering pragmatism. Sarvam ships products, not just papers. They want candidates who can read a paper and implement the relevant parts, but who also know when a simpler baseline is the right first step given a production constraint.

Strong Python and PyTorch. Expect to write code, debug a training loop, or justify a specific implementation choice. Fluency in the Hugging Face ecosystem (Transformers, Datasets, PEFT) is a practical advantage.

Clear communication. Since the team works on genuinely novel problems, the ability to explain a complex approach clearly, both to teammates and to non-technical stakeholders, is valued alongside technical depth.

Weeks 1-2: Strengthen your foundations.
Review transformer architecture in depth, covering attention, positional encoding, and layer normalization. Re-read the 'Attention Is All You Need' paper if you have not recently. Make sure you can explain BPE, WordPiece, and SentencePiece tokenization clearly, including when each is preferred.

Week 3: Go deep on fine-tuning and PEFT.
Study LoRA, QLoRA, and adapter methods. Understand when each is appropriate and what the trade-offs are. Practice a simple LoRA fine-tune on an open dataset using the Hugging Face PEFT library.

Week 4: Indic NLP specifics.
Read Sarvam's publicly released model cards, blog posts, and any papers they have authored. Explore the IndicNLP library and AI4Bharat datasets. Be able to speak to what makes Indic languages challenging: script diversity, morphological richness, code-switching, and data scarcity.

Week 5: Coding and system design practice.
Work on ML coding problems: implementing attention from scratch, writing a data loader for a sequence task, debugging a training loop. Do at least two mock system design exercises, such as designing a data pipeline or an evaluation framework for a new Indic task.

Week 6: Behavioral prep and mock interviews.
Prepare 4-5 STAR stories covering a project with messy data, a technical trade-off you navigated, a time you learned from failure, and a research or experimentation challenge. Do at least one mock interview with a peer.

If you are applying to multiple roles while you prep, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you, so your application momentum keeps going even when you are deep in study mode.

Not knowing Sarvam's work. This is the most commonly reported misstep. Saying 'I know you work on Indian languages' and nothing more signals low motivation. Read at least two of their publicly available model or product announcements before your first round.

Treating it like a product analytics role. Candidates who prepare primarily with SQL, A/B testing, or dashboard questions are typically underprepared. Sarvam data science is applied ML research, not business intelligence.

Being vague about NLP choices. Saying 'I used BERT' without explaining why you chose it, what its limitations were, or how you evaluated it reads as shallow. Always justify your technical choices with trade-offs.

Skipping evaluation design. Many candidates can train a model but struggle to design a meaningful evaluation when no benchmark exists. Practice this skill explicitly before your rounds.

Overcomplicating answers. Some candidates propose a maximally complex pipeline when a simple baseline would be the correct first step. Candidates report that Sarvam interviewers appreciate the instinct to start simple and iterate based on evidence.

Not asking good questions. Asking thoughtful questions about the team's current research challenges, data strategy, or deployment constraints at the end of your rounds shows genuine engagement, which matters at a research-driven company.