sarvam Platform Engineer Interview: Questions, Experience & Prep (2026)

Sarvam is one of India's most prominent AI startups, building foundational models and infrastructure for Indic languages. A Platform Engineer here is not just a DevOps hire: you own the compute fabric that lets researchers train large models, run evaluations, and serve inferences reliably at scale. Candidates report that Sarvam moves fast and expects engineers who can design robust systems and also get their hands dirty with Kubernetes, GPU clusters, and observability tooling.

Knok's job radar (as of July 2026) shows 68 open roles at Sarvam across all functions, a sign of active hiring. For Platform Engineers specifically, there are 204 openings across India right now, with Bangalore leading at 29 roles, followed by Delhi (12) and Pune (10). Sarvam's office presence is primarily in Bangalore, so most platform roles will likely be based there.

The interview process typically involves a screening call, one or more technical rounds covering system design and practical infrastructure problems, and a final conversation with a senior engineer or manager. Candidates report that the process rewards engineers who can speak clearly about trade-offs rather than just naming tools.

These questions reflect what candidates typically report for platform and infrastructure roles at AI-first companies like Sarvam:

1. How would you design an inference serving system for a large language model that needs to handle variable request loads?
2. Walk us through how you manage GPU resource allocation in a multi-tenant Kubernetes cluster.
3. How do you approach CI/CD for ML models, where the artifact is not just code but also model weights?
4. Describe how you would set up observability (metrics, logs, traces) for a model serving API.
5. How would you handle a production incident where model latency spikes and alerts fire in the middle of the night?
6. What is your approach to cost optimization for cloud GPU infrastructure?
7. How would you design a data ingestion pipeline that can reliably process large volumes of training data?
8. How do you think about autoscaling inference endpoints, and what signals would you use to trigger scale-out?
9. Sarvam builds for Indic languages: how would you handle character encoding, tokenization edge cases, and model versioning across multiple languages in your infrastructure?
10. Walk us through a time your infrastructure change caused a production issue. What happened and what did you learn?
11. How do you evaluate whether to build a platform component in-house versus adopting an open-source tool?
12. Describe your experience with infrastructure-as-code. How do you manage state, secrets, and environment parity across staging and production?

Use the STAR format (Situation, Task, Action, Result) for experience-based questions. Here are three examples tailored to Platform Engineer interviews:

Q: Describe a time you improved the reliability of a distributed service.

*Situation:* At my previous company, our NLP inference service was dropping requests intermittently during traffic spikes, and the on-call team was getting paged multiple times a week.

*Task:* I was asked to investigate the root cause and propose a fix that would reduce alert fatigue without requiring a full rewrite.

*Action:* I added structured logging and distributed tracing to understand where requests were timing out. I found that the connection pool to our model server was exhausting under burst traffic. I implemented a request queue with backpressure, tuned the pool size based on load testing, and added a circuit breaker so the API returned a graceful error instead of hanging. I also wrote a runbook so the on-call rotation could handle similar issues without escalating.

*Result:* Pages for this service dropped to near zero over the following month, and the service handled peak traffic without dropping requests. The runbook was adopted across two other services.

---

Q: How have you handled GPU resource contention in a shared cluster?

*Situation:* Our team shared a GPU cluster between model training jobs and interactive experimentation. Researchers complained that their training runs were being preempted unpredictably.

*Task:* I needed to implement a fair scheduling policy that gave training jobs priority without completely blocking researchers from using the cluster.

*Action:* I set up Kubernetes priority classes and resource quotas per team namespace. Training jobs got a higher priority class, while interactive pods were marked as low-priority and preemptible. I added a Slack notification that fired when a pod was preempted so researchers were not left wondering what happened. I also built a dashboard showing cluster utilization by team so leadership could see usage patterns.

*Result:* Training job completion times became much more predictable, and researcher complaints dropped significantly. The dashboard revealed that two teams were over-allocated, which led to a quota rebalancing that freed up capacity for new projects.

---

Q: Tell me about a CI/CD pipeline you built for an ML project.

*Situation:* Our team was deploying model updates manually: someone would SSH into a server, download weights, restart the serving process, and hope nothing broke. This caused several silent failures where the wrong model version was served.

*Task:* I was given ownership of building a proper deployment pipeline for model updates.

*Action:* I designed a pipeline in GitHub Actions that triggered on a new model version tag. It pulled weights from our model registry, ran a smoke test against a staging endpoint (checking that the model returned valid outputs for a fixed set of test inputs), and only promoted to production after the smoke test passed. I used Helm to manage the Kubernetes deployment, with an automatic rollback step that fired if the health check failed post-deploy.

