DEV Community: ifa tade

Goldman Sachs OA Questions: Two Coding Problems and Solutions

ifa tade — Thu, 15 Oct 2026 10:10:10 +0000

The Goldman Sachs OA is an important part of the application process for technical roles such as Software Engineer. Depending on the position and hiring cycle, the assessment may include traditional algorithm questions as well as tasks that require candidates to understand existing code and implement business logic.

This article covers two Goldman Sachs OA questions. The first focuses on reverse array traversal, duplicate removal, and selecting a specified number of unique request IDs. The second is an AI Coding problem involving ticket reservation confirmation, inventory updates, and partition status checks. Understanding the requirements and handling edge cases are essential to solving both problems correctly.

Question 1: Retrieve Unique Request IDs in Reverse Order

What This Question Tests

The goal is to traverse a request array from the end and collect a specified number of unique request IDs. Since an ID may appear multiple times, the solution must track previously encountered IDs and avoid adding duplicates.

The main concepts involved are:

Array Traversal: Iterate through the array from right to left.
Set: Track previously encountered request IDs to prevent duplicates.
Early Termination: Stop traversing once the result contains k unique IDs.

Solution Approach

Maintain a set to track visited IDs and a result array to store the selected IDs.

Start at the end of the request array and move backward one element at a time. For each ID, check whether it already exists in the set. If it does, skip it. Otherwise, add the ID to both the set and the result array.

Continue until the result contains k unique IDs. At that point, stop the traversal and return the result.

This approach prioritizes the most recently encountered unique IDs while preserving their order of discovery during reverse traversal.

Complexity Analysis

Let n be the length of the request array.

Time Complexity: O(n) in the worst case, since each element is examined at most once.
Space Complexity: O(n) in the worst case, for storing visited IDs and the result.

The algorithm is relatively straightforward. The main challenge is following the required traversal order and handling duplicate IDs correctly. Using a Set makes duplicate detection efficient and keeps the implementation simple.

Question 2: AI Coding for Ticket Confirmation and Inventory Updates

What This Question Tests

The second question is an AI Coding task with similarities to some Amazon OA questions that involve modifying existing code and implementing business rules.

Rather than focusing on a standalone algorithm, the task requires completing the ticket confirmation workflow after a ticket has been held or reserved. The implementation must validate the reservation, update inventory counts, clear the reservation record, and check the status of all ticket partitions.

The relevant data includes reservation ownership, ticket status, expiration time, held ticket counts, sold ticket counts, and partition-level inventory information.

Solution Approach

Step 1: Validate the reservation.

Start by checking whether the reservation can be confirmed. Verify the ownership information, current ticket status, and expiration time before making any changes.

Only reservations that satisfy the required business rules should proceed to the confirmation stage.

Step 2: Update the ticket counts.

After validation succeeds, decrease held_count by 1 and increase sold_count by 1.

This represents the transition of one ticket from the held inventory to the sold inventory. Make sure the updates apply to the correct ticket partition.

Step 3: Clear the reservation record.

After confirmation, remove the corresponding reservation record so that it cannot be reused incorrectly.

The status transition, inventory updates, and reservation cleanup must follow the required business logic to avoid inconsistent data.

Step 4: Check the status of every partition.

Finally, iterate through all ticket partitions and determine whether each one is sold out. Apply any required status updates according to the problem's rules.

An important detail is that the final check must cover every partition, not just the partition associated with the confirmed ticket.

Key Implementation Considerations

The main challenge is ensuring that all business rules are handled correctly, rather than implementing a complicated data structure or algorithm.

Validation: Verify ownership, ticket status, and expiration before modifying data.
State Transitions: Apply the correct status changes when a held ticket is confirmed.
Inventory Consistency: Keep held_count, sold_count, and reservation records consistent.
Partition Status: Check every partition against the required sold-out conditions.

If the assessment provides existing code or documentation, review the expected exceptions, state transition rules, and inventory constraints before modifying the relevant functions.

For AI Coding tasks, passing the sample tests is not enough. Consider edge cases such as expired reservations, invalid ticket states, repeated confirmation attempts, and partitions with different inventory levels. These scenarios can reveal errors that are easy to miss during the initial implementation.

