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

381–390 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#381

Post by ninja3925 »

bradlys wrote: post #121
koakuma-chan wrote: post #69

Earlier quoted context omitted.

I haven't been asked leetcode questions in a while and when I was asked, it was an easy level problem. I don't know where they ask hard leetcode problems, I also never solved a hard leetcode problem on my own.

I'm routinely asked LC Hard questions in interviews. Sometimes more than one in one 45 minute interview. That said, I interview in silicon valley and I'm a mixed race American. (extremely rare here) I think a lot of people just don't want me to pass the interview and will put up the highest bar they can. Mind you, I often still give optimal solutions to everything within good time constraints. But I've practiced 1000…

This is not how it works. The interviewer knows 1-2 problems and there is no time for profiling since they are rushing through their day, probably focused on their day to day work. You are the least of their concern, believe me.

Source: we am a hiring manager.

Re: Many hard LeetCode problems are easy constraint problems

#383

Post by RagnarD »

samiv wrote: post #167
tracker1 wrote: post #77

My biggest problem with leetcode type questions is that you can't ask clarifying questions. My mind just doesn't work like most do, and leetcode to some extent seems to rely on people memorizing leetcode type answers. On a few, there's enough context that I can relate real understanding of the problem to, such as the coin example in the article... for others I've seen there's not enough there for me to "get" the ques…

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…

"SMEGMA companies." :D

Re: Many hard LeetCode problems are easy constraint problems

#384

Post by camdenreslink »

MarcelOlsz wrote: post #215
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…

There's an entire planet of jobs that have nothing to do with leetcode. I was talking about those, not FAANG stuff. Unfortunately I am not FAANG royalty. >Of course some still do, like Anthropic were you have to have a perfect score to 4 leetcode questions, automatically judged with no human contact, the worst kind of interview. Should be illegal honestly.

5 years ago non-FAANG companies were fully in leetcode mode for interviews. Maybe 10-15 years ago you could totally avoid it without much problem.

Re: Many hard LeetCode problems are easy constraint problems

#385

Post by catlifeonmars »

didibus wrote: post #319
grugagag wrote: post #293

Earlier 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.

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

#386

Post by Eridrus »

kccqzy wrote: post #5

Great insight. But this is sadly not applicable to interviews. > It's easy to do in O(n^2) time, or if you are clever, you can do it in O(n). Or you could be not clever at all and just write it as a constraint problem This nails it. The point of these problems is to test your cleverness. That's it. Presenting a not-clever solution of using constraint solvers shows that you have experience and your breadth of knowledg…

Constraint solvers are also often not applicable to the real world either.

Many formulations scale in a way that is completely unusable in practice.

Knowing how to get tools like Z3 or Gurobi to solve your problems is it's own skill and one that some companies will hire for, but it's not a general purpose technology you can throw at everything.

This post is the unironic version of "FizzBuzz in TendorFlow", where just because you have a big hammer doesn't mean everything is a nail. And I say that as an enjoyer of bug hammers including SMT solvers.

Re: Many hard LeetCode problems are easy constraint problems

#387

Post by pedrosorio »

MarcelOlsz wrote: post #180
samiv wrote: post #174

Earlier quoted context omitted.

Wait, what.. you did this as a take home for a position? Damn that looks excessive.

Yes. I put a ton of work into it. I had about 60 pages worth of notes. On inverse kinematics, FABRIK, cyclic algorithms used in robotics, A*/RRT for real-world scenarios etc. I was super prepared. Talked to the CEO for about two hours. Took notes on all videos I can find of team members on youtube and their company. Luckily the hiring manager called me back and levelled with me, nobody kept him in the loop and he fel…

> Here's the live assignment requirements: [1] https://i.imgur.com/aaiy7QR.png & [2] https://i.imgur.com/aaiy7QR.png.

These are the same link

Re: Many hard LeetCode problems are easy constraint problems

#388

Post by ec109685 »

gnfargbl wrote: post #66
holden_nelson wrote: post #3

I feel like if I'm being asked this in an interview, they're not asking me to use a constraint solver, they're asking me to _write_ a constraint solver. Just for a specific constraint problem, not a more general constraint solver.

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…

Depends on your experience and what you’re interviewing for. At a high enough level, the questions are pulled from the easier side, and the interviewer doesn’t want you to fail.

Re: Many hard LeetCode problems are easy constraint problems

#389

Post by Eridrus »

bluGill wrote: post #73
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…

Interviews should not be about cleverness. They should test that you can code. I almost never write an algorithm because all the important algorithms are in my standard library already. Sure back in school I did implement a red-black tree - I don't remember if it worked, but I implemented it: I can do that again if you need me to, but it will take me several days to get all the details right (most of it looking up ho…

These tests are programming tests, but also effectively IQ and conscientiousness tests in the same way that most of what people learn in college is pointless, but graduating with a 4.0 GPA is still a strong signal.

I will say, IME, it's pretty obvious when people have seen a problem before, and unless you work at a big company that has a small question pool, most people are not regurgitating answers to these questions but actually grappling with them in realtime. I say this as someone who has been on both ends of this, these problems are all solvable de novo in an hour by a reasonable set of people.

Leetcode ability isn't everything, but I have generally found a strong correlation between Leetcode and the coding aspects of on the job performance. It doesn't test everything, but nothing in my experience of hiring has led me to wanting to lower the bar here as much as raise the bar on all other factors that influence job performance.

Re: Many hard LeetCode problems are easy constraint problems

#390

Post by Eridrus »

kragen wrote: post #284
bluGill wrote: post #80

Earlier quoted context omitted.

If somebody writes the optimal algorithm that should be a negative unless their resume indicates they are writing that algorithm often. The only reason you should know any algorithm well enough to get it right is if your job is implementing the optimal version for every single language. Of course nobody maintains one algorithm in many different languages/libraries (say libc++, python, rust, ada, java - each has diffe…

What if we just really enjoy clever algorithms? I've probably implemented first-order Markov-chain text generation more than a dozen times in different languages, and earlier this week I implemented Newton–Cotes adaptive quadrature just because it sounded awesome (although I missed a standard trick because I didn't know about Richardson extrapolation). I've also recently implemented the Fast Hadamard Transform, roman…

It's usually fairly obvious when people have just seen the solution before.

But also, interviews are fuzzy and not at all objective, false negatives happen as well as false positives.

If you want people to know about these things you should put them in your resume though. People can't read your mind.

Post reply on HN