Goldman Sachs Coding Interview Questions: 2026 Guide

Goldman Sachs coding interview questions tend to reward fast pattern recognition rather than obscure algorithmic tricks. The technical bar is broad: candidates need to move from a timed assessment into live coding, then carry that clarity into a Superday that can include data structures and algorithms, system design, software development lifecycle discussion, and behavioural evaluation.

The strongest preparation is therefore not a random problem list. It is a map of the recurring families: array and string scanning, hashing, two pointers, sliding windows, binary search, trees, graphs, recursion, and dynamic programming. Goldman Sachs's interview kit holds 45 mapped DSA questions and 3 low-level design problems, organised so you can practise the underlying recognition skill rather than memorise isolated solutions.

Reported accounts describe an assessment through HackerRank or HireVue, followed by a CoderPad technical screen and a Superday. The exact sequence can vary by team, location, level, and hiring channel, so treat this as the commonly reported shape rather than a fixed company policy.

The coding rounds

The pattern families to prioritise

A Goldman Sachs preparation plan should begin with recognition, not implementation. In a coding round, you rarely receive a label saying “this is a sliding window problem”. You receive a business-flavoured prompt, some constraints, and limited time. Your job is to translate those details into a familiar computational shape.

The company-specific set is useful because it brings the most relevant DSA material into one place. Across the mapped problems, the practical focus is on core patterns that recur in technical interviews and that can be adapted under follow-up pressure.

Arrays, strings, and hash-based lookup

These are often the earliest patterns to master because they establish the habits needed for everything else: reading constraints, choosing an appropriate data structure, and separating brute force from an efficient approach.

Look for clues such as duplicate detection, matching items across collections, counting frequencies, grouping related values, or finding a missing relationship. A hash map or set is often the right starting point when the prompt requires quick lookup or counting.

The important skill is not merely knowing that a map exists. It is being able to say why it changes the complexity, what the memory trade-off is, and how it behaves on empty input or repeated values. That explanation matters in live rounds because it makes your reasoning inspectable.

Two pointers and sliding windows

These patterns often appear when the input is ordered, when you need to compare from two ends, or when the prompt asks about a contiguous region. Candidates lose time when they repeatedly rescan portions of an array that could be handled by moving boundaries.

Two pointers usually signal a relationship between positions: pair selection, partitioning, or traversal from opposite ends. A sliding window usually signals a contiguous subarray or substring where a running condition must be maintained.

Practise stating the invariant before coding. For example: what does the current window always represent, what causes it to expand, and what causes it to shrink? If you can explain that in plain language, the implementation becomes much less fragile.

Binary search and monotonic reasoning

Binary search is more than searching a sorted array. In interviews, it often appears as “find the smallest feasible value”, “find the earliest point”, or “determine whether a proposed answer can work”.

The recognition cue is monotonicity. If a candidate answer works, do larger answers also work? Or if it fails, do smaller answers also fail? Once you establish that yes-or-no property, you can search the answer space rather than enumerate it.

This is an excellent pattern for practising precision. Boundary choices, loop conditions, and return values are frequent sources of bugs. Explain your initial bounds, describe what each midpoint test means, and test the smallest and largest valid cases aloud.

For a deeper framework on this kind of translation, read how to identify the right DSA pattern in a coding interview.

Trees, graphs, and traversal

Tree and graph questions test whether you can choose the right traversal and keep state under control. Depth-first search is often a natural fit for recursive exploration, path-building, and component-style reasoning. Breadth-first search is often the better fit when distance, layers, or minimum steps matter.

The risk is treating every graph prompt as a memorised template. Before selecting a traversal, clarify what the nodes and edges represent, whether revisiting is possible, whether the graph is directed, and whether cycles must be handled.

The graph traversal patterns guide is useful when you need to refresh the decision rules between depth-first and breadth-first search. During live practice, narrate your visited-state strategy explicitly. It is a small detail, but it shows that you are thinking about correctness rather than only a happy path.

Dynamic programming and state design

Dynamic programming is where many candidates know the technique in theory but struggle to recognise it quickly. The prompt may describe choices over time, a sequence of decisions, an optimisation target, or overlapping subproblems. The decisive step is defining the state.

