Solving Coin Change Greedy Approach with Greedy Approach

Introduction and Core Concepts

The coin change greedy approach is one of the most intuitive and widely taught applications of greedy algorithms in computer science. At its core, the problem is deceptively simple: given a set of coin denominations and a target amount, find the minimum number of coins needed to make that amount. The greedy strategy solves this by repeatedly selecting the largest denomination coin that does not exceed the remaining amount, continuing until the target is reached or deemed impossible.

This approach mirrors how humans naturally handle making change in everyday life. When a cashier needs to return $0.63 in change using US coins (quarters, dimes, nickels, pennies), they instinctively hand over two quarters ($0.50), one dime ($0.60), and three pennies ($0.63) without consciously evaluating all possible combinations. This human intuition is precisely what the coin change greedy approach formalizes into an algorithmic procedure: always make the locally optimal choice at each step with the hope that it leads to a globally optimal solution.

Understanding the coin change greedy approach matters far beyond the cash register. It serves as a foundational case study for the entire paradigm of greedy algorithms, illustrating both their power and their limitations. While greedy algorithms are prized for their simplicity, speed, and low memory overhead, they do not always guarantee an optimal solution for every problem variant. The coin change problem is a perfect example where the greedy choice is optimal for certain coin systems (like the US or Euro systems) but fails for others. Learning when and why the greedy approach works is essential for any software engineer, as it develops critical judgment about algorithm selection, correctness proofs, and the trade-offs between efficiency and optimality.

What Defines a Greedy Choice?

A greedy algorithm builds a solution piece by piece, always choosing the next piece that offers the most immediate benefit. For coin change, "benefit" is defined as reducing the remaining amount as quickly as possible, which means picking the largest coin. The algorithm never reconsideres a previous choice; once a coin is taken, it is part of the final solution. This lack of backtracking is what makes greedy algorithms so fast, but also what makes them vulnerable to missing a better global combination.

The coin change problem itself has two common variations: finding the minimum number of coins (optimization version) and counting the number of ways to make change (counting version). The greedy approach is primarily applied to the optimization version. It is crucial to distinguish the problem statement from the algorithmic technique used to solve it. Dynamic programming can solve the optimization version for any coin system, while the greedy approach can only solve it correctly for specific, so-called "canonical" coin systems.

Canonical vs. Non-Canonical Coin Systems

A coin system is considered canonical if the greedy algorithm always yields an optimal (minimum coin count) solution for any amount. The US coin system [1, 5, 10, 25] and the Euro system [1, 2, 5, 10, 20, 50, 100, 200] are canonical. In contrast, a system like [1, 3, 4] is non-canonical. For an amount of 6, the greedy approach would pick 4 + 1 + 1 (3 coins), while the optimal solution is 3 + 3 (2 coins). Recognizing this distinction is the most important conceptual takeaway when studying the coin change greedy approach, as it determines whether the algorithm is applicable at all.

How It Works

The mechanism of the coin change greedy approach is straightforward and can be broken down into a deterministic sequence of steps. First, the available coin denominations are sorted in descending order, from largest to smallest. This sorting step is critical because it ensures the algorithm always considers the most valuable coin first. Without sorting, the greedy property cannot be enforced.

Second, the algorithm initializes a result collection (often a dictionary or list) to store the count of each coin used and a variable to track the remaining amount to be formed. It then iterates through the sorted denominations. For each coin, it determines the maximum number of times that coin can be used without exceeding the remaining amount. This is typically calculated using integer division: count = remaining // coin. The algorithm adds those coins to the solution and reduces the remaining amount accordingly: remaining -= count * coin.

Third, the process continues to the next smaller denomination until the remaining amount becomes zero, indicating success, or all denominations have been exhausted. If after checking all coins the remaining amount is still greater than zero, it means the amount cannot be formed with the given coin system (this only happens if the smallest coin is not 1). The algorithm's correctness hinges entirely on the assumption that taking as many large coins as possible now will not prevent a better overall solution later.

The Greedy Choice Property and Optimal Substructure

