Hacker News Reader

Comment by pianoben | Hacker News Reader

Personally I suck at leetcode questions, but nevertheless have snuck in to some of these so-called "top-tier" companies. And let me tell you!

These questions have fuck-all to do with the actual work the happens there. Sure, you can usually find someone to tell you how much rainwater accumulates into a random bar chart, but I see as much brain-dead code at the top as anywhere else. As much great code, too, FWIW. Everywhere, the key skills that make for a successful IC are the same, and they definitely don't require implementing splay trees or skip lists from scratch and without references. 99% of the time it's shuffling bits around and using hash maps.

Honestly the people I work with who advocate the hardest for leetcode are the ones who had to grind hard and, evidently, want others to suffer too. As if a sane process would mean their own suffering was in vain.

View on HN

I am not sure that's the whole picture. I don't care about leetcode type problems but if I was applying for a job where they were a barrier to entry, I'd go figure out what it takes to master them.

The bar may simply be "sober enough to understand what it takes to succeed at this task", "committed enough to prepare" and "smart enough to solve them"

These attributes correlate strongly with success, I'd imagine.

I disagree with this point because most interviewers and interviewees are novices, and giving them a task that gives straight pass/fail feedback optimizes for the wrong solution for people that can solve puzzles but not think about systems well. I've had many candidates be able to zip through puzzles but when asked relevant questions about building an understanding systems they wash out immediately. Most systems are more than one code file and I don't need to waste my hiring expenses teaching them how to think about systems from near scratch and having to heavy hand review them to write good code. I have generally found the only leetcode grind types to be less self sufficient and not really a signifier to success. In my experience the leetcode grind type can't even expand on their own answers to answer any useful questions like 'where and why would you use what you just made' and 'what technologies have you used that might utilize this technique' ends up with crickets. Right now my interview has a wash out coding exercise that is beginner oriented to get the resume liars but other than that it's all systems.

> I disagree with this point because most interviewers ... are novices

Having sat on hiring committees, that's a fair summary. Most people are not very good at interviewing, because it's a weird skill, and nobody actually teaches you how to do it well. There's interview training, but it's incredibly short, and seems like half of it is about legal policy. There's ostensibly shadow interviews, but that tends to be luck of the draw on who your shadower is; most won't put in the requisite time to help coach you in conducting better interviews.

I think big companies like to pretend that leetcode interviewing scales well, without actually doing the time necessary to make it scale well.

> Right now my interview has a wash out coding exercise that is beginner oriented to get the resume liars but other than that it's all systems.

This is 100% what I've gravitated to. The longer I've interviewed people, the easier and easier the actual coding parts of my questions have become.

That may be so, but part of my gripe with leetcode is that people tend to grind for many months to "get in shape" for job interviews. That's just not reasonable to expect of anyone, let alone those with families or other responsibilities.

It's not like there aren't benefits to this process. Once you've buffed up, you're prepared for most major tech interviews. Common formats have their advantages.

That said, this format is just too expensive, and has poor predictive power.

// "get in shape" for job interviews. That's just not reasonable to expect of anyone, let alone those with families or other responsibilities.

and

// Once you've buffed up, you're prepared for most major tech interviews.

and

// has poor predictive power.

If "acquiring skill X" is broadly valuable (as you're saying in this case) then your ability to work on acquiring it is predictive of your success.

Sure, it shows that you can apply yourself to a task and finish it. That's also what a college degree shows, but at least there you learn something useful. Come to think of it, that's what any stint over a year or two at a company can show, too.

It's not predictive of the traits that mark a successful IC in my experience. I'm talking about areas like project planning, professionalism, large-scale system design, personal ownership, meticulousness, etc. Curiosity. Some of those might tangentially be covered by leetcode but I guarantee you important stuff isn't.

Everyone I've seen to fail, either via PIP or otherwise, has cracked these interviews. I've seen many fail over the years. Even worse, I've seen many whom I know would be strong performers, wash out because they got the wrong DP problem that day. Where's the benefit in a regime like this? The company loses and good candidates lose, too.

Reply on news.ycombinator.com