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

311–320 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#311

Post by sushisource »

tavavex wrote: post #192
yepitwas wrote: post #118

Earlier quoted context omitted.

If the candidate asks if you're sure you want them to use any language and you say "yes", and then get pissy when they do, the candidate isn't the one who sabotaged anything and they're dodging a bullet if they "fail".

I feel like I'm entering a whole different universe on HN. Maybe things are this equal and fair on the senior, high-paying part of the spectrum that most people here seem to occupy, but in general there's a huge power imbalance in job interviews. Unless you're special and the company wants you in particular, it costs them nothing to turn you down in favor of the other 10000 perfect applicants, while you must find a j…

When I say "any language" when interviewing candidates, I mean it. I would be stoked if someone busted out J in an interview.

Of course, my team also writes SDKs in a bunch of different languages, so it makes sense. Even if that weren't the case though, I'd be stoked. To your point though, early in your career, I get your viewpoint. It's hard out there to get a foot in the door and you have to seize opportunities.

Re: Many hard LeetCode problems are easy constraint problems

#312

Post by sarchertech »

MarcelOlsz wrote: post #220
Tenemo wrote: post #214

Earlier quoted context omitted.

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…

Oh my god Becky, there's even a rocket emoji in the server console logs! Should I also be "honest" about tab-completion? Where do you draw the line? Maybe I should be punished for having an internet connection too. Using AI for docker/readme's/simple scaffolding I would have done anyways ? Oh the horror! There was no lying because there was no discussion or mention of AI at all. Had they asked me, I'd have happily to…

You have that you’re the founder of an AI company in your hacker news profile, and your take home looks completely vibe coded. Why in the world are you surprised that a hiring manager is a little suspicious about your coding skills?

Given what you’ve said in your other comments, it seems like you used AI in a way that I wouldn’t have a problem with but just briefly looking through I can see how it would look suspicious.

Re: Many hard LeetCode problems are easy constraint problems

#313

Post by 6gvONxR4sf7o »

tannhaeuser wrote: post #310

Here's an easy ad-hoc Prolog program for the first problem: % Given a set of coin denominations, % find the minimum number of coins % required to make change. % IE for USA coinage and 37 cents, % the minimum number is four % (quarter, dime, 2 pennies). num(0). num(1). num(2). num(3). num(4). num(5). ?- num(Q), num(D), num(P), 37 is Q * 25 + D * 10 + P You can just paste it into [1] to execute in the browser. Using 60…

Of course, the challenge is that the next question after solving a leetcode problem is often to explain and optimize the performance characteristics, which in prolog can get stupidly hairy.

Re: Many hard LeetCode problems are easy constraint problems

#314

Post by skydhash »

tannhaeuser wrote: post #310

Here's an easy ad-hoc Prolog program for the first problem: % Given a set of coin denominations, % find the minimum number of coins % required to make change. % IE for USA coinage and 37 cents, % the minimum number is four % (quarter, dime, 2 pennies). num(0). num(1). num(2). num(3). num(4). num(5). ?- num(Q), num(D), num(P), 37 is Q * 25 + D * 10 + P You can just paste it into [1] to execute in the browser. Using 60…

I've actually used pseudo-prolog to explain how to solve leetcode problems to a friend. Write the facts, then write the constraints, and then state your problem. Close to the last part, they've already understood how to solve it, or at least how to write the program that can answer the question.

Re: Many hard LeetCode problems are easy constraint problems

#315

Post by LPisGood »

bluGill wrote: post #70
qnleigh wrote: 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…

Constraint solvers (or MILP solvers) while not asymptotically optimal are often as fast or faster than other methods.

Re: Many hard LeetCode problems are easy constraint problems

#316

Post by the_af »

CamperBob2 wrote: post #101

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…

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

Re: Many hard LeetCode problems are easy constraint problems

#318

Post by BhavdeepSethi »

IshKebab wrote: post #271
BhavdeepSethi wrote: post #267

It's insane how many of these new "AI" companies don't let you use AI or even your own IDE for coding interviews. And most questions from such companies are LC type problems so they know any AI tool can one shot it.

Why is that insane? Seems logical to me.

Definitely not insane. Ironic is the correct term. The field is evolving, a lot of these companies talk about replacing outdated practices using AI. Asking software engineers to not use their own tools to solve problems falls under the same bucket.

Re: Many hard LeetCode problems are easy constraint problems

#319

Post by didibus »

grugagag wrote: post #293
roncesvalles wrote: post #264

Earlier quoted context omitted.

>The LC interviews are like testing people how fast they can run 100m after practice Ah, but, the road to becoming good at Leetcode/100m sprint is: >a slow arduous never ending jog with multiple detours and stops along the way Hence Leetcode is a reasonably good test for the job. If it didn't actually work, it would've been discarded by companies long ago. Barring a few core library teams, companies don't really care…

But why stop there? Why not test candidates with problems they have never seen before? Or problems similar to the problems of the organization hiring? Leetcode mostly relies on memorizing patterns with a shallow understanding but shows the candidates have a gaming ability. Does that imply quality in any way? Some people argue that willing to study for leetcode shows some virtue. I very much disagree with that.

> Leetcode mostly relies on memorizing patterns

Math is like that as well though. It's about learning all the prior axioms, laws, knowing allowed simplifications, and so on.

Re: Many hard LeetCode problems are easy constraint problems

#320

Post by skydhash »

hackingonempty wrote: post #46
Der_Einzige wrote: post #27

Earlier quoted context omitted.

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!

I did this, wrote an Essence-prime program to generate Minion solver code for a simple instance of the knapsack problem, as part of a startups "solve one of these and get an interview" challenges. Because I had used those tools recently for a contract job (and wrote/presented a paper on invitation of the solver authors,) I thought it would be fun and didn't really want the job. Got an interview but every dev was like…

I would like to believe that most people capable of writing a solver would appreciate simple code. It's like when looking at ffmpeg or some physic engine code. You know you'll forget the details easily so you make sure everything is as simple as they can be.
Post reply on HN