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

InMobi is a global mobile advertising and marketing technology company headquartered in Bangalore, with major engineering hubs across India. As of July 2026, knok jobradar was tracking 91 open DevOps Engineer roles at InMobi, making it one of the more active hirers in this space. Nationwide, 811 DevOps Engineer roles were open at that time, with Bangalore accounting for the largest share at 187 openings.

The company's infrastructure supports programmatic advertising at scale, so the DevOps interview tests both your depth with cloud-native tooling and your ability to think about reliability and cost under high load. Candidates typically go through multiple rounds covering system design, hands-on technical skills, and a culture or values discussion. The process is reported to be thorough for senior roles and more structured for entry-level positions.

1. Walk me through how you would design a CI/CD pipeline for a microservices platform that handles millions of ad requests per day.
2. How do you manage Kubernetes cluster upgrades with zero downtime for production workloads?
3. Describe your experience with infrastructure-as-code. Which tools have you used and what specific problems did they solve?
4. How have you handled a production incident where a bad deployment caused service degradation?
5. InMobi runs a multi-cloud setup. How would you approach cost optimisation across AWS and GCP?
6. How do you implement secrets management in a containerised environment?
7. What is your approach to setting up observability (metrics, logs, traces) for a brand-new service?
8. How would you enforce security policies across many microservices without slowing down developer velocity?
9. Explain how you have used Terraform or Pulumi to manage state in a team environment without conflicts.
10. How do you handle database migrations in a continuous deployment setup?
11. Describe a time you had to convince a development team to adopt a new DevOps practice. What was your approach and what was the outcome?
12. What is your strategy for maintaining on-call runbooks and reducing alert fatigue?

Q: Walk me through how you would design a CI/CD pipeline for a microservices platform.

*Situation:* At my previous company, we had many microservices all deployed manually by developers pushing directly to staging, which caused frequent conflicts and rollback nightmares.

*Task:* I was asked to design and implement a standardised CI/CD pipeline that all teams could adopt within a quarter.

*Action:* I set up GitHub Actions as the CI layer, with each service running lint, unit tests, and container image builds on every pull request. For CD, I used ArgoCD with a GitOps model so the desired state lived in a Git repository and ArgoCD reconciled it to Kubernetes automatically. I introduced canary deployments using Argo Rollouts so new versions received a small slice of traffic first before full rollout. I also added automated rollback triggers tied to error-rate thresholds from Prometheus.

*Result:* Deployment frequency increased significantly and rollback time dropped from hours to minutes. Teams reported far fewer after-hours incidents in the first two months after the rollout.

---

Q: How have you handled a production incident where a bad deployment caused service degradation?

*Situation:* We pushed a configuration change to our ad-serving cache layer that accidentally set a very low TTL, causing a flood of cache misses and a sharp spike in database load.

*Task:* As the on-call engineer, I had to identify the root cause and restore service quickly while keeping stakeholders informed.

*Action:* I pulled metrics from Grafana to confirm the spike was tied to the deployment timestamp. I then used our GitOps workflow to revert the configuration change, pushed it through the fast-track pipeline, and verified that cache hit rates were recovering. Simultaneously, I posted regular updates in the incident Slack channel so the product team was not left guessing.

*Result:* Service was restored within a short window. I followed up with a blameless post-mortem and added a validation step to the pipeline that checks TTL values against a safe minimum before any future deployment.

---

Q: How do you approach cost optimisation on multi-cloud?

*Situation:* My team was running workloads on both AWS and GCP without any centralised visibility into spend, and the cloud bill had grown faster than the user base.

*Task:* I was asked to build cost-awareness across teams and identify quick wins.

*Action:* I started by tagging all resources with team, environment, and service labels and feeding that data into a cost dashboard. I identified idle and oversized instances using cloud-native recommendations and rightsized them. For compute-heavy batch jobs, I moved workloads to spot or preemptible instances. I also set up budget alerts so teams got notified before overspending, not after the fact.