How to Prepare for the Goldman Sachs OA

Preparation should cover both algorithm fundamentals and practical code modification tasks.

For algorithm questions, practice array traversal, Set and Hash Map operations, sorting, two pointers, binary search, and common graph algorithms. Pay attention to traversal order, duplicate handling, stopping conditions, and time and space complexity.

For AI Coding tasks, focus on reading unfamiliar code, identifying the functions that need to be modified, understanding business constraints, and implementing the required behavior without breaking existing functionality.

For tasks involving inventory or state transitions, it helps to organize the workflow into four stages: validation, data updates, record cleanup, and final status checks. After implementation, test invalid states, expired records, repeated operations, and different inventory conditions across multiple partitions.

The exact format and question types of the Goldman Sachs OA may vary by role and hiring cycle. Use these problems as practice examples and refer to the instructions provided for your specific assessment.

Frequently Asked Questions

What topics are covered in the Goldman Sachs OA?

The content depends on the role and assessment format. Technical assessments may include data structures and algorithms, debugging, code implementation, or other engineering tasks. Review the assessment instructions for your target position to determine the most relevant areas to practice.

How should I prepare for AI Coding questions in the Goldman Sachs OA?

Practice reading existing code, understanding business requirements, completing specified functions, and handling exceptions. For tasks involving state changes, pay particular attention to validation rules, state transitions, data consistency, and edge-case testing rather than focusing only on writing code quickly.

Which algorithms should I review for the Goldman Sachs OA?

Useful topics include arrays, Hash Sets, Hash Maps, sorting, two pointers, binary search, and common graph algorithms. Beyond memorizing techniques, make sure you can translate the problem requirements into a correct implementation and handle boundary conditions.

Conclusion

These two Goldman Sachs OA questions cover different skill sets. The first tests reverse traversal and Set-based deduplication, while the second focuses on reservation validation, ticket inventory updates, and partition status checks.

If you are preparing for the Goldman Sachs OA or coding assessments at other technology companies, practice both algorithm problems and tasks that require modifying existing code. Developing a systematic approach to requirements, implementation, and edge-case testing can help you write more reliable solutions under assessment time constraints.

Capital One OA Questions: 4 Coding Problems and Solutions

ifa tade — Wed, 14 Oct 2026 09:48:29 +0000

The Capital One Online Assessment (OA) tests candidates on fundamental programming skills, algorithmic thinking, and implementation accuracy. This article covers four reported Capital One OA coding questions from an assessment completed on CodeSignal, with an approximate time limit of 70 minutes.

The four problems cover array simulation, divisibility checks, Manhattan distance, and subarray pair counting. Although the solutions do not necessarily require advanced algorithms, candidates must understand the problem requirements, translate them into code, and handle edge cases correctly under time pressure.

Capital One OA Coding Questions at a Glance

Problem	Key Concepts	Main Approach
T1: Arithmetic Operation Validation	Arrays, conditional logic	Calculate and compare each element
T2: Song and Animation Matching	Divisibility, string parsing	Check duration constraints
T3: Diamond-Shaped Matrix Regions	2D arrays, Manhattan distance	Enumerate centers and target cells
T4: Counting Subarrays with at Least k Fruit Pairs	Hash Map, subarrays	Enumerate subarrays and maintain pair counts

These problems focus primarily on implementation. T1 and T2 involve straightforward conditions, T3 requires careful coordinate calculations, and T4 requires tracking element frequencies while expanding a subarray.

T1: Arithmetic Operation Validation

Problem Description

You are given three integer arrays of equal length and an operator array containing only addition and subtraction symbols.

For each index, apply the corresponding operator to the elements from the first two arrays. Compare the result with the element at the same index in the third array.

If the calculated value matches the corresponding element, return true for that position. Otherwise, return false. The final output should be an array containing the results in their original order.

Solution Approach

This problem can be solved with a single array traversal.

Start at index 0 and iterate through the arrays. If the current operator is +, calculate a[i] + b[i]. If the operator is -, calculate a[i] - b[i].

Compare the calculated value with c[i] and append the Boolean result to the output array. After processing every index, return the completed array.

Complexity Analysis

Let n be the length of each array.

