But how do they work, what is the complexity of the solution, for example for the stock prices, is it O(n^2)?
Many hard LeetCode problems are easy constraint problems
431–440 of 551 posts
Re: Many hard LeetCode problems are easy constraint problems
#432Earlier quoted context omitted.
>a candidate’s willingness to invest time and effort I guess it's a matter of opinion but my point is, this is probably the right metric. Arguably, the kind of people who shut up and play along with these stupid games because that's where the money is make better team players in large for-profit organizations than those who take a principled stance against ever touching Leetcode because their efforts wouldn't contrib…
Then what if the test was how well you play chess? That takes time to study to become good. But would it be a good metric for hiring programmers?
But yeah, people used to ask that level of unrelated questions to programmers, and they were happy with the results. "Why are manhole covers round" etc. LeetCode style questions do produce better results than those, so that is why they use them.
Re: Many hard LeetCode problems are easy constraint problems
#433Earlier 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…
Does it work though? When I look at the messy Android code, Fuchsia's commercial failure, Dart being almost killed by politics, Go's marvellous design, WinUI/UWP catastrophical failure, how C++/CX got replaced with C++/WinRT, ongoing issues with macOS Tahoe,.... I am glad that apparently I am not good enough for such projects.
The fact is that they fail is not evidence that leetcode interviews fails to select for high quality engineers.
Re: Many hard LeetCode problems are easy constraint problems
#434Earlier quoted context omitted.
> 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.
In the same way that writing and performing a new song is "just memorizing prior patterns and law" or that writing a new book is the same. I.e. it's not about that. Like sure it helps to have a base set of shared language, knowledge, and symbols, but math is so much more than just that.
Re: Many hard LeetCode problems are easy constraint problems
#435Earlier quoted context omitted.
> 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.
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.
Re: Many hard LeetCode problems are easy constraint problems
#436Earlier 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…
That makes the assumption that company hiring practices are evidence based.
How many companies continue to use pseudo-science Myers Briggs style tests?
Re: Many hard LeetCode problems are easy constraint problems
#437That's why in so many industries they prefer to hire engineers and OR grads and teach them python, than hire SWE and teach them modeling
Re: Many hard LeetCode problems are easy constraint problems
#438Earlier quoted context omitted.
Does it work though? When I look at the messy Android code, Fuchsia's commercial failure, Dart being almost killed by politics, Go's marvellous design, WinUI/UWP catastrophical failure, how C++/CX got replaced with C++/WinRT, ongoing issues with macOS Tahoe,.... I am glad that apparently I am not good enough for such projects.
zero of those failures are of a technical nature. The fact is that they fail is not evidence that leetcode interviews fails to select for high quality engineers.
Re: Many hard LeetCode problems are easy constraint problems
#439Earlier 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…
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.
Re: Many hard LeetCode problems are easy constraint problems
#440Earlier quoted context omitted.
100%. I just went through an interview process where I absolutely killed the assignment (had the best one they'd seen), had positive signal/feedback from multiple engineers, CEO liked me a lot etc, only to get sunk by a CTO who thought it would be cool to give me a surprise live test because of "vibe coding paranoia". 11 weeks in the process, didn't get the role. Beyond fucking stupid. This was the demo/take-home (fo…
That is an insane amount of work for a job application. Were you compensated for it at all?
Doing it slowly over many days is only taking your time and probably wont get you the job anyway since the solution will be a hard to read mess compared to someone who solves it quickly since they are familiar with the domain.