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

Meesho is one of India's largest social commerce platforms, connecting millions of small sellers and buyers across the country. As of mid-2026, knok jobradar tracked 63 open DevOps Engineer roles at Meesho, making it one of the more active employers for this profile right now.

Candidates typically report multiple interview rounds covering Kubernetes, CI/CD pipelines, cloud infrastructure (primarily AWS), observability, and incident management. Expect at least one hands-on scripting or live-coding task. Meesho's systems operate at significant scale, so interviewers focus heavily on reliability thinking and cost efficiency together.

Salary ranges, based on knok jobradar data:

Roles are concentrated in Bangalore but also available in Delhi, Pune, Hyderabad, Chennai, and Mumbai.

Based on candidate reports, these questions come up most often in Meesho DevOps interviews:

1. Walk us through a CI/CD pipeline you built or owned end to end.
2. How have you handled a production incident where the root cause was not immediately obvious?
3. How would you design Kubernetes autoscaling for a flash-sale event at Meesho's traffic scale?
4. How do you manage secrets securely across multiple environments?
5. Explain how you would set up observability for a new microservice from scratch.
6. What is your approach to cost optimisation on AWS or GCP?
7. How do you handle rollback when a deployment causes a production issue?
8. Describe a time you reduced deployment time significantly.
9. How would you implement blue-green or canary deployments for a critical service?
10. How do you enforce infrastructure-as-code standards across multiple teams?
11. What is your approach to container security, including image scanning and runtime policies?
12. How do you work with developer teams who push untested code to shared environments?

Questions 3, 6, and 12 reflect Meesho-specific context: flash-sale traffic spikes, a cost-conscious engineering culture, and close collaboration between platform and product teams.

Q: Walk us through a CI/CD pipeline you built or owned end to end.

*Situation:* My previous team deployed a monolith manually, and each release took several hours with frequent rollback events causing extended downtime.

*Task:* I was asked to design and implement a fully automated deployment pipeline to reduce release time and lower the risk of each deployment.

*Action:* I set up a Jenkins-based pipeline that ran unit tests, integration tests, and a Docker image build in parallel stages. I added automated image vulnerability scanning before any artifact was pushed to our private ECR registry. The pipeline then triggered a Helm-based Kubernetes deployment using a canary strategy, shifting traffic gradually before full rollout.

*Result:* Release cycles shortened dramatically and rollback time dropped as well. The team gained enough confidence to release multiple times per week instead of once per fortnight.

---

Q: How have you handled a production incident where the root cause was not immediately obvious?

*Situation:* Our e-commerce service started throwing intermittent timeouts during peak hours, but all individual service health checks were showing green.

*Task:* I was the on-call engineer and had to identify and resolve the issue quickly to protect user experience.

*Action:* I correlated logs across services using our ELK stack and noticed that timeouts spiked only when a specific downstream payment service had elevated latency. Checking our Prometheus dashboards, I found that a recent deployment had silently removed a circuit breaker configuration. I raised a hotfix PR, re-added the circuit breaker, and deployed it through our fast-track pipeline.

*Result:* Timeouts resolved within minutes of the fix going live. I documented the incident in a post-mortem and added an automated check to alert on circuit breaker configuration drift, preventing recurrence.

---

Q: What is your approach to cost optimisation on AWS?

*Situation:* Our AWS bill had grown considerably quarter over quarter as the team launched new services and scaled existing ones.

*Task:* I was asked to audit cloud spend and propose concrete reductions without impacting reliability or developer velocity.

*Action:* I used AWS Cost Explorer to break down spend by service and team. I found that a large share came from oversized EC2 instances and accumulating RDS snapshots that no one was cleaning up. I right-sized instances based on actual utilisation metrics from CloudWatch, moved suitable batch workloads to Spot Instances, and set up S3 lifecycle policies to expire old snapshots automatically. I also introduced resource tagging so each team could see and own their spend.

*Result:* The team achieved meaningful, measurable cost reductions in the following quarter. More importantly, teams became cost-aware by default and spend growth slowed considerably in subsequent quarters even as traffic continued to rise.