Time complexity: O(n), because each position is processed once.
Space complexity: O(n) for the output array.

The main consideration is implementing the arithmetic operation exactly as specified. In particular, subtraction must preserve the correct operand order.

T2: Matching Songs with Animation Durations

Problem Description

You are given a list of songs and a list of animations. Each item contains a name and a duration, represented as a name-duration pair.

For each song, find an animation whose duration does not exceed the song's duration and divides it evenly. This ensures that the animation can repeat a whole number of times and finish at the same time as the song.

For example, if a song lasts 185 seconds and an animation lasts 37 seconds, the animation must play five times to match the song's duration.

The result should contain the selected animation name and the number of repetitions required, following the output format specified in the problem.

Solution Approach

First, parse each song and animation entry to extract its name and duration.

Then, iterate through the songs and check the available animations. For a song duration songDuration and an animation duration animationDuration, the following conditions must hold:

animationDuration <= songDuration
songDuration % animationDuration == 0

The first condition prevents the animation from exceeding the song's duration. The second ensures that the animation fits the song's duration exactly.

When a match is found, calculate the repetition count using:

repeatCount = songDuration / animationDuration

Store the required animation information in the result. If multiple animations satisfy the conditions, follow the problem's specified selection rule rather than assuming that any valid match can be returned.

Complexity Analysis

Let n represent the number of songs and m represent the number of animations.

If every song is checked against every animation, the time complexity is O(n × m). If the input is large, indexing animations by duration may help reduce unnecessary comparisons.

The key is to distinguish between an animation that is shorter than a song and one whose duration divides the song duration evenly. Both conditions must be satisfied.

T3: Finding Diamond-Shaped Regions in a Matrix

Problem Description

You are given a 2D matrix and an integer radius r. For every cell in the matrix, treat that cell as the center of a diamond-shaped region and collect all cells that satisfy the required distance condition.

Let the center cell have coordinates (centerX, centerY) and a target cell have coordinates (cellX, cellY). A target cell belongs to the region if:

abs(centerX - cellX) + abs(centerY - cellY) + 1 <= r

Repeat this process for every cell in the matrix and return the collected regions in the required format.

Solution Approach

The distance calculation uses Manhattan distance, which measures the sum of the absolute differences between two coordinates. Unlike Euclidean distance, it does not calculate the straight-line distance between two points.

A straightforward solution uses nested enumeration.

Iterate through every row and column, treating the current cell as the center.
For each center, traverse every cell in the matrix.
Calculate the Manhattan distance between the center and the target cell, then add 1.
If the result is less than or equal to r, include the target cell in the current region.
Repeat until every cell has been processed as a center, then return the results.

This approach follows the problem's definition directly and is relatively easy to implement and verify.

Complexity Analysis

Suppose the matrix contains n rows and m columns.

There are n × m possible center cells, and each center requires checking all n × m cells. Therefore:

Time complexity: O(n² × m²).
Space complexity: Depends on the size of the returned regions. Storing all collected cells may require substantial memory.

Pay close attention to the distance formula and matrix boundaries. Every target coordinate must remain within the valid row and column ranges.

T4: Counting Subarrays Containing at Least k Pairs of Identical Fruits

Problem Description

You are given an integer array fruits, where each value represents a fruit type, and an integer k.

Your task is to count the number of contiguous subarrays that contain at least k pairs of identical fruits.

Each pair must consist of two fruits of the same type, and each fruit can belong to only one pair.

For example, three occurrences of the same fruit can form one pair, while four occurrences can form two pairs. Therefore, if a fruit appears frequency times, it contributes:

floor(frequency / 2)

The total number of pairs is the sum of the contributions from all fruit types in the subarray.

Solution Approach

A straightforward solution enumerates every possible contiguous subarray while using a Hash Map to track fruit frequencies.

Fix the left endpoint left with an outer loop. Then, use an inner loop to extend the right endpoint right one position at a time.

Whenever a new fruit enters the current subarray, update its frequency in the Hash Map. Maintain an additional variable, pairs, to track the total number of pairs without recalculating the contribution of every fruit type.

The key observation is that a new pair is formed only when the frequency of a particular fruit changes from an odd number to an even number.

For example:

