Goldman Sachs

# Goldman Sachs Interview Experience — Detailed Round-wise Breakdown ## Overview The interview process consisted of **three rounds**: **Round 1 — Technical + Project + DSA** **Round 2 — Deep Technical + System Design + DSA** **Round 3 — HR / Behavioral** The interview was heavily focused on the projects mentioned in the resume. The interviewers did not restrict themselves to high-level project explanations; they went deep into the **architecture, technology choices, implementation details, failure scenarios, security, RAG pipeline, Redis, RabbitMQ, and authentication**. DSA was also tested progressively, starting from a medium-level problem and moving toward a harder variant. -- # ROUND 1 — Technical + Project + DSA ## 1. Introduction The round started with a standard introduction. A good introduction should briefly cover: Name and academic background Relevant technical interests Major projects Strong DSA/competitive programming background Technologies relevant to the role The important point is to keep the introduction concise because the interviewer generally uses it to decide which projects or technologies to explore further. -- # 2. Project Discussion After the introduction, the interviewer moved directly to the projects mentioned on the resume. The discussion was **resume-driven**, meaning every technology or feature mentioned in the resume could become a potential interview question. The major areas discussed were: ### A. Project Architecture The interviewer wanted to understand: What problem does the project solve? Why was the project built? What is the overall architecture? What happens when a user sends a request? Which service handles the request? Where is the database involved? Where does the AI/RAG pipeline come into the architecture? How do different services communicate? A strong explanation should follow the request flow instead of explaining technologies independently. For example: *User → Frontend → Backend API → Authentication → Business Logic / Agent → RAG / External Service → Database / Cache → Response** This gives the interviewer a clear mental model of the system. -- # 3. RabbitMQ Notification System One of the important project-specific discussions was the **RabbitMQ-based notification system**. The interviewer was interested in why RabbitMQ was used rather than directly processing notifications inside the main request. The basic architecture can be explained as: *Application Service → RabbitMQ → Queue → Notification Consumer → Notification Service → User** ### Why RabbitMQ? RabbitMQ allows notification processing to be decoupled from the main application. For example, suppose a user performs an operation that requires a notification. Instead of: *Request → Generate Notification → Send Notification → Response** the application can do: *Request → Publish Message → Response** and a consumer processes the message asynchronously. ### Benefits Asynchronous processing Loose coupling Better scalability Improved reliability Message buffering Independent scaling of consumers Better handling of traffic spikes ### Important follow-up questions The interviewer can go deeper with: What happens if the consumer goes down? What happens if RabbitMQ goes down? How do you avoid losing messages? What is acknowledgement? What happens when message processing fails? How do retries work? What happens if the same message is processed twice? How would you implement dead-letter queues? A strong answer should mention: *Acknowledgements + durable queues + persistent messages + retry mechanism + dead-letter queue + idempotent consumers.** -- # 4. RAG Pipeline Discussion The interviewer also discussed the **RAG pipeline** implemented in the project. The basic flow is: *Documents → Parsing → Chunking → Embeddings → Vector Database → Retrieval → Context → LLM → Final Answer** The interviewer may ask why RAG was required instead of directly asking the LLM. The key explanation is: > LLMs may not have access to private, domain-specific, or frequently changing information. RAG retrieves relevant information from an external knowledge base and provides it to the LLM as context before generating the answer. ### Important components #### Document ingestion Documents are collected and processed. #### Chunking Large documents are divided into smaller pieces. #### Embedding Each chunk is converted into a vector representation. #### Vector database Embeddings are stored so that semantically similar information can be retrieved later. #### Retrieval The user query is converted into an embedding and compared with stored vectors. #### Generation Retrieved chunks are passed to the LLM as context. -- # 5. DSA — LeetCode 139: Word Break The first DSA problem was **Word Break — LeetCode 139**. The interviewer was testing dynamic programming and string decomposition. The natural DP definition is: *dp[i] = whether the prefix s[0...i-1] can be segmented into valid dictionary words.** For every position `i`, check possible previous positions `j`. If: `dp[j] == true` and `s[j...i-1]` exists in the dictionary, then: `dp[i] = true`. ### Complexity With a hash set for dictionary lookup: Time: approximately **O(n²)** substring checks Space: **O(n + dictionary size)** The interviewer may also ask for: Memoization Tabulation Why 1D DP is sufficient Why a 2D DP is unnecessary -- # 6. LeetCode 140 — Word Break II Immediately after Word Break I, the interviewer moved to the harder variant: *Word Break II** This tests whether the candidate can extend a DP idea into actual reconstruction. Here, instead of answering whether segmentation is possible, we need to **return all possible sentences**. A useful state is: *solve(index) = all valid sentences that can be formed from index onward.** For every dictionary word matching the current prefix: Choose the word. Recursively solve the remaining suffix. Append the current word to every returned sentence. Memoization is extremely important because the same suffix can be encountered through multiple paths. ### Important observation Word Break I asks: > "Is there at least one valid segmentation?" Word Break II asks: > "What are all valid segmentations?" Therefore, Word Break II can have **exponential output size**, so the overall complexity cannot be polynomial in the size of the output alone. -- # 7. Heap-Based Simple Question The round ended the DSA portion with a relatively simple heap-based question. The interviewer was likely checking: Understanding of priority queues Min heap vs max heap C++ STL priority_queue Choosing the correct heap based on the required ordering Complexity of insertion/deletion Important complexity: Insert: **O(log n)** Remove top: **O(log n)** Access top: **O(1)** -- # ROUND 2 — Deep Technical + System Design + DSA Round 2 was considerably deeper. The interviewer again started with the project and then expanded into general backend, security, distributed-system, and data-structure concepts. -- # 1. Explain the Project The project was again asked to be explained. However, unlike Round 1, the interviewer was more interested in **technical depth**. The explanation should therefore move from: *Problem → Architecture → Components → Data Flow → Technology Choices → Failure Handling → Scalability** For every major technology, you should be prepared to answer: > "Why did you use it?" -- # 2. RAG — Chunking The interviewer asked general RAG questions, beginning with chunking. ### What is chunking? Chunking means dividing a large document into smaller pieces before generating embeddings. A document that is too large cannot always be efficiently retrieved or passed to an LLM. Example: ```text Large Document ↓ Chunk 1 Chunk 2 Chunk 3 Chunk 4 ↓ Embeddings ↓ Vector Database ``` ### Why chunking matters Poor chunking can reduce retrieval quality. If chunks are too large: Retrieval becomes less precise Irrelevant information may be included Context becomes unnecessarily large If chunks are too small: Important context may be lost Individual chunks may not contain enough information Therefore, chunk size and overlap must be selected according to the document structure and use case. -- # 3. Semantic Search Semantic search was another important RAG topic. Traditional keyword search looks for matching words. Semantic search instead tries to understand the **meaning** of the query. For example: ```text Query: "What fertilizer should I use for wheat?" Retrieved document: "Recommended nutrient requirements for wheat cultivation..." ``` Even if the exact words do not match, embeddings can identify that the two pieces of text are semantically related. ### Basic flow *Query → Embedding → Vector Similarity → Top-K Documents → LLM** Common similarity measurements include: Cosine similarity Dot product Euclidean distance -- # 4. JWT Authentication and Authorization The interviewer then moved to authentication. ### JWT JWT stands for **JSON Web Token**. A typical JWT consists of: ```text Header.Payload.Signature ``` After successful authentication, the server generates a token. The client sends it with subsequent requests: ```text Authorization: Bearer ``` The backend validates the token before allowing access to protected resources. -- # 5. Authentication vs Authorization This distinction is extremely important. ### Authentication Answers: > "Who are you?" Example: Logging into the application. ### Authorization Answers: > "What are you allowed to access?" Example: A normal user should not be able to access an admin endpoint. -- # 6. Common Security Attacks The interviewer asked about common attacks and their safety measures. Important attacks to prepare: ### SQL Injection Attacker tries to inject malicious SQL into user input. *Protection:** Parameterized queries Prepared statements ORM/query builders Input validation ### XSS Attacker injects malicious JavaScript into content displayed to users. *Protection:** Output encoding Input sanitization Content Security Policy Avoid unsafe HTML rendering ### CSRF An attacker tricks an authenticated user's browser into performing an unwanted action. *Protection:** CSRF tokens SameSite cookies Proper origin/referrer validation ### Brute Force Repeatedly trying passwords or OTPs. *Protection:** Rate limiting Account lockout/throttling Strong password policy MFA/OTP ### Session / Token Theft An attacker obtains a valid authentication token. *Protection:** HTTPS Short-lived access tokens Refresh-token rotation Secure storage Token revocation/replay detection -- # 7. Redis The interviewer then asked: > What is Redis? Redis is an **in-memory key-value data store** commonly used for caching, sessions, counters, rate limiting, queues, and temporary data. The important follow-up question was: > What are you storing in Redis? A good project-specific answer could include: Frequently accessed data Session information Temporary authentication data Rate-limit counters Cached API responses Short-lived application state The key point is to clearly distinguish **persistent data** from **temporary/cache data**. -- # 8. What Happens if Redis Goes Down? This is an important system-design scenario. The answer depends on what Redis is being used for. ### If Redis is only a cache The application should continue functioning. The flow becomes: *Request → Redis miss/unavailable → Database → Response** The system becomes slower but should remain available. ### If Redis stores critical session/state information Then the impact is much larger. Therefore, critical persistent information should generally not exist only in Redis. Possible measures include: Redis replication Redis Sentinel / Cluster Persistence where appropriate Database fallback Graceful degradation Timeouts and circuit breakers The most important principle is: > Redis should not become an unnecessary single point of failure. -- # 9. Modular Architecture The interviewer presented a situation involving a modular architecture and asked about its benefits and disadvantages. ### Benefits Separation of concerns Easier maintenance Independent development Easier testing Better scalability Easier replacement of components Reduced coupling For example: ```text Authentication Module | Crop Module | Market Module | Notification Module | AI Module ``` Each module has a defined responsibility. ### Disadvantages More complexity More interfaces to maintain Communication overhead Debugging can become harder Deployment can become complicated if modules become independent services Poor module boundaries can create unnecessary coupling The key insight is: > Modularity improves maintainability, but excessive modularization can introduce unnecessary complexity. -- # 10. DSA — Median from a Stream The interviewer then asked: > Given a continuous stream of numbers, return the median at any point. The standard solution uses **two heaps**. ### Heap 1 — Max Heap Stores the smaller half of the numbers. ### Heap 2 — Min Heap Stores the larger half. ```text Numbers | --------------- | | Max Heap Min Heap smaller half larger half ``` Maintain the invariant: ```text size(maxHeap) == size(minHeap) ``` or ```text size(maxHeap) = size(minHeap) + 1 ``` The median becomes: ### Odd number of elements ```text maxHeap.top() ``` ### Even number of elements ```text (maxHeap.top() + minHeap.top()) / 2 ``` ### Complexity For each insertion: *O(log n)** Median query: *O(1)** Space: *O(n)** The interviewer first asked for **pseudocode**, then moved to the actual **heap implementation**. This indicates that the interviewer was checking both algorithmic thinking and implementation knowledge. -- # 11. Dijkstra A standard medium-level Dijkstra problem was then asked. The important concepts to explain are: Weighted graph Non-negative edge weights Distance array Min heap / priority queue Relaxation Core relaxation: ```text if dist[u] + weight < dist[v] dist[v] = dist[u] + weight ``` The priority queue stores: ```text (distance, node) ``` The smallest distance is processed first. ### Complexity Using an adjacency list and min heap: *O((V + E) log V)** Dijkstra does not work correctly with negative edge weights. -- # 12. Map Implementation The interviewer then asked for implementation-level understanding of a map. This tests knowledge beyond simply using: ```cpp unordered_map ``` or ```cpp map ``` The candidate should understand that a map can be implemented using different underlying data structures. ### Ordered map Typically implemented using a balanced BST. Operations: Search: O(log n) Insert: O(log n) Delete: O(log n) ### Hash map Uses a hash table. Average: Search: O(1) Insert: O(1) Delete: O(1) Worst case can become O(n), depending on collisions and implementation. -- # 13. AVL Tree An AVL tree is a **self-balancing Binary Search Tree**. For every node: ```text Balance Factor = height(left subtree) - height(right subtree) ``` The balance factor must remain: ```text 1, 0, +1 ``` If it becomes unbalanced, rotations are performed. Four major cases: LL → Right rotation RR → Left rotation LR → Left rotation + Right rotation RL → Right rotation + Left rotation Operations remain: *O(log n)** -- # 14. Red-Black Tree The interviewer also asked about Red-Black Trees. A Red-Black Tree is another self-balancing BST. Each node is assigned a color: ```text Red Black ``` The tree follows balancing properties that prevent it from becoming highly skewed. Its height remains: *O(log n)** Therefore: Search → O(log n) Insert → O(log n) Delete → O(log n) -- # 15. AVL vs Red-Black Tree A common follow-up is to compare them. | Feature | AVL Tree | Red-Black Tree | | ------------- | ----------------------- | ----------------------------- | | Balancing | More strictly balanced | Less strictly balanced | | Search | Very efficient | Efficient | | Insert/Delete | More rotations possible | Generally fewer rotations | | Height | Smaller | Slightly larger | | Good for | Read-heavy workloads | Insert/delete-heavy workloads | A useful interview statement is: > AVL trees maintain stricter balance, so they can provide better lookup performance, while Red-Black Trees generally require less restructuring during insertion and deletion. -- # ROUND 3 — HR / Behavioral Round 3 was primarily an HR round. Unlike the previous two rounds, the focus was not on DSA or implementation details. The interviewer focused on: Motivation Teamwork Project ownership Decision-making Communication Career motivation Company interest -- # 1. Why Did You Make This Project? The interviewer wants to know whether the project was actually yours or simply something copied from a tutorial. A strong answer should cover: *Problem → Motivation → Solution → Impact** Example structure: > "I identified a practical problem where users had to rely on multiple disconnected sources. I wanted to build a single platform that could combine intelligent recommendations with relevant external information. This led me to design the project using an agent/RAG-based architecture." The answer should demonstrate **personal ownership**. -- # 2. How Did You Communicate With Your Teammates? This question evaluates teamwork. A good answer should explain: How tasks were divided How responsibilities were assigned How progress was tracked How disagreements were handled How code was integrated How communication was maintained A strong structure is: ```text Requirement ↓ Task Division ↓ Individual Ownership ↓ Regular Updates ↓ Code Review ↓ Integration ↓ Testing ``` Mentioning Git/GitHub, pull requests, issue tracking, regular discussions, and code reviews can make the answer more concrete if those were actually used. -- # 3. How Did You Decide the Technology Stack? This is a very important project question. Avoid saying: > "We selected React because it is popular." Instead explain the decision based on requirements. For example: ### Frontend React was selected for a component-based UI and efficient development. ### Backend FastAPI/Node.js can be selected based on API requirements, asynchronous operations, ecosystem, and integration needs. ### Database PostgreSQL is appropriate when relational consistency and structured data are important. ### Redis Used for caching and temporary high-frequency data. ### RabbitMQ Used for asynchronous communication and notification processing. ### RAG Used when the system needs domain-specific or external knowledge. The best technology-choice answers always follow: *Requirement → Constraint → Technology → Reason** -- # 4. What Difficulties Did You Face? The interviewer wants to hear about actual engineering problems. Possible categories include: ### Technical difficulties Integrating multiple services Authentication RAG retrieval quality API failures Database integration Asynchronous processing Deployment problems ### Team difficulties Dividing responsibilities Merging code Different implementation approaches Communication gaps ### Solution Always follow: *Problem → Why it happened → What you tried → Final solution → Learning** Do not simply say: > "We faced some bugs but solved them." Instead, explain one concrete engineering problem deeply. -- # 5. What Excites You About Goldman Sachs? This was the final motivational question. The answer should not be limited to: > "Goldman Sachs is a reputed company." A stronger answer connects the company with your technical interests and career goals. A good structure is: ### Technology Interest in building reliable, scalable systems. ### Problem complexity Financial systems operate at significant scale and require correctness, performance, and reliability. ### Learning Opportunity to work with experienced engineers and production-grade systems. ### Impact Interest in solving problems where software engineering has direct business impact. ### Growth Opportunity to develop both technical depth and understanding of large-scale engineering practices. A concise answer could be: > "What excites me about Goldman Sachs is the combination of strong engineering and high-impact problem solving. I am particularly interested in working on systems where scalability, reliability, security and correctness matter significantly. My projects have given me exposure to distributed systems, AI pipelines, authentication and backend architecture, and I would like to take that experience into a production environment while learning from engineers working on large-scale financial systems." -- # Overall Interview Pattern The most important observation from all three rounds is that the interview was **progressively deeper**. ### Round 1 ```text Resume ↓ Project ↓ RabbitMQ ↓ RAG ↓ Word Break ↓ Word Break II ↓ Heap ``` ### Round 2 ```text Project ↓ RAG ↓ Chunking ↓ Semantic Search ↓ JWT ↓ Security Attacks ↓ Redis ↓ Failure Scenarios ↓ Modular Architecture ↓ Median from Stream ↓ Heap Implementation ↓ Dijkstra ↓ Map ↓ AVL ↓ Red-Black Tree ``` ### Round 3 ```text Project Motivation ↓ Teamwork ↓ Technology Decisions ↓ Challenges ↓ Goldman Sachs Motivation ``` # Key Preparation Areas Based on this interview pattern, the highest-priority preparation topics are: ### Projects Complete architecture Request/response flow Database schema Technology choices Failure handling Scalability Trade-offs Authentication Caching Messaging RAG pipeline ### RAG Chunking Chunk overlap Embeddings Vector databases Semantic search Similarity metrics Retrieval Top-K Reranking Hallucination Context window RAG vs fine-tuning ### Backend/System Design Redis RabbitMQ Caching Queues Retry Dead-letter queues Idempotency Rate limiting Modular architecture Microservices Failure handling ### Security JWT Authentication vs authorization XSS CSRF SQL injection Brute force Token theft Refresh-token rotation HTTPS Rate limiting MFA ### DSA The interview particularly emphasized: Dynamic Programming Word Break Backtracking + Memoization Heaps Two heaps Graphs Dijkstra Hash maps BST AVL Trees Red-Black Trees The biggest lesson is that **resume projects were not treated as a formality**. Every technology written on the resume could lead to implementation-level and failure-scenario questions. Therefore, for each project technology, preparation should cover four levels: *What is it? → Why did you use it? → How did you implement it? → What happens when it fails?**