Goldman Sachs data scientist SQL and coding interview 2026

TL;DR

Goldman Sachs evaluates data scientist SQL and coding skills through four technical layers: query efficiency, edge-case handling, optimization under constraints, and integration with Python. The real test is not syntax recall but judgment in trade-offs. Candidates who pass treat SQL as a logic tool, not a scripting language.

Who This Is For

This is for candidates with 0–5 years of data experience applying to Goldman Sachs Data Scientist roles in New York, Salt Lake City, or Bengaluru, where coding rounds are standardized across divisions including Asset Management, ICG, and Global Markets. You likely have a degree in computer science, statistics, or engineering and are preparing after clearing the HackerRank initial screen.

What does the Goldman Sachs data scientist SQL interview actually test?

It tests your ability to reason under schema ambiguity, not just write correct queries. In a Q3 2024 debrief, a candidate was downgraded despite a working solution because they assumed an ORDER BY without checking if the timestamp field had nulls — a critical flaw in financial data pipelines. Goldman’s data is messy: timestamps drift, IDs duplicate across legacy systems, and joins often fail silently.

The difference between a "Lean Forward" and "No Hire" decision often comes down to one moment: whether the candidate asks about data quality before writing code. In one HC meeting, a hiring manager said, “She didn’t get the window function perfect, but she validated the partition key first. That’s risk-aware thinking.”

Not accuracy, but resilience.

Not completeness, but constraint signaling.

Not elegance, but auditability — because at Goldman, every query may become a regulatory artifact.

You’re not debugging your own code. You’re preventing someone else’s downstream failure. Work through a structured preparation system (the PM Interview Playbook covers data integrity edge cases in banking datasets with real debrief examples).

How many coding rounds do Goldman Sachs data scientist candidates face?

You face two scored coding interviews: a 60-minute HackerRank screen and a 45-minute live technical round with a senior data scientist. A third, informal Python discussion may occur during the onsite, but only the first two are scored. The HackerRank test includes 3 problems: 1 SQL, 1 Python (Pandas), and 1 algorithmic logic question. You have 75 minutes total.

In 2024, 68% of rejected candidates failed the HackerRank SQL question not due to syntax, but because they returned 10x the expected rows — a cardinality explosion from a careless JOIN. Goldman’s internal benchmark is 85% query precision before the filter phase.

The live interview uses a shared CoderPad session. You’ll get a schema sketch — never a full ERD — and must ask clarifying questions. One candidate in Salt Lake City was told to “assume it’s correct” after probing primary keys, but later got praised in the debrief for still adding COALESCE guards. Judgment overrides obedience.

What kind of SQL problems does Goldman Sachs ask in 2026?

You’ll get financial time-series aggregation with embedded business logic. Not “find the second-highest salary,” but “calculate rolling 30-day client exposure net of hedges, adjusting for trade settlement lag.” These are multi-step, state-aware problems.

A 2025 real question:

Given a trade log and a corporate action table (stock splits, dividends), compute adjusted notional value per client over time, then flag clients exceeding $50M exposure on any single issuer post-adjustment.

This tests:

Temporal alignment (event time vs. processing time)
Forward-filling missing adjustments
Handling back-dated corporate actions
Client-level rollups with issuer deduplication

In a debrief last November, a candidate lost points for using a RANK() when DENSE_RANK() was needed — seemingly minor, but in risk reporting, gaps in ranking can mask concentration risk. The feedback: “Not wrong, but inattentive to continuity.”

Not syntax, but semantics.

Not aggregation, but lineage.

Not output, but traceability — because at Goldman, someone must be able to reverse-engineer your logic from the query alone.

How is Python evaluated in the Goldman Sachs data scientist interview?

Python is evaluated for data integrity control, not just Pandas fluency. You will not be asked to build a model. You will be asked to clean, align, and validate. In one round, candidates received two mismatched CSVs: one with client IDs as strings, another as integers, and timestamps in mixed timezones. The task was to merge and calculate daily volume.

A top-scoring candidate didn’t jump to pd.merge(). They first ran:

