Goldman Sachs Analyst Internship Interview Experience | Complete Coding Questions & Real Interview Guide

Published : 26 April 2026

6 Views

#interview-experience

#fresher-interview

Getting an interview opportunity for an Analyst Internship role at Goldman Sachs Group, Inc. as a fresher feels exciting and stressful at the same time. Internship interviews at top companies often look simple from the outside, but once the actual process starts, you realize they test much more than just basic DSA.

I recently went through the complete interview process for the Goldman Sachs Analyst Internship interview and although I was rejected in the final round, the experience taught me a lot. In fact, this interview was far more practical and unpredictable than I expected.

This was a remote interview process and the overall timeline was around 1:2 weeks. I applied through another channel (not directly from the company website) and the process had a mix of coding, conceptual questions and one surprisingly deep technical round.

If you are preparing for the Goldman Sachs Internship interview, searching for terms like Goldman Sachs analyst internship interview experience, Goldman Sachs coding questions, Goldman Sachs intern DSA interview or how to crack Goldman Sachs internship interviews, this detailed experience can help you prepare better.

One thing I learned very clearly: Goldman Sachs does not only test coding. They test:

how clearly you explain
how well you understand fundamentals
how strong your project understanding is
how confident you stay when the interview changes direction

That last one matters more than people realize.

Let me walk you through each round in detail, along with the coding questions and optimal Java solutions.

Interview Process Overview

There were a total of 3 rounds:

Round 1 : Online Assessment (MCQs + Coding + Situation-Based Question)
Round 2 : Technical Coding Interview
Round 3 : Resume Deep Dive + Backend/System Questions

The overall difficulty was medium, but Round 3 made the experience much harder than expected.

The biggest lesson: Prepare beyond DSA your resume can become the real interview.

Round 1 : Online Assessment

The interview process started with a one-hour online assessment and even though it was the very first round, it was not something that could be taken lightly. This round was clearly designed to filter candidates quickly, so both speed and accuracy mattered a lot. Unlike regular coding tests that focus only on DSA problems, this assessment covered multiple areas together, which made it more challenging because you had to keep switching your thinking between technical concepts, coding logic and practical decision-making.

The structure of the test included multiple-choice questions, two coding questions and one situation-based question. The topics mainly covered DSA concepts like arrays, strings and graphs, along with core OOP concepts such as inheritance, polymorphism, abstraction and abstract classes. There were also logical reasoning questions and one workplace scenario based question that tested decision-making rather than coding ability.

The coding questions were moderate in difficulty. They were not extremely hard algorithmically, but the real challenge was time management. Since the assessment required moving between MCQs and coding problems, maintaining focus became difficult. Spending too much time on one coding question could negatively affect the MCQ section, while rushing through conceptual questions could lead to avoidable mistakes. That balance was one of the biggest challenges in this round.

One thing that stood out was how important the OOP questions were. Many freshers preparing for software engineering interviews spend most of their time solving coding problems on platforms like LeetCode and GeeksforGeeks, focusing heavily on arrays, linked lists, trees and dynamic programming. But in this round, concepts like polymorphism, inheritance, method overloading vs method overriding, interfaces vs abstract classes and abstraction were given serious importance. Ignoring these topics can be a big mistake because companies often treat them as basic expectations for internship and entry-level roles.

The situation-based question was also interesting because it showed that even internship hiring is not only about technical skills. The question was focused on how I would respond in a workplace scenario, something related to responsibility, prioritization or handling a professional situation. It tested whether I could think like someone working in a real team rather than just someone solving coding questions in isolation.

That part was a good reminder that companies are also evaluating professional judgment, ownership mindset and communication maturity, even at the fresher level. Strong coding skills may help you clear the technical sections, but practical thinking helps companies trust that you can work effectively in a real engineering environment.

Overall, this round was less about solving the hardest problem and more about being balanced. Good DSA knowledge, strong OOP fundamentals, clear logical reasoning and calm decision-making under time pressure mattered much more than trying to over-optimize one section. It was a strong reminder that interview preparation should never be limited to coding platforms alone.

Round 2 : Technical Coding Interview

The second round was the main technical coding interview and this was the round where problem-solving ability was tested most directly. There were two coding problems to solve in 60 minutes, but the important part was that the interviewer was not only evaluating whether I could reach the final answer. They were much more interested in how I approached the problem from the beginning.

This was a very interactive round. Before writing any code, the interviewer asked me to first explain my approach, discuss possible solutions, write rough pseudocode and do a dry run using sample test cases. Only after that was I expected to write the final optimized solution.

