1–10 of 21 posts
I couldn't solve the problem, so after the interview, I looked up Google and found this:
https://www.geeksforgeeks.org/design-a-stack-that-supports-getmin-in-o1-time-and-o1-extra-space/
I wonder how you come up with such a solution when given the problem. It seems just incredible.
In this case, the big clue is that O(1) means that there must be somewhere "constant" to look for the solution. In a stack, there's only one practical place to look in O(1) time. (In principle, "the second element" is always O(1) as well, as long as it is always the second unconditionally, but there's no clear reason to add that condition.) Since that place is incorrect, you're going to have to add one. Then it's only a matter of per-element, or per-stack, and from there it won't take long to work it out.
Larger O() factors imply a larger possibility of places to look and possible things to compute.
Not that I ask these questions in interviews anyhow, but I think a case could be made that's not entirely an unreasonable question. (Albeit weird for a QA position, unless you're going to be literally testing underlying APIs. Any UI-level QA position this is massive overkill for.) That is at least in the ballpark of problems I do solve all the time. I am always adding fields to things for faster lookup or something, even if I'm not implementing a generic stack.
The "do it in O(1) space question" can be a trick question, either accidentally or otherwise, if the interviewer isn't careful to specify that they want it done for integers specifically. A lot of the clever "pack it in a tighter space" questions revolve around exploiting the properties of integers, and involve having seen uses of XOR or things like that. If they don't communicate it's integer-only, and the interviewee makes the completely reasonable assumption that "stacks" are meant to be data-type generic (since that's how we usually encounter them in the real world), the interviewer has accidentally asked a question which may be effectively impossible. (Which, in principle, means you should further ask your interviewer about it. However it seems the sort of people asking this question are also often inclined to not be that specific or something.) If you are not exceedingly fast on your feet with integer manipulation, in many ways the answer is just that you've done enough of these to have more-or-less memorized the tricks.
Unless this is an interview for a super-constrained embedded job, I would not consider this a good interview question. There's a lot of games you can play with the integers specifically, because of their confined range of values and the strong relationships between them, but I almost prefer that you not know them, or that if you do know them that you keep them to yourself. I don't want to see that kind of game played in my code without a very good reason. Plus it's just memorization.
You state "O(1) complexity to find the minimum value", but usually without further qualification, that refers to time, not space. With O(1) time, the easiest solution is just to store the minimum-to-date next to the value in the stack. Consulting the minimum is then just looking at the top value's minimum entry. In this case, the big clue is that O(1) means that there must be somewhere "constant" to look for the solu…
That won’t work. The all-time minimum may have been popped when the call to retrieve the lowest value currently on the stack is made.
As a first go, I would use a min-heap (https://en.wikipedia.org/wiki/Heap_(data_structure)) and a stack. Adding items then is a matter of adding them to both the heap and the stack. Popping would pop an item from the stack, look up any item in the heap with that value, and remove that. To get the minimum, look at the top of the min-heap.
Now, there probably is a way to combine these two data structures. I can’t rapidly think of one that’s more efficient in space and/or time, though.
(Edit: thinking more about it, I guess the problem also requires push and, in particular, pop to be O(1). Without that, the problem is trivial, as you can update the minimum value after every push or pop)
You state "O(1) complexity to find the minimum value", but usually without further qualification, that refers to time, not space. With O(1) time, the easiest solution is just to store the minimum-to-date next to the value in the stack. Consulting the minimum is then just looking at the top value's minimum entry. In this case, the big clue is that O(1) means that there must be somewhere "constant" to look for the solu…
> With O(1) time, the easiest solution is just to store the minimum-to-date next to the value in the stack. Consulting the minimum is then just looking at the top value's minimum entry. That won’t work. The all-time minimum may have been popped when the call to retrieve the lowest value currently on the stack is made. As a first go, I would use a min-heap ( https://en.wikipedia.org/wiki/Heap_(data_structure) ) and a…
"All time minimum" would just be one place to store the minimum, since popping would do nothing to it. It is equivalent to the simplest algorithm to find the min of an unsort array/set/whatever.
This is not a brain teaser, this is a question you know the answer of or you don't. Nobody can come up with a crappy algorithm like this on the spot, especially in an interview setting. I hope your interviewer is reading this.
This pretty standard interview question. You should keep track of the current minimum when you do a push: push 1: [(v=1,m=1)] push -1: [(v=1, m=1), (v=-1, m=-1)] push 3: [(v=1, m=1), (v=-1, m=-1), (v=3, m=-1)] get_min: [(v=1, m=1), (v=-1, m=-1), (v=3, m=-1)] returns m=-1 pop: [(v=1, m=1), (v=-1, m=-1)] returns v=3 get_min: returns -1
O(1) implies it should always be sorted. So just accessing the top should be the solution. This implies that inserts and removals will be the more complex task. The naive approach would just be adding and then sorting - O(nlogn). But the best solution I believe is a max heap.. they essentially wanted you to write a max heap algo.
I've gone through a couple of leetcode style interviews recently. Basically it's either you've seen the question or have done a similar style question. I don't see how you can solve a question like that during an interview otherwise.
I'm sure some people can solve things like that on the spot, but their minds must work differently than mine.
I liked one of the comments on leetcode.com that basically amounted to:"some guy wrote a phd to solve this problem and 30 years later we're now expected to solve this in under 30 minutes in artificially stress induced conditions".