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

Goldman Sachs runs one of the largest financial technology operations in India, with major engineering hubs in Bangalore, Hyderabad, Pune, and Delhi. As of mid-2026, Goldman Sachs has 287 open DevOps roles across India, a substantial share of the 811 total DevOps positions tracked by knok jobradar. Bangalore leads the broader market with 187 of those 811 openings, followed by Delhi (40), Pune (37), and Hyderabad (28).

The interview process typically spans three to five rounds. Candidates report starting with an online coding or systems screen, followed by one or two deep technical interviews covering CI/CD, cloud, and infrastructure topics. A final round usually covers behavioural questions tied to Goldman Sachs values like client focus, integrity, and partnership. The full process commonly takes two to four weeks from first contact to offer.

Salary ranges across the DevOps market in India:

Goldman Sachs is publicly reported to pay competitively within these bands, and total compensation includes bonuses and benefits that vary by level and location.

Goldman Sachs DevOps interviews go deep on both technical skill and engineering judgment. Below are the questions candidates most commonly report seeing.

Technical and Infrastructure

1. Walk us through a CI/CD pipeline you built end-to-end. What tools did you choose and why?
2. How do you ensure zero-downtime deployments for a critical, high-availability service?
3. Describe your Kubernetes experience. How have you handled node failures, pod scheduling issues, or cluster autoscaling in production?
4. What is your approach to secrets management and securing credentials inside a pipeline?
5. How have you implemented Infrastructure as Code? What challenges came up when managing state or handling configuration drift?
6. Goldman Sachs systems deal with latency-sensitive workloads. How do you monitor, alert on, and investigate performance degradation?
7. Describe your experience with blue-green or canary deployments. When would you pick one over the other?
8. How do you handle compliance and audit trail requirements in your infrastructure setup?

Incident and Reliability

1. Walk us through a major production incident you owned. What was your root cause analysis process and what did you change afterwards?
2. How do you approach disaster recovery and business continuity planning for services your team owns?

Behavioural

1. Describe a time you improved developer productivity through a DevOps initiative. What was the outcome?
2. Goldman Sachs values 'client focus'. How does that principle show up in how you prioritise DevOps work day to day?

Use these as starting templates. Replace the details with your own real experiences before your interview.

---

Q: Walk us through a major production incident you owned. What was your root cause analysis process?

*Situation:* Our payment gateway service started throwing elevated error rates late one evening. The on-call alert fired and I picked it up as the primary responder.

*Task:* I had to identify the root cause, restore service as quickly as possible, and make sure the same issue could not silently recur.

*Action:* I pulled up our Grafana dashboards and saw database connection pool exhaustion correlating with a deployment from that afternoon. I rolled back the release using our automated rollback script, which brought error rates down within minutes. I then conducted a full post-mortem: the new release had introduced a connection leak under high load. I wrote a targeted fix, added a specific connection pool saturation metric to our alerting suite, and updated the deployment checklist to require a load test gate before production promotion.

*Result:* Service was restored quickly. The alert we added caught a similar pattern in a different service before it ever reached users, which the team credited directly to this incident review.

---

Q: Describe your Kubernetes experience and how you handled a production cluster issue.

*Situation:* A node in our production Kubernetes cluster became NotReady during business hours, and several pods were evicted without rescheduling correctly because of taint and toleration misconfigurations.

*Task:* I needed to restore pod availability immediately and then audit why our tolerations were set up incorrectly in the first place.

*Action:* I cordoned the failing node and manually triggered pod rescheduling onto healthy nodes. I updated our Helm chart tolerations to match our node pool taints correctly. I also added a runbook to our on-call documentation covering this failure mode, and introduced a cluster health check in our CI pipeline to catch taint mismatches before any future deployments.

*Result:* Pod availability recovered within minutes. The CI check caught a similar misconfiguration in our staging environment a few weeks later, before it could reach production.

---

Q: Tell me about a time you improved developer productivity through a DevOps initiative.

*Situation:* Our deployment process was almost entirely manual. Engineers SSH'd into servers, ran scripts by hand, and then notified the team on Slack. It was slow, inconsistent, and left no audit trail.

*Task:* My goal was to automate the deployment flow end-to-end so engineers could ship code without manual coordination, and so every deployment was logged automatically.

*Action:* I built a CI/CD pipeline using Jenkins and Ansible, connected to our Git repository so that a merge to the main branch triggered automated testing and deployment. I added Slack notifications for deployment status and a one-command rollback that any engineer could trigger directly from Slack.

*Result:* Deployment frequency increased noticeably within the first month, and the team no longer needed to coordinate manually for releases. Rollbacks that had previously required senior engineer involvement could be done by anyone on the team in under a minute.

