You only have free questions left (including this one).

But it doesn't have to end here! Sign up for the 7-day coding interview crash course and you'll get a free Interview Cake problem every week.

You want to be able to access the largest element in a stack.

You've already implemented this ICKStack class:

@interface ICKStack : NSObject { NSMutableArray<NSNumber *> *_items; } @property (readonly, nonatomic) NSUInteger count; @property (readonly, nonatomic) BOOL isEmpty; @property (readonly, nonatomic) NSNumber *top; - (void)push:(NSNumber *)item; - (NSNumber *)pop; @end @implementation ICKStack // initialize an empty stack - (instancetype)init { if (self = [super init]) { _items = [NSMutableArray new]; } return self; } // push a new item onto the stack - (void)push:(NSNumber *)item { [_items addObject:item]; } // remove and return the last item - (NSNumber *)pop { // if the stack is empty, return nil if (_items.count == 0) { return nil; } NSNumber *lastItem = _items.lastObject; [_items removeLastObject]; return lastItem; } // count the number of items in the stack - (NSUInteger)count { return _items.count; } // check if the stack is empty - (BOOL)isEmpty { return _items.count == 0; } // return the last item without removing it - (NSNumber *)top { return _items.lastObject; } @end

Use your ICKStack class to implement a new class ICKMaxStack with a method -getMax that returns the largest element in the stack. -getMax should not remove the item.

Your stacks will contain only integers.

What if we push several items in increasing numeric order (like 1, 2, 3, 4...), so that there is a new max after each -push:? What if we then -pop each of these items off, so that there is a new max after each -pop? Your algorithm shouldn't pay a steep cost in these edge cases.

You should be able to get a runtime of for -push:, -pop, and -getMax.

Actually, we don't support password-based login. Never have. Just the OAuth methods above. Why?

1. It's easy and quick. No "reset password" flow. No password to forget.
2. It lets us avoid storing passwords that hackers could access and use to try to log into our users' email or bank accounts.
3. It makes it harder for one person to share a paid Interview Cake account with multiple people.

Actually, we don't support password-based login. Never have. Just the OAuth methods above. Why?

1. It's easy and quick. No "reset password" flow. No password to forget.
2. It lets us avoid storing passwords that hackers could access and use to try to log into our users' email or bank accounts.
3. It makes it harder for one person to share a paid Interview Cake account with multiple people.

time for -push:, -pop, and -getMax. additional space, where m is the number of operations performed on the stack.

Our solution requires additional space for the second stack. But do we really need it?

Can you come up with a solution that requires additional space? (It's tricky!)