Interview Experience | Engineering New Analyst | π₯π₯ | Goldman Sachs Bellevue
2027 New Grad Full-time @ Goldman Sachs Bellevue Engineering β applied online β HackerRank + Superday | π Positive | Medium | Pending
I applied to the new Engineering office in Bellevue.
When I first saw how much they talk about AI and cloud transformation, I assumed the loop would have a lot of AI infra or ML in it. It did not. It stayed a conventional software engineering loop: coding, database, project, and BQ.
There was a HackerRank and a video interview first, then Superday. My Superday was three rounds.
HackerRank
Two coding questions.
Q1 β meeting rooms. Given a set of meeting intervals, first check whether anything overlaps, then find the minimum number of rooms needed. I used a min heap. The question itself was not hard. There were a few test cases after I finished, and the thing to watch was the interval boundaries.
Q2 β graph, topological sort. I don't fully remember the prompt. The first part was BFS with an indegree count. Then the follow-up was: what if you need to output all possible topological orders? I did not finish writing that one. I said DFS with backtracking β each time pick one of the nodes with indegree zero and recurse from there.
Overall the HackerRank was more normal than I expected. Nothing especially Goldman-specific.
Superday Round 1 β Coding
The interviewer was friendly. We spent five minutes on my resume, then started coding.
The question was LRU Cache. Implement get and put with O(1). I had practiced this one: hashmap plus doubly linked list.
After I finished, the interviewer looked at it and asked: what if multiple threads read and write this cache at the same time?
My first answer was to add a read/write lock. Then he asked: is get really a read?
I paused there. LRU's get does not change the value, but it moves the node to the front, so it does modify the linked list. We talked about locking for a while after that. I started out overcomplicating it, trying to split a read lock and a write lock, and then realized that in this implementation most of the operations change recency anyway. I ended up saying that if correctness comes first, one mutex is more direct.
That was the only question in the round. No second LeetCode. The interviewer seemed to care more about whether the code was clean, and whether I knew where my own data structure breaks under concurrency.
Superday Round 2 β Backend / Database
They did not ask me to design a large system. The prompt was flight ticket booking.
First I walked through the flow: a user searches flights, picks a ticket, pays, and the booking succeeds. I started talking about how to split the services and the interviewer quickly pulled it to the database.
What indexes to build? Users usually query flights by origin / destination / date, so how would the index be built. Then a bit of B-tree β not deep, mostly why database indexes usually use a B/B+ tree and how the lookup walks it.
The longest part was: how do you avoid double booking? Say there is one seat left and two people click at the same time.
I said transaction first, and he immediately asked: what if both of them have already read available? From there we talked about row locks, optimistic locking, and conditional update.
I mentioned holding the seat for a short period. He asked: what if payment is slow, the seat hold has already expired, but a payment callback succeeds afterwards? I was not smooth here. I said roughly that booking and payment should each have their own state, and that payment success should not be treated as booking success. If the seat has already been released, it may need a refund or a compensation path.
The last one was retries. A client times out and sends the booking request again β how do you avoid creating a duplicate? That is an idempotency key.
This was the hardest of the three rounds, because the prompt looked ordinary and it kept pushing further into transaction and concurrency.
Superday Round 3 β Project + BQ
Almost no code in this round.
They had me pick a past project. Mine mentioned Kafka, so the interviewer followed up on it: how partitions are assigned, what a consumer group is, when a rebalance happens. One question I remember clearly: a consumer has already finished processing a message but dies before committing the offset β what happens? I said the message gets consumed again, so downstream should make itself idempotent. He did not go deeper into Kafka internals, and moved on to BQ.
One question fit the direction of this new Bellevue office: do you use GenAI to work faster? I talked about using AI to read code, write tests, and handle repetitive work. He did not let it pass at that. He asked: how do you confirm that what the AI generated is correct? I said I would not merge generated output straight into production code β tests, review, and checking the important edge cases myself.
Then normal BQ. How do you set priorities under a tight deadline, and a time I disagreed with a manager or a teammate. I had prepared the disagreement story, so that one went fine. The GenAI part I had not prepared, and it came out scattered.
They closed with why Goldman / why Bellevue. I did not force the finance angle. I said Bellevue is a new engineering hub and is clearly expanding cloud and AI engineering, which is close to the direction I want to work in.
Overall
It was much more normal than I expected. The Bellevue office leads with AI and cloud, but they did not suddenly start testing model internals.
Coding was common questions. The database round is the one most likely to keep getting pushed.
What I would prepare: for LRU-type questions, besides being able to write it, think about concurrency while you are there. For system design you do not have to memorize some large architecture β transactions, indexes, and locking are the basics that are easy to keep following up on. BQ is not just reciting STAR either. I said I used GenAI and he immediately asked how I validate it; I said I disagreed with a teammate and he asked who decided in the end and how it turned out.
Still waiting on the result.