Frequency changes from 0 to 1: no new pair.
Frequency changes from 1 to 2: add one pair.
Frequency changes from 2 to 3: no new pair.
Frequency changes from 3 to 4: add one pair.

After each expansion, check whether pairs >= k. If the condition holds, increment the answer because the current subarray qualifies.

Do not stop expanding the right endpoint as soon as a valid subarray is found. The task is to count all qualifying subarrays, and longer subarrays may also satisfy the condition.

Complexity Analysis

Let n be the length of the array.

There are O(n²) possible contiguous subarrays. Since each expansion requires only a frequency update and a constant-time check, the overall complexity is:

Time complexity: O(n²).
Auxiliary space complexity: O(n) for the Hash Map.

The important optimization is maintaining the pair count incrementally. Tracking the number of occurrences alone is not sufficient because occurrences and valid pairs are different quantities.

How to Prepare for the Capital One OA

1. Practice Common Coding Patterns

These four questions cover several foundational problem-solving techniques:

Arrays: Traversal, element-by-element calculations, and result collection.
String Parsing: Extracting names and numeric values from formatted input.
Math: Divisibility, modulo operations, and distance calculations.
Matrices: Nested traversal and coordinate-based conditions.
Hash Maps: Frequency counting and incremental state updates.
Subarrays: Fixing a left endpoint, expanding a right endpoint, and counting valid ranges.

Rather than memorizing individual solutions, practice converting problem statements into clear conditions and choosing an appropriate data structure.

2. Practice Under a Time Limit

If your assessment has a time limit of approximately 70 minutes, aim to complete the more straightforward problems efficiently and reserve enough time for questions that require nested enumeration or state tracking.

After implementing each solution, leave time to check the logic and test edge cases. A brute-force solution can be a useful starting point, but always compare its complexity with the input constraints before submitting it.

3. Pay Attention to Edge Cases

Several details in this question set are easy to overlook:

Arithmetic operations must use the correct operand order.
An animation duration must divide the song duration evenly.
The matrix region condition includes an additional +1.
Fruit pairing requires integer division, with every two identical fruits forming one pair.

Before submitting, test small inputs, repeated values, cases with no valid matches, odd fruit frequencies, and cells near matrix boundaries.

These checks can reveal errors that are not obvious from the main examples.

4. Reimplement Solutions Without Looking at the Answer

Reading a solution is not the same as being able to write it during an assessment.

After reviewing a problem, close the reference solution and implement it again from scratch. For the fruit-pair problem in particular, make sure you can explain why the pair count increases only when a fruit's frequency changes from odd to even.

Understanding the reason behind each update makes it easier to handle variations of the same problem.

Final Thoughts

This set of Capital One OA coding questions focuses on foundational algorithms and implementation accuracy. The main topics are array simulation, divisibility checks, Manhattan distance, and subarray pair counting.

The first two problems have relatively direct solutions, while the matrix and subarray problems require more attention to enumeration boundaries and state management.

When preparing for the Capital One OA, prioritize understanding the problem requirements, selecting a suitable approach, and testing edge cases. A clear and correct implementation is a strong starting point for solving these types of coding questions under time pressure.

Capital One OA FAQ

How difficult is the Capital One OA?

The difficulty varies by role, hiring cycle, and assessment version. Coding questions may cover arrays, strings, mathematical operations, Hash Maps, and basic algorithmic techniques. Candidates should focus on understanding the requirements, handling edge cases, and writing correct code within the time limit.

How many coding questions are on the Capital One OA?

The number of questions depends on the specific assessment. The set discussed in this article contains four coding problems with an approximate time limit of 70 minutes. This does not mean every Capital One OA has exactly four questions. Always check the instructions provided with your assessment invitation.

What topics should I practice for the Capital One OA?

Start with Array, String, Hash Map, Sorting, Two Pointers, Prefix Sum, and basic math problems. Depending on the target role, you may also need to practice Graph, Tree, Heap, and Dynamic Programming problems.

Can I use brute force for the Capital One OA?

A brute-force solution may work when the input size is small, but its performance depends on the constraints and time limit. Before submitting, estimate the time complexity and determine whether the solution can process the largest expected input efficiently. If necessary, reduce repeated calculations or use a more suitable data structure.

