Goldman Sachs Interview Questions

After the HireVue stage, candidates typically get a one-hour coding assessment on CoderPad covering two easy to medium-difficulty data structure and algorithm problems, often touching graphs, trees, arrays, or strings. An interviewer is present and watching your process, beyond just your final answer.

Super Day is the final round, conducted virtually or on site in a single day with two to three back-to-back sessions of 45 to 60 minutes each, covering one or two coding interviews similar in difficulty to the earlier screen, plus a behavioral round. It compresses what other firms might spread across a week into a single day.

Java, Python, and C++ are the most commonly supported languages on CoderPad, with Python showing up often given how much of Goldman's quantitative and data tooling relies on it. Pick the language you are fastest and most accurate in rather than trying to prove range under time pressure.

Arrays, strings, and hash map based problems are the most frequent, alongside tree traversal and basic graph problems like checking connectivity or finding a shortest path in an unweighted graph. Dynamic programming appears occasionally but rarely as the primary focus at this level.

Practicing out loud, on camera, under a strict per-question time limit closes the gap between how the format feels in your head and how it actually plays out. Common prompts include 'why Goldman Sachs,' a time you worked under pressure, and how you handle disagreement on a team.

Interviewers routinely open the coding round by asking about a project on your resume before moving into the algorithm problems, checking that you can explain your own past work clearly and specifically rather than in vague generalities. Be ready to explain technical decisions you made, beyond just what the project did.

Yes, expect conceptual questions on encapsulation, inheritance, and interface design, sometimes paired with a short exercise modeling a simple trading or account entity in code. The goal is checking whether you structure code with intention, not reciting textbook definitions.

Entry-level system design, when it appears, tends to be lightweight, something like designing a simple order queue or a basic price-alert notification feature, checking that you understand fundamental tradeoffs rather than expecting production-grade distributed systems knowledge.

Candidates commonly report about three weeks from the initial HireVue invite through Super Day and a final decision, making it one of the faster processes among major banks, though timing can stretch depending on team availability and recruiting cycle timing.

Goldman Sachs engineers work closely alongside trading, risk, and other business functions, so behavioral answers that show comfort communicating technical tradeoffs to non-engineers, and working under real-time pressure, tend to resonate with interviewers evaluating cultural fit.

Basic SQL, filtering, joins, and simple aggregation, comes up either directly in the coding round or as a follow-up conversation topic, since so much of Goldman's internal reporting and reference data infrastructure sits on relational stores.

Expect prompts like 'tell me about a time you had to learn something quickly under a deadline' or 'describe a disagreement with a teammate and how it was resolved,' generally assessed against Goldman's stated values of partnership, client service, and integrity.

Interviewers consistently note that narrating your approach, including dead ends and why you abandoned them, is weighed alongside correctness, since the format is explicitly designed to observe how you think, not only whether you produce a working solution.

Problems involving traversing a graph to determine connectivity, or finding the shortest path between two nodes using breadth-first search, appear regularly, likely because they map naturally to real problems like tracing dependency or settlement chains.

The standard entry-level path relies on the live CoderPad technical screen rather than an untimed take-home assignment, though this can vary by specific team or program, so confirming the exact format with your recruiter ahead of time is worthwhile.

Expect 'what is the time and space complexity of this solution' almost universally, along with 'how would this change if the input were significantly larger,' checking whether you can reason about scaling beyond the immediate test case.

A specific answer tied to the scale and speed of Goldman's trading and risk technology, paired with a genuine personal interest area, whether that is market data infrastructure, low-latency systems, or internal engineering tooling, lands better than a generic answer about prestige or brand name.

Checking for anagrams, finding the longest substring without repeating characters, or reversing words in a sentence come up frequently since they are fast to state and reveal whether you reach naturally for the right data structure under time pressure.

Occasionally, in the form of a conceptual question about race conditions or what a deadlock is, rather than a hands-on concurrent coding exercise, since deep concurrency expertise is generally not expected until the mid or senior level.

A brief situation, the specific action you took, and a concrete outcome, delivered concisely within the time limit, works best, since the recorded format offers no opportunity for an interviewer to redirect a rambling answer back on track.

Generally not technical, it covers your background, visa or work authorization status if relevant, and basic interest in the specific engineering division you are applying to, whether that is core engineering, a specific trading technology team, or a rotational program.

Linked lists, basic stacks and queues, and simple binary tree problems round out the common set, often framed around checking balance, computing depth, or performing an in-order traversal.

A strong, consistent Super Day can offset a shakier earlier technical screen since it is the round where the most interviewers form independent impressions, but a genuinely weak technical screen typically has to be overcome by a clearly standout Super Day across every session.

