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

Sarvam AI is one of India's most closely watched AI-native startups, building large language models, voice recognition, and text-to-speech products tuned for Indian languages. Their DevOps team owns GPU cluster management, model-serving infrastructure, CI/CD for ML workflows, and the reliability of customer-facing speech and language APIs. As of July 2026, Sarvam has 68 open DevOps roles, making it one of the more active AI infrastructure hirers in India right now.

Candidates report that the interview process typically runs three to four rounds: an initial recruiter or HR screening call, one or two technical rounds covering infrastructure and system design, sometimes a practical or take-home exercise, and a final conversation with a senior engineer or hiring manager. Expect deep questions on Kubernetes, cloud-native tooling, and how you think about reliability for AI workloads specifically. The team values engineers who understand both the infrastructure side and the unique demands of serving large ML models at scale.

DevOps Engineer salary ranges (based on industry surveys; verify current Sarvam figures on Glassdoor or levels.fyi):

If you are exploring the wider market, knok's data shows 811 DevOps Engineer openings across India as of July 2026, with Bangalore leading at 187 roles, followed by Delhi (40), Pune (37), Hyderabad (28), Chennai (13), and Mumbai (11).

These questions reflect patterns candidates report from AI-infrastructure company interviews, including companies at Sarvam's stage and focus. Expect technical depth on GPU workloads and ML pipelines alongside standard DevOps topics.

1. Walk us through how you would design a CI/CD pipeline for a machine learning model that needs to be retrained and redeployed on a regular cadence.
2. Sarvam runs GPU-intensive inference workloads. How would you autoscale GPU nodes on Kubernetes to handle burst traffic without over-provisioning?
3. How do you monitor a model-serving endpoint differently from a standard web API? What specific metrics would you track?
4. Describe a time you reduced deployment downtime for a stateful service. What approach did you take and what was the outcome?
5. How would you handle secrets management across multiple microservices in a multi-cloud or hybrid-cloud setup?
6. Walk us through your approach to cloud cost optimization when running large AI models that require expensive GPU instances.
7. Sarvam's APIs serve enterprise customers. How would you design for multi-region failover and high availability?
8. What is your experience with infrastructure-as-code tools like Terraform or Pulumi? How do you manage state safely across a team?
9. How do you approach incident response when a model-serving pod crashes under load? Walk us through your runbook.
10. How would you set up log aggregation and distributed tracing for a system with speech recognition, NLP, and TTS components all communicating with each other?
11. Large ML model Docker images can reach many gigabytes. How do you handle container image optimization and layer caching in your build pipeline?
12. Sarvam processes sensitive voice data. How do you build security into your deployment pipeline from code commit to production?

Q: How do you monitor a model-serving endpoint differently from a standard web API?

*Situation:* At a previous company, our team had deployed a transformer-based text classification service and was monitoring it with the same generic HTTP checks we used for our REST APIs: request counts, status codes, and basic response time.

*Task:* After customer complaints about slow responses during peak hours, I was asked to build proper observability for the ML service before it caused a serious incident.

*Action:* I set up Prometheus with custom histograms tracking inference duration broken down by model version and input length. I added GPU memory utilization and request queue depth as primary signals, neither of which standard web monitoring tracks at all. I built Grafana dashboards showing the relationship between batch size and throughput, and configured alerts on queue depth rather than just error rates. A rising queue is an early warning of latency trouble before it becomes visible to end users.

*Result:* Within the first week the dashboards surfaced a memory leak in the model server. The team fixed it before it caused a customer-facing outage, and those dashboards became the standard template for every subsequent model deployment at the company.

---

Q: Walk us through how you designed a CI/CD pipeline for ML model deployment.

*Situation:* I joined a team where speech model updates were deployed manually, with engineers copying model weights to servers during scheduled maintenance windows. There was no automated testing between a trained model and its production deployment.

*Task:* My goal was to build a pipeline that could deploy new model versions safely, with automated validation and quick rollback capability.

*Action:* I built a GitHub Actions pipeline with three stages. First, a build stage that packaged the model with its serving code into a versioned Docker image pushed to ECR, tagged with the model version and Git commit hash. Second, a staging deployment to an EKS cluster that ran automated smoke tests including latency spot-checks and accuracy checks against a held-out evaluation dataset. Third, a blue-green production rollout on EKS with automatic rollback triggered if error rates rose above the pre-deployment baseline in the window immediately after release. I also embedded model version metadata as environment variables so any engineer could query a running pod and know exactly which model it was serving.

*Result:* Deployment cycles shortened dramatically and engineers stopped doing manual late-night rollouts entirely. The blue-green rollback mechanism caught one bad model version in staging before it ever reached production.

---

Q: Describe a time you managed a production incident on a high-traffic service.

*Situation:* I was on call when our voice API began returning errors for a segment of users during a live product demo for an enterprise customer.

*Task:* I had to diagnose and resolve the issue quickly while keeping stakeholders informed in real time.

*Action:* I pulled the recent deployment history first. A Kubernetes ConfigMap update had gone out a couple of hours earlier. Checking the logs, I found the change had not propagated correctly to all pods: some were still pointing to a deprecated model endpoint. I rolled back the ConfigMap, triggered a rolling restart, and confirmed all pods had picked up the correct configuration. Throughout the incident I posted brief updates to the customer success Slack channel so the team facing the customer had accurate information at every step.

