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

281–290 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#281

Post by IshKebab »

shmerl wrote: post #252
gnfargbl wrote: post #66

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

More exactly, you can't invent algorithms on a spot which took who knows how many years for others to invent. I.e. the question ends up being more if you know about a specific algorithm, which results in "invent it if you don't know about it". It's absolutely silly to test for ability to invent one on the spot, so it's a pretty pointless interview question really.

You can for simple algorithms. It's just really easy for interviewers to overestimate how simple an algorithm is when they have been told the answer.

Re: Many hard LeetCode problems are easy constraint problems

#282

Post by graynk »

Der_Einzige wrote: post #148
CamperBob2 wrote: post #104

Earlier quoted context omitted.

That's an en-dash, not an em-dash

"It's not X, It's Y"

I don't think someone with an account from 2012 and 20k karma would be posting LLM-generated comments. It also doesn't read as one. It doesn't even use the "it's not x it's y" formula, it contraposes things against each other. Like I just did.

Re: Many hard LeetCode problems are easy constraint problems

#283

Post by shmerl »

IshKebab wrote: post #281
shmerl wrote: post #252

Earlier quoted context omitted.

More exactly, you can't invent algorithms on a spot which took who knows how many years for others to invent. I.e. the question ends up being more if you know about a specific algorithm, which results in "invent it if you don't know about it". It's absolutely silly to test for ability to invent one on the spot, so it's a pretty pointless interview question really.

You can for simple algorithms. It's just really easy for interviewers to overestimate how simple an algorithm is when they have been told the answer.

Yeah, that's exactly the point. These kind of algorithms are far from easy to invent even if they look simple once they are known.

Re: Many hard LeetCode problems are easy constraint problems

#284

Post by kragen »

bluGill wrote: post #80
mjr00 wrote: post #40

Earlier quoted context omitted.

> the point is to understand how the candidate thinks, communicates, and decomposes problems. 100% and it's a shame that over time this has become completely lost knowledge, on both sides of the interview table, and "leetcode" is now seen as an arbitrary rote memorization hurdle/hazing ritual that software engineers have to pass to enter a lucrative FAANG career. Interviewees grind problems until they've memorized ev…

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 numerals, Wellons–NRK hash tries, a few different variants of Quicksort (which I was super excited to get down to 17 ARM instructions for the integer case), an arena allocator with an inlined fast path, etc. Recently I wrote a dumb constrained-search optimizer to see if I could get a simpler expression of a word-wrap problem. I learned about the range-minimum-query algorithm during a job interview many years ago and ad-libbed a logarithmic-time solution, and since then I've found a lot of fascinating variants on the problem.

I've never had a job doing this kind of thing, and I don't expect to get one, just like I don't expect to get a job playing go, rendering fractals, reading science fiction, or playing video games. But I think there's a certain amount of transferable skill there. Even if what I need to do this week is figure out how to configure Apache to reverse proxy to the MediaWiki Docker container.

(I know there are people who have jobs hacking out clever algorithms on different platforms. I even know some of them personally. But there are also people who play video games for a living.)

I guess I'd fail your interview process?

Re: Many hard LeetCode problems are easy constraint problems

#285

Post by henry2023 »

RomanPushkin wrote: post #162

- Constraint solvers? That's a nice concept, I heard about this once. However, for the purposes of the interview, let's just write some Python code, I wanna see your way of thinking... (I think it's almost impossible to convince your interviewer into constraint solvers, while the concept itself is great)

Have you ever tried or this is your assumption of what the interviewer would say.

Re: Many hard LeetCode problems are easy constraint problems

#286

Post by cerved »

MiniZinc is a really great modeling language for constraint programming. Back in August I gave a talk at NordConstNet25 on how we used it to build a product configurator in what's (probably) the worlds largest MiniZinc model

https://pierre-flener.github.io/research/NordConsNet/NordCon...

Re: Many hard LeetCode problems are easy constraint problems

#288

Post by cerved »

atilimcetin wrote: post #74

Whenever constraint programming languages come up, you can’t miss mentioning Håkan Kjellerstrand. He’s put together an amazing collection of problems and examples—including plenty for MiniZinc—on his site: https://www.hakank.org/minizinc/

Not only has he made a great website, he's also a super nice guy

Re: Many hard LeetCode problems are easy constraint problems

#289

Post by gotts »

silisili wrote: post #108
another_twist wrote: post #98

Earlier quoted context omitted.

Its not really memorizing solutions. Yes you can get quite far by doing so but follow ups will trip people up. However if you have memorized it and can answer follow ups, I dont see a problem with Leetcode style problems. Problem solving is about pattern matching and the more patterns you know and can match against, the better your ability to solve problems. Its a learnable skill and better to pick it up now. Persona…

It is and isn't. I'd argue it's not memorizing exact solutions(think copy paste) but memorizing fastest algos to accomplish X. And some people might say well, you should know that anyways. The problem for me is, and I'm not speaking for every company of course, you never really use a lot of this stuff in most run of the mill jobs. So of course you forget it, then have to study again pre interview. Problem solving is…

> you never really use a lot of this stuff in most run of the mill jobs. So of course you forget it, then have to study again pre interview.

I'm wondering how software devs explain this to themselves. What they train for vs what they actually do at their jobs differ more and more with time. And this constant cycle of forgetting and re-learning sounds like a nightmare. Perhaps people burn out not because of their jobs but the system they ended up in.

Re: Many hard LeetCode problems are easy constraint problems

#290

Post by renewiltord »

IshKebab wrote: post #279
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 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.
Post reply on HN