← Amazon Interview Insights

Amazon·Software Engineer·Onsite - Coding / Algorithms·Intermediate

Intermediate
Jul 2026

Summary

Amazon SWE coding round, one main problem about making change with minimum pieces plus two follow-ups. Pretty classic greedy territory but the follow-ups pushed it further than I expected.

Questions Asked (3)

Q1

You're implementing the change-dispensing logic for a self-checkout register. Given a dollar amount (up to two decimal places), return the minimum number of physical pieces (bills and coins) needed to make exact change, along with a per-denomination breakdown. Available denominations are $20, $10, $5, $1, $0.25, $0.10, $0.05, and $0.01.

Algorithms & Data Structures
Author's notes

Greedy works here because the denominations are structured nicely.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Use a greedy algorithm that iterates through denominations in descending order, dividing the remaining amount by each denomination to determine the count. Convert the amount to cents (integer) to avoid floating-point precision issues, then convert back for display. Return the total count and a breakdown per denomination.

Pro tip: Mention that while greedy works for this set of denominations (including all standard US coins), it's not universally optimal—e.g., for denominations like 1, 3, 4, greedy fails. This shows you understand the algorithm's limitations and can discuss when dynamic programming would be needed.

1. Clarify requirements and edge cases

Confirm the input range, whether the amount can be zero, and if negative amounts are possible. Discuss rounding for floating-point inputs and ensure exact change is always possible (it is, given $0.01).

2. Choose the algorithm

Select a greedy approach: sort denominations descending, then for each, compute how many fit into the remaining amount. Explain why greedy is optimal for this denomination set (canonical coin system).

3. Handle precision

Convert the dollar amount to cents (multiply by 100 and round to nearest integer) to avoid floating-point errors. Perform all calculations in integer cents, then convert back for output.

4. Implement and test

Write the code, iterating through denominations, updating the remaining amount, and recording counts. Test with edge cases like $0.00, $0.01, $0.99, $1.00, and large amounts like $99.99.

5. Analyze complexity and discuss alternatives

State time complexity O(D) where D is number of denominations (constant here). Mention that for non-canonical systems, dynamic programming (coin change) would be required.

Key Points to Mention

  • Greedy algorithm works because the US denomination system is canonical (optimal for making change).
  • Floating-point precision issues: convert to cents (integer) to avoid errors like 0.1 + 0.2 != 0.3.
  • Time complexity is O(D) where D is the number of denominations (constant), space O(D) for the breakdown.
  • Edge cases: zero amount, amounts less than smallest denomination, and large amounts near the upper limit.
  • The breakdown should include only non-zero denominations for clarity, or include all with zero counts—clarify with interviewer.
  • For non-canonical systems, greedy fails; dynamic programming (coin change) would be needed, but not here.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

How would you modify your loop to exit early once the remaining amount hits zero, instead of continuing to iterate through all denominations?

Algorithms & Data StructuresTechnical Trade-offs
Author's notes

Honestly a one-liner fix, just break out of the loop.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the loop's purpose and the condition for early exit (remaining amount == 0). Then, propose adding a break statement after updating the remaining amount, and discuss any trade-offs such as reduced iterations versus potential code complexity.

Pro tip: Mention that early exit can improve performance but may complicate debugging; suggest adding a comment or logging to track the exit condition. Also, consider edge cases like when the amount is initially zero.

1. Understand the current loop

Explain the existing loop structure and how it iterates through denominations to reduce the remaining amount.

2. Identify exit condition

Determine that the loop should exit when the remaining amount reaches zero, as no further processing is needed.

3. Implement early exit

Add a break statement immediately after updating the remaining amount, checking if it equals zero.

4. Consider trade-offs

Discuss potential impacts on readability, maintainability, and performance, and whether the optimization is worth it.

5. Test edge cases

Mention testing scenarios like amount already zero, amount not reachable, and large denominations.

Key Points to Mention

  • Break statement placement after updating remaining amount
  • Condition check: remaining amount == 0
  • Performance benefit: fewer iterations
  • Trade-off: potential code complexity or reduced clarity
  • Edge cases: zero amount, unreachable amount
  • Alternative: using a while loop with condition

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

The register has a limited stock of each denomination. How do you modify your solution to respect those inventory limits, and what do you return if exact change can't be made?

Algorithms & Data StructuresTechnical Trade-offs
Author's notes

This is where it got more interesting.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Modify the greedy algorithm to track available counts of each denomination and only use a coin if its count is positive. If exact change cannot be made with the available inventory, return a clear signal such as null or an empty list, and explain the trade-offs of this approach.

Pro tip: Mention that with limited inventory, the problem becomes a bounded knapsack or change-making problem, which may require dynamic programming or backtracking to find a feasible solution, and that returning null is often preferred over an empty list to distinguish between 'no change needed' and 'cannot make change'.

1. Clarify the problem and constraints

Confirm the input format, whether denominations are sorted, and the expected return type when exact change is impossible. Ask if the goal is to minimize the number of coins or just find any valid combination.

2. Adapt the algorithm for limited inventory

Modify the greedy approach to decrement available counts as coins are used, or switch to a dynamic programming approach that tracks remaining inventory. Explain why greedy may fail with limited inventory and how DP or backtracking can guarantee a solution if one exists.

3. Handle the impossible case

Decide on a return value (e.g., null, empty list, or a custom error) and justify it. Discuss how the caller should interpret this result and any implications for error handling.

4. Analyze time and space complexity

Compare the complexity of the modified greedy versus DP approach. Mention that DP may be O(amount * number of denominations) but ensures correctness with limited inventory.

5. Discuss trade-offs and edge cases

Talk about when to use greedy (if inventory is plentiful) versus DP (if inventory is tight). Cover edge cases like zero amount, insufficient total inventory, and denominations with zero count.

Key Points to Mention

  • Greedy algorithm may not work with limited inventory; need to consider DP or backtracking.
  • Track remaining counts of each denomination and update them as coins are used.
  • Return null or a specific error to indicate exact change cannot be made, and explain why.
  • Time and space complexity of the chosen approach, especially for DP.
  • Edge cases: amount = 0, no coins available, insufficient total value.
  • Trade-offs between optimality (minimizing coins) and feasibility (just making change).

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.