Earlier quoted context omitted.
[flagged]
What's the point of doing well if you already determined you wouldn't even look at their offer?
What's the point of wasting time? Walk out of the fucking interview then.
Many hard LeetCode problems are easy constraint problems
521–530 of 551 posts
Re: Many hard LeetCode problems are easy constraint problems
#522Earlier quoted context omitted.
What, like lodash? Some of those hail from a time that we didn't have a good set of native methods. So the library is just legacy'd in. But I do agree, lodash performance compared to native functions is crazy bad.
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's probably irrelevant in a personal project. But it's a headache if you are collaborating.
Sometimes it got even worse that original user don't know the exact specification of the utility function either. And the code works just by pure luck. (something like, the method work if all keys are numeric) It will give you a hard time to troubleshoot the problem if it happens.
Re: Many hard LeetCode problems are easy constraint problems
#523Earlier quoted context omitted.
There are other aspects to maintenance, like requirements change. In this case it's trivial to change or add new constraints to a constraint solver, whereas even small changes to a typical DP problem can require a total rethink of the approach. Extending the analogy to other kinds of dependencies left as an exercise for the reader. Point being that software has many dimensions. Reducing the use of dependencies to fea…
Imo, deepending on the desired quality of the result and the amount and complexity of bespoke requirements, the more of the former are present, the more strongly I consider rolling something bespoke. With out-of-the-box libraries, the more custom requirements I have, the more trouble I tend to have supporting them, and trying to make something do a thing it wasn't designed for, can erase initial gains very quickly. A…
I mean, it really depends. I'm writing models for some energy traders at the moment, and things were simple enough in the mvp that we could hand-roll our optimisations. But when we started having to map real contracts it got out of hand super fast. Linear constraints solvers have been a godsend, it makes adding new types of contacts and constraints really easy (and supports almost arbitrary kinds of optimisations).
It's just never as easy as "don't do this" or "always do this". But yeah, I agree with your gist, right tools for the right job and all that. Most of the time you don't know all requirements up front and it can make sense to hedge your bets in the interest of speed until you do.
Re: Many hard LeetCode problems are easy constraint problems
#524Earlier quoted context omitted.
> 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.
But with an explicitly implemented algorithm, you can probably at least give an upper bound.
Re: Many hard LeetCode problems are easy constraint problems
#525Earlier quoted context omitted.
I was told to use ANY language in an interview. I asked them if they were sure, so I solved it with J. They were not too pleased and asked me if I could use another language, so I did prolog and we moved on to the next question. Then the idiot had the audacity to say I should not use "J and Prolog" but any common known language. I asked if assembly was fine, and they said no. Perhaps python or javascript. I did the r…
Reminds me of https://aphyr.com/posts/340-reversing-the-technical-intervie... (and the follow-ups to it)
[deleted]
Re: Many hard LeetCode problems are easy constraint problems
#526Earlier quoted context omitted.
I understand that this is an advertisement for your product, but please do not do this here. Thank you.
You're right to point that out, thanks for keeping things honest. My intention was simply to offer a helpful TL;DR for a very long thread, as it's a feature of a project I'm working on (mentioned in my profile). I'm trying to contribute value without being spammy. If this crosses a line for the community, I'm happy to listen and adjust.
It's a long-established norm on HN that we don't want summaries and TL;DRs. I explained the reasoning recently here: https://news.ycombinator.com/item?id=44946681
Re: Many hard LeetCode problems are easy constraint problems
#527Earlier quoted context omitted.
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.
I think you've missed a big part of maths - yes knowing those things is necessary. But then you also need to be able to see how a difficult or complex problem could be restated or broken down in a different way which lets you use those techniques. Sometimes this is something as trivial as using the right notation or coordinates, sometimes it's much more involved.
Re: Many hard LeetCode problems are easy constraint problems
#528Earlier 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…
> 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.
Re: Many hard LeetCode problems are easy constraint problems
#529Very interesting article and good points. But how about we flip the original statement around: Many problems thought to require giant software packages/libraries are very solvable locally if you know what you are doing This is why LC is actually meaningful - imagine if you faced the coin challenge problem IRLin prod and you decided to pull in a constraint solver - what would've been a 25 line function now is a giant…
hard disagree: Given ANY problem: first ask yourself have others solved this before? that is a hard question to answer, since we don't know in which context a similar puzzle was solved before (structures in different domains can boil down to the same mathematical puzzle). A literature search would be very time costly. The most important point is the flexibility in being able to change the puzzle (a small change in th…
>>It may sound incredibly expensive to pull in a constraint solver
Like this is actually kinda the point of the article. On every constraint programming article half the comments insist that they could do the (example) problem in a dozen lines of C so bringing in SCIP or OR-Tools is "too much" for the (example) problem. Wayne's point (here and in other articles he's written) is that actually constraint problems are fucking everywhere.
This is one of the real lessons of learning Prolog: data queries, scheduling, SAT, LP, integer programming, optimization... etc; it's all constraint programming, hell parsing is a constraint problem if you do it right. No one sees it like that though so they see their entire business application logic as containing at most one knapsack.
Re: Many hard LeetCode problems are easy constraint problems
#530Earlier 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…
I was told to use ANY language in an interview. I asked them if they were sure, so I solved it with J. They were not too pleased and asked me if I could use another language, so I did prolog and we moved on to the next question. Then the idiot had the audacity to say I should not use "J and Prolog" but any common known language. I asked if assembly was fine, and they said no. Perhaps python or javascript. I did the r…
You fired them.