For behavioral questions, use STAR. Keep Situation and Task brief (2-3 sentences each) and spend most of your time on Action and Result. Meesho interviewers typically want to hear what you personally did, so use 'I' deliberately rather than always saying 'we.'

For system design questions: Start by asking clarifying questions about scale, expected traffic patterns, SLA requirements, and team size. Outline the high-level architecture before going deep into any component. Call out trade-offs explicitly: for example, why you chose a pull-based deployment model over push-based, or why you picked Horizontal Pod Autoscaler over Vertical Pod Autoscaler for a given workload.

For incident and troubleshooting questions: Follow a clear timeline covering detection, diagnosis, fix, and prevention. Show your tooling instinct by explaining what you looked at first and why. Meesho runs observability-heavy systems, so mentioning specific signals (latency histograms, error rate alerts, log correlation) lands better than vague statements.

For process questions: Anchor on the problem the process was solving before explaining the process itself. Show that you collaborate with developer teams rather than operate in isolation. End with a measurable outcome or a concrete lesson learned.

Candidates who have gone through Meesho DevOps interviews typically report that interviewers look for the following qualities.

Real ownership over tool familiarity. Listing Kubernetes, Terraform, and Prometheus on your resume is expected. Interviewers want to hear about decisions you made: why you chose a particular approach, what broke, and how you fixed it.

Cost-conscious thinking. Meesho is publicly known for a frugal engineering culture. Mentioning resource limits, Spot Instance strategies, or autoscaling to reduce idle compute costs signals that you think like an owner, not just an operator.

Developer empathy. DevOps at Meesho means enabling product teams to ship faster and safer. Answers that show you collaborated with developers, reduced friction, and improved developer experience tend to score well.

Incident depth. Interviewers probe whether you actually ran the investigation or just observed someone else do it. Be specific about the signals you looked at and the tools you used.

Kubernetes fluency. Expect deep questions on scheduling, autoscaling (HPA and VPA), network policies, RBAC, and Helm. Surface-level answers are typically not enough at mid and senior levels.

Week 1: Kubernetes depth. Review scheduling (taints, tolerations, affinity rules), Horizontal and Vertical Pod Autoscaling, network policies, RBAC, and Helm chart authoring. Practice writing manifests from memory rather than copy-pasting.

Week 2: CI/CD and observability. Build or revisit a complete pipeline using GitHub Actions or Jenkins. Set up Prometheus and Grafana on a local or free-tier Kubernetes cluster. Practise writing alert rules and designing dashboards for a sample microservice.

Week 3: AWS services. Cover EKS, EC2, RDS, S3, IAM policies and roles, VPC networking, and CloudWatch. Focus especially on security configurations (IAM least privilege, security groups) and cost-optimisation levers such as Spot Instances, Reserved Instances, and lifecycle policies.

Week 4: System design and mock interviews. Design a deployment system for a high-traffic flash-sale scenario. Practice incident management walkthroughs out loud. Ask a peer to run mock questions from the list in the section above.

knok checks 150+ job sites nightly, applies to matching DevOps roles on your behalf, and messages HR directly, so you can stay focused on preparation instead of job hunting.

1. Naming tools without explaining decisions. Saying 'I use Kubernetes' without describing scheduling choices, failure handling, or autoscaling strategy signals shallow experience. Go one level deeper into the why behind your choices.

2. Ignoring cost. Answers about infrastructure that never mention resource limits, rightsizing, or Spot Instances can leave a negative impression at a cost-conscious company like Meesho.

3. Passive ownership language. Saying 'we set up the pipeline' without clarifying your specific role makes it hard for interviewers to assess your contribution. Be explicit: 'I designed the pipeline: my teammate handled the Jenkins admin setup.'

4. Skipping trade-offs in system design. Presenting one solution as the obvious best choice without acknowledging its limitations suggests you have not operated systems under real constraints. Always offer at least one alternative and explain why you ruled it out.

5. Jumping into design without clarifying scope. Starting a system design answer without asking about scale, SLAs, or team size often leads to a solution that does not match what the interviewer had in mind. Take a couple of minutes to clarify before proposing architecture.

6. Vague results in STAR answers. Ending with 'it worked out well' is a missed opportunity. Even if you cannot share exact numbers from a previous employer, describe the direction and magnitude of improvement clearly.