Nutanix Software Engineer Interview Guide

One round. That's it — no callback for a second. So this is really a "here's what one 45-ish minute conversation looked like" account, not a full loop.

The opening — comfortable territory. The interviewer started by walking through my resume and asking about my day-to-day tech stack. This part felt easy — I know my stack cold, so I was just talking, not performing. Then it shifted into Go concurrency: goroutine scheduling, channels, the usual "how do you avoid leaks/races" line of questioning. Still comfortable. This is stuff I use weekly, not stuff I crammed.

The observability section — where I felt strong. He asked me to explain the core difference between Grafana and Prometheus and how they actually fit together in a stack — not a textbook definition, more "how would you reason about this if you were setting it up." I walked through Prometheus as the collection/storage/alerting engine and Grafana as the visualization layer on top, plus where alerting logic can live in either. This is the part where I'd say I was genuinely confident, not just reciting.

Then the DSA question — this is where it turned. The problem was a DP-on-graphs question. I started with brute force to make sure I at least had a correct answer on the table, then began optimizing from there — got partway into a decent approach. That's where the interviewer didn't just let me run with it — he kept layering on additional constraints. Each new constraint invalidated part of what I'd built, and I had to keep re-deriving instead of just extending my existing solution. I could feel myself starting to sweat right around the second or third added constraint — I had a shape of an answer but couldn't converge on something correct under the tightened rules before time ran out.

The outcome. Got a rejection email after this round. No further rounds happened, so I can't speak to what a Round 2 would've looked like.

What I'd tell someone prepping for this: don't just prep a canned DP-on-graph solution — prep for the interviewer actively evolving the problem mid-answer. Getting to a working brute force fast matters, but the real test here seemed to be how cleanly you adapt an existing approach when the constraints shift under you, not just whether you can solve the original version.

Questions asked: The DSA round (reconstructed — exact wording not recalled precisely):

The problem was in the family of DP-on-graphs, closest in shape to something like: "Given a weighted directed graph and a starting node, find the maximum sum you can collect along a path, but you're only allowed to make at most K edge traversals."

I opened with brute force — explore all paths up to K edges, track the max sum — to establish a correct baseline. Then I started optimizing toward a dp[node][edges_used] formulation, memoizing on (current node, edges remaining) to avoid recomputation. I had this framed out reasonably well.

Then the interviewer added constraints — first something like "now some nodes can only be visited once across the whole path," which broke the clean memoization (state needed to somehow track visited nodes, blowing up the state space), and then a second tightening on top of that. I wasn't able to re-derive a correct, efficient formulation under the combined constraints before time ran out.