Goldman Sachs Hackerrank Questions 2022

What These Assessments Actually Look Like

Goldman Sachs Hackerrank Questions 2022

I sat through one of these in 2022. The interface is the standard HackerRank dark layout. You get maybe 60 to 90 minutes. Four coding problems, numbered one through four, with difficulty ramping from easy to genuinely hard. The first one is usually something like string manipulation or a simple two-pointer problem. The last one is typically dynamic programming or graph traversal, and that's where most candidates run out of time. There's no discussion board during the test. No external references. Just your IDE and a terminal. What I found unusual compared to other banks' assessments is how much they lean on Python-specific quirks. Memory limits are tight on HackerRank for Goldman Sachs runs, which means recursive solutions hit recursion depth errors faster than you'd expect. I learned this the hard way on a tree traversal question where a standard DFS approach gave me Runtime Error on a 1,000-node test case. I switched to an iterative solution using an explicit stack and it passed immediately. Don't trust recursion unless the tree is shallow or you can do sys.setrecursionlimit(10000) at the top of your file. The questions fall into recognizable buckets. Array and string problems show up almost every time. Two-pointer techniques, sliding windows, and hash map lookups are the standard toolkit. Dynamic programming questions include knapsack variants, longest common subsequence patterns, and sometimes edit distance or partition problems. Graph questions cover BFS and DFS traversal, cycle detection, and occasionally shortest path on small weighted graphs. You'll also see some math-heavy problems involving GCD, prime factorization, or combinatorics with modular arithmetic. Binary search on answer is another pattern that comes up more often than people expect.

Here's a specific edge case I hit during the 2022 assessment that almost cost me the pass. The problem asked me to find the minimum window substring containing all characters from a target string, but one of the hidden test cases included a target with duplicate characters where the input string was significantly larger but had the duplicates spread far apart. My initial sliding window implementation checked character presence instead of character count, so it failed that case. The fix was straightforward — use a Counter for the target and track how many characters I still needed to fulfill, decrementing a remain counter as I expanded the window and incrementing it as I shrank. It added maybe three lines of code but covered the hidden test I was missing. If you're prepping for Goldman Sachs Hackerrank Questions 2022 or anything similar, practicing with Counter-based sliding windows is worth more time than you'd initially think. The time limit is usually around 2 seconds per test case. Python solutions need to be more careful about I/O speed than you might expect. The input() and print() functions add overhead that compounds across many test cases. I started using sys.stdin.readline and building output strings with join instead of printing inside loops. That alone cut my average runtime on multi-testcase problems from 1.8 seconds down to about 0.4 seconds on the same code. It's not a language preference thing, it's just how Python works under the hood on HackerRank's server setup. One thing the Goldman Sachs questions don't do well is test language selection honestly. They tell you you can pick Python, Java, C++, or JavaScript, but Python gets slightly tighter memory and time margins than the others because the test infrastructure runs on CPython with default settings. Java and C++ solutions sometimes pass edge cases that timeout in Python even when the algorithmic complexity is identical. I'd pick whichever language you're fastest in, but if Python times out on a clean O(n log n) solution, that's usually an input/output bottleneck, not an algorithm problem.

The second round tends to focus more on data structure design than pure algorithm problems. Implementing a LRU cache, a circular queue, or a thread-safe counter shows up occasionally. These aren't as glamorous as the DP problems but they filter out candidates who only practice LeetCode hard questions and haven't actually built anything from scratch. I saw one question that asked for a frequency stack supporting push, pop, and get max frequency operations. A hash map mapping frequency to a stack of elements does it in O(1), and it's the kind of thing that's faster to implement than to derive from first principles if you've seen it before. If you're looking for actual question content, there isn't an official public repository from Goldman Sachs. The questions I'm describing come from candidate reports on platforms like Blind and Glassdoor, and they've been consistent across multiple hiring cycles. Some questions get recycled with different numbers or slightly changed constraints. A problem about finding the kth smallest element in a matrix where rows and columns are sorted appeared in a 2021 assessment and resurfaced with modified constraints in 2022. The core technique — min-heap based merge of sorted rows — doesn't change.

