Goldman Sachs Software Engineer interviews typically run 3–5 rounds: online assessment, CoderPad/HackerRank coding screen, HireVue or recruiter call, and a SuperDay with DSA, system design, and hiring manager rounds. The process spans roughly 2–5 months and is distinguished by a SuperDay format combining technical depth with heavy resume and behavioral scrutiny.
$128K
Avg. Base Comp
$188K
Avg. Total Comp
4-6
Typical Rounds
4-20 weeks
Process Length
What strikes us most across these twelve Goldman Sachs software engineer experiences is how consistently the SuperDay format separates candidates who get offers from those who don't. Almost every candidate who advanced past the initial CoderPad screen ended up in a multi-round SuperDay, and the outcomes clustered heavily around performance in that single day. The candidates who received offers described those rounds as feeling like a "conversation" or a "chat" — not because the content was easy, but because they were prepared enough to stay relaxed under pressure. The ones who didn't get offers often cited the breadth of the SuperDay as the real challenge: DSA, low-level system design, SDLC, and a deep resume walkthrough all in the same loop.
A recurring theme we see is that Goldman's interviewers are unusually focused on resume depth and project defensibility. Multiple candidates reported that every line of their CV was fair game — not just a warm-up, but a genuine technical interrogation. One candidate described the SDLC round as going "very deep into every detail" of their background, and another noted that the behavioral portions felt like they were checking whether you actually did what you claimed. This is different from firms where the resume discussion is a formality before the real coding begins. At Goldman, the two are weighted almost equally in the SuperDay.
On the technical side, the coding questions themselves are mostly LeetCode medium difficulty — Trapping Rain Water, Merge Intervals, linked list cycles, BFS/DFS traversals — but the real differentiator is whether you can explain complexity tradeoffs and optimize on the fly while talking. We've also seen a surprising number of candidates encounter low-level design questions like Chess Board or TinyURL rather than broad system architecture, which catches people off guard if they've only prepared for distributed systems discussions. Java internals — HashMap vs. HashSet, TreeSet, static keyword behavior — came up across multiple independent experiences, suggesting this is a consistent signal Goldman looks for in engineering candidates with a Java background.
Synthetized from 12 candidates reports by our editorial team.
Had an interview recently?
Share your experience. Unlock the full guide.
Real interview reports from people who went through the Goldman Sachs process.
If I'm being completely candid, the Goldman Sachs Superday felt very different from the image I had built in my head. Going in, I expected an intense series of technical interrogations focused heavily on algorithms and edge-case coding questions. I had spent days reviewing Java, Spring Boot, distributed systems, Kafka, cloud architecture, databases, and system design because I wanted to be prepared for anything. Naturally, there were nerves before the first round, especially because Goldman has a reputation for maintaining a high technical bar.
The interview started more conversationally than I expected. Rather than immediately jumping into coding exercises, the interviewers wanted to understand the projects I had worked on and the engineering decisions behind them. We spent a significant amount of time discussing my experience building microservices, event-driven systems, and cloud-native applications. I walked them through architectures I had designed, including risk forecasting and compliance reporting platforms, explaining how different services communicated, how data flowed through the system, and how we handled scalability and reliability requirements.
One thing that stood out was how deeply they explored the reasoning behind my choices. Every technology mentioned became an opportunity for a deeper discussion. If I said Kafka, they wanted to know why Kafka instead of another messaging solution. If I mentioned Cassandra and DynamoDB, they wanted to understand the specific use cases for each. When observability tools came up, they asked why multiple tools were necessary rather than relying on a single monitoring platform. These weren't trick questions. They were trying to evaluate whether I truly understood the tradeoffs involved in building production systems.
The moments where I felt most confident were when discussing technologies and architectures I had worked with extensively. Conversations around Java, Spring Boot, REST APIs, microservices, AWS services, Kafka, and database design felt natural because they reflected problems I had solved in real projects. I was able to explain not only what was built but also why it was built that way and what challenges were encountered along the way.
The moments that created the most pressure were the follow-up questions. Not because they were impossible, but because they required deeper thinking in real time. Questions about scalability limits, failure scenarios, database tradeoffs, monitoring strategies, and alternative architectural approaches forced me to move beyond rehearsed explanations. There were definitely moments where I paused, thought through the problem carefully, and worked through the reasoning out loud before answering.
What surprised me most was how collaborative the conversations felt. Instead of trying to catch me making mistakes, the interviewers often explored solutions with me. They would ask follow-up questions, build on my responses, and discuss different approaches. The interaction felt closer to a technical design review among engineers than a traditional question-and-answer interview.
When the Superday ended, I felt cautiously optimistic. I knew there were answers I could have improved, but I also felt that I had demonstrated my technical depth, problem-solving approach, and ability to discuss complex systems. Looking back, the experience was less about memorizing answers and more about showing how I think through engineering problems, justify technical decisions, and communicate effectively under pressure. That was ultimately what made the interview both challenging and rewarding.
Questions asked: The interview was heavily focused on my past experience and system design decisions rather than pure LeetCode-style coding. Most of the discussion revolved around projects listed on my resume, and the interviewers continuously drilled deeper into the technologies and architectural choices I mentioned.
Some of the technical questions I remember included:
One interviewer asked me to draw and explain a complete architecture from the frontend layer all the way to the database layer. I discussed API gateways, authentication, microservices, Kafka, databases, caching, and deployment on AWS. The interviewer then challenged individual components and asked why each one was necessary.
The most difficult part wasn't any single question. It was the depth of the follow-up questions. Every answer led to another "why?" They were less interested in whether I knew a textbook definition and more interested in whether I could justify engineering decisions and explain tradeoffs.
Interestingly, there was very little emphasis on tricky algorithm questions. The conversations felt more like a design review with senior engineers than a traditional coding interview. The interviewers seemed focused on understanding how I think about scalability, reliability, observability, system failures, and real-world production engineering.
There was no take-home assignment in my process. The Superday consisted primarily of technical discussions, architecture deep-dives, and project-based questioning with continuous follow-up questions designed to test depth of understanding rather than memorization.
Share your own interview experience to unlock all reports, or subscribe for full access.
Sourced from candidate reports and verified by our team.
Topics based on recent interview experiences.
Featured question at Goldman Sachs
Given a string, write a function to find its first recurring character.
| Question | |
|---|---|
| Bagging vs Boosting | |
| Find the First Non-Repeating Character in a String | |
| Level Of Rain Water In 2D Terrain | |
| Google Maps Improvement | |
| Append Frequency | |
| Cyclic Detection | |
| Minimum Absolute Distance | |
| Target Indices | |
| Portfolio Platform Architecture | |
| Cross-Region Inventory Sync | |
| How Many Friends | |
| Messenger Service Design | |
| Production Model Monitoring | |
| Optimistic vs Pessimistic Locking | |
| Cloud-Agnostic Deployments | |
| SageMaker Deployment Architecture | |
| Impossibly Iterative Fibonacci | |
| Deciding Between Solutions | |
| Alternative Vendor Tradeoff | |
| Client Solution Pushback | |
| LRU Cache 1 | |
| Using APIs for Downstream Tasks | |
| 2nd Highest Salary | |
| Employee Salaries | |
| Merge Sorted Lists | |
| Closest SAT Scores | |
| Empty Neighborhoods | |
| Subscription Overlap | |
| Top Three Salaries |
Synthesized from candidate reports. Individual experiences may vary.
Candidates complete a HackerRank or similar online coding assessment with easy-to-medium LeetCode-style questions, sometimes accompanied by technical multiple choice questions or an aptitude test with negative marking. This is typically the first filter in the process.
A recorded or live behavioral round focused on resume walkthrough, motivation for the role and division, and communication of technical concepts. Questions include explaining recursion, how you would test something, and how you handle team scenarios.
A brief call with a recruiter to confirm background, availability, and preferred programming language, and to walk through the next steps in the process.
A live coding interview on CoderPad with one to three LeetCode-style problems ranging from easy to medium difficulty, covering topics like hashmaps, BFS/DFS, arrays, and string manipulation. The interviewer often mixes in light resume discussion and expects candidates to explain their approach and complexity as they code.
The main evaluation stage consisting of three to six back-to-back rounds covering DSA and coding, system design (both high-level and low-level), SDLC and software engineering practices, and a deep resume and behavioral discussion. Coding problems range from medium to hard, and design prompts include topics like TinyURL, parking systems, chess board design, and high-frequency transaction processing.
A closing conversation with a hiring manager or Managing Director that is more conversational in tone, covering past experience, fit, and behavioral questions. This round is less technically intensive but still involves resume depth and situational judgment.