Microsoft OA: Two HackerRank Coding Questions and Solutions

ifa tade — Tue, 13 Oct 2026 09:07:22 +0000

Microsoft OA can cover different types of coding problems, from array processing and prefix sums to dynamic programming. In this HackerRank experience, both questions required a clear understanding of the problem and an efficient approach to handling the input.

The first question focused on calculating travel costs between servers, while the second was a variation of the classic House Robber problem. Both could be solved efficiently by identifying the right structure before processing the queries or making selection decisions.

Question 1: Calculate the Cost Between Servers

Problem Overview

The first problem involved a collection of servers arranged in a sequence. Each server had a capacity, and moving between servers incurred a cost determined by the relationship between neighboring servers.

The goal was to answer multiple queries, each asking for the cost of traveling between a starting server and a destination server. Calculating the entire route separately for every query would be inefficient, so the key was to preprocess the information and make each query faster.

Approach

The solution starts by determining which neighboring server is closer to each server. The results are stored in an array called nb, indicating whether the preferred neighbor is on the left or right.

Next, two cumulative cost arrays, rs and ls, are built to handle movement in opposite directions. The rightward array tracks the cost of moving through the servers from left to right, while the leftward array handles movement from right to left.

When calculating the cost of moving to the next server, the algorithm checks whether the previous server's nearest neighbor is the current server. If it is, the movement cost is 1. Otherwise, the cost is based on the difference between the capacities of the two servers.

Once both cumulative arrays have been calculated, answering a query becomes straightforward. If the destination is to the right of the starting server, the algorithm uses rs to calculate the cost. If the destination is to the left, it uses ls instead. Subtracting the corresponding prefix values gives the total cost between the two positions.

This preprocessing approach avoids recalculating the route for every query.

Complexity Analysis

Let n be the number of servers and m the number of queries.

Preprocessing: (O(n))
Each query: (O(1))
Total time complexity: (O(n+m))

The main optimization is moving the repeated work into preprocessing, allowing each query to be answered in constant time.

Question 2: Maximum Sum With No Consecutive Values

Problem Overview

The second question asked for the maximum possible sum under a restriction: two consecutive integer values could not both be selected.

Multiple elements could share the same value, so the first step was to calculate the total sum contributed by each distinct value. After grouping the elements this way, the problem became a variation of the classic House Robber problem.

For example, if several elements have the value 3, their contributions can be combined into a single total for 3. The algorithm then decides whether to take that total or skip it, depending on the neighboring values.

Approach

First, calculate the total contribution of every distinct value and sort the distinct values in ascending order.

The algorithm then processes these values using dynamic programming. Two states, p and q, maintain the best results from the previous positions. Here, p represents the optimal sum before the previous value, while q represents the best sum calculated up to the previous value.

For each new value, there are two possible cases.

Case 1: The current value is consecutive to the previous value.

If the difference between the current value and the previous value is 1, they cannot both be selected. The algorithm compares two options:

Skip the current value and keep the existing best result.
Take the current value's total contribution and add it to p.

The larger result becomes the new optimal state.

Case 2: The current value is not consecutive to the previous value.

If the difference is greater than 1, selecting the current value does not conflict with the previous value. Its total contribution can therefore be added to the existing optimal sum.

After processing each distinct value, the two DP states are updated for the next iteration. Once all values have been considered, q contains the maximum achievable sum.

Complexity Analysis

Let n be the number of input elements and k the number of distinct values.

Grouping values: (O(n))
Sorting distinct values: (O(k\log k))
Dynamic programming: (O(k))
Total time complexity: (O(n+k\log k))

The dynamic programming step uses only two rolling states, so it requires (O(1)) additional space after the distinct values have been sorted and stored.

Key Takeaways From This Microsoft OA

These two HackerRank questions tested different problem-solving skills.

The first question rewarded preprocessing. By building directional cumulative cost arrays, the solution reduced repeated route calculations to constant-time queries.

The second question tested whether a familiar dynamic programming pattern could be recognized in a different setting. Grouping equal values and sorting them transformed the original problem into a House Robber-style selection problem.