`python

assert df1['clientid'].dtype == df2['clientid'].dtype

assert df1['timestamp'].dt.tz is not None

Then wrote a transformation pipeline with logging at each step. The interviewer later said, “He treated the data like it was hostile — and in our world, it is.”

Goldman does not want elegant code. They want defensive code.

Not speed, but repeatability.

Not cleverness, but audit trails.

You are not a data scientist here — you are a risk gatekeeper who uses code.

How should you explain your coding approach during the interview?

You should narrate your assumptions, not your steps. Most candidates say, “Now I’ll join the tables,” which adds zero value. What the committee wants is: “I’m assuming the trade_id is unique here, but in production, I’d check for duplicates because replay logs can inject them.”

In a Q2 2025 debrief, a candidate paused for 90 seconds before typing. They said, “This looks like a FIFO position calculation. If there’s partial settlement, we need to track residual lots. I’ll use a cumulative sum with a reset condition.” The panel marked “Exceptional Judgment” — not because the solution was novel, but because the risk was surfaced early.

Not “I’m doing X,” but “I’m doing X because Y, despite Z constraint.”

Not progress updates, but risk signaling.

Not confidence, but calibrated uncertainty.

The strongest candidates sound like compliance officers with keyboards.

Preparation Checklist

Master window functions with RANGE vs ROWS semantics, especially for time-bounded aggregations
Practice writing SQL that fails fast: add LIMIT 1 early, use CTEs for validation checks
Rebuild 3 real Goldman-like problems: client exposure rollups, trade adjustment chains, threshold alerts with lookback
Simulate schema ambiguity: practice with hand-drawn, incomplete ERDs
Work through a structured preparation system (the PM Interview Playbook covers data integrity edge cases in banking datasets with real debrief examples)
Do 5 timed HackerRank simulations under 70-minute caps
Memorize zero syntax; instead, internalize failure modes (e.g., cross joins from null keys, timezone mishandling)

Mistakes to Avoid

BAD: Writing a full query without validating assumptions

A candidate joined two tables on client_id without checking for duplicates. Output looked correct but failed audit in review. Result: “No Hire.” The debrief noted, “He trusted the data. We can’t.”

GOOD: Starting with data quality assertions

Another candidate said, “Let me check if clientid is truly a key,” then ran a GROUP BY with HAVING COUNT(*) > 1. Found duplicates. Adjusted logic to use clientid + region. Panel scored “Proactive Risk Detection.”

BAD: Optimizing prematurely

One candidate spent 12 minutes rewriting a subquery into a CTE with indexing hints — none of which applied in HackerRank. Time ran out. Feedback: “Over-engineered a prototype.”

GOOD: Flagging optimization as future work

“I’d add a materialized view here if this ran hourly, but for one-off, CTE is maintainable.” Shows prioritization.

BAD: Using .apply() for vectorizable operations

In Python, one candidate used apply(lambda x: ...) to calculate PnL. Slow, unscalable. Downgraded.

GOOD: Using np.where or eval for conditional logic

Faster, auditable, and aligns with internal tooling. One candidate added # vectorized to avoid UDF overhead in Spark — got called out in debrief as “production-aware.”

FAQ

Is window function mastery required for the Goldman Sachs data scientist SQL round?

Yes. You must correctly apply ROWNUMBER(), RANK(), DENSERANK(), and LAG() in time-series contexts. Misusing them — like using RANK() where ties must be preserved — triggers automatic downgrade. In a 2025 case, a candidate lost offer eligibility over a ranking gap that would have misreported client priority. It’s not about syntax — it’s about business impact.

Do Goldman Sachs data scientist interviews include live coding with debugging?

Yes. In the live round, the interviewer will introduce a bug — like a missing GROUP BY or timezone mismatch — and ask you to find it. Most candidates miss it because they don’t validate output distribution. The expectation is proactive verification: check row counts, nulls, and edge values. One candidate ran SELECT MIN(date), MAX(date) first and caught a data truncation — hiring committee called it “textbook risk hygiene.”

How strict is Goldman Sachs on SQL syntax during interviews?

Tolerant of minor typos, but zero tolerance for logical errors. You can forget a COMMIT, but not a PARTITION BY. In a debrief, an engineer said, “He wrote OVER (PARTITION date) — missing BY — but caught it when testing. We gave partial credit.” Self-correction matters. But if you don’t test, you fail — because in production, no one will clean up your cartesian products.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.