Finding the maximum profit from a single buy and sell of a stock given a price array, or extending it to the maximum sum contiguous subarray, comes up frequently since it tests whether you can move from brute force to an optimized single-pass solution.

It occasionally comes up as a natural follow-up if you mention team projects, checking basic git fluency like branching and resolving a merge conflict, but it is rarely a dedicated interview topic on its own at this level.

Goldman Sachs engineering sits across several business-facing divisions including trading technology, risk, and core platform engineering, and knowing roughly which division you are interviewing for helps you tailor examples and questions to that group's actual work.

Deep finance knowledge is not required, but understanding broadly what the systems you would be building support, whether that is order execution, risk calculation, or client reporting, shows genuine interest rather than treating the role as an interchangeable tech job.

Validating whether a binary tree is a valid binary search tree, or computing the lowest common ancestor of two nodes, are frequently reported problems that test recursive thinking under a moderate time constraint.

Stating your initial brute force approach out loud before attempting to optimize demonstrates structured problem solving, and interviewers consistently rate candidates who narrate a clear path from a naive solution toward an efficient one higher than those who stay silent while searching for the optimal approach immediately.

Interviewers often leave time for you to ask questions, and candidates who ask something specific about the team's current technology priorities or a recent project mentioned earlier in the conversation tend to leave a stronger final impression than those asking only generic questions.

It can come up as a lightweight exercise, such as designing a simple endpoint for retrieving account or price data, checking that you think about clear request and response structure rather than full distributed system design.

Most coding rounds are one-on-one with a single engineer, though some sessions, particularly the behavioral round, occasionally include two interviewers, so confirming the format with your recruiter ahead of time avoids surprises.

Reported experiences generally describe Goldman's coding difficulty as easy to medium, testing solid command of fundamentals rather than the hardest algorithmic puzzles, though the bar rises meaningfully once you move past entry-level hiring.

Practicing on a similarly bare editor without heavy IDE auto-complete, and getting comfortable typing and running code while talking through your logic simultaneously, closes the gap between practice and the real assessment experience.

For certain entry-level and internship pipelines, an online coding assessment can precede or run alongside the HireVue stage, so confirming your specific process sequence with your recruiter early avoids missing a step.

Common prompts include designing a real-time market data distribution service, a risk calculation pipeline that needs to process large volumes of positions quickly, or an order management workflow, with interviewers pushing on latency, data consistency, and how the design handles a downstream failure.

Given how latency-sensitive much of Goldman's trading technology is, expect real questions on thread safety, lock contention, and how you would design a component to process high volumes of concurrent price updates without introducing race conditions or stale reads.

It typically covers how updates are published to many downstream consumers efficiently, how staleness or out-of-order updates are detected and handled, and how the system degrades gracefully rather than failing outright if a downstream consumer falls behind.

Expect harder queries involving window functions, multi-table joins with aggregation, and discussion of indexing strategy, sometimes paired with a question about when a relational store is the wrong choice for a specific high-throughput trading or risk workload.

Interviewers ask for a specific technical decision you made and had to defend under pressure, for example a design choice made close to a market open deadline, and probe what tradeoffs you weighed and whether the decision held up over time.

For candidates targeting trading technology specifically, yes, expect questions about minimizing processing latency in a hot path, memory allocation patterns that avoid garbage collection pauses, and how you would measure and validate latency improvements empirically.

Medium-difficulty problems dominate, often involving graphs, moderate dynamic programming, or multi-step string processing, with the expectation that you reach a correct, efficient solution with minimal interviewer prompting.

You might be asked how you would design a system where a calculation error could lead to a materially wrong risk figure being reported, prompting discussion of validation checks, reconciliation against an independent source, and clear escalation paths for detected anomalies.

Expect questions on when to cache reference or market data, how to invalidate a cache correctly when underlying prices update in real time, and the tradeoffs between serving slightly stale data quickly versus always fetching fresh data at higher latency cost.

Behavioral questions increasingly probe how you have reviewed a junior engineer's code, caught an issue before it reached production, or helped ramp up a new team member, since mid-level engineers are expected to raise the technical bar for those around them.

You might be asked to design a system that receives, validates, and routes trade orders reliably, with interviewers focusing on how you would guarantee an order is neither lost nor duplicated, and how you would handle a downstream exchange connection becoming unavailable.

Questions on the tradeoffs between synchronous and asynchronous communication between services, and how you would handle a partial failure where one of several downstream calls in a workflow fails, come up regularly given the interconnected nature of trading platforms.

