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

531–540 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#531

Post by mwcz »

mmis1000 wrote: post #522
mwcz wrote: post #491

Earlier quoted context omitted.

Is that the case? I saw a talk by the author of lodash years ago and he touched on performance. The built-in functions are (or were?) implemented in JS, level terrain for a library like lodash to beat "native" performance. Lodash beat browser built-ins in some cases. The talk was ten years ago, though, so things may have changed. Perhaps more of the built-ins are written in C++ now. Here's the talk: https://youtu.be/…

Ｉt's not really about the performance. It's about the readability. The performance don't even matter if you are just grouping dozens or hundreds items on the gui. Abuse Lodash or Underscore everywhere means the code is not readable unless you know what is every used lodash function intended to do. Combing with weak type and undocumented business logic (and api types), it's a true nightmare experience to work with. It…

"It's not really about the performance" the parent comment was about the performance of lodash.

Re: Many hard LeetCode problems are easy constraint problems

#532

Post by deepsun »

notemap wrote: post #494
deepsun wrote: post #417

Earlier quoted context omitted.

I did quite a bit of competitive programming in school, and pretty much all the world-class competitive problems are reduced to well-known algorithms. It's quite hard to come up with something new (not proven to be unsolvable for its constraints). I believe problem setters just try to disguise a known algorithm as much as possible. Then comes the ability/memorization to actually code it, e.g. if I knew it needs codin…

Solve one of my problems :) https://www.acmicpc.net/problem/33797 Try with an LLM too :)