For Microsoft OA preparation, it is worth practicing prefix sums, array preprocessing, sorting, and dynamic programming. Understanding why an optimization works is more useful than memorizing a specific solution, especially when a question introduces slightly different constraints.

Google SWE Interview Preparation: A Coding and System Design Study Plan

ifa tade — Wed, 30 Sep 2026 08:57:04 +0000

Preparing for a Google SWE interview is overwhelming mostly because of how much there is to cover: data structures and algorithms, coding, system design, behavioral questions, and often a discussion of your past projects. Finding material isn't the hard part. The hard part is deciding what to study first when you only have so many weeks.

What works better than grinding hundreds of random problems is building your plan around the skills the interview actually tests. Here's how I'd organize it, with the focus on coding and system design.

Know What You're Preparing For

Start by listing the areas you'll be tested on. For a typical Google SWE loop, that's:

Data structures and algorithms
Coding
System design
Behavioral questions
Project experience and technical discussion

The exact format varies by role and level, so what your recruiter tells you should be your starting point.

Of these, coding and system design need the most deliberate practice, and they need different kinds. Coding is about solving a problem correctly while the clock is running. System design is about explaining how you'd build something, weighing trade-offs, and getting your decisions across clearly. Studying them the same way won't work well.

Coding: Fundamentals, Then Patterns, Then Timed Practice

I'd split coding prep into three stages, in that order.

Review the fundamentals

Refresh the structures and algorithms that come up most often:

Arrays and strings
Hash tables
Linked lists
Stacks and queues
Trees and graphs
Heaps
Binary search and sorting
DFS and BFS
Dynamic programming and greedy algorithms

You don't need weeks of theory here. You just need the basics to feel automatic, so that when a graph problem shows up you can pick between DFS and BFS and write it out without burning several minutes trying to remember how.

Learn the patterns

Once the basics are back, start grouping problems by pattern instead of counting how many you've solved. A rough map looks like this:

Problem type Typical techniques
Arrays Prefix sum, two pointers
Subarrays Sliding window
Trees DFS, BFS
Graphs DFS, BFS, topological sort
Sorted data Binary search
Top K Heap
Optimization Dynamic programming
Intervals Sorting plus greedy

The point isn't to memorize solutions. It's to get good at seeing the structure of a problem you've never met. When you hit a new one, ask yourself three things: what's the simplest brute-force approach, why is it too slow, and which data structure or algorithm removes that bottleneck? That habit will serve you far better than a bank of memorized answers.

Stick to Mediums before chasing Hards

Spend most of your time on Medium problems, and work through each one the same way:

Read the constraints carefully.
Come up with a brute-force solution.
Find the bottleneck.
Work out a faster approach.
Write the code without peeking at the solution.
Test edge cases.
State the time and space complexity.

If you're stuck after a reasonable stretch, don't stare at it for an hour. Read the explanation, make sure you understand why it works, close it, and then implement it again from scratch. That last step matters more than it sounds, because reading a solution easily gives you the feeling of understanding without the ability to reproduce it.

Add timed practice

Once the fundamentals feel solid, start working under a clock. This is where interview prep stops resembling ordinary LeetCode practice. In a real interview you have to understand the problem, clarify assumptions, explain your plan, write the code, test it, and handle follow-ups, all in one sitting.

Do the occasional mock session where you solve one or two problems with no notes. Afterward, look at more than whether you got the answer. Did you spot the pattern quickly? Did you sink too much time into a weak first idea? Was your explanation clear? Did you test enough edge cases? Notes like these say more about your readiness than a total problem count ever will.

System Design

You can't prepare for system design by memorizing architectures and replaying them. Learn a framework you can apply to a question you haven't seen. This is the one I'd use:

Requirements → Scale → API and data model → High-level design → Deep dive → Trade-offs

Clarify requirements first

Work out what the system actually has to do. If you're asked to design a messaging app, you might ask whether it's one-to-one or group chat, whether delivery needs to be real-time, whether message history is kept, whether there are read receipts or notifications, and how many users to expect. You don't need to ask everything, only the questions that would change your design.

Estimate the scale

Get comfortable with rough numbers: daily active users, requests per second, storage needs, read/write ratio, and how fast traffic might grow. Precision doesn't matter. What you're deciding is whether a simple setup will do or whether you need to start thinking about caching, sharding, replication, or queues.

