"I think I nailed it Nutanix SRE. Either that, or they're just playing with me."

From the way he described it the interview process felt more like a high-intensity operations drill than a traditional Q&A

Round 1 Linux Under Pressure

They began with what they called "a warm-up," but it was anything but.

One of the panelists started with: "Imagine our servers are suddenly hit by a wave of suspicious traffic potentially a DDoS. How would you respond at the OS level?"

My cousin talked about SYN cookies, tuning the TCP backlog, and adjustng relevant sysctl parameters. That led to a follow-up: "Alright, now some containers are maxing out CPU across the cluster. Whats your move?"

This shifted the discussion toward cgroups, namespaces, and applying resource limits effectively. The intent was clear they wanted to see if he genuinely lived and breathed Linux troubleshooting.

Round 2 Handling Distributed Chaos

The second round dove straight into disaster scenarios.

They asked him to design a failover system for a storage cluster capable of switching in under 100 millisecond. He proposed health checks leader election, and quorum-based failover.

But then came the twist: "What if a network partition occurs? Who's the leader now?"

This turned into a conversation about preventing split-brain situations using fencing, metadata quorum arbitrationn and external arbiters.

They also touched on latency handling in geo-distributed RPCs. My cousin talked about distributed tracing, histograms, and retries with exponential backoff until the interviewer asked "And what if those retries cause a traffic storm?"

That's when he brought up circuit breaker patterns to limit cascading failures.

Round 3 Automate or Fall Behind

This round was focused on automation and scale.

The scenario: patch 1,000 VMs with zero downtime. He explained a canary rollout followed by a blue-green deployment strategy.

Then came the hands-on portion: "Write an automation to auto-scale based on disk I/O spikes."

He chose Terraform and Ansible, wiring it up with CloudWatch metrics. That earned some nods, but they pressed further: "What if the canary fails and no one notices?"

That led into alerting systems, rollback triggers, and automated dashboards and a candid remark from him: "If the canary dies and no one's watching, we've got a bigger problem than just the patch."

Round 4Real-World Firefighting

This was a simulated outage exercise

They asked for a postmortem process. He described blameless RCA, building a clear timeline and defining concrete action items.

Then came a turn: "The VP wants updates every 5 minutes during the outage. What do you do?"

He explained the importance of assigning a dedicated communications role, keeping engineers focused, and providing stakeholders with real-time incident channels instead of constant interruptions.

The round also included designing service-level objectives (SLOs) for Nutanix platforms and strategies for predicting disk failures before they happen. When asked about false positives, he replied, "If my detection model floods operations with noise, then that model is now my highest-priority incident."

Round 5 Culture and Decision-Making

The final round was about team fit and judgment calls.

They asked for an example of impactful automation he had built. He shared a failover automation script from his previous role that reduced downtime from hours to seconds.

Another scenario followed: a choice between hitting a demo deadline and addressing a critical reliability issue. His approach fix the issue in the demo environment to avoid showstoppers, then deploy the broader fix post-demo demonstrated both pragmatism and reliability focus.

He also discussed onboarding teams into SRE culture, teaching SLIs and SLAs, creating useful dashboards, and making reliablity part of the development workflow.

Final Verdict

A week later, the offer letter confirmed it he had indeed found his place at Nutanix.