Ask: what information from the past changes the future? If the answer can be represented compactly, you may have a dynamic programming formulation. Then decide whether top-down memoisation makes the recurrence easiest to explain or whether bottom-up iteration makes the computation and memory use clearer.

Do not force dynamic programming onto a problem that a greedy method, a graph traversal, or a simple prefix calculation solves cleanly. Interviewers value judgement. A complicated solution to a simple problem can undermine an otherwise strong performance.

The dynamic programming patterns guide can help you practise identifying state, transition, base case, and evaluation order as separate steps.

What the assessment is really testing

Reported accounts commonly mention a HackerRank assessment or HireVue stage before the live technical interviews. Whatever platform appears in your process, the underlying evaluation is similar: can you read a problem accurately, identify the likely pattern without excessive trial and error, implement a correct solution, and validate it under time pressure?

This is where recognition speed has outsized value.

Recognition speed does not mean jumping to code in seconds. It means moving efficiently through a disciplined internal sequence:

identify the input shape and constraints;
state the naive approach briefly;
notice the bottleneck;
connect that bottleneck to a pattern family;
select the data structure that supports the improved approach;
reserve time for edge cases and a final complexity check.

Candidates often practise only the final step: writing code after they have already seen the editorial. That creates familiarity, not recognition. Better practice starts with a cold read. Give yourself a short period to name the pattern and explain why it fits before writing a line.

The free-to-browse DSA Patterns Sheet is designed for that workflow. Sort your sessions by pattern, then revisit the same pattern after a gap so you must recognise it again rather than rely on recent memory.

Practical rule: if you cannot explain why an approach is efficient before you code it, pause. A few seconds spent naming the bottleneck can prevent a full rewrite later.

The live coding screen: communication becomes part of the solution

After the assessment, reported accounts describe a CoderPad technical screen. This is a different environment from a solo timed test. The interviewer can see your choices develop, ask follow-up questions, and assess how you respond when an initial approach needs adjustment.

A strong live-coding rhythm looks like this:

Restate the problem in your own words.
Ask about assumptions, inputs, constraints, and expected edge-case behaviour.
Describe a simple solution first if it helps establish the baseline.
Explain the improved approach and its complexity.
Code in small, checkable sections.
Walk through representative cases before declaring the solution complete.

The key is to make decisions audible. Interviewers cannot give credit for reasoning they cannot observe. You do not need to narrate every keystroke; instead, speak at the decision points: data structure choice, loop invariant, recursion base case, graph visitation rule, and complexity trade-off.

For more on that skill, see what interviewers actually look for in live coding rounds and how to explain your thought process clearly in coding interviews.

Superday: coding is necessary, but not the whole technical story

Reported accounts describe Superday as a set of interviews that can cover DSA, system design, SDLC or process discussion, and behavioural evaluation. Team-fit discussion and a Managing Director conversation may follow. This is why a Goldman Sachs preparation plan should have breadth without becoming unfocused.

DSA in Superday

Expect the same fundamental pattern families as the assessment, but with more emphasis on discussion. A live interviewer may change a constraint, ask you to reduce memory use, introduce a scale-related follow-up, or request a test strategy. Prepare to defend choices rather than merely produce a final answer.

Return regularly to Goldman Sachs's interview kit during this phase. Use the mapped DSA questions as a timed simulation set, but spend at least as long reviewing your decision process as you spend coding.

System design and SDLC discussion

Goldman Sachs Superday reports include an explicit system-design component. At this level, the question is often less about reciting architecture diagrams and more about showing structured engineering judgement: clarify requirements, identify core entities and flows, discuss reliability and security considerations, make sensible trade-offs, and explain how you would deliver and operate the system.

The low-level design material in the kit covers the kind of design problem evidenced at Goldman Sachs. Goldman Sachs's interview kit includes 3 low-level design problems that you can use to rehearse class boundaries, responsibilities, interfaces, and extension points.

For the distinction between object-level design and architecture-level discussion, the free-to-browse System Design Sheet and Low Level Design Sheet are useful companions. Low-level design versus high-level design explains what each format tends to assess.

Behavioural and seniority signals