403 Forbidden :(

Re: Many hard LeetCode problems are easy constraint problems

#533

Post by mmis1000 »

mwcz wrote: post #531
mmis1000 wrote: post #522

Earlier quoted context omitted.

Ｉt's not really about the performance. It's about the readability. The performance don't even matter if you are just grouping dozens or hundreds items on the gui. Abuse Lodash or Underscore everywhere means the code is not readable unless you know what is every used lodash function intended to do. Combing with weak type and undocumented business logic (and api types), it's a true nightmare experience to work with. It…

"It's not really about the performance" the parent comment was about the performance of lodash.

That's exact why I reply this though (or probably I should reply to your parent comment?). The place these get used are mostly performance insensitive location, it don't really do anything except ruins the readability. And the project is not that old either(It's a past es6-era project), I don't really get why it is used at all.

Re: Many hard LeetCode problems are easy constraint problems

#534

Post by forrestthewoods »

gnfargbl wrote: post #528
forrestthewoods wrote: post #501

Earlier quoted context omitted.

> Or at least, that's my expectation: I've never actually considered working somewhere that does leetcode interviews. Hrm. So what you're saying is you've never actually taken or given this style of interview. Nor presumably ever worked at a company that did this interview. So if on the off-chance these interviews actually were a somewhat successful tool for filtering candidates you wouldn't actually know it? That fe…

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". Interviews are strictly a proxy for "the real job". So arguments that "it's not reflective of the real job" are utterly irrelevant. It is not possible for ANY interview to fully reflect the real job. And you can't ask someone to quit a steady job to trial for 3 to 6 months to see if they're a good fit or not. So we're stuck with proxies.

I definitely think it's important for people who are hired to write code to in some form demonstrate that they are capable of writing code. That seems reasonable. But we can't expect candidates to write a big project for every place they apply. That's too much. And almost all candidates can't share code from their prior job. And solo GitHub side project are quite frankly not relevant for 99.99% of candidates. (And maybe more).

The one tried and trued method of hiring is to hire people you've worked with before who were good. This is not scalable.

Hiring is hard. Really really hard. I find that the vast majority of leet code complaints come from people who don't hire. If anyone ever cracks the puzzle of how to hire better they'll have a monumental competitive advantage. Many many have tried. So far none of have succeeded.

Re: Many hard LeetCode problems are easy constraint problems

#535

Post by wyager »

stuxnet79 wrote: post #228
wyager wrote: post #169

Earlier quoted context omitted.

Leetcode with no prep is a pretty decent coding skill test The problem is that it is too amenable to prep You can move your score like 2stddev with practice, which makes the test almost useless in many cases On good tests, your score doesn't change much with practice, so the system is less vulnerable to Goodharting and people don't waste/spend a bunch of time gaming it

> On good tests, your score doesn't change much with practice, so the system is less vulnerable to Goodharting and people don't waste/spend a bunch of time gaming it This framing of the problem is deeply troubling to me. A good test is one that evaluates candidates on the tasks that they will do at the workplace and preferably connects those tasks to positive business outcomes. If a candidate's performance improves w…

> A good test is one that evaluates candidates on the tasks that they will do at the workplace

Systematizing this is not feasible. The next best thing (in terms of predictive power for future job success) is direct IQ tests, which are illegal in the US. Next best thing after that are IQ proxies like coding puzzle ability.

> If a candidate's performance improves with practice, then so what?

It means the test isn't measuring anything useful. The extremely broad spectrum skills that benefit a software/eng role aren't something you can "practice".

> The only thing we should care about is that the interview performance reflects well on how the candidate will do within the company.

Agreed, which any Goodhartable test will never do.

Re: Many hard LeetCode problems are easy constraint problems

#536

Post by tptacek »

wyager wrote: post #535
stuxnet79 wrote: post #228

Earlier quoted context omitted.

> On good tests, your score doesn't change much with practice, so the system is less vulnerable to Goodharting and people don't waste/spend a bunch of time gaming it This framing of the problem is deeply troubling to me. A good test is one that evaluates candidates on the tasks that they will do at the workplace and preferably connects those tasks to positive business outcomes. If a candidate's performance improves w…

> A good test is one that evaluates candidates on the tasks that they will do at the workplace Systematizing this is not feasible. The next best thing (in terms of predictive power for future job success) is direct IQ tests, which are illegal in the US. Next best thing after that are IQ proxies like coding puzzle ability. > If a candidate's performance improves with practice, then so what? It means the test isn't mea…

Direct IQ tests are not illegal in the US. Several very large companies deliver them to candidates; the most prominent company that administers general cognitive exams for employment purposes has a logo crawl on its front page with names your parents would recognize. If this persistent meme about them being forbidden was real, employment lawyers would be making bank off them. The real reason most companies don't do general IQ testing for candidates is that it's not an effective screen for aptitude.

Re: Many hard LeetCode problems are easy constraint problems

#537

Post by teleforce »

Constraint programming complement ML/AI/LLM nicely in system solving real world problems [1],[2],[3],[4]. One of the highest stakes and hardest engineering problems namely wireless spectrum frequency allocation was solved by constraint programming and presented in [1]. Now anyone can try to solve the problem in a MiniZinc tutorial. Fun fact, there's also Knuth in the presentation audience trying to get some info on the subject matter perhaps for his next book.

[1] Logic, Optimization, and Constraint Programming: A Fruitful Collaboration - John Hooker - CMU (2023) [video]:

https://www.youtube.com/live/TknN8fCQvRk

[2] "We Really Don't Know How to Compute!" - Gerald Sussman - MIT (2011) [video]:

https://youtube.com/watch?v=HB5TrK7A4pI

[3] Google OR-Tools:

https://developers.google.com/optimization

[4] MiniZinc:

https://www.minizinc.org/

Re: Many hard LeetCode problems are easy constraint problems

#538

Post by mwcz »

mmis1000 wrote: post #533
mwcz wrote: post #531

Earlier quoted context omitted.

"It's not really about the performance" the parent comment was about the performance of lodash.

That's exact why I reply this though (or probably I should reply to your parent comment?). The place these get used are mostly performance insensitive location, it don't really do anything except ruins the readability. And the project is not that old either(It's a past es6-era project), I don't really get why it is used at all.

I'm not a lodash stalwart or anything, but years ago when I used it heavily, it made navigating and manipulating large/complex/irregular objects much easier. It's LINQ for JavaScript. And it was very readable and consistent, since most functions in lodash have the same signature.

Re: Many hard LeetCode problems are easy constraint problems

#539

Post by saagarjha »

sailingparrot wrote: post #486
saagarjha wrote: post #475

Earlier quoted context omitted.

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 ?

Basically pure software engineering
Post reply on HN