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

481–490 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#481

Post by zahlman »

tdeck wrote: post #439
tavavex wrote: post #192

Earlier quoted context omitted.

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…

> I'll assume they want Python or Java or C++ or Rust, not Bash or ALGOL 68. I've solved interview questions with one line of Bash before and gotten an offer. The question was something like "count all the files in this folder with a name ending in X". The interviewer was happy I had a quick solution and they could move on to talking about something more interesting.

The obvious ways to do this sort of thing in Bash have some nasty gotchas on non-standard filenames, though.

And a Python solution that avoids those problems is also quite simple and terse for the example you gave, and probably for most problems in the category.

Re: Many hard LeetCode problems are easy constraint problems

#482

Post by nothrabannosir »

xenocratus wrote: post #227
lucianbr wrote: post #83

Earlier quoted context omitted.

> I'd put "ability to work in a team" above "raw academic/reasoning ability" for the vast majority of engineering roles, any day. In this hypothetical, why do you do leetcode hard interviews?

> In this hypothetical, why do you do leetcode hard interviews? I thought I already answered that: >> Not that the latter doesn't matter, of course, but it's by no means the one and only measure.

It is the only thing you measure when you do leetcode.

Re: Many hard LeetCode problems are easy constraint problems

#483

Post by zahlman »

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?

Even if you don't know about modulo, or (floor) division, you could subtract in a loop and see if you reach zero. Obviously not a good approach, but would demonstrate the kind of basic problem solving skill and ability to "write any working code at all" that this sort of thing is supposed to screen for.

You could improve that and still avoid any division or modulus by simply keeping track of when the "next fizz" and "next buzz" should occur. (And output "fizzbuzz" when those numbers are the same and you reach them.)

Re: Many hard LeetCode problems are easy constraint problems

#484

Post by psychoslave »

Sesse__ wrote: post #275
tavavex wrote: post #192

Earlier quoted context omitted.

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…

> Of course when the interviewer asks me to use "any language", I'll assume they want Python or Java or C++ or Rust, not Bash or ALGOL 68. When I did interviews, I used to ask for “any imperative language”. Most people chose C or Java, some chose e.g. Python and the best solutions looked very different from the C/Java ones. I did not deduct points for either; a good solution is a good solution. I once had a candidate…

Even in most used languages it's hard to be accurate without making profiling. And when using a framework, it's almost a garantee that you have no idea of the complexity under the hood of all the facilities you rely on.

Re: Many hard LeetCode problems are easy constraint problems

#485

Post by zahlman »

mcmoor wrote: post #404
jojomodding wrote: post #341

Earlier quoted context omitted.

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.

> or from n*2 to n log n.

I guess you mean n^2 (or maybe n**2, if you're a fellow Pythonista). Many of these — especially the ones where the intended solution is characterized as using a "dynamic programming" technique — are reducible to n.

Re: Many hard LeetCode problems are easy constraint problems

#486

Post by sailingparrot »

saagarjha wrote: post #475
sailingparrot wrote: post #213

Earlier quoted context omitted.

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 don’t know if this has changed or perhaps was not representative but my entire loop at Anthropic involved people reviewing my code.

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

Re: Many hard LeetCode problems are easy constraint problems

#488

Post by never_inline »

roncesvalles wrote: post #264
samiv wrote: post #167

Earlier quoted context omitted.

The LC interviews are like testing people how fast they can run 100m after practice, while the real job is a slow arduous never ending jog with multiple detours and stops along the way. But yeah that's the game you have to play now if you want the top $$$ at one of the SMEGMA companies. I wrote (for example) my 2D game engine from scratch (3rd party libs excluded) https://github.com/ensisoft/detonator but would not b…

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

> the road to becoming good

In my experience, it's totally not true.

Many college students of my generation are pretty good with LC hards these days purely due to FOMO-induced obsessive practice, which doesn't translate to a practical understanding of the job, (or any other parts of CS like OS/networks/languages/automata either).

I will give you an exercise, pick an LC hard problem and it's very likely an experienced engineer who has only done "real work" will not know the "trick" required to solve the problem. (Unless it's something common like BFS or backtracking).

I say this as someone with "knight" badge on leetcode, whatever that means, lest you think it's a sour grapes fallacy.

Re: Many hard LeetCode problems are easy constraint problems

#489

Post by coarise »

jcul wrote: post #431

I've never used constraint solvers, seems like black magic. Need to fill that gap in my knowledge. But how do they work, what is the complexity of the solution, for example for the stock prices, is it O(n^2)?

General constraint satisfaction problem is NP-hard.

Re: Many hard LeetCode problems are easy constraint problems

#490

Post by catlifeonmars »

Jensson wrote: post #435
catlifeonmars wrote: post #385

Earlier quoted context omitted.

In math, you usually need to prove said simplifications. So just memorizing is not enough. As you get more advanced, you then start swapping out axioms.

In programming the simplifications has to be correct even if you don't prove them, and being correct isn't that easy.

Pedantic: how do you know something is correct without proving it? How do you know you have covered all possible edge cases? /Pedantic

In all seriousness, the intersection between correctness and project delivery is where engineering sits. Solutions must be good enough, correct enough, and cheap enough to fit the use case, but ideally no more than that.

Post reply on HN