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

331–340 of 551 posts

Re: Many hard LeetCode problems are easy constraint problems

#331

Post by JonChesterfield »

erikerikson wrote: post #42
jkubicek wrote: post #39

Earlier quoted context omitted.

In defense of questions like this, “willingness to prepare” is a significant differentiator

But what is it differentiating? And is it really the best evidence of willingness to prepare? My MSc and BA on the topics, my open source contributions, two decades of industry experience... Those aren't evidence of not only willingness but execution of preparation?

The papers and open source indicate that you can build stuff. That's not what it's testing for.

Will you put up with very long hours of insane grindy nonsense in the spirit of being a team player for a team that doesn't really remember what game they're playing?

Are you sufficiently in need of income to be fighting through this interview dance in preference to other things, such that once you join you'll be desperate to stay?

Those are extremely important questions, and a willingness to have spent a thousand hours memorising leetcode correlates strongly with the attributes sought.

Re: Many hard LeetCode problems are easy constraint problems

#332

Post by SJC_Hacker »

another_twist wrote: post #106
lawlessone wrote: post #96

Earlier quoted context omitted.

The one's i've gotten have all seemed more like tests of my puzzle solving skills than coding. The worst ones i've had though had extra problems though: one i was only told about when i joined the interview and that they would be watching live. One where they wanted me streaming my face the whole time (maybe some people people are fine with that) And one that would count it against me if i tabbed to another page. So…

You can make up API calls which you can say you'd implement later. As long as these are not tricky blocks, you'll be fine.

For Google, Facebook and Amazon, yes. At least last I interviewed there a few years ago. They're more interested in the data structure/algorithm

But I have also been to places that demand actual working code which is compiled and is tested against cases

Usually there the problem is simpler, so there's that

Re: Many hard LeetCode problems are easy constraint problems

#333

Post by giveita »

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…

Where I interviewed you had effectively 1 or 2 LC question but the interviewer offered clarifying questions making for a real time discussion and coding exercise.

This solves one problem but it does add performance anxiety to the mix having to live code.

Re: Many hard LeetCode problems are easy constraint problems

#334

Post by giveita »

another_twist wrote: post #98
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…

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…

Few people are in both circles of "can memorize answers" and "dont understand what they are doing".

You would need "photographic" memory

Re: Many hard LeetCode problems are easy constraint problems

#335

Post by epolanski »

dmoy wrote: post #177
epolanski wrote: post #153

Earlier quoted context omitted.

Many interviews now involve automated exercises on websites that track your activity (don't think about triggering a focus change event on your browser, it gets reported). Also, the reviewer gets an AI report telling it whether you copied the solution somewhere (expressed as a % probability). You have few minutes and you're on your own. If you pass that abomination, maybe, you have in person ones. It's ridiculous wha…

The major difference between software devs and lawyers, surgeons, and civil engineers is that the latter three have fairly rigorous standards to pass to become a professional (bar, boards, and PE). That could exist for software too, but I'm not sure HN folks would like that alternative any better. Like if you thought memorizing leetcode questions for 2 weeks before an interview was bad, well I have some bad news. May…

You ain't interviewing your plumber or accountant come on and I have millions of other examples.

Re: Many hard LeetCode problems are easy constraint problems

#336

Post by ninkendo »

binarymax wrote: post #63

A loonnngggg time ago when I was green, and wasn't taught about constraint solving in my State University compsci program, I encountered the problem when trying to help a friend with his idea. He wanted to make an app to help sports club owners schedule players for the day based on a couple simple rules. I thought this was going to be easy, and failed after not realizing what I was up against. At the time I didn't ev…

> I thought this was going to be easy, and failed after not realizing what I was up against. At the time I didn't even know what I didn't know

This reminds me of high school ~25 years ago when I just started learning TI-Basic on my calculator and was dabbling in VB6 on my PC, and I was flipping burgers at Steak n Shake as my part time job. The manager moaned about how hard it was to write the employee schedules out each week (taking into account requested days off, etc) and I thought “ooh, I know how to write software now, I’ll make a scheduling program!” I told the manager I bet I could do it.

… it took a very short time for 16 year old me to realize writing scheduling software to solve for various constraints is pretty damned hard. I never brought it up after that.

Re: Many hard LeetCode problems are easy constraint problems

#338

Post by Freedom2 »

roncesvalles wrote: post #264
samiv wrote: post #167

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

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

This is an appeal to tradition and a form of survivorship bias. Many successful companies have ditched LeetCode and have found other ways to effectively hire.

> If you can show that you can become excellent at one thing, there's a good chance you can become excellent at another thing.

My company uses LeetCode. All I want is sane interfaces and good documentation. It is far more likely to get something clever, broken and poorly documented than something "excellent", so something is missing for this correlation.

Re: Many hard LeetCode problems are easy constraint problems

#339

Post by BhavdeepSethi »

henry2023 wrote: post #280
BhavdeepSethi wrote: post #267

It's insane how many of these new "AI" companies don't let you use AI or even your own IDE for coding interviews. And most questions from such companies are LC type problems so they know any AI tool can one shot it.

I discourage it but I let them use it and then give them a specific problem that I know your average Claude 4 or GPT 5 will just not get it right. Actually people perform worse in an interview using AI because they spend time trying to understand what the tool is proposing and then time to figure out why that doesn’t work.

My experience has been quite different. With Cursor/Claude code, I've ended up writing full fledge solutions (running cli/web servers with loggers and unit tests for each functionality). We're talking crawlers, cab booking service like uber, search engines with seed data. All within the hour.

Re: Many hard LeetCode problems are easy constraint problems

#340

Post by spike021 »

MarcelOlsz wrote: post #185
samiv wrote: post #167

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

5 years ago you'd have a project like that, talk to someone at a company for like 30m-1hr about it, and then get an offer.

Not sure if that's a typo. 5 years ago was also pretty LC-heavy.

Ten years ago it was more based on Cracking the Coding Interview.

So i'd guess what you're referring to is even older than that.

Post reply on HN