Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A guide to learning algorithms through LeetCode

github.com

Post reply on HN
Print view View original

141–150 of 222 posts

Re: A guide to learning algorithms through LeetCode

#141

Post by cstejerean »

bradlys wrote: post #85
PragmaticPulp wrote: post #63

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…

Statistically it’s bound to happen that some interviews don’t work out. Sometimes the problem just doesn’t click, or you have a bad day, or you get unlucky and 1 interviewer is being extra strict and unfair. I have both passed and failed interviews at most of the FAANG companies.

Some of my coworkers will usually apply at all the big companies at once and say pass 2-3 out of 5 interviews.

However if you consistently can’t get through an interview loop without an offer despite having studied the basics and repeated attempts there may be something wrong that you are not catching in your interview prep.

Shoot me an email if you’d like some feedback, would be happy to do a dry run and see if I can spot anything obvious. I’m at @cosmin on Github, you can find my email address there.

Re: A guide to learning algorithms through LeetCode

#142

Post by bosswipe »

PragmaticPulp wrote: post #65
logicslave12 wrote: post #32

Earlier quoted context omitted.

I was working on a “startup”/kinda just unemployed for two years. I studied leetcode hard, and got hired into a 300k a year job at FAANG. I know nothing about testing, git, software process, roll outs, dev ops, etc. I barely know how to do software engineering. What an idiotic hiring process.

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…

There's no reason to believe that being able to learn leetcode tricks is a better sign of aptitude then being able to learn good software engineering practices.

Re: A guide to learning algorithms through LeetCode

#143

Post by tourist_on_road »

jkachmar wrote: post #43
tourist_on_road wrote: post #34

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.

Bullshit. It has been my personal experience, and the experience of many people I’ve spoken with, that this kind of trivia is learned in order to get a job and then forgotten immediately afterwards because it’s useless. Anecdotal example: a former colleague is an incredibly talented systems programmer and has had to study leetcode garbage for the last few months in order to feel qualified to interview for a position…

In this regard. I like the google approach for not asking questions that are publicly available on internet.

These are basic computer science fundamentals and critical thinking capabilities that essential for performing the job atleast for software development roles.

Re: A guide to learning algorithms through LeetCode

#144

Post by ummonk »

wdb wrote: post #135
thewarrior wrote: post #98

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.

The bonus is pretty formulaic with fixed performance multipliers - if you're doing poorly enough to get substantially less than the target bonus, you're at risk of losing your job and comp is the least of your worries.

And you absolutely can pay the bills by selling the stock when it vests. Agreed on the mortgage part though.

Re: A guide to learning algorithms through LeetCode

#145

Post by zerr »

PragmaticPulp wrote: post #134
zerr wrote: 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…

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

Yet, they copycat each other on this.

> after you've been programming for 10 years

...as I said, you're not desperate enough, so you become picky how you spend your time.

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

Lowering the churn rate has a higher priority.

> The problems are designed to test CS skills.

No, these problems are designed to test CP skills. Even Norvig admits it has nothing to do with being a good dev/hire: https://www.youtube.com/watch?v=DdmyUZCl75s

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

How Caltech, MIT, Harvard, ETH, etc... test for CS skills? Certainly not with CP riddles - unless you take a CP course, which indeed is a separate [optional] course at some of those universities for interview preps specifically.

Re: A guide to learning algorithms through LeetCode

#146

Post by [deleted] »

jkcorrea wrote: post #112
zerr wrote: 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

[deleted]

Re: A guide to learning algorithms through LeetCode

#148

Post by ummonk »

bradlys wrote: post #85
PragmaticPulp wrote: post #63

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…

Why are you complaining about the problem solving / leetcode culture if that's not what has kept you out of the Big N?

Re: A guide to learning algorithms through LeetCode

#149

Post by shahbaby »

tmpmov wrote: post #109
ghj wrote: post #42

Earlier quoted context omitted.

There are plenty of competitive programming sites where you can grind rating just like you would for MMR rating in video games. For example CodeForces, AtCoder, TopCoder, and even LeetCode have rated contests

Thanks ghj. I was aware of top coder/leet code, though hadn't heard of code forces/at coder. For me the adventure game give a bit more concept linkage. Take Monkey Island, I can remember how to reply to many of the sword fighting insults, or what was needed to get pieces of eight via the cannon at the circus. There's something to be said for linking problems via a memorable story, giving examples and meaning from mul…

Usually when you try to combine education with gaming, the result is something that's not very educational and not very fun.

Re: A guide to learning algorithms through LeetCode

#150

Post by ummonk »

OnionBlender wrote: post #19
TACIXAT wrote: post #8

This is really cool. What order are the chapters in? Seems intense to lead with dynamic programming.

I got really good at dynamic programming problems but then none of the companies I interviewed with asked me a dynamic programming problem. These were large tech companies and well funded startups. Perhaps it was just luck.

I tell interviewees to practice some dynamic programming problems because dynamic programming questions are the least intuitive, and it's good to be prepared in case that's what you get asked.

For the same reason though, I think they make for terrible interview questions - very much dependent on knowing a specific "trick" that doesn't actually come up often in day to day coding.

Post reply on HN