Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Many hard LeetCode problems are easy constraint problems

buttondown.com

Post reply on HN
Print view View original

181–190 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#181

Post by GuB-42 »

tracker1 wrote: post #77

My biggest problem with leetcode type questions is that you can't ask clarifying questions. My mind just doesn't work like most do, and leetcode to some extent seems to rely on people memorizing leetcode type answers. On a few, there's enough context that I can relate real understanding of the problem to, such as the coin example in the article... for others I've seen there's not enough there for me to "get" the ques…

> My biggest problem with leetcode type questions is that you can't ask clarifying questions.

What is there to clarify? Leetcode-type questions are usually clear, much clearer than in real life projects. You know the exact format of the input, the output, the range for each value, and there are often examples in addition to the question. What is expected is clear: given the provided example inputs, give the provided example outputs, but generalized to cover all cases of the problem statement. The boilerplate is usually provided.

One may argue that it is one of the reasons why leetcode-style questions are unrealistic, they too well specified compared to real life problems that are often incomplete or even wrong and require you to fill-in the gaps. Also, in real life, you may not always get to ask for clarification: "here, implement this", "but what about this part?", "I don't know, and the guy who knows won't be back before the deadline, do your best"

The "coin" example is a simplification, the actual problem statement is likely more complete, but the author of the article probably felt these these details were not relevant to the article, though it would be for someone taking the test.

Re: Many hard LeetCode problems are easy constraint problems

#182

Post by HarHarVeryFunny »

another_twist wrote: post #98
tracker1 wrote: post #77

My biggest problem with leetcode type questions is that you can't ask clarifying questions. My mind just doesn't work like most do, and leetcode to some extent seems to rely on people memorizing leetcode type answers. On a few, there's enough context that I can relate real understanding of the problem to, such as the coin example in the article... for others I've seen there's not enough there for me to "get" the ques…

Its not really memorizing solutions. Yes you can get quite far by doing so but follow ups will trip people up. However if you have memorized it and can answer follow ups, I dont see a problem with Leetcode style problems. Problem solving is about pattern matching and the more patterns you know and can match against, the better your ability to solve problems. Its a learnable skill and better to pick it up now. Persona…

I'd say that learning to solve tough LeetCode problems has very little (if not precisely zero) value in terms of you as a programmer learning to do something useful. You will extremely rarely need to solve these type of tougher select-the-most efficient-algorithm problems in most real-world S/W dev jobs, and nowadays if you do then just as AI.

Of course you may need to pass an interview LeetCode test, in which case you may want to hold your nose and put in the grind to get good at them, but IMO it's really not saying anything good about the kind of company that thinks this is a good candidate filter (especially for more experienced ones), since you'd have to be stupid not to use AI if actually tasked with needing to solve something like this on the job.

Re: Many hard LeetCode problems are easy constraint problems

#184

Post by tracker1 »

MarcelOlsz wrote: post #172
tracker1 wrote: post #77

My biggest problem with leetcode type questions is that you can't ask clarifying questions. My mind just doesn't work like most do, and leetcode to some extent seems to rely on people memorizing leetcode type answers. On a few, there's enough context that I can relate real understanding of the problem to, such as the coin example in the article... for others I've seen there's not enough there for me to "get" the ques…

