Peeking Iterator - Practice Coding Problems

Peeking Iterator - Problem

Design a Peeking Iterator - Create an enhanced iterator that extends the functionality of a standard iterator by adding a peek() operation.

You're given a basic iterator that supports next() and hasNext() operations. Your task is to implement a PeekingIterator class that adds the ability to look ahead at the next element without consuming it.

Key Requirements:

next() - Returns the next element and advances the iterator
hasNext() - Returns true if more elements exist
peek() - Returns the next element without advancing the iterator

The challenge is maintaining the iterator's state while supporting the peek functionality efficiently. This pattern is commonly used in parsers, tokenizers, and streaming data processors where you need to make decisions based on upcoming elements.

Input & Output

example_1.py — Basic Usage

$ Input: Iterator: [1, 2, 3] Operations: ["peek", "next", "peek", "next", "hasNext"]

› Output: [1, 1, 2, 2, true]

💡 Note: peek() returns 1 without advancing, next() returns 1 and advances, peek() returns 2, next() returns 2 and advances, hasNext() returns true since 3 remains

example_2.py — Multiple Peeks

$ Input: Iterator: [1, 2] Operations: ["peek", "peek", "next", "peek", "next", "hasNext"]

› Output: [1, 1, 1, 2, 2, false]

💡 Note: Multiple consecutive peeks return the same value without advancing. After consuming all elements, hasNext() returns false

example_3.py — Single Element

$ Input: Iterator: [42] Operations: ["hasNext", "peek", "hasNext", "next", "hasNext"]

› Output: [true, 42, true, 42, false]

💡 Note: Single element case - peek doesn't affect hasNext() result until element is consumed via next()

Visualization

Tap to expand

Understanding the Visualization

Initial State

Iterator is ready, no element cached yet

First Peek

Cache the next element from underlying iterator

Multiple Peeks

Return cached element without re-fetching

Next Operation

Return cached element and clear cache

Direct Next

If no cache, directly get from underlying iterator

Key Takeaway

🎯 Key Insight: The optimal solution balances memory efficiency with functionality by caching only what's needed, when it's needed - a perfect example of lazy evaluation in iterator design.

Time & Space Complexity

Time Complexity

⏱️

O(1)

All operations (peek, next, hasNext) are constant time

✓ Linear Growth

Space Complexity

O(1)

Only stores one cached element and iterator reference

✓ Linear Space

Constraints

1 ≤ nums.length ≤ 1000
-1000 ≤ nums[i] ≤ 1000
At most 1000 calls will be made to next(), hasNext(), and peek()
Follow up: How would you extend this to support multiple peek() calls ahead?

Asked in

G Google 45 a Amazon 38 Apple 32 ⊞ Microsoft 28

The optimal solution uses a cached element approach with O(1) space complexity. By maintaining a single cached value and a boolean flag, we can efficiently implement peek() functionality while preserving the lazy evaluation principle of iterators. This approach only fetches the next element when peek() is first called, making it memory-efficient and suitable for large or infinite data streams.

Common Approaches

Approach	Time	Space	Notes
✓ Cached Next Element (Optimal)	O(1)	O(1)	Cache only the next element on-demand for efficient peeking
Store All Elements (Brute Force)	O(n)	O(n)	Load all iterator elements into an array upfront

Cached Next Element (Optimal) — Algorithm Steps

Initialize with reference to underlying iterator
Use cached value and hasPeeked flag for state management
On first peek(), cache the next element from iterator
next() returns cached value if available, otherwise gets from iterator
hasNext() checks both cached state and underlying iterator

Visualization

Tap to expand

Step-by-Step Walkthrough

Initial State

Iterator ready, no cached element

First Peek

Cache next element from underlying iterator

Subsequent Peeks

Return cached element without advancing

Next Call

Return cached element and clear cache

Code -

solution.c — C

typedef struct {
    struct Iterator* iterator;
    bool hasPeeked;
    int peekedValue;
} PeekingIterator;

PeekingIterator* peekingIteratorCreate(struct Iterator* iter) {
    PeekingIterator* obj = malloc(sizeof(PeekingIterator));
    obj->iterator = iter;
    obj->hasPeeked = false;
    obj->peekedValue = 0;
    return obj;
}

int peekingIteratorPeek(PeekingIterator* obj) {
    if (!obj->hasPeeked) {
        obj->peekedValue = iteratorNext(obj->iterator);
        obj->hasPeeked = true;
    }
    return obj->peekedValue;
}

int peekingIteratorNext(PeekingIterator* obj) {
    if (obj->hasPeeked) {
        obj->hasPeeked = false;
        return obj->peekedValue;
    }
    return iteratorNext(obj->iterator);
}

bool peekingIteratorHasNext(PeekingIterator* obj) {
    return obj->hasPeeked || iteratorHasNext(obj->iterator);
}

Time & Space Complexity

Time Complexity

⏱️

O(1)

All operations (peek, next, hasNext) are constant time

✓ Linear Growth

Space Complexity

O(1)

Only stores one cached element and iterator reference

✓ Linear Space

Constraints

1 ≤ nums.length ≤ 1000
-1000 ≤ nums[i] ≤ 1000
At most 1000 calls will be made to next(), hasNext(), and peek()
Follow up: How would you extend this to support multiple peek() calls ahead?

78.2K Views

Medium-High Frequency

~15 min Avg. Time

1.9K Likes

Ln 1, Col 1

Smart Actions

💡 Explanation

AI Ready

💡 Suggestion Tab to accept Esc to dismiss

// Output will appear here after running code

Code Editor Closed

Click the red button to reopen

Input & Output

Visualization

Time & Space Complexity

Related Problems

Constraints

Common Approaches

Cached Next Element (Optimal) — Algorithm Steps

Visualization

Code -

Time & Space Complexity

Constraints

Select Compiler