In this article
Prepare for Amazon SDE II by separating the online assessment, live coding, systems design, and discussion of your experience. This guide connects official candidate resources to an original interval exercise and a practical review plan. The exercises are nrml preparation material, not reported Amazon questions.
Confirm that the published SDE II track matches your invitation
Amazon’s SDE II preparation page describes an application, an online assessment, and an interview loop. It lists four 55-minute loop interviews and at least one systems-design question. Those details concern this published SDE II track; they should not be copied into a university, senior, specialist, or differently specified invitation. Amazon SDE II interview preparation
Start a preparation sheet with your target role, current stage, preferred language, invitation deadlines, and permitted tools. Put unanswered questions beside the stage they affect. A missing design-session format is different from an unclear online-assessment rule. Resolve each with the recruiter instead of building your entire plan around another candidate’s timetable.
The material below is our suggested rehearsal. It does not establish a passing score, predict a question, or confirm that you may use an assistant in your assessment. You can use AI to critique private preparation when appropriate, but follow the explicit rules for each actual stage. Preparation software offering AI does not change an employer’s permissions.
Rehearse the timed coding portion as a complete session
The dedicated SDE II assessment guide describes a 90-minute coding section with two questions, followed by design and work-style components. It calls coding the only timed section and recommends reserving two hours overall. Its non-coding estimates differ from those on the main SDE II page, so use the invitation for your actual logistics. Amazon SDE II online assessment preparation
For an original rehearsal, select two unfamiliar tasks before starting the clock. Skim both, identify the easier complete solution, and reserve time to run boundary cases. Record the state of each attempt when time expires. Repairing the code afterward is valuable practice, but keep that result separate from what you completed during the timed attempt.
Review why you lost time. If you spent fifteen minutes debugging a parser that the task did not require, the next session should simplify input handling. If you understood the algorithm but could not state an invariant, practice explaining one loop before adding more problems. This diagnosis gives your next session a purpose beyond increasing a completion count.
Use a maintenance-window exercise to rehearse precise coding
Here is an original exercise unrelated to any claimed Amazon question. A service receives maintenance windows as integer start/end pairs. Every start must be strictly smaller than its end. Return sorted, nonoverlapping windows covering the same time, merging windows that overlap or touch. Leave the caller’s input unchanged. Empty input returns an empty list.
For [(8, 12), (3, 9), (4, 5), (12, 14)], the answer is [(3, 14)]. Trace the nested interval (4, 5): replacing the current end of 9 with 5 would shrink coverage and incorrectly separate the later interval. Taking the maximum end preserves the union. Touching endpoints merge because this exercise explicitly says they do, not because every scheduling application should use that rule.
The following script checks nesting, touching boundaries, separate windows, empty input, invalid endpoints, and unchanged input. Use it to practice explaining the loop invariant: completed output windows are sorted and disjoint, and the last window contains every processed interval that overlaps its current connected group. The implementation sorts a copy, then extends only the final group.
def merge_windows(windows):
ordered = []
for start, end in windows:
if type(start) is not int or type(end) is not int or start >= end:
raise ValueError('expected increasing integer endpoints')
ordered.append((start, end))
ordered.sort()
result = []
for start, end in ordered:
if not result or start > result[-1][1]:
result.append((start, end))
else:
result[-1] = (result[-1][0], max(result[-1][1], end))
return result
windows = [(8, 12), (3, 9), (4, 5), (12, 14)]
before = list(windows)
assert merge_windows(windows) == [(3, 14)]
assert windows == before
assert merge_windows([(3, 9), (4, 5)]) == [(3, 9)]
assert merge_windows([(1, 2), (2, 3)]) == [(1, 3)]
assert merge_windows([(1, 2), (4, 6)]) == [(1, 2), (4, 6)]
assert merge_windows([]) == []
for invalid in [[(2, 2)], [(4, 1)], [(True, 4)], [(1, 2.5)]]:
try:
merge_windows(invalid)
except ValueError:
continue
raise AssertionError(f'accepted invalid endpoints: {invalid!r}')
print('Maintenance-window rehearsal checks passed.')Explain the invariant, cost, and deliberately unsupported inputs
After running the example, replace the maximum-end calculation with the incoming end in a temporary copy. The nested-window assertion should fail. Restore the correct implementation and run the suite again. This checks a specific likely error while keeping your explanation grounded in an observable difference. Do not change the expected answer just to match the mutation.
The sort costs O(n log n); the scan is linear. The implementation uses O(n) additional space for the copied intervals and output. It assumes every input item is a pair and does not define a special error for malformed record shapes. State that boundary rather than claiming exhaustive validation. If the interviewer changes the input contract, handle that change explicitly.
Amazon’s technical-topics guide emphasizes applying fundamentals and practicing outside an IDE. Amazon software development interview topics For this rehearsal, close autocomplete for one attempt and explain the merge condition aloud. On another attempt, ask a partner to change whether touching windows should merge. The important observation is whether you can identify the exact condition and tests affected by that change.
Turn the coding exercise into a requirements-led design discussion
Extend the fictional service: many teams now submit maintenance windows, and customers need a daily view for their region. Before drawing components, define whether the view includes proposed or approved windows, what a region means, and how quickly an edit must become visible. Decide whether users need a current view or an auditable history of previous decisions.
Begin with a write API, durable records, and a query path that applies the selected region and time range. Discuss when on-demand merging is adequate and when a stored projection might be justified. Introduce one failure: a worker crashes after updating the projection but before acknowledging the event. Explain how a repeated event avoids corrupting the result.
This follow-up is original design practice, not an official Amazon rubric. Its purpose is to make you connect a data invariant to persistence, concurrency, and operations. A useful design answer identifies a consistency choice and its consequence. A larger diagram without a defined update contract does not explain how the customer gets the correct schedule.
Prepare real experience with decisions and consequences
Pair the technical rehearsal with one real experience from your own work. Choose a situation where your initial plan changed after new evidence: a customer report, a failed test, a capacity constraint, or a disagreement with a teammate. Separate what you personally did from what the team accomplished, and use measurements only when you can substantiate them.
Write a short outline covering the problem, your responsibility, the alternatives, your decision, and the observed outcome. Then let a partner ask what you would do differently and which fact would have changed your choice. Avoid inventing a cleaner ending or forcing a technical story into a claim of impact you cannot defend. Specific uncertainty is more informative than a memorized success narrative.
Finish each practice session with one next action: simplify an invariant explanation, add a missing boundary case, compare two storage choices, or clarify a real project decision. Keep this separate from any claim of readiness. Finishing a checklist demonstrates practice completed; it does not predict a hiring decision.
Common questions about Amazon SDE II preparation
Is this an AI-enabled interview guide? It is a company preparation guide. The official pages reviewed here do not establish blanket permission to use AI. Check the rules attached to your own assessment and live sessions before using any assistant.
Should I memorize the maintenance-window solution? No. Use it to rehearse a contract, counterexample, invariant, and follow-up change. Then choose a different domain and repeat the reasoning without the reference implementation. The exercise is deliberately small so your explanation can be inspected.
Should every role use the same schedule? No. Match the role level and stage in your invitation. The published SDE II resources are a starting point, while your recruiter resolves role-specific details. Keep coding, design, and discussion of real work in the plan instead of treating any one of them as a substitute for the others.
Sources & editorial notes
This article was authored with AI using primary-source research and an automated technical review. It has not been reviewed by a human. Code examples are illustrative; run and verify them in your own environment.
- Amazon SDE II interview preparation
Supports the published SDE II process, loop count and design scope; not a universal format or AI permission. Accessed October 31, 2026; access date is not a publication date.
- Amazon SDE II online assessment preparation
Supports the timed coding component and OA structure; non-coding estimates differ between official pages. Accessed October 31, 2026; access date is not a publication date.
- Amazon software development interview topics
Supports applying fundamentals and preparation outside an IDE; the maintenance-window exercise and plan are original nrml material. Accessed October 31, 2026; access date is not a publication date.
Put the reading into practice
Work through an existing repository, review AI suggestions, and test the decisions behind your changes.
Explore practice problems