For technical 'how do you' questions: Open with the problem you are solving and why it matters, describe your tool choices with the reasoning behind them (not just the names), and close with a tradeoff you considered or a lesson you learned. Goldman Sachs interviewers want to see that you think in systems, not just scripts.

For incident questions: Follow a clear timeline: detect, isolate, fix, communicate, prevent recurrence. Always include what you changed after the incident. Firms like Goldman Sachs care as much about your process for preventing recurrence as about your speed during the incident itself.

For behavioural questions: Use the STAR structure (Situation, Task, Action, Result) and keep each section tight. One concrete action beats a list of five vague ones. For 'client focus' questions, the 'client' might be an internal engineering team or a business stakeholder, so think broadly about who you were serving.

For architecture or design questions: Ask clarifying questions before diving into a solution. State your assumptions out loud. Goldman Sachs systems are large-scale and regulated, so show you are thinking about reliability, security, and observability from the start, not as afterthoughts you bolt on at the end.

For 'tell me about a time' questions: Pick stories where the outcome was positive but not perfect. A story where you fixed something imperfectly and then improved the process shows more maturity than a story where everything went smoothly on the first try.

Goldman Sachs DevOps interviewers are typically senior engineers or engineering managers who have worked in high-stakes financial environments. They are looking for a few specific things beyond basic tool knowledge.

Ownership and reliability mindset. Goldman Sachs runs systems where downtime has direct financial consequences. Candidates who talk about 'my service' and explain what they did personally to keep it reliable stand out over candidates who describe tasks they were assigned.

Security awareness without being prompted. DevSecOps is a real expectation here, not a bonus. If you describe a CI/CD pipeline and never mention secrets management, access controls, or vulnerability scanning, interviewers will notice the gap.

Communication under pressure. Candidates report that interviewers often ask follow-up questions mid-answer, simulating the back-and-forth of an incident call. Stay calm, ask for clarification when you need it, and think out loud rather than going quiet.

Financial domain awareness. You do not need to be a trader, but knowing why latency, auditability, and regulatory compliance matter in a bank shows that you have researched the context you would be working in.

Comfort with scale and complexity. Goldman Sachs operates at a scale most startups never reach. Show that you are genuinely curious about the engineering complexity involved, rather than treating it as a checkbox.

Two to three weeks before the interview

Review publicly available content from Goldman Sachs engineering (tech blog posts, conference talks, public job descriptions). Understand which cloud platforms they use, publicly reported as a mix of on-premise and cloud infrastructure. Brush up on Kubernetes internals, Terraform state management, and your primary CI/CD tool at a level deeper than everyday usage.

One week before

Prepare two to three STAR stories covering: a production incident you owned start to finish, a productivity or automation improvement you drove, and a time you pushed back on a bad technical decision. Write them down and practise telling each one out loud in under three minutes.

Also brush up on financial DevOps topics: high-availability architecture, disaster recovery, audit logging, and secrets management in a regulated environment. These topics come up specifically at firms like Goldman Sachs and are easy to under-prepare for.

Two to three days before

Do a mock interview with a peer or on a practice platform. Focus on thinking out loud during technical questions rather than going silent. Review every tool listed on your resume and make sure you can explain a specific decision you made with each one, because Goldman Sachs interviewers commonly ask you to go deep on your own experience.

Day before

Rest and review your STAR stories once. Check your setup if the interview is remote: camera, audio, and a quiet space. Keep a notepad handy for sketching out architecture during design questions.

For tracking the actual open roles, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so you are not manually scanning 287 Goldman Sachs DevOps listings across multiple portals.

Listing tools without explaining decisions. Saying 'I used Jenkins, Docker, and Terraform' tells the interviewer nothing. Explain why you chose those tools over the alternatives and what tradeoffs you accepted.

Vague incident stories. 'We had an outage and I helped fix it' is not a story Goldman Sachs interviewers can evaluate. They want your specific role, your diagnostic steps, and what changed in the system because of your actions.

Skipping security in technical answers. At a financial firm, leaving security out of your pipeline or infrastructure design is a red flag. Weave in secrets management, RBAC, and scanning naturally rather than adding them as an afterthought when prompted.

Over-engineering answers to simple questions. If asked how you would monitor a service, start simple and add complexity only if the interviewer asks you to go deeper. Jumping straight to a full observability stack for a basic question can signal poor judgment about proportionality.

Not asking clarifying questions on design problems. Goldman Sachs systems have real constraints around scale, latency, and regulation. Jumping into a design without understanding those constraints signals that you would do the same on the job.

Underselling your impact. Many Indian engineers default to saying 'we' when they should say 'I'. It is not boasting to describe your specific actions. Interviewers need to understand your individual contribution, not your team's collective output.