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

451–460 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#451

Post by torginus »

Very interesting article and good points.

But how about we flip the original statement around:

Many problems thought to require giant software packages/libraries are very solvable locally if you know what you are doing

This is why LC is actually meaningful - imagine if you faced the coin challenge problem IRLin prod and you decided to pull in a constraint solver - what would've been a 25 line function now is a giant python library that carries 30MB of native dependencies around.

These solutions are often lacking in many ways, since mentally offloading some of the work means you don't have to understand the problem in depth or how the designated tool solves it, which can lead to nasty surprised in production.

We see this everywhere - people pulling in questionable npm packages to save themselves 30 mins of thinking or 20 mins of reading docs - people convinced that you do need that huge 3D framework that comes with an editor to make a WebGL widget on your landing page etc.

You are more willing to accept bloat of others, just because they pulled in Electron, because they were too afraid to learn how native UI works.

People need to be more curious, and strive to be more knowledgeable.

Re: Many hard LeetCode problems are easy constraint problems

#452

Post by [deleted] »

MarcelOlsz wrote: post #220
Tenemo wrote: post #214

Earlier quoted context omitted.

There's even a rocket emoji in server console.logs... There are memes with ChatGPT and rocket emojis as a sign of AI use. The whole repo looks super vibe-coded, emojis, abundance of redundant comments, all in perfect English and grammar, and the readme also has that "chatty" feel to it. I'm not saying that using AI for take-home assignments is bad/unethical overall, but you need to be honest about it. If he was lying…

Oh my god Becky, there's even a rocket emoji in the server console logs! Should I also be "honest" about tab-completion? Where do you draw the line? Maybe I should be punished for having an internet connection too. Using AI for docker/readme's/simple scaffolding I would have done anyways ? Oh the horror! There was no lying because there was no discussion or mention of AI at all. Had they asked me, I'd have happily to…

[deleted]

Re: Many hard LeetCode problems are easy constraint problems

#453

Post by mcdeltat »

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…

There's probably a general positive correlation between knowing a lot of specific algorithms/techniques (i.e. as tested by LC) and being a great developer. HOWEVER I think the scenario of a real world job is far more a subset of that.

Firstly these questions you get like 30 mins to do, which is small compared to the time variance introduced by knowing or not knowing the required algorithm. If you know it you'll be done in like 10 mins with a perfect answer. Whereas if you don't know you could easily spend 30 mins figuring it out and fail. So while on average people passed by LC may be good engineers, in any one scenario it's likely you reject a good engineer because the variance is large. And then it's easy to see why people get upset, because yeah it feels dodgy to be rejected when you happen to not know some obscure algorithm off the top of your head. The process could be fairer.

Secondly, as many say, the actual job is rarely this technical stuff under such time pressure. Knowing algorithms or not means basically nothing when the job is like debugging CI errors for half your day.

Re: Many hard LeetCode problems are easy constraint problems

#454

Post by jongjong »

My Leetcode ability is unpredictable. I either ace the test or I can't finish it in time. The only way to make outcomes predictable is practice, but I have too much agency and not enough time for that.

Leetcode requires a very different set of skills from software engineering. Software engineering isn't so much about solving puzzles as it is about making good decisions. It's about knowing what's important and knowing where the boundaries are. It's about anticipating problems in their broadest form; creating just the right amount of flexibility and allowing the solution to solidify as your understanding of the problem deepens.

Re: Many hard LeetCode problems are easy constraint problems

#455

Post by jvanderbot »

torginus wrote: post #451

Very interesting article and good points. But how about we flip the original statement around: Many problems thought to require giant software packages/libraries are very solvable locally if you know what you are doing This is why LC is actually meaningful - imagine if you faced the coin challenge problem IRLin prod and you decided to pull in a constraint solver - what would've been a 25 line function now is a giant…

Wait are you making the opposite claim? That one should eschew the "correct" formulation in favor of a bespoke one? Despite the stated (and hopefully obvious) difficulties that brings with maintenance, generalization, etc?

Re: Many hard LeetCode problems are easy constraint problems

#456

Post by citizen-stig »

Jensson wrote: post #432
galaxyLogic wrote: post #416

Earlier quoted context omitted.

Then what if the test was how well you play chess? That takes time to study to become good. But would it be a good metric for hiring programmers?

Because chess is more unrelated to the job? It is easy to see that LeetCode problems are closer to a programmers job than what chess is. But yeah, people used to ask that level of unrelated questions to programmers, and they were happy with the results. "Why are manhole covers round" etc. LeetCode style questions do produce better results than those, so that is why they use them.

Then testing how they play Factorio will work better

Re: Many hard LeetCode problems are easy constraint problems

#457

Post by mmis1000 »

jvanderbot wrote: post #455
torginus wrote: post #451

Very interesting article and good points. But how about we flip the original statement around: Many problems thought to require giant software packages/libraries are very solvable locally if you know what you are doing This is why LC is actually meaningful - imagine if you faced the coin challenge problem IRLin prod and you decided to pull in a constraint solver - what would've been a 25 line function now is a giant…

Wait are you making the opposite claim? That one should eschew the "correct" formulation in favor of a bespoke one? Despite the stated (and hopefully obvious) difficulties that brings with maintenance, generalization, etc?

You probably haven't see front-end projects that pulls tons of library for a simple sorting or grouping task. Sometimes even solvable with build-in array function alone. It's a true nightmare when you have to deal with that kind of projects.

Re: Many hard LeetCode problems are easy constraint problems

#458

Post by anonzzzies »

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…

Yes. If work was leetcode problem solving, I would actually enjoy it. Updating npm packages and writing tiny features that get canned a week later is all not that stimulating.

Re: Many hard LeetCode problems are easy constraint problems

#459

Post by komali2 »

mmis1000 wrote: post #457
jvanderbot wrote: post #455

Earlier quoted context omitted.

Wait are you making the opposite claim? That one should eschew the "correct" formulation in favor of a bespoke one? Despite the stated (and hopefully obvious) difficulties that brings with maintenance, generalization, etc?

You probably haven't see front-end projects that pulls tons of library for a simple sorting or grouping task. Sometimes even solvable with build-in array function alone. It's a true nightmare when you have to deal with that kind of projects.

What, like lodash? Some of those hail from a time that we didn't have a good set of native methods. So the library is just legacy'd in. But I do agree, lodash performance compared to native functions is crazy bad.

Re: Many hard LeetCode problems are easy constraint problems

#460

Post by usgroup »

segmondy wrote: post #75
gnfargbl wrote: post #66

Earlier quoted context omitted.

You're right, but that just shows how fundamentally silly this interview approach is. In any real engineering situation I can solve 100% of these problems. That's because I can get a cup of coffee, read some papers, look in a textbook, go for a walk somewhere green and think hard about it... and yes, use tooling like a constraint solver. Or an LLM, which knows all these algorithms off by heart! In an interview, I cou…

I was told to use ANY language in an interview. I asked them if they were sure, so I solved it with J. They were not too pleased and asked me if I could use another language, so I did prolog and we moved on to the next question. Then the idiot had the audacity to say I should not use "J and Prolog" but any common known language. I asked if assembly was fine, and they said no. Perhaps python or javascript. I did the r…

:-) I would have hired you!
Post reply on HN