*Result:* The changes led to a meaningful reduction in monthly cloud spend. Teams became more accountable for their own usage once they could see the per-service cost breakdown.

For system design questions, use a structure of: scope (what is the scale, what are the SLOs), components (CI layer, CD layer, observability), trade-offs (why this tool over that one), and failure modes (what happens when a component breaks). InMobi's scale in ad-tech means you should always address how your design handles traffic bursts, not just steady state.

For incident and operational questions, use the STAR format but make the 'Action' step the longest part. Interviewers want to see your actual decision-making process, not just the outcome. Break the Action into: detect, diagnose, mitigate, communicate, and prevent recurrence.

For 'convince your team' or cross-functional questions, show empathy first. Describe the other team's constraint (developer velocity, learning curve), then explain how your solution addressed that constraint before listing the reliability benefits. This signals that you can work across teams, which matters a lot at a company the size of InMobi.

InMobi's DevOps interviews are reported to focus on real operational experience, not just knowledge of tools. Interviewers typically look for the following qualities.

Ownership mindset. InMobi's engineering culture values engineers who treat reliability as their own problem, not someone else's. Come with specific examples of incidents you owned from detection through to post-mortem.

Scale awareness. Advertising platforms handle sharp traffic spikes around campaigns and events. Mention how your past work handled variable load, and show you understand the difference between designing for average load and designing for peak load.

Tool-agnostic thinking. Candidates who explain 'why' they chose a tool (Helm vs Kustomize, Prometheus vs Datadog) consistently do better than those who simply list tools on a resume. Be ready to discuss trade-offs honestly, including what you gave up.

Collaboration with developers. DevOps at InMobi is not a gatekeeper function. Interviewers look for people who reduce friction for development teams while maintaining platform reliability.

Week 1: Core skills brush-up. Revisit Kubernetes internals (scheduling, networking, storage), Terraform state management, and at least one CI/CD platform in depth (GitHub Actions or GitLab CI). Practice drawing CI/CD and infrastructure diagrams from memory without referring to documentation.

Week 2: InMobi-specific context. Read about how programmatic advertising infrastructure works (DSP, SSP, RTB pipelines). This helps you frame answers in terms of InMobi's actual domain. Review multi-cloud cost management concepts for AWS and GCP side by side.

Week 3: Behavioural and system design practice. Do at least two mock system design sessions with a peer, focusing on high-throughput and low-latency systems. Write out three to four STAR stories covering: a complex incident, a process you improved, a time you worked across teams, and a technical decision you made under uncertainty.

On the day. Ask clarifying questions before answering design problems. State your assumptions out loud. If you are unsure about a specific InMobi tool or stack detail, say so directly and explain how you would approach learning it quickly.

Listing tools without explaining decisions. Saying 'I used Helm' without explaining why Helm over another option signals surface-level knowledge. Always pair a tool with the problem it solved and the trade-off you accepted.

Vague incident stories. Saying 'we had an outage and I fixed it' does not land well. Interviewers want the sequence: how you detected the issue, how long diagnosis took, what you ruled out first, and what you changed to prevent recurrence.

Ignoring the developer experience angle. Candidates who frame all DevOps work as 'enforcing policy' or 'locking things down' miss InMobi's collaborative culture. Show that you care about making deployment easy for developers, not just safe for the platform.

Over-claiming solo ownership. Large-scale reliability work is always a team effort. If you exaggerate your individual contribution, experienced interviewers will notice when your story contains no collaboration at all.

Not asking about the current state. Before proposing solutions in a design question, ask what InMobi currently uses, what pain points exist, and what constraints are in play. This shows maturity and avoids prescribing solutions to problems the team has already solved.

If you are applying broadly while preparing, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you. With 91 open DevOps roles at InMobi alone tracked in July 2026, automated applications help you stay ahead of fast-moving hiring pipelines.