For a greedy algorithm to be correct, the problem must exhibit two properties. The first is the greedy choice property: a globally optimal solution can be arrived at by making a locally optimal (greedy) choice. For canonical coin systems, this holds because any optimal solution for an amount can be transformed to include the largest coin without increasing the number of coins. The second is optimal substructure: an optimal solution to the problem contains optimal solutions to subproblems. After choosing a coin of value c, the remaining problem is to optimally make change for amount - c, which is a smaller instance of the same problem.

Proving that a coin system is canonical is non-trivial. A classic result by Pearson shows that to test canonicity, it is sufficient to check amounts up to a certain bound (specifically, up to c_{n} + c_{n-1} where c_{n} is the largest denomination). This theoretical depth is why interviews and academic courses emphasize not just implementing the greedy approach, but also understanding its proof of correctness and its failure modes.

Why Sorting Matters

Sorting is not just a preprocessing convenience; it is integral to the algorithm's logic. Consider coins [1, 10, 25] and amount 30. If iterated in ascending order, the algorithm would incorrectly take thirty 1-cent coins. Sorted descending, it correctly takes one 25-cent coin and five 1-cent coins. The time complexity of sorting is often the dominant factor in the overall runtime, which is why many implementations assume the input is already sorted or sort it once upfront. In production systems where the coin system is fixed, sorting can be done offline.

Implementation

Implementing the coin change greedy approach in Python is concise, but a robust implementation must handle edge cases, input validation, and clear output formatting. Below are several implementations progressing from a basic version to more production-ready variants.

The first example demonstrates the canonical greedy algorithm. It assumes coins are positive integers, includes validation, and returns both the total coin count and the breakdown of coins used. Note the use of integer division and modulo operations for efficiency.

def coin_change_greedy(coins, amount):
    """
    Solve coin change using the greedy approach.
    Returns minimum coins for canonical systems.
    
    Args:
        coins (list): List of coin denominations (e.g., [1, 5, 10, 25])
        amount (int): Target amount to make change for
    
    Returns:
        dict: Mapping of coin -> count, or None if impossible
    """
    if amount < 0:
        raise ValueError("Amount cannot be negative")
    if amount == 0:
        return {}
    if not coins:
        return None

    # Sort coins in descending order for greedy selection
    sorted_coins = sorted(coins, reverse=True)
    remaining = amount
    result = {}

    for coin in sorted_coins:
        if remaining == 0:
            break
        if coin <= 0:
            raise ValueError("Coin denominations must be positive")
        if coin > remaining:
            continue
        
        # Use as many of current coin as possible
        count = remaining // coin
        if count > 0:
            result[coin] = count
            remaining -= count * coin  # Equivalent to remaining % coin

    # If remaining > 0, amount cannot be formed (e.g., coins=[5,10], amount=3)
    if remaining != 0:
        return None

    return result

# Example: US coins
us_coins = [1, 5, 10, 25]
print(coin_change_greedy(us_coins, 63))  # {25: 2, 10: 1, 1: 3}
print(coin_change_greedy(us_coins, 41))  # {25: 1, 10: 1, 5: 1, 1: 1}

The second implementation adds a helper to calculate the total number of coins and demonstrates handling of a non-canonical system where the greedy result is suboptimal. This is useful for educational purposes and for building a hybrid system that can detect potential failures.

def greedy_with_count(coins, amount):
    """Wrapper that returns total coin count and breakdown."""
    breakdown = coin_change_greedy(coins, amount)
    if breakdown is None:
        return None, None
    total_coins = sum(breakdown.values())
    return total_coins, breakdown

def demonstrate_greedy_limitation():
    """Show where greedy fails vs optimal."""
    # Non-canonical system: [1, 3, 4]
    coins = [1, 3, 4]
    amount = 6
    
    greedy_count, greedy_breakdown = greedy_with_count(coins, amount)
    print(f"Greedy for {amount} with {coins}: {greedy_breakdown} -> {greedy_count} coins")
    # Greedy picks 4 + 1 + 1 = 3 coins
    # Optimal is 3 + 3 = 2 coins (requires DP to find)
    
    # Another failure: [1, 10, 25] is actually canonical for US, 
    # but [1, 15, 25] is not
    coins2 = [1, 15, 25]
    amount2 = 30
    g_count2, g_break2 = greedy_with_count(coins2, amount2)
    print(f"Greedy for {amount2} with {coins2}: {g_break2} -> {g_count2} coins")
    # Greedy: 25 + 1*5 = 6 coins
    # Optimal: 15 + 15 = 2 coins

