Many hard LeetCode problems are easy constraint problems • Hacker News Board

Re: Many hard LeetCode problems are easy constraint problems

#391

Post by ec109685 » Sat, Sep 13, 2025, 4:00 AM UTC

saghm wrote: post #372

segmondy wrote: post #75

Earlier quoted context omitted.

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…

Reminds me of https://aphyr.com/posts/340-reversing-the-technical-intervie... (and the follow-ups to it)

We had a programming language class at college and wrote the same program in everything from Java to Lisp. The lisp was way nicer.

Re: Many hard LeetCode problems are easy constraint problems

#392

Post by [deleted] » Sat, Sep 13, 2025, 4:02 AM UTC

kentm wrote: post #346

grugagag wrote: post #293

Earlier quoted context omitted.

But why stop there? Why not test candidates with problems they have never seen before? Or problems similar to the problems of the organization hiring? Leetcode mostly relies on memorizing patterns with a shallow understanding but shows the candidates have a gaming ability. Does that imply quality in any way? Some people argue that willing to study for leetcode shows some virtue. I very much disagree with that.

To play the devils advocate, being able to memorize patterns and recognize which patterns apply to a given problem is extremely valuable. Tons of software dev is knowing the subset of algorithms, data structures, and architecture that apply to a similar problem and being able to adapt it.

[deleted]

Re: Many hard LeetCode problems are easy constraint problems

#393

Post by roncesvalles » Sat, Sep 13, 2025, 4:03 AM UTC

grugagag wrote: post #293

roncesvalles wrote: post #264

Earlier quoted context omitted.

>The LC interviews are like testing people how fast they can run 100m after practice Ah, but, the road to becoming good at Leetcode/100m sprint is: >a slow arduous never ending jog with multiple detours and stops along the way Hence Leetcode is a reasonably good test for the job. If it didn't actually work, it would've been discarded by companies long ago. Barring a few core library teams, companies don't really care…

But why stop there? Why not test candidates with problems they have never seen before? Or problems similar to the problems of the organization hiring? Leetcode mostly relies on memorizing patterns with a shallow understanding but shows the candidates have a gaming ability. Does that imply quality in any way? Some people argue that willing to study for leetcode shows some virtue. I very much disagree with that.

I think you have a misunderstanding. Most companies that do LC-style interviews usually show unknown problems.

Memorizing the Top 100 list from Leetcode only works for a few companies (notably and perplexingly, Meta) but doesn't for the vast majority.

Also, just solving the problem isn't enough to perform well on the interview. Getting the optimal solution is just the table stakes. There's communication, tradeoffs between alternative solutions, coding style, follow-up questions, opportunities to show off language trivia etc.

Memorizing problems is wholly not the point of Leetcode grinding at all.

In terms of memorizing "patterns", in mathematics and computer science all new discovery is just a recombination of what was already known. There's virtually no information coming from outside the system like in, say, biology or physics. The whole field is just memorized patterns being recombined in different ways to solve different problems.

Re: Many hard LeetCode problems are easy constraint problems

#394

Post by theendisney » Sat, Sep 13, 2025, 4:04 AM UTC

   coins = [100,50,25,10,5,1]
   change = 1234;
   result = [0,0,0,0,0,0];
   for(i=0:icoins[i]){
       result[i]++;
       change-=coins[i];
     }
   }
   //[12,0,1,1,4]

Coudnt help myself sorry

Re: Many hard LeetCode problems are easy constraint problems

#395

Post by gnatman » Sat, Sep 13, 2025, 4:10 AM UTC

“Many hard problems are, to me, quite easy”

Re: Many hard LeetCode problems are easy constraint problems

#396

Post by grugagag » Sat, Sep 13, 2025, 4:14 AM UTC

roncesvalles wrote: post #393

grugagag wrote: post #293

Earlier quoted context omitted.

But why stop there? Why not test candidates with problems they have never seen before? Or problems similar to the problems of the organization hiring? Leetcode mostly relies on memorizing patterns with a shallow understanding but shows the candidates have a gaming ability. Does that imply quality in any way? Some people argue that willing to study for leetcode shows some virtue. I very much disagree with that.

