Live data from Hacker News

A guide to learning algorithms through LeetCode

github.com

121–130 of 222 posts

Re: A guide to learning algorithms through LeetCode

#121

It's becoming obvious to me that my time is better spent learning to solve these riddles rather than actually becoming a better developer. I have a job search coming up at the end of the year and whilst I've managed to largely avoid companies that ask this type of question, I believe it's seriously constraining my career. I can't speak for everyone but the whiteboard interview has prevented me from leaving jobs earli…

One of the big unspoken reasons these questions stick around: they cause little imposter syndrome anxiety for the senior engineers who need to conduct the interview. You ask a candidate to code a toy problem, and the candidate either knows the "trick" to solving it quickly or they don't -- very little risk for you as the interviewer, you're just watching things play out.

But if your interview requires you to pair program on real code like you'll do in your actual job, it opens up a lot of room to look dumb in front of an interviewee. You have to handle bugs on the fly. You have to look up (for the 5000th time in your career) whether you should be using Array.slice or Array.splice in this case. You go back and look at a similar implementation in your code base for a template instead of coding from memory.

And that's a shame because the live coding exercise is both a better predictor of hands-on job success and it's a better recruiting tactic: you've just had a vulnerable, collaborative experience with someone who will actually be working with you on a regular basis and you get a sense of whether you'd actually like to work there. But we keep doing these algorithms exercises because they require such little effort or interaction from engineers who are doing this interview in between two meetings with no prep time.

Re: A guide to learning algorithms through LeetCode

#122

Earlier quoted context omitted.

I think that's what these leetcode type questions are good at. You're either naturally adept enough to do well, or internally motivated enough to memorize/learn them. Either way, it's a decent signal for a company that needs someone to learn their internal, proprietary techstack

> You're either naturally adept enough to do well, or ... I'm personally very wary of using algorithms questions as a proxy for how "adept" someone is at software engineering . If I were running a business, I'd personally want to make sure people could manage technical debt and build decoupled systems. I have had multiple positions at FAANG companies, and despite being "adept" according to these algorithms questions…

Why do you suppose these hires aren’t good at learning engineering best practices? I see comments like yours here all the time. Is it some kind of arrogance, perhaps amplified by a false signal sent by getting hired off leet code questions in the first place?

Re: A guide to learning algorithms through LeetCode

#123
post #102
post #85

Earlier quoted context omitted.

> All things considered, spending 50-100 hours of your free time solving problems on a free website at your leisure is really a small price to pay. The problem is - it's not 50-100 hours for most candidates to pass. I've done well past 400 hours of interview prep and never received an offer from Big N. I tried the consistent 1-hour or so a day for months thing - it isn't guaranteed either. Want to emphasize this poin…

I don't think it's just about solving the problem. It's also about: - how you convinced yourself and the interviewer that your solution was correct (essentially an informal proof of your code) - how you test your code after you finish coding - what clarifying questions you asked to tease out a concrete question - what edge cases you thought of and how you handled them - how you handle bugs if they appear in the code…

From talking to some people who give out these interviews, most of those points really don't matter at all. What matters is A) getting a correct solution and B) being able to explain how you arrived at the solution. Tests, idiomatic code, clean design, etc are not expected and will inevitably waste precious time. Besides, the very nature of the interview (using a walled-off in-browser pseudo-IDE) restricts you from actually writing best-practice code.

Re: A guide to learning algorithms through LeetCode

#124
post #28

Earlier quoted context omitted.

Firefox says, "Warning: Potential Security Risk Ahead" for that website.

Nice how browsers have trained people to be scared if there's not a lock. It's just an expired cert, not revoked, and you're not entering payment information.

There's a reason certs have a limited lifetime. People should be trained to avoid such websites.

Re: A guide to learning algorithms through LeetCode

#125

Earlier quoted context omitted.

The popular sentiment on computer science knowledge has done a complete 180 in the past several years. Not that long ago, it was popular to complain that junior SWEs didn't really understand the algorithms, the data structures, and what was going on behind the scenes. The complaint was that they were just copy and pasting from internet searches until things sort of worked on their machine, but they couldn't recognize…

> Personally, I've never met anyone who was good at Leetcode yet produced bad code in production. I'm sure there's someone out there who knows a guy who knows a guy who can somehow ace Leetcode but can't write an efficient website backend, but it's not the norm. Weird. Ability to leetcode doesn't mean you know what is happening in e.g. an RDBMS. We've had people good at leetcode write a single query to delete hundred…

You can learn how to use some function to call into a database and study its behaviour, if you can grind leetcode and solve problems.

