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

541–550 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#541

Post by gnfargbl »

forrestthewoods wrote: post #534
gnfargbl wrote: post #528

Earlier quoted context omitted.

Your criticism is valid. I've also never worked at a place that uses beatings to improve employee morale. So, I can't guarantee that beatings aren't an effective technique for doing so.

lol. My deeply unpopular opinion is that "leet code style" interviews are actually pretty decent at avoiding false positives. Obviously some specific questions are gotcha trivia and many interviewers are bad no matter the question. But they're a reasonably accurate proxy. Their issue is false negatives. End of the day the ONLY question an interview sets out to answer is "will this candidate be successful in this role…

It's a fair point; hiring is hard.

It's been a while since I had to hire outside your "people you've worked with before" bucket, but when I did, here are the two questions which worked best:

1. Tell me about a time you analysed a complex problem and came up with a solution.

2. Tell me something creative you did at work. Something you're proud of.

In my experience, a good candidate typically had excellent answers to those questions, because (1) a good candidate has had to do some real engineering at some point and they can tell you about it, and (2) a good candidate has done technical work which they're really proud of just in and of itself, and they want to tell you about it.

A technical question was useful in reducing false positives, but something a couple of steps above FizzBuzz should be fine for that. You just find out anything useful about a candidate by asking them to recreate some esoteric CS algorithm on the spot, unless you really need to select for people who can recreate esoteric CS algorithms on the spot.

Re: Many hard LeetCode problems are easy constraint problems

#542

Post by sailingparrot »

saagarjha wrote: post #539
sailingparrot wrote: post #486

Earlier quoted context omitted.

Might depend on the specific position you applied to. Was it a pure SDE role or more on the research side ?

Basically pure software engineering

Interesting, maybe they stopped doing this then. It used to be that you received a link for an automated online test, with 4 progressively harder questions, and you needed to score 1000/1000 to go the next step and speak to a human.

Re: Many hard LeetCode problems are easy constraint problems

#543

Post by CamperBob2 »

the_af wrote: post #499
the_af wrote: post #316

Earlier quoted context omitted.

By the way, ChatGPT was able to solve this problem and give the correct solution.

Interesting that an informative comment, without any implications or insinuations, got downvoted. HN sucks sometimes. "Intellectual discourse" and "hacker curiosity" my ass.

I voted you back up. It's the least I could do. :)

Re: Many hard LeetCode problems are easy constraint problems

#544

Post by cerved »

gnarlouse wrote: post #515
cerved wrote: post #512

Earlier quoted context omitted.

Presumably you run it with multiple workers, preferably in parallel (it's designed to run like that) Depending on your problem and how you can solve it (single threaded & low memory vs. anything goes) it might be a good idea trying other solvers. OR-Tools CP-SAT(LP) pretty much never does bad on a any problems but there are other CP-SAT solvers like Chuffed & Huub as well as Gecode which is a pure CP solver that does…

Wow thanks, I’ll have to look at those. The CPSAT was an LLM suggestion that I just ran with after doing some very weak research—im not a constraint programming researcher by any means. Since we’re on the topic and you seem knowledgeable, any good primer literature I might check out for understanding the basis of tweaking constraint solvers? I have started running into some performance issues after integrating an opt…

The Coursera courses are a great resource for learning how to model problems.

> any good primer literature I might check out for understanding the basis of tweaking constraint solvers? I have started running into some performance issues after integrating an optimization function, and have started to wonder how can I claim back some performance.

There is usually less tweaking of solvers and much more remodeling the problem using a different viewpoint or constraints to solve the problem. There courses teach you that. But beware that's it's not so trivial.

Also, careful with LLMs and constraint solvers, sometimes they yield absolute rubbish.

Re: Many hard LeetCode problems are easy constraint problems

#545

Post by chipsrafferty »

koakuma-chan wrote: post #258
chipsrafferty wrote: post #251

Earlier quoted context omitted.

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?

But if you're brand new, you aren't qualified for this job. I guess it was a quick way to assess, if you can't solve this in 60 seconds, we can end the interview early? But I thought it was odd still.

Re: Many hard LeetCode problems are easy constraint problems

#547

Post by theendisney »

efortis wrote: post #421
theendisney wrote: post #394

coins = [100,50,25,10,5,1] change = 1234; result = [0,0,0,0,0,0]; for(i=0:i coins[i]){ result[i]++; change-=coins[i]; } } //[12,0,1,1,4] Coudnt help myself sorry

me neither function coin_change(change) { const coins = [25, 10, 5, 1] for (const coin of coins) { const n = change / coin | 0 change -= n * coin console.log(coin, n) } } coin_change(25+10+5+1)

Or....

  [100,500,25,10,5,1].map(coin=>{
     n = change / coin | 0
     change %= coin;
     return n 
    })
Coding on a Phone is hell

Re: Many hard LeetCode problems are easy constraint problems

#548

Post by btilly »

mcmoor wrote: post #405
btilly wrote: post #78

Earlier quoted context omitted.

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.

There may be a lot of ways to write the recursive solution. But adding caching to any of them will give you a top-down dynamic programming solution.

Re: Many hard LeetCode problems are easy constraint problems

#549

Post by btilly »

zelphirkalt wrote: post #450
mcmoor wrote: post #405

Earlier quoted context omitted.

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.

Project Euler 18. I tried 3 heuristic approaches, before accepting, that to get the real answer without brute forcing it (because it comes back later in non-brute forcable version anyway), I need to find another way. I came up with an optimal solution, but it is still not dynamic programming, which I would also consider inferior to the bottom up solution I have found.

There is only one efficient solution that can be described as bottom up, and that one is in fact dynamic programming.

A top-down solution in this case is in fact strictly worse. Why? Because while both take similar numbers of operations, in the bottom up solution you can throw away a row once you've processed the one above it. But in a top-down solution, you never know when you might call a particular recursive call again.

This is very common. In a bottom up approach, we often know when we're done with data and can throw it away. This memory savings is the reason why people try to learn a bottom up approach. But it does come with the price of trying to figure out various kinds of "tricks". (That in complicated cases, may not be findable.)

Re: Many hard LeetCode problems are easy constraint problems

#550

Post by jonnycoder »

userbinator wrote: post #407
jonnycoder wrote: post #260

Earlier quoted context omitted.

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.

Yea it’s pretty easy after doing them, but it’s rare for software developers these days to do that activity on a day to day basis. It reminded me of the software crackers of the 90s and 2000s who would post cracks for windows software like autocad.

It’s also relative because a $50/hr contract job isn’t exactly attracting low level FAANG engineering talent. But it’s a nice take home challenge for some second rate engineer like myself who will tackle any problem until I figure it out.

Post reply on HN