Live data from Hacker News

Many hard LeetCode problems are easy constraint problems

buttondown.com

231–240 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#231

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…

D'oh, that makes sense, I didn't consider the case where it would keep returning 10.

Re: Many hard LeetCode problems are easy constraint problems

#232

Earlier quoted context omitted.

There's an entire planet of jobs that have nothing to do with leetcode. I was talking about those, not FAANG stuff. Unfortunately I am not FAANG royalty. >Of course some still do, like Anthropic were you have to have a perfect score to 4 leetcode questions, automatically judged with no human contact, the worst kind of interview. Should be illegal honestly.

> Should be illegal honestly. I can't imagine this kind of entitlement. If you don't want to work for them, don't study leetcode. If you want to work for them (and get paid tons of money), study leetcode. This isn't a difficult aristotelian ethics/morals question.

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

Re: Many hard LeetCode problems are easy constraint problems

#233
post #222

Earlier quoted context omitted.

5 years ago you'd have a project like that, talk to someone at a company for like 30m-1hr about it, and then get an offer.

I have been getting grilled on leet code style questions since the beginning my of my career over 12 years ago. The faangs jump and then the rest of the industry does some dogshit imitation of their process

I'm lucky I'm in the frontend webdev sphere then I guess instead of like being a pure backend guy. I've had a couple of those live ones and just denied them. I did manage to implement a "snake" algorithm once but got denied because I wasn't able to talk about time/space complexity.

Re: Many hard LeetCode problems are easy constraint problems

#234

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…

Its not really memorizing solutions. Yes you can get quite far by doing so but follow ups will trip people up. However if you have memorized it and can answer follow ups, I dont see a problem with Leetcode style problems. Problem solving is about pattern matching and the more patterns you know and can match against, the better your ability to solve problems. Its a learnable skill and better to pick it up now. Persona…

Been in software development for 30 years. I have no idea what "Leetcode" is. As far as I know I've never been interviewed with "Leetcode", and it seems like I should be happy about that.

And when someone uses "leet" when talking about computing, I know that they aren't "elite" at all and it's generally a red flag for me.

Re: Many hard LeetCode problems are easy constraint problems

#235
post #61

Earlier quoted context omitted.

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…

I agree with everything you've written. Clarifying my "YOLO" usage: I was being a little flippant, in the sense that when ending an interview early with direct critical feedback, the most likely outcome is a "burned bridge" with that company (you're never coming back). Which reminds me one of my favorite twisted idioms: We'll burn that bridge when we get to it! I guess I've finally found an acceptable real-world use…

may the bridges I burn light the way.

Re: Many hard LeetCode problems are easy constraint problems

#236
post #214
post #205

Earlier quoted context omitted.

It's funny because this repo really does seem vibe-coded. Obviously I have no reason not to believe you, but man! All those emojis in the install shell script - I've never seen anyone other than an AI do that :) Maybe you're the coder that the AI companies trained their AI on. Sorry about the job interview. That sucks.

There's even a rocket emoji in server console.logs... There are memes with ChatGPT and rocket emojis as a sign of AI use. The whole repo looks super vibe-coded, emojis, abundance of redundant comments, all in perfect English and grammar, and the readme also has that "chatty" feel to it. I'm not saying that using AI for take-home assignments is bad/unethical overall, but you need to be honest about it. If he was lying…

As a big believer in documentation and communication in general, there's this inevitable double-bind that people hate whatever you give them and also hate it if you give them nothing. LLMs have made this worse.

No emojis and any effort to be comprehensive? Everyone complains "what is this wall of text", or "this is industry not grad school so cut it out with the fancy stuff" or "no one spends that much time on anything and it must be AI generated". (Frequently just a way of saying that they hate to read, and naively believe that even irreducibly complex stuff is actually simple).

Stuff that's got emojis, a friendly casual tone and isn't information dense? Well that's very chatty and cute, it also has to be AI and can't be valuable.

Since you can't win with docs, the best approach is to produce high quality diagrams that are simultaneously useful for a wide audience from novice to expert. The only problem is that even producing high quality diagrams at a ratio of 1 diagram per 1k lines of code is still very time consuming to produce if you're putting lots of thought into it, double so if you're fighting the diagramming tools, or if you want something that's easy for multiple stakeholders with potentially very different job descriptions to take in. Everyone will call it inadequate, ask why it took so long, and ask for the missing docs that they will hate anyway!

On the bright side, LLMs are pretty great at generating mermaid, either from code, or natural language descriptions of data-flows. Diagrams-as-code without needing a whole application UI or one of a limited number of your orgs lucid-chart licenses is making "Don't like it? Submit a PR" a pretty small ask. Skin in the game helps to curbs endless bike-shedding criticism

Re: Many hard LeetCode problems are easy constraint problems

#237

Earlier quoted context omitted.

5 years ago you'd have a project like that, talk to someone at a company for like 30m-1hr about it, and then get an offer.

Did you mean to type 25? 5 years ago LC challenge were as, if not more, prevalent than they are today. And a single interview for a job is not something I have seen ever after 15 years in the space (and a bunch of successful OSS projects I can showcase). I actually have the feeling it’s not as hardcore as it used to be on average. E.g. OpenAI doesn’t have a straight up LC interview even though they probably are the m…

I literally got my first real job 26 years ago by talking about my game engine, for a fintech firm.

Re: Many hard LeetCode problems are easy constraint problems

#238

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…

> 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 question/assignment.

The issue is that leetcode is something you end up with after discovery + scientific method + time, but there's no space in the interview process for any of that.

Your mind slides off leetcode problems because it reverses the actual on-the-job process and loses any context that'd give you a handle on the issue.

Re: Many hard LeetCode problems are easy constraint problems

#239
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…

> 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". Absolutely agree. When I interview, I start with a simple problem and add complexity as they go. Can they write X? Can they combine it with Y? Do they understand how Z is related?

Same. I'm never doing a fail/pass type interview. Instead I try to assess where the candidate is on the beginner/intermediate/expert axis and match that with the expectations of the role I'm interviewing for.

Re: Many hard LeetCode problems are easy constraint problems

#240
post #209

Earlier quoted context omitted.

how much did this job pay?

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
Post reply on HN