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

401–410 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#401

Post by roncesvalles »

grugagag wrote: post #396
roncesvalles wrote: post #393

Earlier quoted context omitted.

I think you have a misunderstanding. Most companies that do LC-style interviews usually show unknown problems. Memorizing the Top 100 list from Leetcode only works for a few companies (notably and perplexingly, Meta) but doesn't for the vast majority. Also, just solving the problem isn't enough to perform well on the interview. Getting the optimal solution is just the table stakes. There's communication, tradeoffs be…

It’s not about memorizing individual problems per se, but rather recognizing overall patterns and turning the process into a gameable endeavor. This can give candidates an edge, but it doesn’t necessarily demonstrate higher-level ability beyond surface familiarity with common patterns and the expectations around them. I’d understand the value if the job actually involved work similar to what's reflected in leetCode s…

>a candidate’s willingness to invest time and effort

I guess it's a matter of opinion but my point is, this is probably the right metric. Arguably, the kind of people who shut up and play along with these stupid games because that's where the money is make better team players in large for-profit organizations than those who take a principled stance against ever touching Leetcode because their efforts wouldn't contribute anything to the art.

Re: Many hard LeetCode problems are easy constraint problems

#402

Post by grugagag »

roncesvalles wrote: post #401
grugagag wrote: post #396

Earlier quoted context omitted.

It’s not about memorizing individual problems per se, but rather recognizing overall patterns and turning the process into a gameable endeavor. This can give candidates an edge, but it doesn’t necessarily demonstrate higher-level ability beyond surface familiarity with common patterns and the expectations around them. I’d understand the value if the job actually involved work similar to what's reflected in leetCode s…

>a candidate’s willingness to invest time and effort I guess it's a matter of opinion but my point is, this is probably the right metric. Arguably, the kind of people who shut up and play along with these stupid games because that's where the money is make better team players in large for-profit organizations than those who take a principled stance against ever touching Leetcode because their efforts wouldn't contrib…

Maybe yes maybe not, I'm leaning not but it's just an opinion. But as a company be careful what you wish for, these same candidates are often skilled at gaming systems and may leave your team as soon as they've extracted the benefits. They’re likely more interested in playing the game than in seriously solving real-world problems.

Re: Many hard LeetCode problems are easy constraint problems

#403

Post by mcmoor »

shmerl wrote: post #252
gnfargbl wrote: post #66

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…

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.

I hate when it asks for a memorized specific problem, but most of the hard ones I found needs a clever twist of a well-known algorithm, and I still struggle at that too for hard LC.

Re: Many hard LeetCode problems are easy constraint problems

#404

Post by mcmoor »

jojomodding wrote: post #341
_alternator_ wrote: post #19

Earlier quoted context omitted.

This. Literally every problem in NP can be cast as a constraint problem. The question of whether a solver is the right solution varies a lot depending on the application, and in an interview , it’s almost by definition not the right solution. They can also be dreadfully slow (and typically are) compared to just a simple dynamic program.

LeetCode problems typically are in P. The challenge is finding out why.

Yeah I think the trivial solution is always harder complexity and the main challenge is to lower it. Either from NP to P or from n*2 to n log n.

Re: Many hard LeetCode problems are easy constraint problems

#405

Post by mcmoor »

btilly wrote: post #78
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…

Bottom up dynamic programming algorithms require some cleverness. All of the ones listed can be solved with a top down dynamic programing algorithm. Which just means "write recursive solution, add caching to memoize it". For some of these, you can get cleverer. For example the coin change problem is better solved with an A* search. Still, very few programmers will actually need these algorithms. The top thing we need…

For the love of me I still can't consistently solve dynamic programming problems. Because "write a clever brute force solution that can be cached" is so broad that there are tons of variations out there, and a slight twist can bring you out of the loop fast.

Re: Many hard LeetCode problems are easy constraint problems

#406

Post by chaboud »

Apocryphon wrote: post #150
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…

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

Note how I structure my problem solving questions to be progressive and adjustable, both up and down. This gives me room to simplify and get the candidate to a place where they can show me something (candidates who truly come up goose eggs on everything functional but still show solid fundamentals may be showing that the interview is for the wrong job family). It also means that it is virtually impossible to get all the way to "the end" and "finish" the problem, as I leave room for extension and modification. I had one question that I thought was long enough, and, of maybe ~120 interviews with it, exactly two people dunked on it, one writing out code for solutions with and without libraries. That guy was a complete jerk, and I wasn't at all surprised when the entire panel came back not-inclined.

My first boss (a CTO at a start-up) drilled this into us. What you know is far less valuable than how you learn/think and how you function on a team.

Re: Many hard LeetCode problems are easy constraint problems

#407

Post by userbinator »

jonnycoder wrote: post #260
MarcelOlsz wrote: post #172

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…

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…

Part 2 is the challenging part; it's mostly a problem solving thing and less of a coding problem

That doesn't look too challenging for anyone who has experience in low-level programming, embedded systems, and reverse engineering. In fact for me it'd be far easier than part 1, as I've done plenty of work similar to the latter, but not the former.

Re: Many hard LeetCode problems are easy constraint problems

#408

Post by userbinator »

_whiteCaps_ wrote: post #191
MarcelOlsz wrote: post #172

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…

That is an insane amount of work for a job application. Were you compensated for it at all?

The other comments here note that, and the author even stated it directly, that it was vibe-coded.

Re: Many hard LeetCode problems are easy constraint problems

#409

Post by Apocryphon »

chaboud wrote: post #406
Apocryphon wrote: post #150

Earlier quoted context omitted.

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

Note how I structure my problem solving questions to be progressive and adjustable, both up and down. This gives me room to simplify and get the candidate to a place where they can show me something (candidates who truly come up goose eggs on everything functional but still show solid fundamentals may be showing that the interview is for the wrong job family). It also means that it is virtually impossible to get all…

Interesting. Sounds like you and other HN commentators from firms that interview better than the industry Leetcode convention oughta be on one of those workplace lists on GitHub (like this one: https://github.com/poteto/hiring-without-whiteboards) for applicants who want to go through a more interesting process.

Re: Many hard LeetCode problems are easy constraint problems

#410

Post by userbinator »

Tenemo wrote: post #214
johnfn wrote: 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…

If you're using AI for an interview, you are basically telling them "you could just not bother with hiring me and use AI yourself" which is neither good for you nor them.
Post reply on HN