How to Prepare Without Wasting Time

Most candidates overprepare on random LeetCode problems and underprepare on fundamentals they already know. I'd recommend spending two weeks on medium-difficulty array and string problems, one week on dynamic programming patterns (knapsack, LCS, partition, coin change), and a few days on graph traversal and basic graph problems. That covers roughly 80 percent of what shows up. The remaining 20 percent is usually math or a specialized data structure you can pick up in an hour if your fundamentals are solid. Practice under real test conditions. Close your IDE's autocomplete, turn off the compiler warnings that help you catch bugs, and set a 30-minute timer per problem. The HackerRank environment gives you nothing but a text editor and a run button. Intellisense and debugging tools don't exist there. If you normally solve problems with full IDE support, the transition is jarring and it slows you down in ways that practice doesn't prepare you for. Don't chase the hardest problems. The Goldman Sachs assessment has a clear difficulty distribution where solving the first three correctly with good complexity is enough to pass. The fourth problem is often designed to be unsolvable within the time limit for most candidates. Spending 45 minutes trying to crack it when you haven't solved the second one yet is the most common mistake I see in candidates who ultimately get rejected. Move on after 20 minutes if you're stuck, come back if time permits, and never leave a correct solution unsubmitted because you're busy on a harder problem.

There's also the question of whether you should memorize solutions or truly understand them. Memorization gets you through a single interview. Understanding gets you through follow-up rounds where the interviewer asks you to modify the solution, handle a constraint change, or explain why a different approach would fail. During my own assessment, the follow-up for the minimum window substring problem asked me to handle Unicode surrogate pairs correctly. My initial solution assumed single-character graphemes, and the interviewer immediately pushed me to fix it. The people who understood the sliding window mechanics at a deeper level adapted quickly. The people who'd memorized the standard answer stalled. One useful resource is the HackerRank official tutorial section. It has problems organized by topic and difficulty, and the gold medal problems in each category tend to overlap significantly with what banks actually use. I also found that doing mock assessments on platforms like Codingame or CodeSignal helped me get used to the pacing pressure, even though the question style differs slightly from what Goldman Sachs uses. The time management skill transfers directly. When you're reviewing your solutions after practice, check for hidden inefficiencies. A solution that looks O(n) might actually be O(n squared) because of string concatenation in a loop or repeated list slicing. Python strings are immutable, so building a result with s += char in a loop is O(n squared) in the worst case. Use a list and join it instead. Similarly, checking membership in a list is O(n) while checking membership in a set is O(1), and that difference becomes critical when you're iterating over large inputs in nested loops. These aren't subtle points. They're the difference between a passing solution and a Time Limit Exceeded result on the same algorithmic approach.

The final thing I'd note is that the written portion of the assessment sometimes includes a short open-ended question about system design or trade-offs. It's rare but it shows up, and it's usually worth 10 to 15 percent of your score. A question might ask you to compare a hash map versus a sorted array for a search-heavy workload, or to explain when you'd choose BFS over DFS. These don't require lengthy answers. Two or three sentences with correct reasoning and accurate terminology is usually enough. Overthinking them wastes time better spent on the coding problems. If you want to download practice sets or find specific Goldman Sachs Hackerrank Questions 2022 collections, most of what exists online is user-contributed and sits on GitHub repositories or PDFs shared on forums. There's no official Goldman Sachs document you can download. The repositories that aggregate these questions tend to be updated slowly, so the 2022 set might include problems that have since been retired or replaced. Treat any third-party collection as supplementary material, not as a definitive preview. The actual questions change enough between hiring cycles that relying solely on old sets will leave gaps in your preparation. The assessment itself usually doesn't give you feedback during the test. You submit and then wait for results, which come back within a few days to a couple of weeks depending on the volume of candidates. The pass threshold isn't publicly disclosed, but candidates who make it through tend to solve at least two problems completely and make meaningful progress on a third. Solving one problem perfectly and having partial credit on two others is borderline. Solving nothing correctly is an automatic rejection. The gap between passing and failing is usually small in absolute terms, which is intentional — they're screening for a baseline competency level, not trying to identify the single best candidate.