The Managing Director round adds a career and seniority signal beyond pure technical problem solving. Prepare concise stories about ownership, difficult trade-offs, disagreement, delivery under pressure, quality improvements, and learning from mistakes.

Avoid generic stories that make your contribution impossible to locate. Be ready to explain what you decided, what constraints you faced, what changed because of your work, and what you would do differently now. An AI interview can help you rehearse those answers aloud and reduce the tendency to over-explain or lose the narrative.

A focused practice plan

Start with diagnosis

Before revising everything, identify the patterns that slow you down. Take several unfamiliar problems and record the point of failure: did you misread the condition, choose the wrong data structure, fail to see the pattern, or make an implementation mistake?

That diagnosis should determine your next practice block. If recognition is weak, group practice by pattern. If implementation is weak, repeat the same pattern in your primary language until the standard moves feel natural. If communication is weak, solve aloud.

Build a pattern loop

Use a repeatable cycle:

solve a cold problem without hints;
label the pattern after you have reasoned about it;
compare your approach with the editorial;
write down the clue you missed or used;
revisit a related problem later without notes.

This approach produces durable recognition. It also prevents the false confidence that comes from remembering a solution you saw recently.

Use in-browser code practice to make execution part of your preparation. Compile, test boundary cases, and get used to correcting small mistakes quickly rather than hoping your first submission is perfect.

Add live-round constraints

Once your core patterns feel stable, practise in conditions closer to the screen. Speak your approach before coding. Do not silently consult notes. Test with examples you invented yourself. After finishing, spend a few minutes explaining how the solution changes if constraints change.

For system and design discussion, sketch requirements before classes or components. State what you are deliberately leaving out and why. This is not a weakness; scoped thinking is evidence of engineering judgement.

Rehearse the full narrative

In the final stage of preparation, rotate through coding, design, SDLC discussion, and behavioural stories. You are not trying to become perfect at every topic in a day. You are trying to be composed, structured, and adaptable across the shape of the loop.

Frequently asked questions

Are Goldman Sachs coding interview questions difficult?

They are commonly reported as demanding but grounded in familiar DSA patterns. Difficulty often comes from time pressure, follow-up discussion, and the need to communicate a correct approach clearly.

Does Goldman Sachs use an online assessment?

Reported accounts describe either a HackerRank assessment or HireVue early in the process. Confirm the format with your recruiter because it can vary.

What DSA patterns should I prioritise?

Prioritise arrays and strings, hashing, two pointers, sliding windows, binary search, trees, graphs, recursion, and dynamic programming. Focus on recognising when each pattern applies.

What happens in the technical screen?

Reported accounts describe a CoderPad technical screen. Expect live problem solving, discussion of your approach, implementation, testing, and complexity analysis.

Is system design part of Goldman Sachs Superday?

Reported accounts describe an explicit system-design round within Superday. Prepare to structure ambiguous requirements, discuss trade-offs, and communicate engineering decisions clearly.

Should I prepare low-level design?

Yes. The kind of design problem evidenced at Goldman Sachs is useful for practising classes, interfaces, responsibilities, and extensibility. It complements architecture-level system-design preparation.

What are SDLC questions in an interview?

These questions examine how you build and operate software: planning, testing, releases, code review, incident response, reliability, collaboration, and decision-making across a delivery cycle.

How should I prepare for the Managing Director round?

Prepare specific stories that demonstrate ownership, judgement, collaboration, and growth. Keep the focus on your personal contribution, the trade-off you made, and the result.

Is pattern practice better than solving random problems?

For interview preparation, pattern practice is usually more efficient because it trains recognition. Random problems still help, especially later, when you need to test whether the recognition has become transferable.

Where to start

Start with the patterns that make you hesitate. Build speed on arrays, hashing, windows, traversal, binary search, and dynamic programming; then practise explaining each choice under realistic conditions. Treat the assessment as a recognition test and the live rounds as a reasoning-and-communication test.

Open Goldman Sachs's interview kit to practise the 45 mapped DSA questions and 3 low-level design problems relevant to the company. Pair that work with the free-to-browse DSA Patterns Sheet, use an AI interview for coding and behavioural rehearsal, and practise until your explanation is as reliable as your implementation.

Goldman Sachs Coding Interview Questions: Patterns and Prep (2026)