That structure made the round feel very different from online coding tests. Here, communication mattered as much as coding. Throughout the round, the interviewer kept asking questions like:

Can this be optimized?
What happens for edge cases?
Why did you choose this approach?

This part matters a lot because many candidates focus only on reaching code quickly, but strong interview performance usually comes from explaining thought process clearly and showing confidence in decision-making.

Problem 1: Check if Grid Satisfies Conditions

The first problem looked simple on the surface, but it was one of those questions where small mistakes can easily lead to rejection. The interviewer gave me a 2D grid and asked me to check whether it followed two specific conditions.

The first condition was that every vertically adjacent cell must have the same value.
The second condition was that every horizontally adjacent cell must have different values.

For example:

grid = [
 [1, 0, 1],
 [1, 0, 1],
 [1, 0, 1]
]

This grid satisfies both conditions because all vertical values match and all horizontal neighbors are different, so the correct output would be true.

At first glance, the problem looks extremely easy and that is exactly why it becomes dangerous in interviews. Under pressure, many candidates focus on one condition and forget the other, which leads to incorrect solutions. The interviewer was clearly checking whether I could read the problem carefully and validate conditions systematically instead of rushing.

My first thought was to avoid overcomplicating the problem. There was no need for extra data structures, no advanced algorithm and no optimization trick. The cleanest solution was simply to traverse the grid once.

For every cell, I would compare it with the cell below it to validate the vertical condition and compare it with the cell to the right to validate the horizontal condition.
If the vertical values were not equal, I would immediately return false.
If the horizontal values were equal, I would also return false.
If the full traversal completed without any violation, the answer would be true.

This gives an O(m × n) solution, which is fully optimal because every cell must be checked at least once. This problem mainly tested careful reading, matrix traversal fundamentals, edge-case handling and implementation clarity. Sometimes the simplest-looking problems are actually the most dangerous because they punish carelessness.


public class GridConditions {

    public boolean satisfiesConditions(int[][] grid) {
        int m = grid.length;
        int n = grid[0].length;
        for (int i = 0; i < m; i++) {
            for (int j = 0; j < n; j++) {
                if (i + 1 < m && grid[i][j] != grid[i + 1][j]) {
                    return false;
                }
                if (j + 1 < n && grid[i][j] == grid[i][j + 1]) {
                    return false;
                }
            }
        }
        return true;
    }
}

Problem 2: Minimize Maximum Value in a Grid

The second problem was more interesting because it was based on optimization thinking rather than direct implementation. The interviewer described a scenario where values inside a grid had to be adjusted or redistributed so that the maximum value became as small as possible.

This type of problem is common in companies like Goldman Sachs because it tests whether candidates can move beyond brute force and recognize hidden optimization patterns. The exact constraints depended on redistribution rules, but the real challenge was not syntax. It was identifying the right direction.

My first instinct was to think about brute force trying all possible redistributions and checking which arrangement gives the smallest maximum value. But that idea breaks immediately for large constraints. Too many combinations. Too much unnecessary work. Clearly not acceptable for an interview.

That is when the interviewer gave a small hint by asking: Can you think of a way to reduce the search space?

That usually signals a binary search problem. The key insight here was understanding monotonicity. If a maximum value X is achievable, then any larger value than X will also be achievable. That creates a monotonic condition. And whenever a problem gives a monotonic true/false condition, Binary Search on Answer becomes a strong possibility.

This is a very common Goldman Sachs interview pattern. Instead of searching for the final arrangement directly, we binary search the answer itself. We choose a middle value mid and ask: Is it possible to keep all values ≤ mid under the given rules?

If yes, we try smaller values.
If no, we move toward larger values.

This dramatically reduces complexity and shows strong optimization thinking.

The interviewer cared much more about this reasoning than the exact implementation because the isPossible() logic depends on the exact constraints of the original problem. That was the real evaluation. This problem mainly tested optimization thinking, recognizing binary search patterns, reducing brute force approaches and clearly explaining trade-offs. Even if the final implementation changes, the thought process matters most.


public class MinimizeMaxGrid {

    public int minimizeMaximum(int[][] grid) {
        int left = 0;
        int right = 1000000000;
        while (left < right) {
            int mid = left + (right - left) / 2;
            if (isPossible(grid, mid)) {
                right = mid;
            } else {
                left = mid + 1;
            }
        }

        return left;
    }