Interviewers ask about your approach to testing financial calculation logic specifically, including how you would build confidence that a pricing or risk formula is correct beyond simple unit tests, sometimes referencing parallel-run or shadow-testing strategies.

It typically blends a deep dive into your most complex recent project with questions about how you handle ambiguous requirements, since mid-level hires are expected to need meaningfully less specification detail than entry-level engineers.

You might be asked to design an internal API for retrieving position or pricing data used by multiple downstream teams, covering versioning strategy and how you would evolve the API without breaking existing consumers across the firm.

Yes, most Goldman Sachs Super Day loops for 3 to 6 year candidates give system design its own dedicated round alongside coding, reflecting that engineers at this level are expected to reason about architecture, beyond implementing a clearly specified feature.

You might be asked to design a batch or streaming pipeline that ingests end-of-day trade data and produces reconciled positions, with interviewers probing how you would handle late-arriving data and ensure the pipeline's output is auditable.

You may be walked through a scenario where a service is intermittently returning incorrect calculations under load, and interviewers watch for a structured investigation approach: isolating scope, checking recent changes, and forming a testable hypothesis rather than guessing.

Behavioral questions ask for a specific incident you helped resolve, including how you communicated status during the incident and what changed afterward to prevent recurrence, reflecting the operational seriousness expected around live trading systems.

You might be asked to design a simplified order book or portfolio position tracker in code, focusing on class responsibilities and how the design would extend cleanly to support a new instrument type without a large rewrite.

Given the firm's growing use of cloud infrastructure for non-latency-critical workloads, questions about how a service would be containerized and deployed increasingly appear, though depth expected varies significantly by the specific team and workload.

Asking a specific, informed question about a recent technical challenge the team faced, ideally referencing something mentioned earlier in the day, signals genuine engagement and is consistently noted favorably by interviewers assembling final feedback.

You may be asked how you would explain a technical tradeoff to a trader or risk manager with no engineering background, since mid-level Goldman engineers increasingly interact directly with business stakeholders on live systems.

Expect prompts scoped to trading-platform scale, such as designing a real-time risk aggregation system across multiple asset classes or a resilient order routing service, where interviewers push hard on consistency guarantees, latency budgets, and graceful degradation under partial outage.

Strong candidates proactively raise how a design would produce an auditable, immutable trail of pricing and trading decisions, since Goldman's systems operate under substantial regulatory scrutiny and interviewers notice when this consideration is missing from an otherwise sound design.

Encryption of sensitive market and client data, strict access control around systems that can move real money or execute trades, and defense against manipulation or replay attacks are expected talking points given the elevated stakes of a global markets technology platform.

Interviewers ask for a specific example where you influenced architecture direction across multiple teams or resolved a disagreement between senior engineers on a critical trading system decision, then probe hard on what pushback you received and how the decision ultimately performed.

Beyond correctness, senior candidates are expected to discuss specific techniques like minimizing memory allocation in a hot path, choosing appropriate data structures for cache locality, and how they would empirically measure whether a latency optimization actually worked in production.

Expect detailed questions on designing for specific failure modes in trading infrastructure: what happens if a pricing feed goes stale mid-session, how you would design failover for a critical order routing component, and how you would define meaningful SLOs for a system where downtime has direct financial consequences.

Usually one round, slightly less puzzle-oriented than mid-level rounds but paired with deeper follow-up on how you would structure the solution for testability, extend it for a much larger input volume, or adapt it for a concurrent execution environment.

Senior candidates are often asked to describe a time a risk or compliance requirement materially shaped a technical design decision, checking for genuine experience navigating regulatory constraints rather than only unconstrained system design.

It typically covers how positions across asset classes are ingested and normalized, how the aggregation stays consistent as new trades stream in throughout the day, and how the system reconciles against an independent end-of-day calculation to catch discrepancies early.

Behavioral questions ask for concrete examples of developing a junior or mid-level engineer's technical judgment over time, beyond reviewing their pull requests, and interviewers listen for a structured, repeatable approach rather than a one-off anecdote.

Interviewers commonly present a scenario forcing a choice between strong consistency and lower latency for a specific trading use case, for example position updates versus market data display, and expect you to justify the choice against real financial risk.

Interviewers ask for examples where a technical decision you drove was adopted beyond your immediate team, such as a shared risk calculation library or a platform pattern other trading technology groups followed, and probe how you built consensus for that adoption across teams with competing priorities.

You might be asked to design a firm-wide market data platform or a shared execution infrastructure meant to serve many downstream trading strategies, with interviewers pushing on multi-tenancy, backward compatibility, and how you would govern change without breaking existing high-stakes consumers.