I think you have a misunderstanding. Most companies that do LC-style interviews usually show unknown problems. Memorizing the Top 100 list from Leetcode only works for a few companies (notably and perplexingly, Meta) but doesn't for the vast majority. Also, just solving the problem isn't enough to perform well on the interview. Getting the optimal solution is just the table stakes. There's communication, tradeoffs be…

It’s not about memorizing individual problems per se, but rather recognizing overall patterns and turning the process into a gameable endeavor. This can give candidates an edge, but it doesn’t necessarily demonstrate higher-level ability beyond surface familiarity with common patterns and the expectations around them. I’d understand the value if the job actually involved work similar to what's reflected in leetCode style problems, but in most cases, that couldn’t be further from reality. leetCode serves little purpose beyond measuring a candidate’s willingness to invest time and effort. That’s the only real virtue it rewards. But ultimately, I believe leetCode style interviews are measuring the wrong metric.

Re: Many hard LeetCode problems are easy constraint problems

#397

Post by roncesvalles » Sat, Sep 13, 2025, 4:17 AM UTC

saghm wrote: post #366

roncesvalles wrote: post #264

Earlier quoted context omitted.

>The LC interviews are like testing people how fast they can run 100m after practice Ah, but, the road to becoming good at Leetcode/100m sprint is: >a slow arduous never ending jog with multiple detours and stops along the way Hence Leetcode is a reasonably good test for the job. If it didn't actually work, it would've been discarded by companies long ago. Barring a few core library teams, companies don't really care…

> If it didn't actually work, it would've been discarded by companies long ago You're assuming that something else works better. Imagine if we were in a world where all interviewing techniques had a ton of false positives and negatives without a clear best choice. Do you expect that companies would just give up, and not hire at all, or would they pick based on other factors (e.g. minimizing the amount of effort neede…

I never made any claims about optimality. It works (for whatever reason) hence companies continue to use it

If it didn't work, these companies wouldn't be able to function at all.

It must be the case that it works better than running a RNG on everyone who applied.

Does it mean some genius software engineer who wrote a fundamental part of the Linux kernel but never learned about Minimum Spanning Trees got filtered out? Probably. But it's okay. That guy would've been a pain in the ass anyway.

Re: Many hard LeetCode problems are easy constraint problems

#398

Post by fooker » Sat, Sep 13, 2025, 4:19 AM UTC

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…

This repo has enough red flags to warrant some suspicion.

You have also not attempted to hide that, which is interesting.

Re: Many hard LeetCode problems are easy constraint problems

#399

Post by zaxioms » Sat, Sep 13, 2025, 4:24 AM UTC

LegionMammal978 wrote: post #65

drob518 wrote: post #62

SAT, SMT, and constraint solvers are criminally underutilized in the software industry. We need more education about what they are, how they work, and what sorts of problems they can solve.

At least personally, I've been very underwhelmed by their performance when I've tried using them. Usually past a few dozen variables or so is when I start hitting unacceptable exponential runtimes, especially for problem instances that are unsatisfiable or barely-satisfiable. Maybe their optimizations are well-suited for knapsack problems and other classic OR stuff, but if your problem doesn't fit the mold, then it's…

I'm surprised to hear this. Modern SAT solvers can easily handle many problems with hundreds of thousands of variables and clauses. Of course, there are adversarial problems where CDCL solvers fail, but I would be fascinated if you can find industrial (e.g. human written for a specific purpose) formulas with "dozens of variables" that a solver can't solve fairly quickly.

Re: Many hard LeetCode problems are easy constraint problems

#400

Post by zaxioms » Sat, Sep 13, 2025, 4:28 AM UTC

LegionMammal978 wrote: post #147

js8 wrote: post #139

Earlier quoted context omitted.

I wish I knew better how to use them for these coding problems, because I agree with GP they're underutilized. But I think if you have constraint problem, that has an efficient algorithm, but chokes a general constraint solver, that should be treated as a bug in the solver. It means that the solver uses bad heuristics, somewhere.

I'm pretty sure that due to Rice's theorem, etc., any finite set of heuristics will always miss some constraint problems that have an efficient solution. There's very rarely a silver bullet when it comes to generic algorithms.

Rice's theorem is about decidability, not difficulty. But you are right that assuming P != NP there is no algorithm for efficient SAT (and other constraint) solving.