Sketch the high-level design

Lay out the major pieces: load balancer, API servers, database, cache, message queue, object storage, search or notification services, whichever apply. Don't include a component just because it appears in every system design diagram. Each one should be there because it solves a specific problem.

Study real examples

Rather than memorizing dozens of questions, pick a handful of representative systems:

URL shortener
Messaging system
File storage
News feed
Rate limiter
Notification system
Distributed storage

For each, concentrate on why the design works. If there's a cache, what problem is it solving? If there's a queue, why does that step need to be asynchronous? If you chose a particular database, what access pattern makes it a good fit? Answering those questions is what lets you carry the ideas over to a new problem.

A 4-Week Plan

If you have about a month, this is how I'd lay it out.

Week 1: coding fundamentals. Cover arrays, strings, hash tables, linked lists, stacks and queues, trees, and binary search. Don't worry about finishing everything. The real aim this week is to find out where you're still slow or shaky.

Week 2: advanced patterns. Move on to graphs, DFS/BFS, heaps, sliding window, two pointers, intervals, dynamic programming, and greedy algorithms. Start adding timed practice here.

Week 3: system design. Work on clarifying requirements, capacity estimation, API design, data modeling, high-level architecture, caching, database choices, queues, replication and partitioning, and trade-offs. Practice explaining your designs out loud rather than only drawing them.

Week 4: mocks and review. This isn't the week to learn a pile of new topics. Mix timed coding sessions, system design mocks, behavioral prep, and project discussions, and go back over the problems you missed earlier. If you keep making the same mistake, fix that instead of adding more problems to your list.

Coding vs. System Design: How to Split Your Time

There's no ratio that works for everyone. It depends on the role, the interview format, and where you're weakest right now. If coding is your weak spot, put more hours there. If Mediums feel comfortable but you lose the thread in design discussions, shift toward system design.

An easy way to decide is to jot down your weak spots after each session:

Area Current issue Next step
Coding Slow on graph problems Practice DFS/BFS
Coding Missing edge cases Add a 10-minute review
System design Vague requirements Practice clarifying questions
System design Too many components Focus on trade-offs
Communication Scattered explanations Practice thinking aloud

That gives you a plan based on what's actually going wrong rather than on guesses.

Don't Neglect Communication

A common mistake is treating the interview like a coding contest. Your interviewer isn't only reading your final code; they're following your reasoning. So practice saying it out loud. For example: "The brute-force approach is O(n²), so I want to cut down the repeated work." Then say which data structure or algorithm you'll use and why.

The same goes for system design. "I'll use Redis here" tells the interviewer very little. Compare that with: "Reads far outnumber writes, so I'd cache the frequently accessed data to take load off the database." The second version shows the thinking behind the choice, which is what they want to see.

If You Only Have Two Weeks

Don't try to cram a three-month plan into fourteen days. Cut it down to what matters.

For coding, review the common data structures, practice the common patterns, stay on Medium problems, do timed sessions, and go over your mistakes. For system design, learn one reusable framework, study a few representative systems, practice capacity estimation and explaining trade-offs, and do at least a few mock sessions. You're aiming to be consistent, not to know everything.

Wrapping Up

A good Google SWE interview preparation plan isn't about ticking off an enormous topic list. It's about building the skills you'll use in the room. For coding, that means recognizing patterns, writing correct code, and solving problems under time pressure. For system design, it means requirements, scale, architecture, and trade-offs rather than memorized diagrams. And as the interview gets closer, practice in conditions that feel as much like the real thing as you can manage.

If you'd like a wider look at the process, including the interview stages and the other technical areas, the Google SWE Interview Guide on InterviewShow is a good next read.

How to Prepare for an Amazon SDE Coding Interview

ifa tade — Fri, 25 Sep 2026 13:24:08 +0000

Grinding through hundreds of LeetCode problems is the default advice everyone gives, but it's not really what separates a strong interview from a mediocre one. In a real technical interview, you're not just solving a problem — you're understanding it, explaining your reasoning, writing working code, analyzing its complexity, and responding on your feet when the interviewer pushes further. Solving problems matters, but so does how you communicate your way through them.