*Result:* Silent deployment failures were essentially eliminated over the two quarters that followed. The deploy process, which previously required manual effort from an engineer each time, became fully automated and reliable.

For system design questions: Think out loud in layers. Start with requirements: what is the scale, the latency expectation, the consistency requirement? Then sketch the data flow. Then discuss where failure can happen and how you handle it. Interviewers at companies like Sarvam want to see that you think about failure modes, not just the happy path.

For 'why did you choose X over Y' questions: Use the trade-off frame. Name what you gave up and why that trade-off made sense for the specific context. Saying 'we used Kafka because it fit our team's existing knowledge and the throughput requirement, even though it added operational overhead' is stronger than just saying 'Kafka is the right choice.'

For incident or failure questions: Be concrete and specific. Name the symptom, the investigation path, the root cause, and what you changed permanently (not just the hotfix). Interviewers want to see debugging instinct, not just a good outcome.

For 'build vs. buy' questions: Anchor on total cost of ownership, team expertise, and how central the capability is to your product. If it is a core competency (like Sarvam's model serving infrastructure), building gives you control. If it is commodity plumbing (like log aggregation), buying is usually right.

For coding or hands-on tasks: Candidates report Sarvam may include practical scripting or infrastructure exercises. Think about edge cases, explain what you are doing as you go, and ask clarifying questions before diving in.

Based on what candidates typically report for AI-infrastructure roles, Sarvam interviewers are evaluating a few things beyond raw technical knowledge.

Ownership mindset. They want engineers who treat infrastructure as a product, not just a support function. Come with examples of times you proactively found and fixed problems before they became incidents.

ML-awareness. You do not need to train models yourself, but you should understand the lifecycle: data ingestion, training runs, evaluation, model registry, serving, and retraining. Know the difference between batch inference and online inference and when each applies.

Systems fundamentals. Distributed systems concepts come up consistently: consistency vs. availability trade-offs, idempotency, backpressure, and failure isolation. Be ready to reason from first principles, not just name tools.

Communication clarity. Sarvam moves fast and teams are lean. Interviewers want to see that you can explain a complex system or decision in a way that a product manager or a researcher (not just another infra engineer) could follow.

Curiosity about AI infrastructure. Given Sarvam's focus on Indic language models, showing genuine interest in the specific challenges of serving multilingual models (tokenization, latency requirements for voice interfaces, model versioning across languages) will help you stand out.

Week 1: Foundations and company context
Read Sarvam's public blog posts and any available technical writing about their model architecture and infrastructure choices. Understand what 'Indic language models' means in practice: what are the tokenization challenges, and what latency is needed for voice-first products? Revise distributed systems fundamentals: replication, partitioning, and consistency models.

Week 2: Practical tooling
Brush up on Kubernetes concepts relevant to ML: GPU node pools, priority classes, resource quotas, and scheduling. Revisit your CI/CD experience and be ready to draw a deployment pipeline on a whiteboard. If you have not used a model registry (MLflow, Weights and Biases, or similar), read the documentation for at least one.

Week 3: Mock interviews and gap-filling
Do at least two system design mock sessions focused on inference serving and data pipelines. Record yourself answering behavioral questions using STAR format. Identify any tools mentioned in Sarvam's job description that you have not used, and spend focused time on those gaps.

Ongoing: Applications running in the background
Knok checks 150+ job sites nightly, applies to Platform Engineer roles that match your resume, and messages HR on your behalf, so your applications keep moving even while you are deep in interview prep.

Treating this like a pure DevOps interview. Sarvam is an AI company. If your answers focus entirely on web app deployments and never touch model serving, training pipelines, or ML-specific concerns, you will likely miss the mark.

Naming tools without explaining trade-offs. Saying 'I would use Kafka' is not enough. Interviewers want to hear why, and what you would give up by making that choice.

Skipping the 'what went wrong' part of your stories. Candidates who only tell success stories come across as lacking self-awareness. The most convincing STAR answers include a moment of friction and a genuine lesson learned.

Under-preparing for Indic language context. Sarvam's domain is specific. If you walk in without any awareness of why serving a model for Hindi or Tamil presents different infrastructure challenges than serving an English model, you miss a chance to show genuine interest in the company's mission.

Being vague about scale. 'It was a large system' is not useful. Even if you cannot share exact numbers, describe the nature of the scale: 'we handled bursty traffic from a consumer app, so writes were spiky but reads were steady.' Specificity signals real experience.