Ask HN: How are you supposed to use LeetCode?
17 comments
Think of the leetcode site as a set of practice problems. If you're struggling to solve a problem, then that shows what you should study to become better at leetcode. In your case, maybe the O(n) algorithm is a pattern that's broadly applicable to other problems too.
I think that if you're stuck on a problem for more than 30 minutes, it's better to go read the solution and learn from it than to keep struggling. (Then go back a week later and see if you can solve the problem from memory).
Opinions certainly differ on whether leetcode makes for a good interviewing process. On your specific problem, there are a ton of similar problems where you need to traverse possible solutions in a particular order to be efficient. I regularly see similar problems at work.
I think that if you're stuck on a problem for more than 30 minutes, it's better to go read the solution and learn from it than to keep struggling. (Then go back a week later and see if you can solve the problem from memory).
Opinions certainly differ on whether leetcode makes for a good interviewing process. On your specific problem, there are a ton of similar problems where you need to traverse possible solutions in a particular order to be efficient. I regularly see similar problems at work.
> I regularly see similar problems at work.
No way anyone gets that in 30 minutes without having seen it exactly before. Moving pointers in from the sides, according to Y height, both at the same time when equal, and then not using that to find the solution, just to narrow the search space? I mean, it's not like I and everyone else didn't think along those lines, but that exact algorithm is totally non-obvious. I spent like 20 minutes on something similar, another 20 on a recursive split/merge thing that went nowhere, then got brute force working.
No way anyone gets that in 30 minutes without having seen it exactly before. Moving pointers in from the sides, according to Y height, both at the same time when equal, and then not using that to find the solution, just to narrow the search space? I mean, it's not like I and everyone else didn't think along those lines, but that exact algorithm is totally non-obvious. I spent like 20 minutes on something similar, another 20 on a recursive split/merge thing that went nowhere, then got brute force working.
The problems can be solved quickly with training. There’s a limited number of techniques and you develop pattern recognition with practice. Once you get that down it’s about executing well under pressure and communicating your thought process.
no, they can be solved quickly by memorizing the optimal solution and training to write the code very quickly. so basically train like a monkey.
“solve the problem from memory” - there you have it
That's the truth, ain't it. These algorithms didn't just poof out of nowhere. Some of them took years to figure out. But somehow, people aren't smart if they can't regurgitate the optimum solution in 20 minutes. Despite the fact, some of them already work in FANG.
Here's the truth, there are over >200 people that apply for a single FANG job. Don't believe me? Buy LinkedIn premium and find out yourself. Talk to a Fang recruiter. Leetcode is just a way to filter people down to 5. It reflects nothing on your intelligence other than willingness to be a lemming that receives >200k per annum.
Here's the truth, there are over >200 people that apply for a single FANG job. Don't believe me? Buy LinkedIn premium and find out yourself. Talk to a Fang recruiter. Leetcode is just a way to filter people down to 5. It reflects nothing on your intelligence other than willingness to be a lemming that receives >200k per annum.
I don't think it's that non obvious. You're maximizing the area A = H*W which means maximizing H and W. Obviously the largest W is between height[0] and height[n-1]. You don't know if this will give the largest A as there might be a pair of heights with smaller W so you have to search inside. If you decrease W but want to increase A, then H must increase. From this you should recognize that the only way to increase H is with an inner line that's higher than min(height[0], height[n-1]). Any other lines cannot mathematically be candidates for a larger area. Once you know how to select your candidates, it's just a matter of checking them to find the max area.
Of course trying to make this deduction during an actual interview when one or multiple people are watching you is an entirely different problem. Hopefully leetcode will give you enough practice to recognize patterns so that you don't need to think too deeply during interviews.
Of course trying to make this deduction during an actual interview when one or multiple people are watching you is an entirely different problem. Hopefully leetcode will give you enough practice to recognize patterns so that you don't need to think too deeply during interviews.
I don't think you have it. Say you have an input like this:
[3,2,100,100,2,3]
So you start on the outsides working in with your method, and you will stop at the two outermost 3s, because the 2 is less area, and never make it to the inner 100s. That's why the actual algorithm is to keep moving the pointers in until they meet, in a very specific way, keeping track of the maximum the whole time. It's not about actually finding the maximum and stopping early, it's about reducing the search space to O(n) from the naive O(n^2).
EDIT: However! There is a condition where h[n] <= len(h), which actually makes your method work! But you never mentioned that, so I think you may have gotten it by accident. :D
Like, with that condition, it becomes something like this:
[1,1,6,6,1,1]
and then stopping at the outer 1s is equivalent to making it in to the 6s.
I guess my issue is that I didn't example the conditions well enough. There's was a huge clue in there!
[3,2,100,100,2,3]
So you start on the outsides working in with your method, and you will stop at the two outermost 3s, because the 2 is less area, and never make it to the inner 100s. That's why the actual algorithm is to keep moving the pointers in until they meet, in a very specific way, keeping track of the maximum the whole time. It's not about actually finding the maximum and stopping early, it's about reducing the search space to O(n) from the naive O(n^2).
EDIT: However! There is a condition where h[n] <= len(h), which actually makes your method work! But you never mentioned that, so I think you may have gotten it by accident. :D
Like, with that condition, it becomes something like this:
[1,1,6,6,1,1]
and then stopping at the outer 1s is equivalent to making it in to the 6s.
I guess my issue is that I didn't example the conditions well enough. There's was a huge clue in there!
Without any conditions on the input, you cannot stop early and must visit each element at least once. The candidate selection I mentioned is for picking which edge to keep as you reduce the search space for a potentially bigger area (sorry if I didn't explain it clearly).
[3,2,100,100,2,3]
[2,100,100,2,3] (keep right 3, check if 2-3 has a larger area)
[100,100,2,3] (keep right 3, check if 100-3 has a larger area)
[100,100,2] (keep left 100, check if 100-2 has a larger area)
[100,100] (keep left 100, check if 100-100 has a larger area)
[3,2,100,100,2,3]
[2,100,100,2,3] (keep right 3, check if 2-3 has a larger area)
[100,100,2,3] (keep right 3, check if 100-3 has a larger area)
[100,100,2] (keep left 100, check if 100-2 has a larger area)
[100,100] (keep left 100, check if 100-100 has a larger area)
> But it's the kind of thing you would see in a CS textbook, not just come up with on your own.
Well, LeetCode is a CS-textbook-problems kind of site.
You use it however you like. While I was searching for my first job, I spent some time solving problems and optimizing them, half to keep my skills from degrading after college, and half just for fun. I just treated it like a puzzle collection and had a good time with some of the more open-ended questions. I'm sure it'd be useful to help learn a new language as well. I'm not convinced it's effective as a general skill-improvement tool, though.
Well, LeetCode is a CS-textbook-problems kind of site.
You use it however you like. While I was searching for my first job, I spent some time solving problems and optimizing them, half to keep my skills from degrading after college, and half just for fun. I just treated it like a puzzle collection and had a good time with some of the more open-ended questions. I'm sure it'd be useful to help learn a new language as well. I'm not convinced it's effective as a general skill-improvement tool, though.
I think leetcode interview is useful to assess the candidate reasoning in front of a problem. If you don't produce a code that runs correctly in 30 mins, this should not matter as long as you have explained your approach and reasoned about options and complexity.
Of course, not all company reason like this. I guess in FAANG interview they want you to nail the exercises during the interview. I think for them this is a signal of exceptional capabilities and a proof that you real worked hard to try to get a job with them.
It actually comes down to a few simple algorithms, only one of which I didn't see in college. These kinds of water problems use a "monotonic stack" if I remember correctly. That's the algorithm that I didn't see in school.
In reality, after you practice a lot of these problems, you realize that there are only a few broad categories and that most of them just use what you learned in school. You just have to practice to become fast.
In reality, after you practice a lot of these problems, you realize that there are only a few broad categories and that most of them just use what you learned in school. You just have to practice to become fast.
I wish I could help here. I have made exactly one foray into leetcode, wrote out an algorithm for a fairly easy tree traversal thing, tried to submit it and just was told it went into an infinite loop.
I copied my solution elsewhere ran it, and it worked fine.
The only thing I could guess is the input wasn't what I was expecting, but I couldn't verify what input leetcode was actually giving me, so I just walked away.
The whole thing was a waste of time anyways. I still have yet to ever get a leetcode question during an interview and I've been doing this almost a decade now.
Then again, I don't try and get jobs at FAANG companies or FAANG wannabes.
I copied my solution elsewhere ran it, and it worked fine.
The only thing I could guess is the input wasn't what I was expecting, but I couldn't verify what input leetcode was actually giving me, so I just walked away.
The whole thing was a waste of time anyways. I still have yet to ever get a leetcode question during an interview and I've been doing this almost a decade now.
Then again, I don't try and get jobs at FAANG companies or FAANG wannabes.
You beat your head against the wall, submit your solution and see how it compares runtime-wise and memory-wise with others. If you're not scoring well on those metrics, then you go to the discussion to see if there are better solutions and re-implement and resubmit with the goal of understanding how the solution works. After doing this enough times you start to notice patterns of solutions to different classes of problems. If you want something that is more guided at a regular pace, have a look at interviewcake.com
It’s a spiritual digression. Our best developers didn’t come up from a hazing. We failed in assessing talent, so we resorted to this.
We have yet to see outsized results from the leetcode group, but we have seen outsized results from the pre-non-leetcode group.
Results matter, as the leetcode dipshits would say.
We have yet to see outsized results from the leetcode group, but we have seen outsized results from the pre-non-leetcode group.
Results matter, as the leetcode dipshits would say.
Do popular 300 medium difficulty problems
the idea is that you can produce the optimal solution within a minute in a tech interview. to do that you have to memorize it because no-one is able to do that otherwise. not even that gayle woman who wrote that shitty book. so, this is why coding interviews are broken today.
It probably took me 2 full hours, and I only got it with a brute force approach and a butt-load of optimization to make it efficient later.
So, anyway, then I go to the discussion tab, and that's where everyone is chatting about this really cool, elegant, O(n) solution. But it's the kind of thing you would see in a CS textbook, not just come up with on your own. And I didn't see any proofs, so I still don't know that it _really_ works. But I do see lots of examples of exactly how to implement it.
My question is; what's the point then? Are you supposed to not look at the discussion and beat your head against the wall trying to best Donal Knuth, or do you look at the discussion and then just copy it all over with your brain totally turned off? I don't get it.
Oh, here it is, in case anyone is wondering:
https://leetcode.com/problems/container-with-most-water/