Live data from Hacker News

Many hard LeetCode problems are easy constraint problems

buttondown.com

251–260 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#251

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 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 was once asked fizz buzz in an interview and it made me sad that some people don't pass it.

Re: Many hard LeetCode problems are easy constraint problems

#252

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…

More exactly, you can't invent algorithms on a spot which took who knows how many years for others to invent. I.e. the question ends up being more if you know about a specific algorithm, which results in "invent it if you don't know about it". It's absolutely silly to test for ability to invent one on the spot, so it's a pretty pointless interview question really.

Re: Many hard LeetCode problems are easy constraint problems

#253

Earlier quoted context omitted.

I meant no human-in-the-loop wrt hiring, which is what I thought you were getting at.

It's the same exact thing - if some company makes you jump through hoops to get hired that you find distasteful just don't apply to company.

You don't know their interview process unless it's one of the big tech companies though.

Re: Many hard LeetCode problems are easy constraint problems

#254

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!

This - the only downside to a constraint solver is it's usually slower. If you want them to write a fast algorithm, then specify that. Have an actual metric for it, if they can pass it with the declarative language, then great. If not, they should have written a more complicated algorithm.

Re: Many hard LeetCode problems are easy constraint problems

#255
post #240

Earlier quoted context omitted.

60k-120k euros. The upper 20k probably being entirely inaccessible so in reality probably like 70-100k euros.

It's always these low pay jobs that have the sloppiest interview experiences

I find it's less about the salary than it is the type of company. Any startup doing anything they consider remotely "cutting edge" is going to probably be a shit show.

Re: Many hard LeetCode problems are easy constraint problems

#256
post #250
post #169

Earlier quoted context omitted.

Leetcode with no prep is a pretty decent coding skill test The problem is that it is too amenable to prep You can move your score like 2stddev with practice, which makes the test almost useless in many cases On good tests, your score doesn't change much with practice, so the system is less vulnerable to Goodharting and people don't waste/spend a bunch of time gaming it

I think LC is used mostly as a metric of how much tolerance you have for BS and unpaid work: If you are willing to put unpaid time to prepare for something with realistically zero relevance with the day-to-day duties of the position, then you are ripe enough to be squeezed out.

It selects for age and childlessness.

Re: Many hard LeetCode problems are easy constraint problems

#257
post #70
post #36

Earlier quoted context omitted.

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…

IBO premature optimization is normally one of two things:

1. Any optimization in a typical web development file where the process is not expected to be particularly complex. Usually a good developer will not write something very inefficient and usually bottlenecks come from other areas

2. Doing stuff like replacing a forEach with a for loop to be 0.5% faster

Re: Many hard LeetCode problems are easy constraint problems

#258

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 was once asked fizz buzz in an interview and it made me sad that some people don't pass it.

I guess when you're brand new you don't know about the mod operator?

Re: Many hard LeetCode problems are easy constraint problems

#259

Earlier quoted context omitted.

I meant no human-in-the-loop wrt hiring, which is what I thought you were getting at.

It's the same exact thing - if some company makes you jump through hoops to get hired that you find distasteful just don't apply to company.

No. Certain things just harm basic human dignity and should be outlawed. Judgement comes from our peers, not from machines.

Re: Many hard LeetCode problems are easy constraint problems

#260

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…

Hah I feel you there. Around 2 years ago I did a take home assignment for a hiring manager (scientist) for Merck. The part B of the assignment was to decode binary data and there were 3 challenges: easy, medium and hard.

I spent around 40 hours of time and during my second interview, the manager didn't like my answer about how I would design the UI so he quickly wished me luck and ended the call. The first interview went really well.

For a couple of months, I kept asking the recruiter if anyone successfully solved the coding challenge and he said nobody did except me.

Out of respect, I posted the challenge and the solution on my github after waiting one year.

Part 2 is the challenging part; it's mostly a problem solving thing and less of a coding problem: https://github.com/jonnycoder1/merck_coding_challenge

Post reply on HN