How to Crack a DevOps Interview in India 2026

DevOps interviews at Indian product companies have become significantly more rigorous over the past two years. Companies like Swiggy, Razorpay, Zepto, PhonePe, and Flipkart now run 4–6 round processes that include coding, system design, and deep infrastructure debugging. This guide gives you a complete preparation framework.

What the Interview Process Looks Like

At Indian Tier-1 product companies (Swiggy, Razorpay, Meesho, CRED)

1. Recruiter screen — background, CTC expectations, notice period
2. Technical screen — 45–60 min, mix of Linux/Kubernetes/CI-CD questions
3. Coding round — 1–2 LeetCode easy/medium problems in Python or Go
4. System design / Infrastructure design — 60 min architecture discussion
5. Deep technical — live debugging, Kubernetes or Linux troubleshooting scenario
6. Hiring manager / culture — team fit, ownership, past incident discussion

At MNC India offices (Microsoft, Amazon, Google)

Similar structure but with additional rounds. Google adds a specific SRE reliability design round. Amazon runs a Leadership Principles round at every level.

At Series A–B startups

Usually 2–3 rounds: a technical screen, a take-home or live coding exercise, and a hiring manager conversation. Less structured but ownership and breadth matter more.

Round 1: Recruiter Screen

This is often skipped as a “real” prep step — it shouldn’t be.

• Have your story ready in 2 minutes: current role, what you own, why you’re looking
• Know your current CTC and target range — give a range, not a fixed number
• Research the company’s stack before the call — mention it (“I saw you’re on AWS + Kubernetes, which aligns well with what I’m doing currently”)
• Ask about the team size, on-call expectations, and tech stack to signal seriousness

Round 2: Technical Screen

This is where most candidates get eliminated. Topics covered:

Linux (non-negotiable)

• Process management: ps, top, htop, signals, zombie processes
• File system: inodes, lsof, df -h vs du, permissions, find
• Networking: netstat/ss, tcpdump, curl -v, DNS resolution flow, /etc/hosts
• Performance debugging: strace, perf, vmstat, load average vs CPU utilisation
• Common question: “A server’s load average is 40 but CPU is only 20% — what’s happening?”

Kubernetes

• Pod lifecycle, init containers, sidecar pattern
• Services: ClusterIP vs NodePort vs LoadBalancer vs Headless
• Debugging: CrashLoopBackOff, OOMKilled, Pending (affinity vs resource pressure)
• RBAC: ServiceAccount, Role, RoleBinding — when to use ClusterRole
• Common question: “Walk me through what happens when you run kubectl apply -f deployment.yaml”

CI/CD

• GitHub Actions: workflow triggers, matrix builds, secrets, self-hosted runners
• Deployment strategies: rolling vs blue-green vs canary — trade-offs, not just definitions
• Common question: “How would you implement a zero-downtime deployment for a stateful service?”

Infrastructure as Code

• Terraform: state management, modules, import, drift detection
• Common question: “Two engineers run terraform apply simultaneously — what happens? How do you prevent it?”

Round 3: Coding Round

This surprises many DevOps candidates — but it’s now standard at serious companies.

What they’re testing: Can you write clean, working code? Not algorithmic genius — practical problem solving.

Topics:

• String manipulation (parsing log lines, extracting fields)
• File I/O (reading config files, processing CSVs)
• Basic data structures (dictionaries, sets for deduplication)
• LeetCode: focus on Easy and Medium — Two Sum, Valid Parentheses, Merge Intervals, Top K Frequent Elements

Language: Python is the safest choice for DevOps roles. Go is a bonus.

Preparation: 30–40 LeetCode problems is sufficient for most DevOps roles. Don’t spend 6 months on algorithms — a week of focused practice is enough for the tier of problems asked.

Round 4: System Design / Infrastructure Design

This is the most differentiating round. Most candidates describe tools; strong candidates describe trade-offs.

Common questions

• “Design a CI/CD pipeline for a microservices application with 50 services”
• “Design a Kubernetes-based deployment system that supports blue-green deployments across 3 regions”
• “Your team is deploying 200 times a day — design the observability stack”
• “Design a secret management system for a company with 30 microservices”

How to structure your answer

1. Clarify requirements: scale, team size, SLO targets, budget constraints
2. Start with the happy path: describe the normal flow end to end
3. Add failure modes: what happens when component X fails?
4. Discuss trade-offs: “We could use X or Y — X is simpler but Y gives us Z at the cost of…”
5. Talk numbers: latency, throughput, cost — even rough estimates show maturity

Common mistakes

• Jumping to a specific tool without justifying the choice
• Not discussing failure modes
• Over-engineering (designing for Google-scale when the company has 20 engineers)

Round 5: Live Debugging

Some companies give you a broken cluster or a failing deployment and watch you fix it. This is the hardest round to fake.

Preparation: Set up a local Kubernetes cluster (k3s, kind, or minikube) and intentionally break things:

• Delete a CNI plugin and troubleshoot network failures
• Set wrong resource limits and cause OOMKill events
• Break RBAC permissions and debug auth failures
• Simulate etcd disk pressure

Narrate your thinking out loud during the round — “I’m checking X because I want to rule out Y” shows senior-level debugging instinct.

The Behavioural Round: Incidents and Ownership

Every company above a certain size asks about incidents. Prepare 2–3 stories using this structure:

STAR + Impact:

• Situation: what system, what scale, what was at stake
• Task: what you were responsible for
• Action: what specifically you did (technical decisions, not “we fixed it”)
• Result: quantified outcome — “reduced MTTR from 45 min to 8 min”, “recovered ₹2Cr in lost transactions”
• Learning: what changed after the incident (runbook, alert, architecture change)

The best incident stories involve something going wrong in production that you owned end to end — alert fired, you diagnosed, you fixed, you prevented recurrence.

30-Day Preparation Plan

Week 1: Foundations

• Linux: 2 hours of man pages and lab practice daily
• Kubernetes: Rebuild a cluster from scratch with kubeadm

Week 2: Core Topics

• CI/CD: Build a GitHub Actions pipeline for a real project
• Terraform: Write a complete AWS VPC + EKS module from scratch

Week 3: Coding + Design

• LeetCode: 5 problems per day (Easy/Medium)
• System design: practice 1 infrastructure design question per day out loud

Week 4: Mock Practice

• Do 2 full mock interviews (use Pramp, or ask a colleague)
• Revise weak areas from mock feedback
• Read 3–4 post-mortems from Google SRE book or public incident reports

What Separates Good Candidates from Great Ones

After screening hundreds of DevOps candidates, hiring managers consistently cite:

1. Quantified impact — “I reduced deploy time from 45 minutes to 8 minutes” beats “I improved the CI/CD pipeline”
2. Trade-off thinking — knowing why you made a decision, not just what decision you made
3. Production instinct — having been on-call, having owned incidents, having written runbooks
4. Public work — a GitHub with real Terraform modules or Kubernetes configs that you can walk through during the interview

Browse DevOps jobs in India on FzlOps — all listings include the tech stack so you can target your preparation to what companies are actually using.