For candidates blending technical leadership with people responsibilities, interviewers add questions about handling performance conversations, prioritizing competing platform investments, and balancing hands-on technical work against organizational responsibilities as scope grows.

Staff-level candidates are asked to walk through a real decision to build in-house versus adopt a vendor solution for trading or risk infrastructure, with strong answers covering total cost of ownership, latency implications, and vendor risk specific to a regulated markets business.

Interviewers ask how you have prioritized paying down technical debt in a critical trading system against relentless feature delivery pressure, expecting a defensible framework rather than a single anecdote about one project.

You might be asked to design a disaster recovery strategy for a system whose extended downtime would materially affect the firm's ability to trade, covering active-active data center strategies, recovery time targets, and how you would validate the plan works before a real failure forces the test.

Behavioral prompts ask for a time you disagreed with another senior technical leader on platform direction and had to reach resolution without direct authority over their team, checking for influence built through evidence and relationships rather than escalation.

Staff candidates are asked how they have improved practices like incident response, deployment safety, or code review standards across more than one team, since technical leadership at this level is expected to raise the baseline for others firm-wide.

Interviewers typically select one area from your background and probe it for ten or more minutes with pointed follow-ups, specifically to test whether your seniority reflects genuine hands-on expertise rather than surface familiarity across many topics.

Given how much trading technology depends on integrating with external exchanges and data vendors, you may be asked how you would design an integration layer that isolates Goldman's core systems from a third party's instability or protocol changes.

Expect questions about how you have reduced infrastructure cost or improved compute efficiency for a system running at significant scale, since staff engineers are expected to reason about the financial impact of technical decisions, beyond correctness and performance alone.

It typically addresses how sensitive market, position, and client data is classified, access-controlled, and made auditable across its full lifecycle, reflecting the elevated data governance bar that comes with operating a globally regulated markets platform.

Beyond the standard Super Day-style loop, staff and principal candidates commonly have an additional conversation with a senior technology leader assessing whether the scope and impact of your prior work genuinely matches the level being hired for.

Interviewers ask for specifics: how many engineers or teams reported into your organization, how large a technology portfolio you owned, and what measurable business outcomes resulted from decisions you led, since vague claims of leading 'large teams' get pressure-tested for real numbers.

You might be asked to describe a multi-year platform consolidation or modernization you led across a trading business, covering how you sequenced the work, managed risk to live systems during migration, and secured executive buy-in for a multi-quarter, high-stakes effort.

Expect a detailed walkthrough of how you led an organization through a significant production incident with real market or financial exposure, including how you communicated with senior leadership and, where relevant, regulators during the event, beyond the technical fix itself.

Candidates are asked how they have built and retained strong engineering organizations in a highly competitive hiring market, including how they have handled underperformance or restructuring, since leadership hires are expected to own people strategy alongside technical strategy.

Given the intensity of regulatory oversight in global markets, interviewers probe your direct experience partnering with risk, compliance, and legal functions on technology decisions, checking whether you can lead comfortably inside a heavily regulated institution.

It typically describes a concrete framework for how much organizational risk appetite was allocated to new technology adoption versus protecting the reliability of systems that directly support live trading, along with a specific example of how that balance was struck and adjusted.

You may be asked to describe how you have presented technology strategy or risk to non-technical partners or senior firm leadership, since director and managing director-level technologists are frequently expected to represent engineering priorities well outside the engineering organization.

Interviewers ask how you have aligned competing technology priorities across different trading or business units that each have their own urgent roadmap, testing your ability to negotiate shared infrastructure investment without simply deferring to the loudest stakeholder.

Expect questions on how you have led decisions about which workloads move to public cloud versus remaining on latency-sensitive, tightly controlled infrastructure, reflecting the firm's deliberate, risk-aware approach to cloud adoption for a global markets business.

You may be asked how you have developed the next layer of technical leadership underneath you, since firms like Goldman Sachs explicitly evaluate whether a leadership candidate builds durable organizational capability or creates a single point of dependency on themselves.

Given the scale of Goldman's trading and risk technology estate, leadership candidates with direct experience consolidating overlapping systems following growth or reorganization are asked to detail how they managed the transition without disrupting live trading operations.

Strong candidates describe a significant strategic misstep they owned, what they learned, and specifically how they changed their own decision-making process afterward, since interviewers are wary of leadership candidates who cannot name a real failure.

Beyond the technical and leadership interview loop, these hires typically go through additional conversations with senior business and technology partners assessing strategic fit with the specific division's priorities, and reference checks carry significant weight given the scope of trust involved.