demonstrate_greedy_limitation()

For scenarios where the coin system is fixed and many queries are made (e.g., a vending machine processing thousands of transactions), we can optimize by pre-sorting and using a class-based design. This avoids re-sorting on every call and provides a clean API.

class GreedyCoinChanger:
    """Optimized changer for fixed canonical coin systems."""
    def __init__(self, coins):
        if not coins or any(c <= 0 for c in coins):
            raise ValueError("Coins must be non-empty and positive")
        # Pre-sort once during initialization
        self.coins = sorted(coins, reverse=True)
        # Verify smallest coin is 1 for guaranteed solvability
        if self.coins[-1] != 1:
            print("Warning: Smallest coin != 1, some amounts may be impossible")

    def make_change(self, amount):
        """Return breakdown for amount using pre-sorted coins."""
        if amount < 0:
            raise ValueError("Amount must be non-negative")
        
        remaining = amount
        result = {}
        for coin in self.coins:
            if remaining == 0:
                break
            if coin > remaining:
                continue
            count = remaining // coin
            result[coin] = count
            remaining %= coin  # More efficient than subtraction

        return None if remaining != 0 else result

    def min_coins(self, amount):
        """Return just the minimum coin count."""
        breakdown = self.make_change(amount)
        return None if breakdown is None else sum(breakdown.values())

# Usage: Pre-sort once, query many times
changer = GreedyCoinChanger([1, 5, 10, 25, 50, 100])
print(changer.make_change(187))  # {100: 1, 50: 1, 25: 1, 10: 1, 1: 2}
print(changer.min_coins(187))    # 6

A final variant shows how to integrate a fallback to dynamic programming when the system might be non-canonical. This hybrid approach uses greedy for speed when safe, but can verify optimality for critical applications.

def coin_change_dp(coins, amount):
    """DP solution (always optimal) for comparison/fallback."""
    INF = float('inf')
    dp = [INF] * (amount + 1)
    dp[0] = 0
    # dp[i] = min coins to make amount i
    for i in range(1, amount + 1):
        for coin in coins:
            if coin <= i and dp[i - coin] + 1 < dp[i]:
                dp[i] = dp[i - coin] + 1
    return dp[amount] if dp[amount] != INF else None

def hybrid_change(coins, amount):
    """Use greedy, but warn if DP finds better solution."""
    greedy_breakdown = coin_change_greedy(coins, amount)
    if greedy_breakdown is None:
        return None
    
    greedy_count = sum(greedy_breakdown.values())
    dp_count = coin_change_dp(coins, amount)
    
    if dp_count is not None and dp_count < greedy_count:
        print(f"Warning: Greedy suboptimal! Greedy={greedy_count}, Optimal={dp_count}")
    
    return greedy_breakdown

# Canonical system: no warning
print(hybrid_change([1, 5, 10, 25], 63))
# Non-canonical: will warn
print(hybrid_change([1, 3, 4], 6))

Step-by-Step Example

To solidify understanding, let us walk through a concrete execution of the coin change greedy approach. We will use the canonical US coin system [1, 5, 10, 25] and a target amount of 87 cents. The goal is to find the minimum number of coins. We will trace the algorithm's state at each iteration.

First, the algorithm sorts the denominations in descending order, yielding [25, 10, 5, 1]. It initializes remaining = 87 and an empty result map {}. The iteration begins with the largest coin, 25. The algorithm asks: how many 25-cent coins can we use without exceeding 87? The calculation is 87 // 25 = 3 with a remainder of 87 % 25 = 12. It records 25: 3 and updates remaining = 12. This is the greedy choice in action: take as much value as possible from the largest denomination.

