Goldman Sachs SWE Interview: Coding Screen Guide

Estimated read time: 7-9 minutes

Summary: The Goldman Sachs SWE coding screen is an engineer-led technical gate, commonly reported around 45-60 minutes. The source supports coding, data structures and algorithms, OOP fundamentals, SQL/database questions, Java/Python/C++ language fundamentals, complexity, and edge-case follow-ups. Exact question wording is weak, and role paths vary, so prepare for practical fundamentals rather than one narrow question bank.

TL;DR + FAQ (read this first)

At-a-glance takeaways

• The coding screen is likely 45-60 minutes where reported.
• Expect DSA plus possible OOP, SQL/database, language fundamentals, and complexity discussion.
• Role path matters: SWE, analyst, strats, and quant developer reports can differ.
• Senior candidates may see broader design or architecture later, but coding fundamentals still matter.
• Exact questions are not strongly verified, so practice themes and follow-ups.

Quick FAQ

Is this only algorithms?
No. The source also supports OOP, databases, language fundamentals, complexity, and edge cases in some paths.

Should I study finance math?
Only if your path is strats or quant developer. For SWE, keep finance context role-adjacent unless the recruiter says otherwise.

What should I clarify?
Ask whether the screen is general SWE, technology analyst, backend, database-heavy, or specialized.

What matters most?
Correct implementation, fundamentals, communication, and edge-case awareness.

---

1) What the coding screen measures

The screen evaluates coding ability, CS fundamentals, language fluency, and problem solving. The source also mentions databases and OOP as possible topics. That means a strong answer is not just a working snippet. It includes a clear approach, clean implementation, complexity explanation, and tests.

Because Goldman Sachs technology paths vary, the interviewer may move between coding, fundamentals, and role-specific questions. Stay flexible and ask clarifying questions before assuming the domain.

---

2) How questions may evolve

A coding task may start as a standard DSA problem, then add an edge case, database-like record aggregation, object modeling, or language-specific follow-up. For example, an array problem can become a hash-map optimization. A transaction-record task can add duplicate ids. An OOP question can become a design for extensibility.

When the interviewer changes the constraint, restate the new requirement and update the simplest part of your solution that needs to change.

---

3) Questions to practice

These are representative tasks based on source themes, not confirmed verbatim Goldman Sachs questions.

• Given an array of numbers, find the pair or group that satisfies a target condition. Start simple, then optimize with a hash map.
• Given transaction-like records, group by account or symbol and return totals. Now handle duplicate records and missing fields.
• Design a small set of classes for orders, trades, or events. How would you extend the model without rewriting callers?
• Write a SQL query to aggregate records by user or day, then explain how you would improve it if it became slow.
• Explain a language feature in Java, Python, or C++ that affects correctness, memory, or concurrency.
• Solve a DSA task, then explain runtime, space, and edge cases.
• Given code with a hidden edge-case bug, identify the failing input and fix the implementation.

---

4) Level-specific expectations

The slug table lists intern through senior as relevant, with Staff+ possible or role-dependent. The source says exact level differences are sparse.

• Intern and New Grad: expect fundamentals, coding, and possibly analyst-path breadth.
• Junior and Mid-Level: show implementation quality, CS basics, database comfort, and clear communication.
• Senior: coding still matters, but be ready for design, project depth, and architecture in later stages.
• Staff+: public evidence is weak, so confirm whether coding, design, or leadership depth is emphasized.

---

5) Common failure modes

Preparing only generic DSA. Databases, OOP, language fundamentals, and finance-technology context may appear.

Confusing paths. Strats and quant developer reports can include topics that are not universal SWE expectations.

Weak fundamentals. Be able to explain complexity, classes, SQL, and language behavior clearly.

No edge-case tests. Empty input, duplicates, missing records, and large input matter.

Silent coding. Explain assumptions and tradeoffs as you go.

---

6) How to prepare

• Practice array, string, hash-map, and basic graph/tree problems.
• Review OOP, SQL aggregation, indexing basics, and language-specific fundamentals.
• Use financial-record examples only as data-shape practice unless your path requires deeper finance context.
• After each solution, name complexity and tests.
• Ask the recruiter which technical themes apply to your path.

---