100%. I just went through an interview process where I absolutely killed the assignment (had the best one they'd seen), had positive signal/feedback from multiple engineers, CEO liked me a lot etc, only to get sunk by a CTO who thought it would be cool to give me a surprise live test because of "vibe coding paranoia". 11 weeks in the process, didn't get the role. Beyond fucking stupid. This was the demo/take-home (fo…

Damn... that's WAY more than I'll do for an interview process assignment... I usually time box myself to an hour or two max. I think the most I did was a tic-tac-toe engine but ran out of time before I could make a UI over it.

Re: Many hard LeetCode problems are easy constraint problems

#185

Post by MarcelOlsz »

samiv wrote: post #167
tracker1 wrote: post #77

My biggest problem with leetcode type questions is that you can't ask clarifying questions. My mind just doesn't work like most do, and leetcode to some extent seems to rely on people memorizing leetcode type answers. On a few, there's enough context that I can relate real understanding of the problem to, such as the coin example in the article... for others I've seen there's not enough there for me to "get" the ques…

The LC interviews are like testing people how fast they can run 100m after practice, while the real job is a slow arduous never ending jog with multiple detours and stops along the way. But yeah that's the game you have to play now if you want the top $$$ at one of the SMEGMA companies. I wrote (for example) my 2D game engine from scratch (3rd party libs excluded) https://github.com/ensisoft/detonator but would not b…

5 years ago you'd have a project like that, talk to someone at a company for like 30m-1hr about it, and then get an offer.

Re: Many hard LeetCode problems are easy constraint problems

#186

Post by bluGill »

lucianbr wrote: post #83
xenocratus wrote: post #48

Earlier quoted context omitted.

> If someone solves a leetcode hard with a constraint solver and you don't hire them, you are an idiot. I do hope you're exagerating here, but in case you aren't: this is an extremely simplistic view of what (software) engineers have to do, and thus what hiring managers should optimize for. I'd put "ability to work in a team" above "raw academic/reasoning ability" for the vast majority of engineering roles, any day.…

> I'd put "ability to work in a team" above "raw academic/reasoning ability" for the vast majority of engineering roles, any day. In this hypothetical, why do you do leetcode hard interviews?

> why do you do leetcode hard interviews?

I don't. I do easy code interviews because there are people who work great on a team and know enough buzzwords to sound like they know how to write code, but cannot. Something that isn't hard to solve in about 20 minutes (I can solve in 5 - but I've seen a solution several times and so don't have to think about the solution), but is different enough that you haven't memorized the solution. If you can't solve an easy problem then you can't code.

Re: Many hard LeetCode problems are easy constraint problems

#187

Post by Jtsummers »

zzzeek wrote: post #144

I've never heard of a "dynamic programming algorithm". Read wikipedia and it seems to mean....use a recursive function? The coin problem is an easy recursive problem (I just wrote the code for it to make sure my old brain can still do it).

It's usually covered in a first or second year algorithms course. It's a recursive problem definition paired with tabling to eliminate redundant work. Critically, the recursive subproblems have to be overlapping (they'll do some of the same work as the other recursive steps) to see any benefit. You can implement it top-down and add a cache (memoization) or you can implement it bottom-up and fill out the table iteratively rather than through recursion.

If you just implement it recursively without tabling then you end up re-doing work and it's often an exponential runtime instead of polynomial.

To clarify on overlapping, consider Fibonacci:

  F(n) = F(n-1) + F(n-2) # and the base cases
F(n-1) includes F(n-2) in its definition, and both F(n-2) and F(n-1) include F(n-3). If you implement this naively it produces an exponential runtime. Once you add the table, the single initial recursive call to F(n-1) will end up, through its chain of calls, storing the result of F(n-2) and now the implementation is linear instead of exponential.

Re: Many hard LeetCode problems are easy constraint problems

#188

Post by samiv »

MarcelOlsz wrote: post #180
samiv wrote: post #174

Earlier quoted context omitted.

Wait, what.. you did this as a take home for a position? Damn that looks excessive.

Yes. I put a ton of work into it. I had about 60 pages worth of notes. On inverse kinematics, FABRIK, cyclic algorithms used in robotics, A*/RRT for real-world scenarios etc. I was super prepared. Talked to the CEO for about two hours. Took notes on all videos I can find of team members on youtube and their company. Luckily the hiring manager called me back and levelled with me, nobody kept him in the loop and he fel…

I feel bad for you, and I support you in naming and shaming this company. It's just horseshit to jerk people around like that.

I hope you can at least leverage this demo. Maybe remove the identifications of it and shove it into your CV as a "hobby project"? It looks pretty good for that.

Best!

Re: Many hard LeetCode problems are easy constraint problems

#189

Post by MarcelOlsz »

tracker1 wrote: post #184
MarcelOlsz wrote: post #172

Earlier quoted context omitted.

100%. I just went through an interview process where I absolutely killed the assignment (had the best one they'd seen), had positive signal/feedback from multiple engineers, CEO liked me a lot etc, only to get sunk by a CTO who thought it would be cool to give me a surprise live test because of "vibe coding paranoia". 11 weeks in the process, didn't get the role. Beyond fucking stupid. This was the demo/take-home (fo…

Damn... that's WAY more than I'll do for an interview process assignment... I usually time box myself to an hour or two max. I think the most I did was a tic-tac-toe engine but ran out of time before I could make a UI over it.

I put absolutely every egg into that basket. The prospect of working in Europe (where I planned to return to eventually) working on cool robot stuff was enticing.

The fucking CTO thought I vibe-coded it and dismissed me. Shout-out to the hiring manager though, he was real.

Re: Many hard LeetCode problems are easy constraint problems

#190

Post by joz1-k »

zzzeek wrote: post #144

I've never heard of a "dynamic programming algorithm". Read wikipedia and it seems to mean....use a recursive function? The coin problem is an easy recursive problem (I just wrote the code for it to make sure my old brain can still do it).

> Read wikipedia and it seems to mean....use a recursive function?

Yes, that's one (common) approach to dynamic programming. The recursive function call are memoized so that previous calculations are remembered for future function calls. Overlapping subproblems become trivial if you can reuse previously computed values. The recursion with memoization is top-down dynamic programming.

Post reply on HN