Next, the algorithm moves to the 10-cent coin. With remaining = 12, it computes 12 // 10 = 1, remainder 2. It adds 10: 1 to the result and sets remaining = 2. The total value accounted for so far is 3*25 + 1*10 = 85 cents. The algorithm then considers the 5-cent coin. Since 5 > 2, it skips this denomination entirely; no 5-cent coins are used. This skipping logic is crucial for correctness and prevents adding coins that would overshoot the target.

Finally, the algorithm processes the 1-cent coin. With remaining = 2, it calculates 2 // 1 = 2, remainder 0. It adds 1: 2 and sets remaining = 0. The loop terminates because the remaining amount is zero. The final breakdown is {25: 3, 10: 1, 1: 2}, totaling 3 + 1 + 2 = 6 coins. For US coins, this is provably optimal. No other combination of these denominations can make 87 cents with fewer than 6 coins.

Contrasting with a Failure Case

Now consider the same step-by-step process with a non-canonical system [1, 3, 4] and amount 6. Sorted descending, the coins are [4, 3, 1]. Starting with remaining = 6, the algorithm takes 6 // 4 = 1 coin of value 4, leaving remaining = 2. It then considers 3: since 3 > 2, it skips. Finally, it takes 2 // 1 = 2 pennies, leaving remaining = 0. The greedy solution is {4: 1, 1: 2} for 3 coins. However, the optimal solution is {3: 2} for only 2 coins. This walkthrough visually demonstrates why the greedy choice can be a trap: taking the largest coin (4) blocked the ability to use two 3's, which would have been globally better. This is the core reason why dynamic programming is required for arbitrary coin systems.

Visual Trace Table

For the successful US coin example (87 cents), the trace can be summarized as follows: Iteration 1 (25): count 3, remaining 12; Iteration 2 (10): count 1, remaining 2; Iteration 3 (5): count 0, remaining 2; Iteration 4 (1): count 2, remaining 0. The monotonic decrease of the remaining amount and the one-pass nature of the algorithm are evident. There is no backtracking or reconsideration of earlier decisions, which is the hallmark of greediness.

Complexity Analysis

Analyzing the time and space complexity of the coin change greedy approach reveals why it is so attractive for canonical systems. Its efficiency is a major advantage over more general but slower methods like dynamic programming.

The algorithm's performance is dominated by two operations: sorting and the greedy selection loop. If the coin denominations are provided unsorted, sorting takes O(k log k) time where k is the number of denominations. The subsequent loop iterates over each denomination exactly once, performing constant-time arithmetic (division and modulo) per coin, resulting in O(k) time. If the coins are already sorted, the total time is simply O(k). This is remarkably fast, especially when k is small (typically < 10 for real currencies) and independent of the target amount n.

This independence from n is a critical distinction. Dynamic programming solutions have a time complexity of O(k * n), which grows linearly with the amount. For a large amount like $1,000,000 cents ($10,000), DP would require millions of operations, while the greedy approach would still only need to iterate over a handful of coin types. Space complexity is equally favorable. The greedy algorithm uses O(k) auxiliary space to store the result map in the worst case (if every denomination is used) and O(1) extra space beyond that. Some implementations that only return the count use O(1) space. In contrast, DP requires an array of size n+1, leading to O(n) space.

It is important to note that these complexities assume arithmetic operations are O(1). For extremely large amounts that exceed typical integer limits, the cost of division could grow, but for all practical monetary amounts, this assumption holds. The best, average, and worst cases for the greedy loop are all O(k) because it always scans all denominations in the worst case (when the amount requires pennies). There is no input-dependent branching that significantly alters the asymptotic behavior.

For completeness, if we consider n as the target amount value, the greedy approach is often described as O(k log k) or O(k), while DP is O(n*k). This makes greedy exponentially faster with respect to n when n is large. The trade-off, of course, is the loss of generality. The table above clearly shows that greedy is the superior choice when the coin system is known to be canonical and performance is critical.

Variations and Optimizations

