I recently appeared for an Amazon SDE-I Intern OA, and I wanted to share my experience, especially the coding sections, because the second question was quite different from a typical LeetCode problem.

Q1 — Binary String Problem

The first question was easy based on a binary string log and an integer k.

We can choose one substring of length k and change every 0 inside that substring to 1.

The goal is to find the maximum number of consecutive 1s possible after the operation.

Example

log = "11001"
k = 2

11[00]1
   ↓
11[11]1

Result = "11111"

Answer = 5

O(n) Approach

For every possible substring of length k, imagine that we flip that entire window.

Suppose the selected window is:

        [   k   ]
...1111 [ 0010 ] 111...
        ↑       ↑
       left    right

After changing all 0s inside the window to 1, the entire window contributes exactly k consecutive 1s.

Therefore:

answer for this window
=
consecutive 1s immediately before the window
+ k
+ consecutive 1s immediately after the window

So instead of actually modifying the string for every window, we can precompute:

• left[i] = consecutive 1s ending at index i
• right[i] = consecutive 1s starting at index i

Then for every window [i, i+k-1]:

current =
    left[i-1]
    + k
    + right[i+k]

with proper boundary checks.

This allows us to check every possible window in O(1) after preprocessing.

Complexity

Preprocessing: O(n)
Checking all windows: O(n)

Time:  O(n)
Space: O(n)

Q2 — Repository-Based Question 💀

This was where things became much more difficult.

Instead of giving a normal coding problem, Amazon provided an existing repository/codebase.

There were 7+ files, and some individual files had around 400–500+ lines of code.

The task involved understanding an existing return/risk evaluation system.

Some of the logic included:

• Category returnability
• Return-window validation
• Linked-account aggregation
• Return history
• Order-value based scoring
• Risk-score calculation
• Auto-approve / Manual-review / Reject decisions
• Reason mapping

The challenging part wasn't simply writing code.

It was:

Understand the codebase
        ↓
Understand the existing logic
        ↓
Run tests
        ↓
Find why tests fail
        ↓
Identify the correct component
        ↓
Modify the implementation
        ↓
Run tests again
        ↓
Debug again

There were 6 test cases, and I managed to pass only 2/6.

This question taught me something different from regular DSA.

Code reading + debugging + testing + understanding existing architecture + problem solving.

Q3 — Situational Judgement

The OA also included a Situational Judgement section.

The questions focused more on workplace situations such as:

• Teamwork
• Communication
• Ownership
• Handling disagreements
• Taking feedback
• Decision making
• Customer focus

It felt less like a traditional exam and more like evaluating how you would behave while working in an engineering team.

Overall Experience

For me, the OA was much more than just DSA.

It tested:

DSA
+
Problem Solving
+
Codebase Understanding
+
Debugging
+
Testing
+
Workplace Decision Making

The biggest takeaway for me was the repository-based question.

2/6 tests passed.

Obviously, I would have liked to do much better, but it also showed me exactly what I need to improve:

I need to become better at entering an unfamiliar codebase, understanding existing code quickly, tracing execution, and debugging systematically.
Bold