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

61–70 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#61

Post by w10-1 »

cobbzilla wrote: post #29

Here’s my empirical evidence based on several recent “coding session” interviews with a variety of software companies. Background: I have been developing software for over 30 years, I hold a few patents, I’ve had a handful of modestly successful exits. I kind of know a little bit about what I am doing. At this stage in my career, I am no longer interested in the super early stage startup lifestyle, I’m looking at IC/…

Yes, it is a death spiral; if you are to lead them, you have to know what to fix when, to avoid making things worse.

The solution is typically not just to fix their code. They got in over their heads by charging ahead and building something they'll regret, but their culture (and likely the interviewer personal self-regard) depends on believing their (current) tech leaders.

So yes, the interviewer is most comfortable if you chase and find the ball they're hiding.

But the leadership question is whether you can relieve them of their ignorance without also stripping their dignity and future prospects.

I've found (mostly with luck) that they often have a sneaking suspicion that something isn't right, but didn't have the tools or pull to isolate and address it. As a leader if you can elicit that, and then show some strategies for doing so, you'll improve them and the code in a way that encourages them that what was hard to them is solvable with you, which helps them rely on you for other knotty problems.

It's not really that you only live once; it's that this opportunity is here now and should have your full attention, and to be a leader you have to address it directly but from everyone's perspective.

Even if you find you'd never want to work with them, you'd still want to leave them feeling clearer about their code and situation.

Re: Many hard LeetCode problems are easy constraint problems

#63

Post by binarymax »

A loonnngggg time ago when I was green, and wasn't taught about constraint solving in my State University compsci program, I encountered the problem when trying to help a friend with his idea.

He wanted to make an app to help sports club owners schedule players for the day based on a couple simple rules. I thought this was going to be easy, and failed after not realizing what I was up against. At the time I didn't even know what I didn't know.

I often look back on that as a lesson of my own hubris. And it's helped me a lot when discussing estimates and timelines and expectations.

Re: Many hard LeetCode problems are easy constraint problems

#64

Post by LordDragonfang »

> This was a question in a different interview (which I thankfully passed):

> Given a list of stock prices through the day, find maximum profit you can get by buying one stock and selling one stock later.

It was funny to see this, because I give that question in our interviews. If someone suggested a constraint solver... I don't know what I'd have done before reading this post (since I had only vaguely even heard of a constraint solver), but after reading it...

Yeah, I would still expect them to be able to produce a basic algorithm, but even if their solution was O(n^2) I would take it as a strong sign we should hire them, since I know there are several different use cases for our product that require generalized constraint solving (though I know it by other names) and having a diverse toolset on hand is more important in our domain than writing always-optimal code.

Re: Many hard LeetCode problems are easy constraint problems

#65

Post by LegionMammal978 »

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 very hit-or-miss.

Re: Many hard LeetCode problems are easy constraint problems

#66

Post by gnfargbl »

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 could solve 0% of these problems, because my brain just doesn't work that way. Or at least, that's my expectation: I've never actually considered working somewhere that does leetcode interviews.

Re: Many hard LeetCode problems are easy constraint problems

#67

Post by tomas789 »

ebiester wrote: post #22
theflyinghorse wrote: post #7

Earlier quoted context omitted.

The point is to test whether or not you put in the time to sharpen common patterns and also to test your communication ability

Super common patterns like dynamic programming?

Yes. It is common on leetcode.

Re: Many hard LeetCode problems are easy constraint problems

#68

Post by joelthelion »

hermannj314 wrote: post #8

Most interviews are based on the premise that if a diabetic can't synthesize their own insulin in their basement, they are somehow cheating at the game of life. If my wife's blood sugar is high, she takes insulin. If you need to solve a constraint problem, use a constraint solver. If your company doesn't make and sell constraint solving software, why do you need me to presume that software doesn't exist and invent it…

In defense of coding tests, most people who can't solve simple dynamic programming problems generally turn out to be pretty poor programmers IRL.

At least that's been my experience. I'm sure there are exceptions.

Re: Many hard LeetCode problems are easy constraint problems

#69

Post by koakuma-chan »

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…

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.

Re: Many hard LeetCode problems are easy constraint problems

#70

Post by bluGill »

qnleigh wrote: post #36
Analemma_ wrote: post #4

Earlier quoted context omitted.

Yes and no: I've asked questions like this in interviews, and I'd count it as a plus if the candidate reached for a constraint solver. They're criminally underused in real-world software engineering and this would show the candidate probably knows how to get the right answer faster instead of wasting a bunch of time. Now, if they did answer with a constraint solver, I'd probably ask some followup whiteboard questions…

Yes, especially if the interviewee said something like 'this may not be asymptomatically optimal, but if it's not a known bottleneck, then I might start with constraint solver to get something working quickly and then profile later.' Especially if it's a case where even the brute-force solution is tricky. Otherwise penalizing interviewees for suggesting quick-and-dirty solutions reinforces bad habits. "Premature opti…

Using a bad algorithm when a good algorithm that is known to exist is premature pessimization and should be avoided.

There is some debate about what premature optimization is, but I consider it about micro optimizations that often are doing things a modern compiler will do for you better than you can. All too often such attempts result in unreadable code that is slower because the optimizer would have done something different but now it cannot. Premature optimization is done without a profiler - if you have a profile of your code and can show a change really makes a difference then it isn't premature.

On the other hand job interviews imply time pressure. If someone isn't 100% sure how to implement the optimization algorithm without looking it up brute force is faster and should be chosen then. In the real world if I'm asked to do something I can spend days researching algorithms at times (though the vast majority of the time what I need is already in my language's standard library)

Post reply on HN