It's a good enough filter, the alternative is either way more costly or way worse(if you have seen "interviewing" which are just thinly veiled nepotism).

Re: A guide to learning algorithms through LeetCode

#126

Earlier quoted context omitted.

The popular sentiment on computer science knowledge has done a complete 180 in the past several years. Not that long ago, it was popular to complain that junior SWEs didn't really understand the algorithms, the data structures, and what was going on behind the scenes. The complaint was that they were just copy and pasting from internet searches until things sort of worked on their machine, but they couldn't recognize…

> Personally, I've never met anyone who was good at Leetcode yet produced bad code in production. It's all anecdotal evidence. I've worked with some brilliant people at most places I've been and I can't think of 1 person who even had LeetCode account. Producing great production code is more about experience and knowledge of the domain than knowing how to bang out algorithms.

[deleted]

Re: A guide to learning algorithms through LeetCode

#127

Earlier quoted context omitted.

I think that's what these leetcode type questions are good at. You're either naturally adept enough to do well, or internally motivated enough to memorize/learn them. Either way, it's a decent signal for a company that needs someone to learn their internal, proprietary techstack

> You're either naturally adept enough to do well, or ... I'm personally very wary of using algorithms questions as a proxy for how "adept" someone is at software engineering . If I were running a business, I'd personally want to make sure people could manage technical debt and build decoupled systems. I have had multiple positions at FAANG companies, and despite being "adept" according to these algorithms questions…

I have observed this problem and usually it’s not because the people are incapable but that the incentives are to ship things that move the needle to quickly get promoted. The financial rewards at these companies from promotions are huge.

Where the managers have incentivized quality and stability my team mates have moved mountains and I’ve seen some really good stuff but otherwise not.

Re: A guide to learning algorithms through LeetCode

#128
post #85

Earlier quoted context omitted.

> I can’t compete against people who essentially seem to have no life or other interests than getting job at Big N (or enjoy competitive programming). Interview prep doesn't need to be a grind. One of the nice things about Leetcode is that the problems are bite-sized. You can do one or two per day on your lunch break and make a lot of progress in a matter of months, or even weeks. Don't approach it like a cram sessio…

> All things considered, spending 50-100 hours of your free time solving problems on a free website at your leisure is really a small price to pay. The problem is - it's not 50-100 hours for most candidates to pass. I've done well past 400 hours of interview prep and never received an offer from Big N. I tried the consistent 1-hour or so a day for months thing - it isn't guaranteed either. Want to emphasize this poin…

No one is guaranteed a job at Big-N companies.

It's important to understand that Big-N job offers or rejections aren't a perfect indicator of a person's programming ability.

The interview process isn't perfect. It's not designed to be perfect, because that's an impossible goal. In reality, Big-N companies have so many applicants that some of them have higher rejection rates than Ivy League universities.

At this scale, the goal isn't to admit any and every qualified candidate. The goal is to select for the best of the best and minimize false positives, even if it results in a large number of false negatives.

Re: A guide to learning algorithms through LeetCode

#129
post #122

Earlier quoted context omitted.

> You're either naturally adept enough to do well, or ... I'm personally very wary of using algorithms questions as a proxy for how "adept" someone is at software engineering . If I were running a business, I'd personally want to make sure people could manage technical debt and build decoupled systems. I have had multiple positions at FAANG companies, and despite being "adept" according to these algorithms questions…

Why do you suppose these hires aren’t good at learning engineering best practices? I see comments like yours here all the time. Is it some kind of arrogance, perhaps amplified by a false signal sent by getting hired off leet code questions in the first place?

It’s false based on what I’ve seen. Plenty of people passionate about good engineering where I am. But they are sometimes trapped in a system which doesn’t always incentivize it.

Re: A guide to learning algorithms through LeetCode

#130

Earlier quoted context omitted.

> Where are the papers that correlate this niche, specialized skill to general job performance and productivity? I would love to read this research if it existed in the public domain. However, much of this comes down to trade secrets and business practices. It's also not very amenable to controlled studies. Practically speaking, these companies have a lot at stake in their hiring process. It's strange that so many pe…

On your last point, the best alternative I've seen is take-home projects where it would take less than a week to complete. The interviewer is free to frame a problem in a way that allows the engineer to apply their real-world experience and show their fit for the job. It removes all the variables around interview stress/anxiety and as a result is a better (but not perfect) indication of their performance.

> On your last point, the best alternative I've seen is take-home projects where it would take less than a week to complete.

Ironically, take-home interviews are another contentious topic on HN and other internet message boards. The common complaint is that people don't want to invest much of their personal time into interviewing for companies.

Post reply on HN