Live data from Hacker News

A guide to learning algorithms through LeetCode

github.com

131–140 of 222 posts

Re: A guide to learning algorithms through LeetCode

#131

Earlier quoted context omitted.

But it might come handy when implementing - route optimization problems - Building database query optimization engine You can argue that not everyone is implementing these from scratch every day. But it could be argued that given an opportunity, an engineer should have the skills and ability to build these systems.

> But it could be argued that given an opportunity, an engineer should have the skills and ability to build these systems. Having the skills and ability to build these systems doesn't mean you can regurgitate all the algorithms required to build them on a whiteboard in 30-60 minutes. It means you have to ability to search for algorithms and apply them to your problem at hand over the course of several days, weeks, or…

Isn't it what computer science is all about. You won't necessarily see the exact problem. But having the ability to reduce the problem at hand to an efficient algorithm that you might have "regurgitated".

Re: A guide to learning algorithms through LeetCode

#132

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.

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

That's not the point, though. No one said that Leetcode is mandatory for being a good programmer.

The point is that Leetcode, however imperfect, is still a usable signal for programming ability.

Those excellent programmers you know would likely not have much difficulty with Leetcode style problems if they were to try them. That's the point.

Re: A guide to learning algorithms through LeetCode

#134
post #93

Earlier quoted context omitted.

Interviews are only partially about testing your body of experience. They're also supposed to test your aptitude and ability to grow in the future. If you were capable of studying Leetcode so hard that you mastered the interview process at one of the most selective software companies in the world in only a few months, it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability…

Err, but why do you have to prove it for every next job?... In reality, it's a legal way for: 1. Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps. 2. Making switching jobs harder - for every next job one has to prepare again, because nobody is using Competitive Programming stuff during real work, so you forget. Keep in mind that CP != CS. And CP is not everyone's cu…

> why do you have to prove it for every next job

Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer.

> Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps.

In my experience, senior developers don't need anywhere near as much prep as junior developers for these interviews. Leetcode problems are difficult when you're a new college grad with zero years of programming experience. They're significantly easier after you've been programming for 10 years.

> Making switching jobs harder - for every next job one has to prepare again

Companies aren't going out of their way to make it harder to hire good employees into their own companies.

Leetcode isn't an industry-wide conspiracy. Companies are using it because they believe it's a good filtering mechanism for candidates. When the Big N companies have higher rejection rates than Ivy League universities, they can afford to be selective.

> Keep in mind that CP != CS.

The problems are designed to test CS skills.

How else would you suggest reorganizing the interviews to test for CS skills?

Re: A guide to learning algorithms through LeetCode

#135
post #97

Earlier quoted context omitted.

My experience of FAANG interviews outside the US is that the salaries they offer are really disappointing compared to the US. Other industries like finance were a better deal compared those companies. If I can get paid £90-110k in the City why bother working for Facebook were they were offering less than £90k? Note, I don't consider bonuses or equity to part of salary.

Why would equity or bonuses not be part of the salary ? You are almost certain to receive it and the stocks perform quite well on average. They still pay better than finance all things taken together or am I wrong ?

Bonus is not guaranteed so why take that into account?

Stock maybe but you can't pay the bills with that or get a mortgage even can make it more difficult.

Re: A guide to learning algorithms through LeetCode

#136
post #93

Earlier quoted context omitted.

Err, but why do you have to prove it for every next job?... In reality, it's a legal way for: 1. Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps. 2. Making switching jobs harder - for every next job one has to prepare again, because nobody is using Competitive Programming stuff during real work, so you forget. Keep in mind that CP != CS. And CP is not everyone's cu…

#2 doesn't make sense, though: If I'm company B, trying to poach from company A, it would be in my best interest to make the leap to applying/interviewing less difficult, not more for employee's of company A. Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent

> Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent

They have been caught doing so in the past. [0]

[0]: https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...

Re: A guide to learning algorithms through LeetCode

#137
post #93

Earlier quoted context omitted.

Err, but why do you have to prove it for every next job?... In reality, it's a legal way for: 1. Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps. 2. Making switching jobs harder - for every next job one has to prepare again, because nobody is using Competitive Programming stuff during real work, so you forget. Keep in mind that CP != CS. And CP is not everyone's cu…

#2 doesn't make sense, though: If I'm company B, trying to poach from company A, it would be in my best interest to make the leap to applying/interviewing less difficult, not more for employee's of company A. Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent

> Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent

This is a proven reality, and has been out in the open for a long time.

Re: A guide to learning algorithms through LeetCode

#138
post #93

Earlier quoted context omitted.

Err, but why do you have to prove it for every next job?... In reality, it's a legal way for: 1. Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps. 2. Making switching jobs harder - for every next job one has to prepare again, because nobody is using Competitive Programming stuff during real work, so you forget. Keep in mind that CP != CS. And CP is not everyone's cu…

> why do you have to prove it for every next job Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer. > Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps. In my experience, senior developers don't need anywhere near as much prep as junior developers for these interviews. Leetcode problems are difficult when you're a…

I've been programming for 10 years and I'm pretty good at it, at every job I've had I get lots of praise and recognition and accelerated promotions. But I have a hard time with leetcode problems and have failed several interviews because of them. It's not that I can't learn the leetcode tricks, it's that I don't have the motivation or the time to drill for months on them so that I can retain all the tricks.

I don't have a CS degree so I think that might be the difference, I didn't get to spend four years thinking about algorithms and data structures. Leetcode interviews are a form of gatekeeping that CS degree people use to filter out non-CS people.

Re: A guide to learning algorithms through LeetCode

#139
post #135

Earlier quoted context omitted.

Why would equity or bonuses not be part of the salary ? You are almost certain to receive it and the stocks perform quite well on average. They still pay better than finance all things taken together or am I wrong ?

Bonus is not guaranteed so why take that into account? Stock maybe but you can't pay the bills with that or get a mortgage even can make it more difficult.

You sell the stock when it vests and pay your bills ?

Re: A guide to learning algorithms through LeetCode

#140

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

>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

I'm very interested in this claim. Every interviewing-is-broken thread, someone mentions that pairing, or take-home exercises, or work samples, or their favorite method, are better predictors than algorithm problems. On the one hand I doubt any but the biggest companies could conduct studies on this; on the other hand individuals at smaller companies might honestly remember only those times their hires filtered through this method were successful, due to confirmation bias. So it seems like an inherently difficult thing to study.

Whereas, algorithm questions lend themselves easily to a "rubric" and seeing, 1 or 2 years later, if higher "grades" corresponded to better job performance.

Post reply on HN