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

501–510 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#501

Post by forrestthewoods »

gnfargbl wrote: post #66
holden_nelson wrote: post #3

I feel like if I'm being asked this in an interview, they're not asking me to use a constraint solver, they're asking me to _write_ a constraint solver. Just for a specific constraint problem, not a more general constraint solver.

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…

> Or at least, that's my expectation: I've never actually considered working somewhere that does leetcode interviews.

Hrm. So what you're saying is you've never actually taken or given this style of interview. Nor presumably ever worked at a company that did this interview. So if on the off-chance these interviews actually were a somewhat successful tool for filtering candidates you wouldn't actually know it?

That feels like a miss.

Re: Many hard LeetCode problems are easy constraint problems

#502

Post by hirvi74 »

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…

I agree with essentially everything you said. While reinventing the wheel isn't always to most efficient solution, such actions have sometimes paid dividends in my past.

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

Absolutely, though I am not sure lack of curiosity nor strive is always the issue. It's one thing to green field one's own solution in an attempt to better one's abilities, but it's also a bit idealistic in a working world of impending deadlines and death-march Agile sprints.

In this case, a 25 line function to solve a constraint would likely take me far less time than grokking an external library's documentation, but in many cases, I feel developers jump on external dependencies because time is of the essence.

Re: Many hard LeetCode problems are easy constraint problems

#503

Post by adgjlsfhk1 »

Der_Einzige wrote: post #27
holden_nelson wrote: post #3

I feel like if I'm being asked this in an interview, they're not asking me to use a constraint solver, they're asking me to _write_ a constraint solver. Just for a specific constraint problem, not a more general constraint solver.

If someone solves a leetcode hard with a constraint solver and you don't hire them, you are an idiot. Do you know how few people in this world even know what a constraint solver is, let alone how to correctly define the problem into one? I used a constraint solver to solve a homework problem once in my CS degree 3rd year. My god just writing the damn constraints was a huge cognitive load!

you might be interested in trying out JuMP.jl. It's a Julia package that abstracts over constraint solvers and can do some very complex reformulations automatically to take the declarative definition of your problem and turn it into the types of constraints that the solver you're using supports.

Re: Many hard LeetCode problems are easy constraint problems

#504

Post by Avshalom »

thomasahle wrote: post #18

Interview: > We can solve this with a constraint solver Ok, using your favorite constraint solver, please write a solution for this. > [half an hour later] Ok, now how would you solve it if there was more than 100 data points? E.g. 10^12?

Well how would you solve it if there were 10^12 data points

Re: Many hard LeetCode problems are easy constraint problems

#505

Post by userbinator »

lupire wrote: post #462
userbinator wrote: post #410

Earlier quoted context omitted.

If you're using AI for an interview, you are basically telling them "you could just not bother with hiring me and use AI yourself" which is neither good for you nor them.

In 2025, everyone is hiring for people who can use AI to write software. They already are using AI themselves. They need more people who can.

Not everyone. I know there are some employers who are extremely against any form of AI being used in making their products.

Re: Many hard LeetCode problems are easy constraint problems

#506

Post by fullofideas »

bradlys wrote: post #121
koakuma-chan wrote: post #69

Earlier quoted context omitted.

I haven't been asked leetcode questions in a while and when I was asked, it was an easy level problem. I don't know where they ask hard leetcode problems, I also never solved a hard leetcode problem on my own.

I'm routinely asked LC Hard questions in interviews. Sometimes more than one in one 45 minute interview. That said, I interview in silicon valley and I'm a mixed race American. (extremely rare here) I think a lot of people just don't want me to pass the interview and will put up the highest bar they can. Mind you, I often still give optimal solutions to everything within good time constraints. But I've practiced 1000…

Not sure about the timespan that you are referring to. Post covid hiring high, in the last 2 years or so, the hiring bar has been extremely high, in general. Not denying your experiences, may be it is even higher for you.

Personally, my experience has been that pre-covid, majority of interviewers were assessing your problem solving ability and if you can code the algorithm that you came up with. Getting the most optimal solution and fixing all edge cases for all problems in all interviews was not strictly necessary. But these days, even if you have the best solution coded up for 3 problems and missed one edge case in the 4th problem, you are not “good enough”. At one place, I was dinged for not thinking of the edge case before I wrote the program, even though I caught it while coding it up, in spite of having the write solution for the other 3 problems asked in the 2 coding rounds. It is a tough market, and probably tougher for you. Good luck mate.

Re: Many hard LeetCode problems are easy constraint problems

#507

Post by gnarlouse »

cerved wrote: post #307
gnarlouse wrote: post #163

Been working on a calendar scheduling app that uses a constraint solver to auto schedule events based on scheduling constraints (time of day preferences and requirements, recurrence rules), and track goal progress (are you slipping on your desired progress velocity? Get a notification). It’s also a meal planner: from a corpus of thousands of good, healthy recipes, schedule a meal plan that reuses ingredients nearing…

Which solver do you use?

Google ORTools’ CpSolver, with IntervalVars for the calendar portion.

Re: Many hard LeetCode problems are easy constraint problems

#508

Post by bubblyworld »

torginus wrote: post #497
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?

I'm sorry but after reading your comment I can't seem to be able to decide if you favor writing the dynamic programming version or pulling in the constraint solver. Both are correct in the sense that they give the right output, and I don't think pulling in a huge library (maintained by who knows and for how long) is going to be beneficial for maintenace. And having a good understanding of both the precise requirement…

There are other aspects to maintenance, like requirements change. In this case it's trivial to change or add new constraints to a constraint solver, whereas even small changes to a typical DP problem can require a total rethink of the approach. Extending the analogy to other kinds of dependencies left as an exercise for the reader.

Point being that software has many dimensions. Reducing the use of dependencies to fear of learning or thinking is a bit reductive in my opinion, even for stuff that seems simple initially.

Re: Many hard LeetCode problems are easy constraint problems

#509

Post by MarcelOlsz »

userbinator wrote: post #408
_whiteCaps_ wrote: post #191

Earlier quoted context omitted.

That is an insane amount of work for a job application. Were you compensated for it at all?

The other comments here note that, and the author even stated it directly, that it was vibe-coded.

Wrong.

Re: Many hard LeetCode problems are easy constraint problems

#510

Post by echelon »

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…

That's not a job you want.
Post reply on HN