While the basic coin change greedy approach is simple, several variations and optimizations adapt it to more complex real-world constraints and improve its robustness.

One common variation is the limited supply problem. The classic greedy algorithm assumes an infinite supply of each coin denomination. In reality, a cash register or vending machine has a finite inventory. The optimization here is to cap the number of coins taken at each step by the available supply: count = min(remaining // coin, supply[coin]). This small change makes the algorithm more practical but also introduces a new failure mode where a greedy choice might exhaust a large coin needed later, even in a canonical system. For limited supply, even canonical systems may require DP or backtracking to find a feasible optimal solution.

Another important variation is handling non-canonical detection. Instead of blindly trusting greediness, a robust system can include a verification step. As mentioned earlier, Pearson's algorithm can test if a coin system is canonical by checking a bounded set of amounts. An optimized implementation might run this check once at startup. If the system is found to be non-canonical, it can automatically switch to a DP fallback for all future queries. This hybrid strategy combines the speed of greedy for the common canonical case with the correctness of DP for the general case.

A third optimization involves early termination and branch pruning. If the remaining amount becomes zero, the loop can break immediately without checking smaller denominations. While this does not change the worst-case complexity, it improves average-case performance, especially for amounts that are multiples of large denominations. Additionally, using modulo operation (remaining %= coin) instead of repeated subtraction is a micro-optimization that leverages hardware-efficient division.

Floating-Point and Currency Handling

A subtle but critical optimization for real financial software is avoiding floating-point arithmetic. Representing $1.37 as a float can lead to precision errors (e.g., 1.37 * 100 = 136.999...). The best practice is to convert all monetary values to the smallest integer unit (cents) before applying the greedy algorithm. All coin denominations and the target amount should be integers. This ensures exact division and modulo operations and prevents off-by-one errors that could cause incorrect change.

Generalization to Other Greedy Problems

The coin change greedy approach is a specific instance of a broader class of optimization techniques. Its logic can be generalized to other problems like fractional knapsack, activity selection, and Huffman coding. Recognizing this pattern helps in designing new greedy algorithms: sort by a key metric (value density, finish time, frequency), then iteratively pick the best available option. Studying coin change provides a template for reasoning about these other problems.

Real-World Applications

Although the coin change problem is often presented as an academic exercise, its greedy solution powers numerous real-world systems where speed and simplicity are paramount. The most obvious application is in financial and retail systems. Point-of-sale (POS) terminals, vending machines, ATMs, and automated ticketing kiosks all need to dispense change quickly. These systems use canonical currency denominations, so the greedy approach is both optimal and maximally efficient. An ATM dispensing $375 with bills [1, 5, 10, 20, 50, 100] will greedily use 3x100 + 1x50 + 1x20 + 1x5, minimizing the number of bills dispensed, which reduces mechanical wear and transaction time.

Beyond physical currency, the same logic applies to resource allocation in web servers and cloud infrastructure. Consider a load balancer that needs to allocate a requested amount of memory or compute units using fixed-size blocks (e.g., 1GB, 4GB, 16GB instances). To minimize the number of instances (and thus management overhead), a greedy allocation that uses the largest possible blocks first is ideal, provided the block sizes form a canonical system (e.g., powers of two). Similarly, content delivery networks (CDNs) that cache content in chunks of varying sizes can use a greedy strategy to fulfill a storage request with the fewest chunks.

In networking and databases, the greedy coin change principle appears in packet fragmentation and page allocation. IP packets may need to be fragmented into Maximum Transmission Units (MTUs) of specific sizes. Database storage engines allocate disk pages of fixed sizes (e.g., 4KB, 8KB, 16KB) to store records. Fulfilling a request for a contiguous block of storage with the fewest pages reduces I/O operations and fragmentation. When page sizes are canonical (often powers of two), greedy allocation is optimal.

Even in manufacturing and logistics, the analogy holds. Cutting stock problems, where raw materials of standard lengths must be cut to fulfill orders, can use a greedy approach to minimize the number of cuts if the stock sizes are well-chosen. While many industrial cutting problems require more complex optimization due to waste minimization, the greedy heuristic provides a fast, good-enough solution for canonical stock sets. The key insight across all these domains is that whenever a resource comes in discrete, standardized denominations and the goal is to minimize the count of items used, the coin change greedy approach is a candidate solution—provided the denomination system is verified to be canonical for the required range of amounts.

Comparison with Alternatives

Choosing the right algorithm for the coin change problem depends on the properties of the coin system and the performance requirements. The greedy approach is not the only option, and understanding its alternatives is crucial for making informed engineering decisions.

The primary alternative is Dynamic Programming (DP), which comes in two flavors: bottom-up (tabulation) and top-down (memoization). DP guarantees an optimal solution for any coin system, canonical or not, by systematically exploring all possibilities and storing the best solution for each sub-amount. Its time complexity is O(k * n) and space is O(n), where n is the target amount. This makes it much slower and more memory-intensive than greedy for large n, but it is the only correct choice for arbitrary denominations.

Another alternative is Brute Force / Recursion without memoization. This approach tries every combination of coins recursively, leading to exponential time complexity O(k^n) in the worst case. It is only useful for very small amounts and is primarily of theoretical interest to illustrate why DP's memoization is necessary.

Breadth-First Search (BFS) can also be applied by modeling the problem as a shortest path in a graph where nodes are amounts and edges represent adding a coin. BFS finds the minimum number of coins and has similar complexity to DP, O(k * n), but can be slightly more intuitive for some and can be optimized to find a solution without computing all subproblems if the target is small.

Finally, for very large amounts and specific coin systems, mathematical optimization using number theory (like the Chicken McNugget theorem for two coins) can provide O(1) formulas, but these are highly specialized and not generalizable.

In practice, the decision tree is simple: if you control the coin system and can ensure it is canonical (as with most national currencies), use the greedy approach for its superior speed and simplicity. If the coin system is arbitrary, user-provided, or must handle limited supply optimally, use dynamic programming. Many production systems implement a hybrid that defaults to greedy and falls back to DP when a non-canonical system is detected or when the greedy solution is proven suboptimal for a given amount.

Common Mistakes and Best Practices

Even though the coin change greedy approach is conceptually simple, developers frequently make mistakes that lead to incorrect results, subtle bugs, or inefficient code. Awareness of these pitfalls is essential for writing reliable software.

The most common and critical mistake is assuming greedy is always optimal. Novice programmers often implement the greedy algorithm for any coin system without verifying canonicity. This leads to silent failures where the algorithm returns a valid but non-minimal solution. For example, using greedy with coins [1, 3, 4] for amount 6 returns 3 coins instead of the optimal 2. The best practice is to either prove the system is canonical, document the assumption explicitly, or implement a verification step that compares the greedy result against a DP solution for a sample of amounts during testing.

A second frequent error is failing to sort the denominations. If the input array is [1, 25, 10, 5] and the code iterates in the given order, it will incorrectly prioritize 1-cent coins. Always sort in descending order at the start of the function or require pre-sorted input and validate it. Another related mistake is sorting in ascending order and then iterating from the end, which is correct but less readable than a direct descending sort.

Third, using floating-point numbers for currency is a notorious source of bugs. As discussed, 0.1 + 0.2 != 0.3 in binary floating point. An amount like $0.30 might be represented as 0.299999..., causing amount // 0.25 to yield 1 instead of the expected 1 with remainder 0.05. The best practice is to work exclusively in integer cents (or the smallest currency unit) and only format as dollars/cents for display.

Best Practices Checklist

• Validate Inputs: Check that amount is non-negative, coins are positive integers, and the coin list is non-empty. Raise clear exceptions for invalid inputs.
• Handle Impossible Amounts: If the smallest coin is not 1, some amounts cannot be formed. Return None or raise an exception rather than returning a partial solution. Always check if remaining != 0 after the loop.
• Document Assumptions: Add a docstring comment stating "This function assumes a canonical coin system. For arbitrary systems, use DP." This prevents future maintainers from misusing the function.
• Test Edge Cases: Test with amount 0 (should return 0 coins), amount 1, large amounts, and amounts that are exact multiples of large coins. Include tests for known non-canonical failure cases if the function might receive arbitrary input.
• Prefer Modulo for Efficiency: Use remaining %= coin instead of remaining -= count * coin for clarity and to leverage optimized division.
• Consider Limited Supply: If inventory is finite, extend the algorithm to track supply and be aware that greedy may no longer be optimal even for canonical systems. In such cases, DP with bounded knapsack logic is safer.

Finally, a subtle mistake is not handling duplicate denominations. If the input is [1, 5, 5, 10, 25], a naive implementation might count the 5-cent coin twice. Deduplicate and sort the coin list first using sorted(set(coins), reverse=True) to ensure correctness and avoid redundant iterations.

Interview Questions

The coin change problem is a staple of technical interviews because it tests understanding of greedy algorithms, dynamic programming, and the ability to reason about correctness. Here are common questions and how to approach them.

Q1: Implement a greedy coin change function and explain when it fails.

This question assesses basic implementation and conceptual depth. A strong answer provides clean Python code that sorts coins descending, uses integer division, and returns a breakdown. Crucially, it must also provide a counterexample where greedy fails, such as coins [1, 3, 4] and amount 6, and explain why: the greedy choice of 4 blocks the optimal 3+3 solution. Mentioning canonical vs. non-canonical systems and stating that US coins are canonical demonstrates advanced knowledge. Interviewers look for the candidate to volunteer the limitation without being prompted.

Q2: Given coins [1, 5, 10, 25] and amount 63, how many coins does the greedy approach use? Walk through it.

This is a step-by-step execution test. The expected walkthrough is: sorted [25,10,5,1], 63//25=2 (remainder 13), 13//10=1 (remainder 3), 5 > 3 skip, 3//1=3 (remainder 0). Total 2+1+3=6 coins (2 quarters, 1 dime, 3 pennies). A good candidate will also state the time complexity O(k log k) and space O(k) and note that this is optimal for US coins. Some interviewers will follow up by asking what happens with amount 30 and coins [1, 15, 25] to see if the candidate can spot the greedy failure (25+5*1=6 coins vs optimal 15+15=2).

Q3: Compare the greedy approach vs. dynamic programming for coin change. When would you use each?

This evaluates system design judgment. The answer should contrast time/space: greedy O(k log k) time, O(k) space, fast but only optimal for canonical systems; DP O(k*n) time, O(n) space, always optimal but slower for large n. The candidate should state: use greedy when the coin system is known canonical (e.g., standard currencies) and performance matters for many queries or large amounts; use DP when the system is arbitrary, when limited supply must be handled optimally, or when correctness is more important than speed. Mentioning a hybrid approach (try greedy, verify with DP) shows mature engineering thinking.

Q4: How would you modify the greedy algorithm if each coin has a limited supply?

This tests adaptability. The modification is to change count = remaining // coin to count = min(remaining // coin, supply[coin]). However, the deeper insight is that with limited supply, even a canonical system can make greedy suboptimal. Example: coins [1, 5, 10, 25] with supply {25:1, 10:3} and amount 30. Greedy takes 25+5*1 (needs five 1's, but if 1's are limited, it might fail while 10*3 would succeed). The candidate should note that for limited supply, a DP solution modeled as a bounded knapsack is generally required for optimality, and greedy becomes a heuristic.

Q5: How do you prove that the US coin system is canonical? Or, how would you test if a given system is canonical?

This is an advanced theory question. A complete proof for US coins is lengthy, but the candidate can outline the approach: show the greedy choice property holds for each denomination. For testing an arbitrary system, the candidate should mention Pearson's algorithm: it suffices to check all amounts up to a bound (c_n + c_{n-1}) where greedy is compared to DP optimal. If greedy matches DP for all amounts in that range, the system is canonical. Alternatively, for interview purposes, a simpler brute-force test for all amounts up to a reasonable limit (e.g., 100 or 1000) comparing greedy vs DP can be proposed as a practical verification method, acknowledging it is not a formal proof for all n but is sufficient for testing.