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

441–450 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#441

Post by tdeck »

aDyslecticCrow wrote: post #134
nice_byte wrote: post #81

Earlier quoted context omitted.

[flagged]

Use the right tool for the job. Thats engineering. Instead you insist we should solve a nieche problem with a ill suited tool, while inventing a costume solution when a standard solution exist.

This kind of tradeoff discussion is good to explicitly call out in an interview. I often say things like "if this were my own project I'd use X, but on a team I would probably try to find a library in a language the team already uses".

Bringing the team up on Prolog and integrating it into your CI/CD system and finding some way to connect it with other services is often going to be a poor choice, even if in isolation it's the very best tool for the job. And that's the best case solution - more likely the tests will be limited and not automated, the code review will be rubber stamp because only the author knows the language, and the code and deploy process will be a black box that everyone is afraid to touch once the author moves on.

Obviously in an interview none of the code should make it into production, but being openly pragmatic is still a good idea. And if you use an obscure language, you'd better have better than usual communication skills to concisely explain how the code works for someone who hasn't used that language before. I've seen it done well but it's difficult.

Re: Many hard LeetCode problems are easy constraint problems

#442

Post by Jensson »

baq wrote: post #256
m000 wrote: post #250

Earlier quoted context omitted.

I think LC is used mostly as a metric of how much tolerance you have for BS and unpaid work: If you are willing to put unpaid time to prepare for something with realistically zero relevance with the day-to-day duties of the position, then you are ripe enough to be squeezed out.

It selects for age and childlessness.

And experience selects for age as well, doesn't make it a bad signal.

Re: Many hard LeetCode problems are easy constraint problems

#443

Post by Tade0 »

deepsun wrote: post #419

As an interviewer, I gave one pretty simple task (people solved it in as little as 8 minutes), wasn't using any real CS, even though I'm good at it. The reason was that aboint 70% of candidates couldn't write a simple loop -- to filter those out. The actual solution didn't matter much, I gave a binary decision. The actual conversation matters more.

This. Main point of giving candidates CS problems was always to weed out those who couldn't program at all, but somehow were still in the industry. I worked with such people - it's unpleasant.

Somehow someone figured that giving harder problems should result in better candidates. Personally, despite having passed most of the tests I've been subjected to, I don't see the connection.

Re: Many hard LeetCode problems are easy constraint problems

#445

Post by Jensson »

tavavex wrote: post #201
bluGill wrote: post #175

Earlier quoted context omitted.

That is what people miss about interviews. Often when you interview you don't have reasonable leads on any other job and so you don't feel like there is a choice since you likely need a job (unemployment rarely pays as well as a job). However interviews are not only about the company deciding if they will hire you, they are also about do you want to work there and convincing you to take the job if one is offered. So…

People don't miss that about interviews, they just know that the balance of power is so skewed that the interests of the employer become the only relevant part. The employer can keep going through hundreds of applicants until they find someone who's literally perfect in every single way, they have nearly unlimited time. Meanwhile, the applicants need a job now, any job at all, they're on a hard time limit until their…

> they just know that the balance of power is so skewed that the interests of the employer become the only relevant part

That happens since people only apply to very well paying jobs. If you apply to shit enough jobs they wont be asking hard questions, and those who offer shit jobs will say "all the power lies with the employees, I have no power to make them stay or apply, I am social and nice to them and they still reject my job offer!".

Just give the companies what they want and they all will want you, it is that easy. If you try to give them something they don't care about, like a hiring manager giving you a smile and minimum wage, of course you will get rejected a lot. Give them what they ask for, not what you think they should want.

Re: Many hard LeetCode problems are easy constraint problems

#446

Post by Jensson »

renewiltord wrote: post #290
IshKebab wrote: post #279

Earlier quoted context omitted.

I interviewed at an investment bank in London and they asked me pretty hard questions. One was to implement some multithreaded producer consumer thing in C++. I can't remember the details but it was... well you know how writing multithreaded C++ is. I was allowed to look up references at least. Took me maybe 20 minutes and the whole time the interviewer was just sitting on his phone while I wrote it. Weird experience…

If you wrote an MPSC queue (standard question) with multithreaded demo in 20 minutes in C++ you’re pretty hot shit, mate. Their loss. It’s not that it’s hard. But that speed without error is just really good. C++ is particularly unforgiving too.

He didn't get the job so changes are it wasn't correct.

Re: Many hard LeetCode problems are easy constraint problems

#447

Post by awesome_dude »

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.

> Or problems similar to the problems of the organization hiring?

People complain, rightly so in some cases, that their "interview" is really doing some (unpaid) work for the company

Re: Many hard LeetCode problems are easy constraint problems

#449

Post by zelphirkalt »

3vidence wrote: post #59
viccis wrote: post #45

Earlier quoted context omitted.

>The point of these problems is to test your cleverness. In my experience, interviewers love going to the Leetcode "Top Interview 150" list and using problems in the "Array String" category. I'm not a fan of these problems for the kind of jobs I've interviewed for (backend Python mostly), as they are almost always a "give me a O(n) runtime O(1) memory algorithm over this array" type challenge that really doesn't rese…

Honestly in day to day programming I find data types & associated APIs are so so much more important than algorithms. I would rather work with a flexible data type with suboptimal performance than a brittle data type that maybe squeezes out some extra performance. Your example of in-place array mutation feels like a good example of such a thing. I feel like there should be a category of interviewing questions for "co…

I would rather work with persistent data structures, the least brittle of all, which would also in many cases trivially allow me to parallelize the work, but as far as I can see all the leetcode problems are low level mutation based problems with no clue about functional data structures. Clueless interviewers look to these problems as if they alone epitomized great programming, while they are often inflexible single core stuff, that may not even be appropriate for this day and age any longer.

Re: Many hard LeetCode problems are easy constraint problems

#450

Post by zelphirkalt »

mcmoor wrote: post #405
btilly wrote: post #78

Earlier quoted context omitted.

Bottom up dynamic programming algorithms require some cleverness. All of the ones listed can be solved with a top down dynamic programing algorithm. Which just means "write recursive solution, add caching to memoize it". For some of these, you can get cleverer. For example the coin change problem is better solved with an A* search. Still, very few programmers will actually need these algorithms. The top thing we need…

For the love of me I still can't consistently solve dynamic programming problems. Because "write a clever brute force solution that can be cached" is so broad that there are tons of variations out there, and a slight twist can bring you out of the loop fast.

Project Euler 18. I tried 3 heuristic approaches, before accepting, that to get the real answer without brute forcing it (because it comes back later in non-brute forcable version anyway), I need to find another way. I came up with an optimal solution, but it is still not dynamic programming, which I would also consider inferior to the bottom up solution I have found.
Post reply on HN