    private boolean isPossible(int[][] grid, int maxValue) {
        // depends on actual constraints
        return true;
    }
}

This round taught me something very important:

Interviewers are not only hiring someone who can write code.
They are hiring someone who can think clearly, explain decisions confidently and stay calm when pushed with follow-up questions.
For the first problem, success came from careful reading and avoiding silly mistakes.
For the second problem, success came from recognizing patterns and explaining optimization logic instead of forcing brute force.

That balance between clarity and reasoning is what makes a strong technical interview performance.

Round 3 : Resume Deep Dive + Unexpected Backend Questions

Honestly, this was the most surprising round of the entire interview process. I went into this round expecting another DSA interview because almost everyone I had spoken to before the interview mentioned the same pattern—after the coding rounds, they usually had another technical round focused on algorithms or problem solving. So naturally, I prepared the same way. I revised common DSA patterns, practiced problem-solving explanations and expected another whiteboard-style coding discussion. But the moment the interview started, I realized this round was going in a completely different direction.

The interviewer opened my resume, looked at it carefully and instead of asking a coding question, started drilling deeply into almost every project and technology I had mentioned. That instantly changed the entire interview. It no longer felt like an internship interview. It felt like I was being interviewed for a backend engineer role. And honestly, that shift was a little unsettling because it was not what I had prepared for.

The discussion quickly moved into areas like: Java standard libraries, networking concepts, Docker, CI/CD, backend development, project architecture, APIs, database choices, even basic system design discussions

This was much deeper than I expected. The interviewer was not satisfied with surface-level answers. Every answer triggered another why.

For example, when discussing one of my projects, they asked: Why did you choose this database? At first, I gave a normal answer about performance and familiarity. But that was not enough. The follow-up came immediately: Why not another database? What trade-offs did you consider? That is where the real interview started. They wanted reasoning, not just statements. Another question was: How does Docker help deployment? This was not just about defining Docker. They wanted practical understanding.

How does containerization solve real deployment issues?
How does it help consistency across environments?
What changes between local development and production?

Similarly, they asked: What happens inside a CI/CD pipeline? Again, this was not a textbook definition question. They wanted to know whether I actually understood build stages, testing flow, deployment automation, rollback thinking and how production releases are managed.

Then came project architecture questions like: How does your project handle failures? That one really stood out. Because it forced me to think beyond features.

What happens if an API fails?
What happens if the database becomes slow?
What happens if external dependencies break?

These are the kinds of questions backend engineers deal with in real production systems.

The interviewer also asked about Java standard library usage: What standard library classes did you use and why? This sounds simple, but it was actually testing whether I understood my own implementation decisions.

Why HashMap instead of TreeMap?
Why ArrayList instead of LinkedList?
Why certain concurrency utilities?

These details matter more than many freshers realize. Honestly, this round left me a little rattled. Not because the questions were impossible, but because I had prepared mostly for DSA-style interviews and suddenly found myself defending backend architecture decisions from old projects. That mental switch is hard during a live interview.

You start realizing very quickly whether you truly understand what you wrote on your resume or whether you only remember the surface-level version. That was the biggest lesson from this round.

Your resume is not just a document.
Your resume is your question paper.

If you write something there, you must be ready to defend it deeply.

Not just what you built, but why you built it that way.
Not just what tools you used, but why you chose them.
Not just what worked, but what broke and how you handled it.

That is something many freshers underestimate. Especially for internship interviews, people assume only DSA matters. But if your resume strongly points toward backend projects, APIs, Docker, databases or deployment work, the interview can quickly become backend-heavy. And in that moment, preparation strategy changes completely. That was the biggest learning for me.

Final Result : Rejected

In the end, I was rejected. Yes, it felt disappointing. Especially because the final round was so unexpected.

Honestly, it felt a little unfair at first because many other candidates had standard DSA rounds, while mine turned into a backend deep dive that I had not fully prepared for. That feeling is natural. When you compare your interview path with others, rejection feels even harder. But interviews are unpredictable. And sometimes that unpredictability itself is the lesson. After reflecting on it, I realized the rejection showed me exactly where I needed improvement.

I needed stronger backend fundamentals.
I should have revised my projects much more deeply instead of only preparing DSA.
I needed more confidence when the interview direction suddenly changed.

Because real interviews do not always follow the expected script. Sometimes the strongest preparation is not solving one more coding problem. Sometimes it is understanding your own work better.

That round taught me more than many successful interviews probably would have. And honestly, sometimes rejection gives the best preparation for the next opportunity.