*Result:* Service was restored quickly. I wrote a detailed post-mortem and added a config validation step to the deployment pipeline so the same class of issue could not reach production again.

For system design and architecture questions, start by clarifying scale and constraints before proposing any solution. Sarvam interviewers want to see you ask about GPU type, expected request volume, and acceptable latency before jumping to an architecture. State your assumptions out loud.

For behavioral 'tell me about a time' questions, use the STAR structure: Situation (brief context), Task (what you were responsible for), Action (what you specifically did, using 'I' not 'we'), Result (an observable or measurable outcome). Keep Situation and Task short. Spend most of your time on Action and Result.

For troubleshooting questions, walk through your diagnostic process step by step. Sarvam values structured thinking: check recent changes first, isolate the layer (network, application, infrastructure, model), read the logs, form a hypothesis, test it. Avoid jumping straight to a solution without showing your reasoning.

For cost optimization questions, frame your answer around three levers: right-sizing (choosing the correct instance type for the workload), scheduling (spot or preemptible instances for non-critical jobs), and waste elimination (idle volumes, unused clusters, redundant data transfers). AI infrastructure has specific cost patterns around GPU idle time that are worth mentioning explicitly.

For security questions, structure your answer around least privilege, secrets management (never in environment variables or source code), and auditability. Name specific tools you have used such as HashiCorp Vault, AWS Secrets Manager, or Kubernetes external-secrets, rather than speaking in generalities.

ML infrastructure awareness. Sarvam is an AI-first company. Interviewers want DevOps engineers who understand what makes AI workloads different: GPU scheduling, large model artifact management, model versioning alongside code versioning, and the latency characteristics of inference under load. You do not need to be an ML engineer, but understanding why inference workloads behave differently from typical web services will set you apart from candidates with only standard DevOps backgrounds.

Kubernetes depth. Expect questions that go beyond 'I have deployed on Kubernetes.' Interviewers want to see you understand pod scheduling, resource limits and requests, node affinity for GPU nodes, horizontal pod autoscaling, and how to debug common failure states like CrashLoopBackOff or OOMKilled pods.

Infrastructure-as-code discipline. Terraform or Pulumi experience is important. Candidates report being asked about state management, module design, and how to detect and handle drift between declared code and actual running infrastructure.

Ownership mentality. Sarvam is a startup, which means smaller teams and broader scope. Interviewers look for engineers who treat production reliability as a personal responsibility rather than someone else's ticket. In your stories, describe times you went beyond the immediate task to fix a root cause.

Communication under pressure. The incident management question is partly technical and partly a communication test. Interviewers want to know you keep stakeholders informed, write clear post-mortems, and treat incidents as learning opportunities rather than events to minimize or hide.

Week 1: Core Kubernetes and cloud fundamentals.
Review Kubernetes concepts you might have gaps in: custom resource definitions, admission controllers, network policies, and GPU node configuration. Practice the kubectl debug workflow for common failure states. If you have not used Terraform recently, build a module from scratch that provisions an EKS or GKE cluster.

Week 2: ML-specific infrastructure.
Read about how companies serve large language models: concepts like model sharding, batching strategies, and tradeoffs between different serving frameworks. You do not need to implement these, but being able to discuss them shows the ML-infrastructure literacy Sarvam values. Review Prometheus and Grafana, specifically custom metrics and alerting rules for non-HTTP workloads.

Week 3: System design practice.
Practice designing two or three systems out loud: a model deployment pipeline, a multi-region failover setup, and a cost-optimization plan for a GPU fleet. Use the 'clarify constraints first' habit on every design question. Record yourself or practice with a peer so you can hear how clearly you explain trade-offs.

Week 4: Interview-specific preparation.
Prepare five to six STAR stories covering incidents, pipeline improvements, security work, and cost savings. Review Sarvam's public product announcements and any available engineering content so you can speak to the specific workloads their team manages. Reach out to people who have interviewed there recently via LinkedIn for current process details.

Knok checks 150+ job sites nightly, applies to matching roles on your behalf, and messages HR directly, so your applications keep moving even while you are deep in prep mode.

Treating Sarvam like a standard web-company DevOps interview. Candidates who prepare only generic Kubernetes and CI/CD content without thinking about GPU workloads or ML pipelines often struggle in the technical rounds. Add at least one ML-infrastructure angle to every major topic you prepare.

Saying 'we' instead of 'I' in behavioral answers. Interviewers want to know your specific contribution. 'We migrated the cluster' tells them nothing about what you did. Be concrete: 'I wrote the Terraform modules and handled the state migration while a colleague managed the application-layer cutover.'

Skipping the clarifying questions in system design. Jumping straight into an architecture without asking about scale, latency requirements, budget, and team size is a common red flag, especially for senior roles where interviewers expect you to lead the scoping conversation.

Vague results in STAR answers. 'The system improved' is not a result. Even when you cannot share exact numbers, describe the observable change: deployments that used to require a maintenance window now happen during business hours without any downtime, or an alert that used to fire multiple times a week went silent after the fix.

Not preparing questions to ask. Sarvam interviewers typically leave time for your questions. Candidates who have nothing to ask signal low interest or poor preparation. Prepare genuine questions about on-call culture, current infrastructure challenges, or how the team handles model versioning in production.