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

141–150 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#141

Post by chaboud »

StefanBatory wrote: post #79
chaboud wrote: post #24

Earlier quoted context omitted.

When I interview with problem solving problems, the point is to understand how the candidate thinks, communicates, and decomposes problems. Critically, problem solving questions should have ways to progressively increase and decrease difficulty/complexity, so every candidate "gets a win" and no candidate "dunks the ball". Interviewers learn nothing from an instant epiphany, and they learn next to nothing from someone…

Would a good answer be "I can do it as a constraint problem, but since I guess you are not asking for this, the solution is..." and then proceed as usual?

Id probably stop the candidate, dig into how they’d using constraint based solvers, and how they might expect that to fall apart. Applicability and judgment is worth way more than raw algorithmic questions.

One way to think about this is:

Is a fresh graduate more likely to provide a solid answer to this than a strategic-thinking seasoned engineer? If so, just be conscious of what your question is actually probing.

And, yes, interview candidates are often shocked when I tell them that I’m fine with them using standard libraries or tools that fit the problem. It’s clear that the valley has turned interviewing into a dominance/superiority model, when it really should be a two-way street.

We have to remember that the candidate is interviewing us, too. I’ve had a couple of interviews as the interviewee where the way the interview was conducted was why I said “no” to an offer (no interest in a counter, just a flat “no longer interested” to the recruiter, and, yes, that surprises recruiters, too).

Re: Many hard LeetCode problems are easy constraint problems

#142

Post by HumblyTossed »

nice_byte wrote: post #81
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…

[flagged]

They dodged a bullet. It would have been hell working there.

Re: Many hard LeetCode problems are easy constraint problems

#143

Post by drob518 »

LegionMammal978 wrote: post #136
drob518 wrote: post #117

Earlier quoted context omitted.

Well, they aren’t magic. You have to use them correctly and apply them to problems that match how they work. Proving something is unsat is worst case NP. These solvers don’t change that.

Of course they aren't magic, but people keep talking about them as if they're perfectly robust and ready-to-use for any problem within their domain. In reality, unless you have lots of experience in how to "use them correctly" (which is not something I think can be taught by rote), you'd be better off restricting their use to precisely the OR/verification problems they're already popular for.

Hence my statement about education. All tools must be used correctly in their proper domain, that is true. Don’t try to drive screws with a hammer. But I'm curious what problems you tried them on and found them wanting and what your alternative was? I actually find that custom solutions work better for simple problems and that solvers do a lot better when the problem complexity grows. You’re better off solving the Zebra puzzle and its ilk with brute force code, not a solver, for instance.

Re: Many hard LeetCode problems are easy constraint problems

#145

Post by SkiFire13 »

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?

Maybe because they are simplier to practice than working in a team?

Re: Many hard LeetCode problems are easy constraint problems

#146

Post by anal_reactor »

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/…

Maybe the process works as designed. It's just that "hiring the best developer" isn't necessarily the goal here

Re: Many hard LeetCode problems are easy constraint problems

#147

Post by LegionMammal978 »

js8 wrote: post #139
LegionMammal978 wrote: post #65

Earlier quoted context omitted.

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 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.

Re: Many hard LeetCode problems are easy constraint problems

#150

Post by Apocryphon »

chaboud wrote: post #24
kccqzy wrote: post #5

Great insight. But this is sadly not applicable to interviews. > It's easy to do in O(n^2) time, or if you are clever, you can do it in O(n). Or you could be not clever at all and just write it as a constraint problem This nails it. The point of these problems is to test your cleverness. That's it. Presenting a not-clever solution of using constraint solvers shows that you have experience and your breadth of knowledg…

When I interview with problem solving problems, the point is to understand how the candidate thinks, communicates, and decomposes problems. Critically, problem solving questions should have ways to progressively increase and decrease difficulty/complexity, so every candidate "gets a win" and no candidate "dunks the ball". Interviewers learn nothing from an instant epiphany, and they learn next to nothing from someone…

> the point is to understand how the candidate thinks, communicates, and decomposes problems

Interviewers always say this, but consider: would you endorse a candidate who ultimately is unable to solve the problem you've presented them, even if they think, communicate, and decompose problems well? No interview in this industry prizes those things over getting the answer right.

Post reply on HN