Goldman Sachs Software Engineer Interview Questions
Software engineers at an investment bank build the logic close to the business: checks that stop an order that breaks a limit, code that puts a value on a bond or an option, and overnight runs that measure how a portfolio would behave in a crisis. Prepare to design these out loud, explain trade-offs between speed and safety, and describe how you work with traders, bankers and risk teams. What to show here: sound engineering judgment explained clearly to the business. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Goldman Sachs hires, in its own words, and its questions for every job →
1. Tell me about a time you explained a technical risk to someone on the business side and it changed their decision.
- Describe the decision and the risk you saw.
- Explain how you put it in business terms.
- Show the options you offered.
- Share what was decided and the result.
“A business lead wanted to start a new calculation for all clients on one day. I saw a risk: the calculation depended on a data feed that arrived late about once a week, and on those days the figures would be wrong without anyone noticing. I did not talk about feeds. I said that roughly one morning a week, clients would see yesterday's numbers marked as today's. I offered two options: wait for a check on the feed, or start with a small group. He chose the small group. We found the problem in the first week, and your result.”
Weak answers use technical terms the listener could not follow, or stayed silent because the decision belonged to someone else.
2. Describe a code review, given or received, where a reviewer caught something that would have produced a wrong figure. What did the team change afterwards?
- Describe the change under review.
- Explain what was caught and why tests missed it.
- Show how you responded.
- Share the change to the process.
“I submitted a change that converted amounts between currencies. My tests passed. A reviewer asked which day's rate I used for trades booked late in the evening, and I realised I used the rate for the day the code ran, not the trade date. It would have been wrong only around midnight, which is why the tests missed it. I thanked her, fixed it and added tests around the date boundary. We then added a question to our review checklist: which date does each figure depend on? Since then, your result. I now ask that question myself.”
Weak answers treat review as a formality, or became defensive when the mistake was found.
3. Every order must be checked against risk limits before it goes to the market, and the check must add almost no delay. How would you design it?
- Define the limits: order size, position, price bands, per client or desk.
- Keep limits and current positions in memory.
- Update positions from orders and fills as they happen.
- Refuse the order if the check cannot be completed.
“I would place the check in the order path, as a component that holds limits and current exposure in memory, so that each check is a few comparisons with no database call. Limits load at the start and update through a controlled channel. Exposure is updated as orders are sent and filled, counting open orders as if they will fill. Checks cover order size, resulting position and a price too far from the market. If the component cannot decide, for example because its state is out of date, the order is refused and not let through. Every refusal is logged with its reason.”
Weak answers call a database for each order, or allow orders through when the check is unavailable.
4. You need code that puts a value on bonds today, and on options and other instruments later. How would you structure it so a new instrument can be added without touching the old ones, and how would you test it?
- Separate the instrument data from the pricing method.
- Define a common interface for pricing.
- Pass market data in and never fetch it inside.
- Test against known values and simple limits.
“I would separate what an instrument is from how it is priced. Each instrument type is a plain data object. Each pricing method follows one interface that takes an instrument and a set of market data and returns a value. A new instrument means a new data type and a new pricer, registered in one place, with no change to bond code. Market data is always passed in, so that the same inputs give the same output. For testing I would use cases with values worked out by hand, check simple truths such as a bond being worth less when rates rise, and compare with the previous version.”
Weak answers build one large function with a branch for each instrument, or fetch live prices inside the calculation so results cannot be repeated.
5. Each night the bank revalues a very large portfolio under many what-if market scenarios, and the run must finish before morning. How would you make it fast enough?
- Split the work into independent pieces by position and scenario.
- Spread the pieces across many workers.
- Reuse shared results and avoid repeated work.
- Retry failed pieces and track progress against the deadline.
“Valuing one position under one scenario does not depend on any other, so the work splits cleanly. I would cut it into tasks and hand them to a pool of workers across many machines, with similar positions grouped so that shared inputs are loaded once. Results that many tasks need, such as a rate curve for a scenario, are calculated once and cached. If a worker fails, only its tasks are run again. I would run the most important portfolios first and show progress against the deadline, so that a late run is seen at midnight and not at dawn.”
Weak answers speed up a single loop on one machine, or restart the whole run when one piece fails.
6. Bankers advising a company on a private deal hold information that people on the trading side must not see. How would you design access control for deal documents to enforce that?
- Deny by default and grant access deal by deal.
- Tie access to a named deal team with an approver.
- Log every access and review the logs.
- Limit what support staff and engineers can see.
“I would begin from no access at all. Each deal has a named team, and a person joins it only when a responsible approver adds them, with a record of who approved and when. Access is checked on the server for every request, by deal, not by department. When someone leaves the team, access ends at once. Every open, download and search is logged, and those logs are reviewed for unusual patterns. Engineers and support staff are users too. They should work with masked or test data, and any emergency access is time limited, approved and logged.”
Weak answers grant access by department or job title, or forget that administrators can read everything.
7. Why do you want to work as an engineer close to traders, bankers and risk teams, and why Goldman Sachs?
- Say why working close to the business appeals to you.
- Name the problems that interest you.
- Connect them to what the firm does.
- Say what you want to learn.
“I do my best work when I understand why the software exists. At an investment bank the engineer sits close to the people who use the system, and the feedback is quick and honest. The problems interest me too: a limit check that must be both fast and safe, or a valuation that must be exactly repeatable. Goldman Sachs is known for markets and for advising on deals, so both kinds of problem are present. I have worked on your project, and I want to learn enough about the products that I can question a requirement, not only build it.”
Weak answers want to be left alone to code, or cannot name any problem particular to a bank.
8. Markets move sharply on unexpected news and the number of messages reaching your service grows many times over. It starts to fall behind. What do you do in the moment, and what do you change afterwards?
- Confirm that the service is behind and by how much.
- Drop or delay low-priority work to protect the critical path.
- Add capacity if that is safe and keep users informed.
- Afterwards, test against the worst day and design for overload.
“First I would measure the lag, that is, how old the messages are that we are processing now. Then I would protect what matters most. Orders and risk updates come first, while reports and less urgent work are paused. If prices are queued, I would keep only the latest for each instrument and not work through old ones. I would tell users that the data is delayed, so that nobody trusts a stale figure. Afterwards I would replay that day's traffic in a test, find the bottleneck and design how the service reduces its load in a planned way.”
Weak answers restart the service and lose its state, or treat every message as equally important.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.