Start With the Problem, Not the Code

The fastest way to sink an interview is to start typing before you've actually understood what's being asked. Take a moment first to pin down the basics: What does the input look like, and what should come out? Could there be duplicates, or could the input be empty? What are the constraints, and is the data already sorted? Getting these details straight up front saves you from confidently solving a problem you were never actually asked.

Talk Through the Brute-Force Approach First

You don't need to leap straight to the optimal solution — in fact, doing so can make for a worse interview, not a better one. It's often more useful to start with the straightforward approach: if you're looking for relationships between elements in an array, for instance, you might begin by considering every pair. Walk through the complexity of that approach — if it comes out to O(n²), ask yourself whether the structure of the problem gives you room to cut down on the work. This kind of thinking shows the interviewer how you optimize, rather than just that you memorized the right answer in advance.

Learn to Recognize the Right Data Structure

A lot of problems become far more manageable once you spot which data structure they're really asking for:

Hash maps shine at frequency counting, fast lookups, duplicate detection, and mapping keys to values.
Stacks are your go-to for parentheses matching, monotonic stack problems, backtracking, and anything involving nested structures.
Queues handle BFS, level-order traversal, and scheduling-style problems.
Heaps are built for top-K problems, priority-based processing, and tracking running minimums or maximums.
Graphs come up whenever the problem is really about relationships, networks, dependencies, or traversal.

The more of these patterns you internalize, the faster you'll recognize what's actually going on in an unfamiliar problem.

Reason Through Time Complexity

Once you've got an approach, sit with its complexity for a moment — is it O(n), O(n log n), O(n²)? — and be ready to explain why. Ask yourself how many passes you're making through the input, whether you're sorting anywhere, whether there are nested loops, and how much extra memory you're using. This kind of analysis becomes especially important the moment an interviewer asks you to make your solution faster.

Don't Skip Edge Cases

Code that handles the obvious example can still quietly fall apart elsewhere. Before you call a solution done, run it mentally against the edge cases: empty input, a single element, duplicates, very large inputs, negative values, data that's already sorted (or reverse-sorted), missing values. You don't have to write a formal test for each one, but you should be able to show the interviewer you've thought about them.

Expect the Follow-Up Questions

Getting a working solution rarely ends the conversation. Interviewers like to push further: Can you make it faster? Can you cut the memory usage? What if the input were huge, or arrived as a stream instead of all at once? Could you solve it without sorting? These questions exist to probe whether you actually understand the trade-offs in your solution, so it's worth knowing more than one way to approach a given problem rather than banking on a single memorized path.

Practice Thinking Out Loud

Working through a problem silently in your head is a completely different skill from narrating your way through one live. When you practice, say it out loud: restate the problem, call out the constraints that matter, describe your first approach, explain how you'd optimize it, write the code, test it, then talk through the complexity. The closer this gets to how a real interview actually feels, the less foreign the real thing will be.

Practice by Pattern, Not at Random

Working through problems in no particular order isn't the most efficient way to prepare. You'll get more out of your time by grouping problems into patterns instead:

Pattern Common Topics
Hashing Frequency, lookup, duplicates
Two Pointers Arrays, strings
Sliding Window Subarrays, substrings
Binary Search Sorted data
BFS / DFS Trees, graphs
Dynamic Programming Optimization problems
Intervals Scheduling and ranges
Heap Top K and priority problems

Once these patterns click, unfamiliar problems stop feeling quite so unfamiliar.

Don't Neglect the Non-Coding Half

Coding is only one piece of an Amazon SDE interview. Depending on the role, you'll likely also face behavioral questions tied to Amazon's Leadership Principles — so a prep plan that's 100% algorithms is an incomplete one. A more balanced plan makes room for coding practice, mock interviews, behavioral stories, review of the Leadership Principles, and a polished resume.

Final Thoughts

In the end, preparing for an Amazon SDE interview has less to do with memorizing a stack of solutions and more to do with building a repeatable way of thinking through problems — understanding requirements, picking the right data structure, weighing trade-offs, writing clean code, reasoning about complexity, catching edge cases, and handling whatever follow-up comes your way. Get comfortable with that process, and it'll serve you well beyond this one interview too.