Live data from Hacker News

Many hard LeetCode problems are easy constraint problems

buttondown.com

171–180 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#171

Earlier quoted context omitted.

> My biggest problem with leetcode type questions is that you can't ask clarifying questions. Huh? Of course you can. If you're practicing on leetcode, there's a discussion thread for every question where you can ask questions till the cows come home. If you're in a job interview, ask the interviewer. It's supposed to be a conversation. > I wouldn't even mind the studying on leetcode types sites if they actually had…

Many interviews now involve automated exercises on websites that track your activity (don't think about triggering a focus change event on your browser, it gets reported). Also, the reviewer gets an AI report telling it whether you copied the solution somewhere (expressed as a % probability). You have few minutes and you're on your own. If you pass that abomination, maybe, you have in person ones. It's ridiculous wha…

"don't think about triggering a focus change event on your browser, it gets reported)."

So .. my approach would be to just open dev tools and deactivate that event.

Show of practical skill or cheating?

Re: Many hard LeetCode problems are easy constraint problems

#172

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 (for https://monumental.co): https://github.com/rublev/monumental

Re: Many hard LeetCode problems are easy constraint problems

#173

I implemented the simple greedy algorithm and immediately fell into the trap of the question: the greedy algorithm only works for "well-behaved" denominations. If the coin values were [10, 9, 1], then making 37 cents would take 10 coins in the greedy algorithm but only 4 coins optimally (10+9+9+9). That's a bad algorithm, then, not a greedy algorithm. Wouldn't a properly-implemented greedy algorithm use as many coins…

> Wouldn't a properly-implemented greedy algorithm use as many coins as possible of a given large denomination before dropping back to the next-lower denomination?

Yes, and it won't work on the problem described. The greedy algorithm only works on certain sets of coins (US coin denominations are one of those sets), and fails in at least some cases with other coin sets (as illustrated in the bit you quoted).

Re: Many hard LeetCode problems are easy constraint problems

#174

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…

Wait, what.. you did this as a take home for a position? Damn that looks excessive.

Re: Many hard LeetCode problems are easy constraint problems

#175
post #87

Earlier quoted context omitted.

[flagged]

Interviews go both ways ... I don't think they lost out on anything they wanted.

That is what people miss about interviews. Often when you interview you don't have reasonable leads on any other job and so you don't feel like there is a choice since you likely need a job (unemployment rarely pays as well as a job). However interviews are not only about the company deciding if they will hire you, they are also about do you want to work there and convincing you to take the job if one is offered.

So make sure you use those "do you have any questions" time to ask questions! What is it really like to work there. How much notice do you need to give before taking vacation? Do they really give pay raises? How often do they lay people off? What is the dress code? Do they let you take time for your kids school activities? And so on - these questions should be things that are important to you - find out.

In the best cases the interview is only about convincing you to take the offer - generally because someone who you worked with at a previous job said "hire this person" and they trust that person enough to not need any other interview. So keep your network open.

Re: Many hard LeetCode problems are easy constraint problems

#176

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.

This will be true in some interviews, but not in all.

I'm generally against using leetcode in interviews, but wherever I've seen it used it's usually for one reason & one reason alone: known dysfunctional hiring processes. These are processes where the participants in the hiring process are aware of the dysfunction in their process but are either powerless or - more often - too disorganised to properly reform the process.

Sometimes this is semi-technical director level staff leveraging HR to "standardise" interview techniques by asking the same questions across a wide range of teams within a large corp. Other times this is a small underresourced team cobbling together interview questions from online resources in a hurry, not having the cycles to write a tailored process for themselves.

In these cases, you're very likely to be dealing with a technical interviewer who is not an advocate of leetcode interviewing & is attempting to "look around" the standardised interview scoring approach to identify innovative stand out candidates. In a lot of cases I'd hazard even displaying an interest in / some knowledge of solvers would count significantly in your favour.

Re: Many hard LeetCode problems are easy constraint problems

#177

Earlier quoted context omitted.

> My biggest problem with leetcode type questions is that you can't ask clarifying questions. Huh? Of course you can. If you're practicing on leetcode, there's a discussion thread for every question where you can ask questions till the cows come home. If you're in a job interview, ask the interviewer. It's supposed to be a conversation. > I wouldn't even mind the studying on leetcode types sites if they actually had…

Many interviews now involve automated exercises on websites that track your activity (don't think about triggering a focus change event on your browser, it gets reported). Also, the reviewer gets an AI report telling it whether you copied the solution somewhere (expressed as a % probability). You have few minutes and you're on your own. If you pass that abomination, maybe, you have in person ones. It's ridiculous wha…

The major difference between software devs and lawyers, surgeons, and civil engineers is that the latter three have fairly rigorous standards to pass to become a professional (bar, boards, and PE).

That could exist for software too, but I'm not sure HN folks would like that alternative any better. Like if you thought memorizing leetcode questions for 2 weeks before an interview was bad, well I have some bad news.

Maybe in 50-100 years software will have that, but things will look very different.

Re: Many hard LeetCode problems are easy constraint problems

#178
post #94

I find this post interesting independent of the question of whether leetcode problems are a good tool for interviews. It's: here are some kinds or problems constraint solvers are useful for. I can imagine a similar post about non-linear least squared solvers like ceres.

Yeah, especially for learning how to use a solver!

> Most constraint solving examples online are puzzles, like Sudoku or "SEND + MORE = MONEY". Solving leetcode problems would be a more interesting demonstration.

He's exactly right about what tutorials are out there for constraint programming (I've messed around with it before, and it was pretty much Sudoku). Having a large body of existing problems to practice against is great.

Re: Many hard LeetCode problems are easy constraint problems

#179

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.

The purpose of coding questions should be a problem that you can solve in about 20 minutes, then they ask another, and then you get 20 minutes to either finish or talk about other things. If you ask questions where either someone knows the trick and they pass, or they don't and fail you don't learn much. You need to watch the person write code to see if they are reasonable about it.

Re: Many hard LeetCode problems are easy constraint problems

#180
post #174

Earlier quoted context omitted.

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…

Wait, what.. you did this as a take home for a position? Damn that looks excessive.

Yes. I put a ton of work into it. I had about 60 pages worth of notes. On inverse kinematics, FABRIK, cyclic algorithms used in robotics, A*/RRT for real-world scenarios etc. I was super prepared. Talked to the CEO for about two hours. Took notes on all videos I can find of team members on youtube and their company.

Luckily the hiring manager called me back and levelled with me, nobody kept him in the loop and he felt terrible about it.

Some stupid contrived dumbed down version of this crane demo was used for the live test where I had to build some telemetry crap. Nerves took over, mind blanked.

Here's the take-home assignment requirements btw: https://i.imgur.com/HGL5g8t.png.

Here's the live assignment requirements: [1] https://i.imgur.com/aaiy7QR.png & [2] https://i.imgur.com/aaiy7QR.png.

At this rate I'm probably going to starve to death before I get a job. Should I write a blog post about my last 2 years of experiences? They are comically bad.

This was for monumental.co - found them in the HN who's hiring threads.

Post reply on HN