Ask HN: Did preparing for LeetCode type of interviews improve your skills?
191 comments
I thought it was a waste of time because the most optimal solutions tended to require a stateful, even pointer-diddling, style of code that doesn't align with what I do in the real world. I'm sure they're fun and enlightening to some extent, but I'm not really interested in programming like it's still the 90s.
In Australia I have fortunately not encountered a company that uses these puzzles in interviews. I feel bad for my friends in America who have to practice them every time they switch jobs.
In Australia I have fortunately not encountered a company that uses these puzzles in interviews. I feel bad for my friends in America who have to practice them every time they switch jobs.
> In Australia I have fortunately not encountered a company that uses these puzzles in interviews.
The big ones are definitely doing it. FAANG of course, but also Atlassian, Optiver, Xero, Akuna etc. I am not sure, but maybe it's more common in the less experience levels? I am not experienced enough to know hiring after 5YOE etc.
The big ones are definitely doing it. FAANG of course, but also Atlassian, Optiver, Xero, Akuna etc. I am not sure, but maybe it's more common in the less experience levels? I am not experienced enough to know hiring after 5YOE etc.
big banks use them for filtering too, even contracting. And there are also some small companies that use them for some reason, probably the tech lead learned that from a big firm they worked in.
Yeah. I think there's a lot of startups who are sort of emulating the FAANGs because it is "norm". I personally think that's good because I'd rather have everyone have a similar process than have very different processes across companies. Makes it much easier to interview and prepare for one.
I'd rather they interview real skills used on the job, and since it's already what I do day to day, I don't need to prepare. With small companies leetcode is a waste of time because they don't have time to do rounds and rounds of interview like big tech, so using leetcode for 1 round mean they only have another 1 or even no round left for the real stuff, system design and the like.
An example of good tech interview at a company (not in Australia) I interviewed recently, is a take home test that encompasses doing 1 or more PRs to fix issues, code reviewing someone else's PR, and document a simple security audit.
An example of good tech interview at a company (not in Australia) I interviewed recently, is a take home test that encompasses doing 1 or more PRs to fix issues, code reviewing someone else's PR, and document a simple security audit.
Yeah I find in business software an optimal algorithm is not worth the cost of readability.
Most of the applications I work with have moderate data and few users. It has to work robustly and has to be easy to modify.
Most of the applications I work with have moderate data and few users. It has to work robustly and has to be easy to modify.
Working closer to the front end, I've found that a solid foundation in SQL (to prevent ORM explosions), regex and basic app architecture is far more useful than deep algo knowledge. I've had to use tree traversal like a handful of times and bit shifting like twice.
Let's not talk about working with dates and times.
Let's not talk about working with dates and times.
> Let's not talk about working with dates and times.
Took me years of part-time use to really understand these.
Still waiting for an opportunity to code any non-trivial data structure I meticulously learned about in the past.
Took me years of part-time use to really understand these.
Still waiting for an opportunity to code any non-trivial data structure I meticulously learned about in the past.
You'll rarely find that sort of work when doing user-visible stuff, because most software doesn't have enough users or complexity to justify the cost of custom data structures. But if you look at the software running on your computer right now, you'll find these programs are chock full of clever data structures. (Eg VS code, firefox, nodejs, rustc, etc.)
If you want that sort of work, you kind of need to be building software infrastructure. So, contribute to linux, mysql, firefox, ... or work at FAANG, Microsoft, Dropbox, or something like that.)
Or work on a product that needs high performance (like video games) or has a lot of users (like Twitter).
If you want that sort of work, you kind of need to be building software infrastructure. So, contribute to linux, mysql, firefox, ... or work at FAANG, Microsoft, Dropbox, or something like that.)
Or work on a product that needs high performance (like video games) or has a lot of users (like Twitter).
Wanted to echo the same sentiment but from the UK too
We use it less but they're there, mostly for filtering. It's hilarious because there was one time this company sent me an easy hackerrank. I nailed it, did interviews with them, one of which they followed up on the lame hackerrank instead of something useful like pairing or system design, nailed that too. Then they called me after the final round and asked me to do a dynamic programming problem, just so they "have one more data point". I actually tanked that one but at that point I already felt they didn't know what they were looking for anyway, one of waaax
> most optimal solutions tended to require a stateful, even pointer-diddling, style of code
not necessarily, a search problem can be solved in a functional way in 2 steps: 1) constructing a search space in lazy stream, this is where dfs or bfs happens 2) filtering the stream using standard filter function
Similarly if you do dynamic programming using memoization instead of tabularization you might not need any state
I think, like practical problem solving, algorithms have been predominantly taught in a stateful way of writing code that was popular because of the computing power constraints back in the day. That doesn't mean that's the only way to write them
not necessarily, a search problem can be solved in a functional way in 2 steps: 1) constructing a search space in lazy stream, this is where dfs or bfs happens 2) filtering the stream using standard filter function
Similarly if you do dynamic programming using memoization instead of tabularization you might not need any state
I think, like practical problem solving, algorithms have been predominantly taught in a stateful way of writing code that was popular because of the computing power constraints back in the day. That doesn't mean that's the only way to write them
LeetCode is an excellent collection of problems you’ll never encounter in real life. If you don’t have a computer science background you might learn some things. Otherwise, it’s just solving silly problems for the sake of solving silly problems.
It reminds me of when my college required linear algebra for my degree. Learning things that I knew without a shadow of a doubt I would never put to use again.
It reminds me of when my college required linear algebra for my degree. Learning things that I knew without a shadow of a doubt I would never put to use again.
Funny, linear algebra is essential if you want to do anything machine learning or graphics related.
More so than LeetCode
More so than LeetCode
I am on the job hunt right now with about 5 years of experience. How do you find jobs that do not require technical interviews? Every single company I have applied to (about 10 so far) has required LeetCode style interviews
Maybe in Europe it is different? There is still a coding part, but is somewhat relevant to the job position (build an API that does xyz etc)
> Maybe in Europe it is different? There is still a coding part, but is somewhat relevant to the job position
Anecdata: In Europe but have had more than a handful of these nonsense Leetcode tests. Normally for companies with an inflated sense of their own worth - but possible to spot this from their mission statement, website, etc. and avoid them.
Anecdata: In Europe but have had more than a handful of these nonsense Leetcode tests. Normally for companies with an inflated sense of their own worth - but possible to spot this from their mission statement, website, etc. and avoid them.
> Normally for companies with an inflated sense of their own worth
This is also my experience, crappy Berlin startups that pay poorly and expect you to jump through hoops and work long hours. I switched to contracting and haven't had to do any of these silly tests, I usually discuss the project and my past projects and that's enough. A few times I've been asked to do a take home challenge which I don't mind and actually quite enjoy. Separated from the interview process I find some of the leetcode type challenges kind of fun, like doing a puzzle but they have been of very little practice use to me in my work.
This is also my experience, crappy Berlin startups that pay poorly and expect you to jump through hoops and work long hours. I switched to contracting and haven't had to do any of these silly tests, I usually discuss the project and my past projects and that's enough. A few times I've been asked to do a take home challenge which I don't mind and actually quite enjoy. Separated from the interview process I find some of the leetcode type challenges kind of fun, like doing a puzzle but they have been of very little practice use to me in my work.
As of 2020, most SV interviews for Devops/SRE were not Leetcode - just normal programming, though possibly kinda lengthy.
In 2021, it's a few percent higher. The one I saw recently was related to checking for N matches against M permutations.
All required passing a test suite.
In 2021, it's a few percent higher. The one I saw recently was related to checking for N matches against M permutations.
All required passing a test suite.
For all the hate these interviews get, they do make you a better programmer. Before doing these problems I had no framework for thinking about how to program optimally. Doing these problems helps a lot.
Don't fall for the hate people give. Every selective interview process gets hate. It's extremely useful for your development as a programmer.
Edit: I do think it's not good when there are bad interviewers. For example, interviewers who don't give you a chance to think, or expect you to know the perfect solution rightaway. Or just arrogant interviewers :(
Don't fall for the hate people give. Every selective interview process gets hate. It's extremely useful for your development as a programmer.
Edit: I do think it's not good when there are bad interviewers. For example, interviewers who don't give you a chance to think, or expect you to know the perfect solution rightaway. Or just arrogant interviewers :(
I agree to an extent, but at my company we have hired a few very intelligent people who ace these leet code algorithmic interviews, but they're at the same time the most incompetent engineers in the company.
On top of prematurely optimising code that executes once in a blue moon and creating an unnecessary maintenance burden, they also lacked any skill in designing codebases whatsoever, and generally pick the worst solution for a problem (which is sometimes detrimental to performance overall, even if the "local implemenation" is great) Most of my refactoring nightmare situations were caused by leetcoders.
Maybw it's just anecdotal, but in my experience there's been a strong correlation.
Also an aside: they tend to be quite a bit snobby/circlejerky and vastly overestimate their skills. IMO, leetcoding is a skill but not the most important one. And also, once you start approaching software as design/engineering, the leetcode will start coming gradually and naturally to you.
On top of prematurely optimising code that executes once in a blue moon and creating an unnecessary maintenance burden, they also lacked any skill in designing codebases whatsoever, and generally pick the worst solution for a problem (which is sometimes detrimental to performance overall, even if the "local implemenation" is great) Most of my refactoring nightmare situations were caused by leetcoders.
Maybw it's just anecdotal, but in my experience there's been a strong correlation.
Also an aside: they tend to be quite a bit snobby/circlejerky and vastly overestimate their skills. IMO, leetcoding is a skill but not the most important one. And also, once you start approaching software as design/engineering, the leetcode will start coming gradually and naturally to you.
I don't hate selective interview process.
I hate it when interviewer is an asshole. Somehow in my experience companies that have 'Leetcode' or that kind of thing in process have interviewer that is an asshole.
If someone thinks he is better than me just because he is in a position to ask questions, well that leaves me frustrated for the rest of the day after interview.
It is specially frustrating when you already have the experience, I am now almost 10 years and a senior dev and I cannot really put up with it.
When I was a junior trying to find any job I was not offended at all, but I still remember all bad interviews.
I hate it when interviewer is an asshole. Somehow in my experience companies that have 'Leetcode' or that kind of thing in process have interviewer that is an asshole.
If someone thinks he is better than me just because he is in a position to ask questions, well that leaves me frustrated for the rest of the day after interview.
It is specially frustrating when you already have the experience, I am now almost 10 years and a senior dev and I cannot really put up with it.
When I was a junior trying to find any job I was not offended at all, but I still remember all bad interviews.
For quick comparison, Wwat's your opinion on fizzbuzz?
I don't mind solving fizzbuzz, I don't mind take home assignments.
They don't know me and besides my CV they have to see that I can write code or see that I can use a computer. I can invest up to 2h into some task if I am switching jobs and offer/company is interesting for me.
For some specialistic roles I don't mind questions about specific technologies, just keep in mind that for example "Web Development" spans so many topics that we might have vastly different experience and questions that you ask or the way you ask them might not connect to my experience.
That is why it should be more of a discussion to try to find out common understanding than grill:quizz, shooting question and 0.5s answer.
They don't know me and besides my CV they have to see that I can write code or see that I can use a computer. I can invest up to 2h into some task if I am switching jobs and offer/company is interesting for me.
For some specialistic roles I don't mind questions about specific technologies, just keep in mind that for example "Web Development" spans so many topics that we might have vastly different experience and questions that you ask or the way you ask them might not connect to my experience.
That is why it should be more of a discussion to try to find out common understanding than grill:quizz, shooting question and 0.5s answer.
Fizzbuzz is laughable, I don't like Leetcode and now that I'm in charge of hiring, I don't do Leetcode.
But fizzbuzz is truly the lowest of the low bars you can pass. You could even do it in a language you have never ever written before.
But fizzbuzz is truly the lowest of the low bars you can pass. You could even do it in a language you have never ever written before.
Yes, completely agree with this. There's so many bad interviewers out there, and sadly many are really arrogant too.
However, in my experience, most interviewers are not like that. But even one bad interviewer leaves a really foul taste.
However, in my experience, most interviewers are not like that. But even one bad interviewer leaves a really foul taste.
Everybody hates to be in front of an asshole no matter the context. Care to elaborate specific things you wish interviewers didn't do?
Context: I do conduct a fair amount of technical interviews and it can be quite awkward to be in front of an engineer with arguably more experience but that struggles to write a correct solution to a relatively simple problem.
Context: I do conduct a fair amount of technical interviews and it can be quite awkward to be in front of an engineer with arguably more experience but that struggles to write a correct solution to a relatively simple problem.
Worst was being actively aggressive in their tone shooting questions and approach "well you have an engineering degree, we will see about that". Then there were quite some dismissive with sighing when not getting answers they like to hear.
They could keep it to themselves and go back to their colleagues and nag about "what a waste of time, that guy was".
I am also interviewing people from time to time, but I see it as part of my job not some kind of punishment. So maybe don't push technical colleagues, who are not happy about it, to do it.
They could keep it to themselves and go back to their colleagues and nag about "what a waste of time, that guy was".
I am also interviewing people from time to time, but I see it as part of my job not some kind of punishment. So maybe don't push technical colleagues, who are not happy about it, to do it.
> "well you have an engineering degree, we will see about that".
Well this means you dodged a bullet early :) It's better they wasted your time for the interview (couple hours or days of preparing?) than months or years of your time working there.
Well this means you dodged a bullet early :) It's better they wasted your time for the interview (couple hours or days of preparing?) than months or years of your time working there.
Yes, bullet possibly dodged but that still makes it frustrating and a time waster. And these types of interviews don’t expose or test on knowledge needed on the actual codebase. I see it as a cockyness contest which I don’t want to be part of.
I am quite happy with that dodged bullet, after that I found job I am working now couple years with satisfaction.
> Before doing these problems I had no framework for thinking about how to program optimally.
You didn't study CS in school?
> It's extremely useful for your development as a programmer.
Can you give some concrete example?
You didn't study CS in school?
> It's extremely useful for your development as a programmer.
Can you give some concrete example?
You didn't study CS in school?
Anecdotally, many programmers I know didn't.
Also 'CS' has grown into a huge and varied field that can include everything from highly abstract mathematics to cognitive behavior and human psychology. If you want to it is absolutely possible to get through an entire CS curriculum without doing much actual practical programming.
Anecdotally, many programmers I know didn't.
Also 'CS' has grown into a huge and varied field that can include everything from highly abstract mathematics to cognitive behavior and human psychology. If you want to it is absolutely possible to get through an entire CS curriculum without doing much actual practical programming.
"You didn't study CS in school?"
Quite an entitled comment. Studying CS in school doesn't mean you've learned everything there is while practicing programming. Yes, you learn these skills on the job, but doing programming interview questions helped me learn skills too.
Quite an entitled comment. Studying CS in school doesn't mean you've learned everything there is while practicing programming. Yes, you learn these skills on the job, but doing programming interview questions helped me learn skills too.
It's not an entitled comment, it's a genuine question. If you claim you "had no framework" you need to explain why.
The point of any CS curriculum is just that, providing you with a framework (which should ideally be a balance of theoretical and practical knowledge). It doesn't teach you the job. Neither do leetcode questions.
The point of any CS curriculum is just that, providing you with a framework (which should ideally be a balance of theoretical and practical knowledge). It doesn't teach you the job. Neither do leetcode questions.
Sorry if I misunderstood. I don't think most CS curriculums teach you analyzing programs and writing them efficiently. My data structures and algorithms classes were great but still not enough practical knowledge to implement programs day to day. On top of that, there was practically no code review. I don't think there's enough time for professors and TAs to analyze your code and tell you if this is a good way of doing things or is it clean or will it waste a lot of memory.
Still, leetcode might teach you to write code that passes time and memory constraints, but it certainly won't teach you how to write clean code that passes a code review.
I agree. I don't think Leetcode is a good reflection of programming interviews. In programming interviews, you're supposed to have a sound thought process, write clean code, and don't need to pass hundreds of test cases. Leetcode is just a programming environment that, imo, is not the same as a programming interview.
I'd rather learn interview algorithms from books. And by getting feedback from trusted peers.
I'd rather learn interview algorithms from books. And by getting feedback from trusted peers.
Frankly, as a return student, most students I've encountered at my crappy state school are incredibly entitled. On top of that, don't know how to code. That's because my shitty state school lumped in programming with general IT support as if they're the same field. I don't understand why a network analyst or database admin needs to know about OOP or Algorithms when the most complicated thing they're gonna do is work with AD or maybe manage a server.
No I don't think it has helped my skills at all. In the rare one or two cases in my career where I've needed an advanced algorithm, I had plenty of time to look up the best way to do it online.
I think it is important to know WHEN you're facing an algorithmic problem, and to be able to generalize your problem enough to recognize what kinds of algorithms might apply. But leetcode style questions as currently posed go way beyond that imo.
I think it is important to know WHEN you're facing an algorithmic problem, and to be able to generalize your problem enough to recognize what kinds of algorithms might apply. But leetcode style questions as currently posed go way beyond that imo.
I'm a PhD student with focus on compilers and algorithm. Leetcode scare me too. I currently work at FAANG and I had to spend a month practicing leetcode before I got my job.
Yes, and no.
I thought I was a good Ruby programmer, but preparing for a FB interview in Ruby, and bombing an earlier one, really showed me how slow I was with the syntax.
Leetcoding really improved my grasp of the language.
I thought I was a good Ruby programmer, but preparing for a FB interview in Ruby, and bombing an earlier one, really showed me how slow I was with the syntax.
Leetcoding really improved my grasp of the language.
AFAIK lots of Chinese students go through more than six/seven hundred of LeetCode problems, at least thrice each problem, before they are ready for job hunting.
Kind of. When I was doing LeetCode, I tried to give myself an additional challenge by implementing in a "functional taste", that is, to make heavy use of immutable data structures and Java Stream API (I mostly used Java at the time). That did help me a bit in writing better functional code in general.
The bigger benefit to me, however, was that I got more confident during the interviews.
The bigger benefit to me, however, was that I got more confident during the interviews.
My feeling on this is mixed—I competed in ICPC in college, which is a competitive circuit of programming contests (like leetcode, but predating it) and went to the world finals, which is easier than it sounds but not nothing. I think there are a few levels on which this sort of practice might help your career, and the question of whether they do help depends on which level you mean:
1) Learning the algorithms. I agree with the general criticism that these algorithms aren't that broadly applicable. I work on data storage software, so we use a few relatively fancy data structures, but even so most of my day to day work isn't on the code that manipulates them. That said, I think succeeding at these contests (especially when they're timed) requires you to practice avoiding bugs, particularly off-by-one errors, and I think that practice is pretty broadly applicable.
2) Thinking in terms of data structures. The data structures that a program uses are a lot more important than the actual code. Some critics complain that programming contests teach you to write messy code. I think that the people who are really good at programing contests who write messy code (ime, it's more compact than messy) do it because they've trained themselves to look at a program and see the data structures rather than the code, and in my opinion that's a better way to think about a program.
3) Learning to get good at something in general. This is the main reward I feel like I've gotten from these contests. I think many skills in life (including job performance and career advancement) can be developed the same way: study the rules, study the best competitors to understand what's achievable and what techniques are available, make an attempt, try to understand the results you got, try to improve your approach, repeat. I think programming contests are a great place to learn to do this (among many others, of course).
1) Learning the algorithms. I agree with the general criticism that these algorithms aren't that broadly applicable. I work on data storage software, so we use a few relatively fancy data structures, but even so most of my day to day work isn't on the code that manipulates them. That said, I think succeeding at these contests (especially when they're timed) requires you to practice avoiding bugs, particularly off-by-one errors, and I think that practice is pretty broadly applicable.
2) Thinking in terms of data structures. The data structures that a program uses are a lot more important than the actual code. Some critics complain that programming contests teach you to write messy code. I think that the people who are really good at programing contests who write messy code (ime, it's more compact than messy) do it because they've trained themselves to look at a program and see the data structures rather than the code, and in my opinion that's a better way to think about a program.
3) Learning to get good at something in general. This is the main reward I feel like I've gotten from these contests. I think many skills in life (including job performance and career advancement) can be developed the same way: study the rules, study the best competitors to understand what's achievable and what techniques are available, make an attempt, try to understand the results you got, try to improve your approach, repeat. I think programming contests are a great place to learn to do this (among many others, of course).
"Learning to get good at something in general" is the real thing these kind of tests proxy for.
There's a lot of things in life that are a pain in the butt, hard, and stupid that you just gotta do.
I went through the leetcode grind a few times, the last time I went through it I ended up taking a job at a startup that I was using as a "practice" interview before the FAANG ones because I could relocate out of California. I never would have interviewed there though if I wasn't laser focused committed to leaving my previous job for a better opportunity.
If you're the kind of person who grinds leetcode, you're _probably_ also the kind of person who spends the extra time reading all the documentation for redux. Or spends the extra time writing a tricky unit test before shipping something. That being said, there's still _plenty_ of people who fail leetcode phone interviews (e.g. myself) but go the extra mile, and FAANG companies still manage to let some questionable hires through the cracks. But engineer hiring is currently a filtering game, not a sourcing game.
You can either learn the rules of Monopoly and play or sit in the corner during board game night and complain you're not playing checkers. shrug
There's a lot of things in life that are a pain in the butt, hard, and stupid that you just gotta do.
I went through the leetcode grind a few times, the last time I went through it I ended up taking a job at a startup that I was using as a "practice" interview before the FAANG ones because I could relocate out of California. I never would have interviewed there though if I wasn't laser focused committed to leaving my previous job for a better opportunity.
If you're the kind of person who grinds leetcode, you're _probably_ also the kind of person who spends the extra time reading all the documentation for redux. Or spends the extra time writing a tricky unit test before shipping something. That being said, there's still _plenty_ of people who fail leetcode phone interviews (e.g. myself) but go the extra mile, and FAANG companies still manage to let some questionable hires through the cracks. But engineer hiring is currently a filtering game, not a sourcing game.
You can either learn the rules of Monopoly and play or sit in the corner during board game night and complain you're not playing checkers. shrug
I think this is the most plausible explanation too, but is this true in practice? I would have thought most talented programmers don't want to waste their time on leetcode, so it would primarily select for people who can't succeed without dedicating time to it.
Have you seen this first-hand and compared leetcode grinders against say, prolific open source developers?
Have you seen this first-hand and compared leetcode grinders against say, prolific open source developers?
Most people in the world care about money, and practicing leetcode is worth way more money per time spent than basically anything else for a talented programmer, up until you hit the level where you can get into top paying companies.
You can get into well paying jobs without it, but then you need skills that are way harder to practice and usually you also need a lot of personal connections as those jobs often selects friends.
You can get into well paying jobs without it, but then you need skills that are way harder to practice and usually you also need a lot of personal connections as those jobs often selects friends.
I'm not really convinced by this argument. Consistently improving your overall skills will lead you to outpace the competition significantly more in the long run than min-maxing, unless your industry is extremely bad at differentiating ability.
I suppose there's an argument to be gained that the marginal gain of Leetcode given thousands of hours of practice already is the better side of the tradeoff, but that's a circular argument. You're going to select your programmers based on whether they recently spent 30 hours doing Leetcode, rather than on what they got out of the 10,000 hours of regular coding practice they did beforehand? Doesn't seem like a good selection criteria to me.
That's why I asked whether OP had actually seen the effect he was describing and compared results directly. It's easy to come up with hypothetical benefits.
I suppose there's an argument to be gained that the marginal gain of Leetcode given thousands of hours of practice already is the better side of the tradeoff, but that's a circular argument. You're going to select your programmers based on whether they recently spent 30 hours doing Leetcode, rather than on what they got out of the 10,000 hours of regular coding practice they did beforehand? Doesn't seem like a good selection criteria to me.
That's why I asked whether OP had actually seen the effect he was describing and compared results directly. It's easy to come up with hypothetical benefits.
It is a bit tiring to explain the process to everyone, but here it goes:
Companies don't select programmers based on leetcode performance, no, they care a great deal about those 10,000 hours people spent. However if you fail that leetcode test you are out no matter what other experience you have. And it so happens that the set of companies paying twice the average for any experience levels tend to do leetcoding, so no matter what level of experience you have leetcoding is great. Although sometimes your experience might impress low tier companies but not high tier ones, so they downlevel you and ultimately your total compensation didn't move much.
If you haven't seen this process then you are either ignorant, don't live in an area with high tier companies, or don't have a lot of experience. Personally I did double my income by going through this process and I've seen many others do as well.
Now, lots of low tier companies started seeing high tier companies do this process, so they started copying it for some reason. But it doesn't work if you don't combine it with also paying significantly more than most others.
Companies don't select programmers based on leetcode performance, no, they care a great deal about those 10,000 hours people spent. However if you fail that leetcode test you are out no matter what other experience you have. And it so happens that the set of companies paying twice the average for any experience levels tend to do leetcoding, so no matter what level of experience you have leetcoding is great. Although sometimes your experience might impress low tier companies but not high tier ones, so they downlevel you and ultimately your total compensation didn't move much.
If you haven't seen this process then you are either ignorant, don't live in an area with high tier companies, or don't have a lot of experience. Personally I did double my income by going through this process and I've seen many others do as well.
Now, lots of low tier companies started seeing high tier companies do this process, so they started copying it for some reason. But it doesn't work if you don't combine it with also paying significantly more than most others.
Ok, but companies do select based on Leetcode performance, in practice. It's the largest portion of the interview. It's useful as a filter, but it's treated as a benchmark. As evidenced by:
> Personally I did double my income by going through this process and I've seen many others do as well.
That's insane. That's a broken market. If that's happening, it's not a reliable signal.
Ultimately, if the market is rational then your actual ability will matter more than anything else. The only time that isn't the case is if the market is irrational. You can argue the market is currently irrational (although I would say that's not quite what's going on), but placing a long-term bet on it staying that way... Bad idea, IMO.
But I think the actual explanation for why high-tier (read: large) companies use Leetcode is a combination of the fact that they're monopolies, so they aren't punished for bad selection criteria (see Google's use of lateral thinking puzzles for years before admitting they were completely useless for predicting job performance), and that they need a replicable interview procedure that can be applied consistently by a workforce that fundamentally isn't very good at interviewing, thinks they are, and doesn't care if they get it wrong. It's the Big Mac of interviewing methods.
> Personally I did double my income by going through this process and I've seen many others do as well.
That's insane. That's a broken market. If that's happening, it's not a reliable signal.
Ultimately, if the market is rational then your actual ability will matter more than anything else. The only time that isn't the case is if the market is irrational. You can argue the market is currently irrational (although I would say that's not quite what's going on), but placing a long-term bet on it staying that way... Bad idea, IMO.
But I think the actual explanation for why high-tier (read: large) companies use Leetcode is a combination of the fact that they're monopolies, so they aren't punished for bad selection criteria (see Google's use of lateral thinking puzzles for years before admitting they were completely useless for predicting job performance), and that they need a replicable interview procedure that can be applied consistently by a workforce that fundamentally isn't very good at interviewing, thinks they are, and doesn't care if they get it wrong. It's the Big Mac of interviewing methods.
> The only time that isn't the case is if the market is irrational.
There are other situations, such as when measuring actual ability is sufficiently difficult or impossible (subject to the constraints you pointed out - via a process that's repeatable by a largely undifferentiated set of interviewers).
In those situations, you have basically no choice but to look for proxy measures.
Now, obviously, proxies can be gamed to various degrees. Leetcode is not actually such a terrible proxy, though. Here are some points in favor:
1) On average, better engineers will require less practice time to achieve similar results,
2) There is a certain minimum level of capability required to even "grind it out"; that minimum doesn't serve as a sufficient floor for being a net productive engineer, but it gets you a reasonable chunk of the way there, and that's why so much of the evaluation criteria for these interviews focuses on communication ability, since that's the rest of what they care about
Taken together, you get a process that is reasonably good at eliminating false positives and still manages to tilt the field in favor of more skilled candidates. On the candidate's side, it has the benefits of being generalizable across multiple interviews and also getting easier each time you do it.
While I'm somewhat sympathetic to the claim that the process favors candidates who have more free time, I think it's a largely overstated concern. First, this is true of any interviewing process wherein a candidate can improve their performance through practice. To a first approximation this is all interview processes. Second, it doesn't take _that_ much time. If you put in 100 hours (which is basically "made it a moderately important priority for 2-3 months") and you still can't clear any interviews, there are a few possible explanations.
1) You're failing at the communication side of things. Thankfully this is also something you can practice!
2) You fall into an unfortunate edge case, e.g. extreme performance anxiety, which isn't reflected in your day-to-day work. This sucks! I don't think there's a process that doesn't have unfortunate edge cases; all we can do is try to minimize them.
3) You're not able to learn the material well enough to generalize it to novel interview questions. This is the process working as intended.
I've also heard a reason that goes something like "I can totally solve those problems, just not in 45 minutes". Problem-solving speed is going to be positively correlated with other traits of talented engineers; obviously some otherwise talented engineers will still fall on the right side of the curve. Again, this sucks, but please bring me a process that effectively rules out false positives without bringing in some false negatives. If you can manage it there's a huge market opportunity there.
There are other situations, such as when measuring actual ability is sufficiently difficult or impossible (subject to the constraints you pointed out - via a process that's repeatable by a largely undifferentiated set of interviewers).
In those situations, you have basically no choice but to look for proxy measures.
Now, obviously, proxies can be gamed to various degrees. Leetcode is not actually such a terrible proxy, though. Here are some points in favor:
1) On average, better engineers will require less practice time to achieve similar results,
2) There is a certain minimum level of capability required to even "grind it out"; that minimum doesn't serve as a sufficient floor for being a net productive engineer, but it gets you a reasonable chunk of the way there, and that's why so much of the evaluation criteria for these interviews focuses on communication ability, since that's the rest of what they care about
Taken together, you get a process that is reasonably good at eliminating false positives and still manages to tilt the field in favor of more skilled candidates. On the candidate's side, it has the benefits of being generalizable across multiple interviews and also getting easier each time you do it.
While I'm somewhat sympathetic to the claim that the process favors candidates who have more free time, I think it's a largely overstated concern. First, this is true of any interviewing process wherein a candidate can improve their performance through practice. To a first approximation this is all interview processes. Second, it doesn't take _that_ much time. If you put in 100 hours (which is basically "made it a moderately important priority for 2-3 months") and you still can't clear any interviews, there are a few possible explanations.
1) You're failing at the communication side of things. Thankfully this is also something you can practice!
2) You fall into an unfortunate edge case, e.g. extreme performance anxiety, which isn't reflected in your day-to-day work. This sucks! I don't think there's a process that doesn't have unfortunate edge cases; all we can do is try to minimize them.
3) You're not able to learn the material well enough to generalize it to novel interview questions. This is the process working as intended.
I've also heard a reason that goes something like "I can totally solve those problems, just not in 45 minutes". Problem-solving speed is going to be positively correlated with other traits of talented engineers; obviously some otherwise talented engineers will still fall on the right side of the curve. Again, this sucks, but please bring me a process that effectively rules out false positives without bringing in some false negatives. If you can manage it there's a huge market opportunity there.
These are interesting points, but they very much read like post-hoc rationalisations to me. Let me take a different tact, I want to try challenging some of the more fundamental assumptions.
Do you really believe in the quality of Leetcode as an evaluation criteria, or are you trying to justify it? Google used lateral thinking puzzles for something like 8 years before realising they were completely useless (not just unreliable - they had zero predictive power). We have precedent for these companies using selection methods that are bananas, and smaller companies copying them.
>There are other situations, such as when measuring actual ability is sufficiently difficult or impossible
Sure, that's an example of why the market might be irrational. But then I'd ask: do you think it's extremely difficult/impossible to judge other programmers? I mean that seriously. I don't find that difficult. I can usually size up another programmer pretty quickly. If I sniff around a bit and look at some example code, my intuitive read will be much more three-dimensional and reliable than giving them two Leetcodes. You don't find that to be the case?
How much do you spend on hiring one candidate? I'm guessing tens of thousands, if not more. You can't invest a day into trawling that candidate's GitHub? "But not all candidates have a GitHub." Ok, but some do, so that's not the reason.
What I think is actually extremely difficult is a large, beurocratic organisation developing a replicable, second-hand evaluation system. It's a standardised test, and it has the same problems as most standardised tests.
> you get a process that is reasonably good at eliminating false positives
Right, it's good as a filtering mechanism. But if it's just a filtering mechanism, it shouldn't take up the majority of the interview.
Like, here is one of the assumptions you're making: most good engineers grind Leetcode before a new job. I don't think that's true. I think the number of people who grind Leetcode, even among the best candidates, is extremely small. Like <10%. If that's the case, it's inherently a very flawed criteria. If nothing else, you're filtering for the candidates that everyone else is filtering for - which means you're filtering not for capable candidates, but for candidates who are overpriced.
Here's another thing that's absent from these discussions: algorithms questions were developed before Leetcode existed. They're not designed for a world where you can game them. Leetcode is a bug in the system, but a lot of your justifications are, "it's fine, because the selection criteria is actually designed to select people who game it." Really? You want people to game the criteria? I don't buy it.
Do you really believe in the quality of Leetcode as an evaluation criteria, or are you trying to justify it? Google used lateral thinking puzzles for something like 8 years before realising they were completely useless (not just unreliable - they had zero predictive power). We have precedent for these companies using selection methods that are bananas, and smaller companies copying them.
>There are other situations, such as when measuring actual ability is sufficiently difficult or impossible
Sure, that's an example of why the market might be irrational. But then I'd ask: do you think it's extremely difficult/impossible to judge other programmers? I mean that seriously. I don't find that difficult. I can usually size up another programmer pretty quickly. If I sniff around a bit and look at some example code, my intuitive read will be much more three-dimensional and reliable than giving them two Leetcodes. You don't find that to be the case?
How much do you spend on hiring one candidate? I'm guessing tens of thousands, if not more. You can't invest a day into trawling that candidate's GitHub? "But not all candidates have a GitHub." Ok, but some do, so that's not the reason.
What I think is actually extremely difficult is a large, beurocratic organisation developing a replicable, second-hand evaluation system. It's a standardised test, and it has the same problems as most standardised tests.
> you get a process that is reasonably good at eliminating false positives
Right, it's good as a filtering mechanism. But if it's just a filtering mechanism, it shouldn't take up the majority of the interview.
Like, here is one of the assumptions you're making: most good engineers grind Leetcode before a new job. I don't think that's true. I think the number of people who grind Leetcode, even among the best candidates, is extremely small. Like <10%. If that's the case, it's inherently a very flawed criteria. If nothing else, you're filtering for the candidates that everyone else is filtering for - which means you're filtering not for capable candidates, but for candidates who are overpriced.
Here's another thing that's absent from these discussions: algorithms questions were developed before Leetcode existed. They're not designed for a world where you can game them. Leetcode is a bug in the system, but a lot of your justifications are, "it's fine, because the selection criteria is actually designed to select people who game it." Really? You want people to game the criteria? I don't buy it.
I don't consider myself particularly talented, but it's really not that much time to practice. At 10+ years of experience, I spent maybe up to 40 hours of practice the last couple of times I switched to interviewing mode. Pretty easy to spread out over 2 weeks to a month to get in shape. I don't consider that an unreasonable or unacceptable burden.
It's not that it's unreasonable, it's that it's a bad criteria because it's so easy. In 40 hours, a college graduate can get to the point where they're outdoing, say, one of the principal architects of AlphaGo? Then that selection criteria sucks. In any other situation we avoid metrics that are easy to game.
The argument that it selects for industriousness strikes me as a cope. It might, but it's also so easy to game that it obscures actual ability (unless you're just using it as a filter). Is that trade-off really worth it?
The argument that it selects for industriousness strikes me as a cope. It might, but it's also so easy to game that it obscures actual ability (unless you're just using it as a filter). Is that trade-off really worth it?
So, i was responding to your comment:
> I would have thought most talented programmers don't want to waste their time on leetcode, so it would primarily select for people who can't succeed without dedicating time to it.
I was saying that it's not that much of a waste of time, because it's not that much of a time investment for a good outcome (doing well at interviews).
If you want to change the argument from "it's a waste of time" to "it's trivially easy and easy to game", then why are there people who complain about leetcode and not wanting to do it?
> I would have thought most talented programmers don't want to waste their time on leetcode, so it would primarily select for people who can't succeed without dedicating time to it.
I was saying that it's not that much of a waste of time, because it's not that much of a time investment for a good outcome (doing well at interviews).
If you want to change the argument from "it's a waste of time" to "it's trivially easy and easy to game", then why are there people who complain about leetcode and not wanting to do it?
It is both a waste of time and easy to game. The reason it's a waste of time is that it's easy to game, so some of your rivals will be gaming it. Which means you have to do it too, so it just becomes a dumb tax you pay every time you interview for a new job.
That's all from the individual candidate's perspective, of course. From the employer's perspective, you're still only going to have a minority of your interviewees having prepared their cheat codes. So you're evaluating based on ability to prepare a cheat code. Which IMO is retarded. If there wasn't a site dedicated to preparing cheat codes (which is how it used to be), then it would be sensible.
That's all from the individual candidate's perspective, of course. From the employer's perspective, you're still only going to have a minority of your interviewees having prepared their cheat codes. So you're evaluating based on ability to prepare a cheat code. Which IMO is retarded. If there wasn't a site dedicated to preparing cheat codes (which is how it used to be), then it would be sensible.
Hmm, i think your understanding of the state of things is slightly backwards. Because Google is so large, interviews so many people, has such a strong brand name, and pays so much more than everyone else, their interview process is going to be a very well-known quantity. Therefore, the questions that they used to use all were being gamed, so they kept on adjusting and tweaking and upping the difficulty, until they ended up with where they are now.
So the point is, how do you interview if you know that everyone is going to know all the questions ahead of time? Seems like google's solution is they'll just make their questions difficult leetcode level. So, then their thinking is, sure if you're able to grind leetcode to a point that you can pass our interviews, then we'll be perfectly happy to hire you. So you've "cheated" the system by learning how to program a wide variety of difficult algorithm-heavy programs. Worst case scenario, your resume is a complete sham, but at least you're able to write the code that they're hiring you to write, and everything else that you're lacking, well, they'll be indoctrinating you in the google way anyways, so they don't care about your past experience.
So the point is, how do you interview if you know that everyone is going to know all the questions ahead of time? Seems like google's solution is they'll just make their questions difficult leetcode level. So, then their thinking is, sure if you're able to grind leetcode to a point that you can pass our interviews, then we'll be perfectly happy to hire you. So you've "cheated" the system by learning how to program a wide variety of difficult algorithm-heavy programs. Worst case scenario, your resume is a complete sham, but at least you're able to write the code that they're hiring you to write, and everything else that you're lacking, well, they'll be indoctrinating you in the google way anyways, so they don't care about your past experience.
That doesn't sound like an effective pipeline to me. That sounds like a really bad pipeline, and a lot of post-hoc justifications to minimise the issues.
I'm hesitant to take Google's use of a tool as an indication that the tool is good, or that the process is refined. They used brain teasers for years before figuring out they had zero predictive power. Ignoring the implications of the scale of that mistake, one thing it indicates is that they aren't able to effectively evaluate different interviewing methods.
I'm hesitant to take Google's use of a tool as an indication that the tool is good, or that the process is refined. They used brain teasers for years before figuring out they had zero predictive power. Ignoring the implications of the scale of that mistake, one thing it indicates is that they aren't able to effectively evaluate different interviewing methods.
If they had no ability to effectively evaluate, how did they conclude that brain teasers had no predictive power?
I see google's process along the same lines as "democracy is the worst form of government except all those other forms that have been tried".
Now ideally, what you'd want is to be able to perfectly read someone's mind and someone's intention, to be able to tell instantly their strengths and weaknesses, to be able to tell which of those weaknesses are trivial ones that will get smoothed over a week into the job, and which of those are ones that are actually long-term issues that will poison your organization. It's possible that individuals with such judgement exist (Paul Graham has said that YC's success was attributed to Jessica's ability to judge founders) and that they work at google. But now you also need a process that can interview and evaluate a thousand people every single week. So what works for small companies where you can agonize over every hire or for exec searches, doesn't make as much sense for mass hiring of peons.
So given those constraints, everyone knows your process, everyone wants to apply, you need to interview a thousand people a week and decide to hire a hundred of them, and they really don't all need to be rockstar founder quality, but they all need to be able to produce something, you can start to imagine what type of interview process you might end up with.
I see google's process along the same lines as "democracy is the worst form of government except all those other forms that have been tried".
Now ideally, what you'd want is to be able to perfectly read someone's mind and someone's intention, to be able to tell instantly their strengths and weaknesses, to be able to tell which of those weaknesses are trivial ones that will get smoothed over a week into the job, and which of those are ones that are actually long-term issues that will poison your organization. It's possible that individuals with such judgement exist (Paul Graham has said that YC's success was attributed to Jessica's ability to judge founders) and that they work at google. But now you also need a process that can interview and evaluate a thousand people every single week. So what works for small companies where you can agonize over every hire or for exec searches, doesn't make as much sense for mass hiring of peons.
So given those constraints, everyone knows your process, everyone wants to apply, you need to interview a thousand people a week and decide to hire a hundred of them, and they really don't all need to be rockstar founder quality, but they all need to be able to produce something, you can start to imagine what type of interview process you might end up with.
[deleted]
>look at a program and see the data structures rather than the code, and in my opinion that's a better way to think about a program.
that sounds pretty difficult for me to understand
when you read the code, analyze and understand it and due to your experience you see that something is bad (e.g poor api), then how can you "lose focus" from it / ignore it?
how it ain't just lack of experience or simply not caring?
that sounds pretty difficult for me to understand
when you read the code, analyze and understand it and due to your experience you see that something is bad (e.g poor api), then how can you "lose focus" from it / ignore it?
how it ain't just lack of experience or simply not caring?
It is a question of priority, I think what GP is saying is that programmers used to these contests will focus on getting their structures right first, and will take care of logic on a second time, if they have time for it. In programming contests, they don't have time.
And I think it makes sense and that is a hierarchy. Data structures are the most important, followed by logic (algorithms), followed by comments.
The reason is that if you change your data structures, you need to change your algorithms, and if you change your algorithms, you need to change your comments. Data structures define everything, comments define nothing but themselves.
And I think it makes sense and that is a hierarchy. Data structures are the most important, followed by logic (algorithms), followed by comments.
The reason is that if you change your data structures, you need to change your algorithms, and if you change your algorithms, you need to change your comments. Data structures define everything, comments define nothing but themselves.
Yeah exactly, thanks. I think I should've said "and focus on the data structures" instead of "and see the data structures"
I think as somebody wfo too as competed in ICPC albeit not at world finals, I just want to add an important caveat, getting to world finals has a lot to do where are you from, for example if you are from a historically tough university or place such as India, Belarus or China. It is exponentially harder since due to how ICPC works the rules make it a piece of cake if you are from an unnamed college in norther America but much harder if you are from an established IIT in India or from somewhere like university of Tokyo.
Except there’s not much competitive programming bench strength in India (happy to link to ample evidence). Really facetious to compare it with China where the bench strength is real, and those thrown by the wayside could have otherwise killed it.
> It ("getting to world finals") is exponentially harder since due to how ICPC works the rules make it a piece of cake if you are from an unnamed college in norther America but much harder if you are from an established IIT
Rephrased as I understood it in context, it says: "unnamed colleges in northern America has better chances at getting to WF than India, Belarus, or China".
Which is a surprising statement to me. At my time (2008-2012, followed it a few more years thereafter), the heavy hitters were from Belarus/Russia, China, and India to a smaller extent. I remember getting news that Shanghai Jiao Tong really dedicates time to training, almost like a sport. Petr Mitrichev is Russian and tourist (forgot his real name) is AFAIK Belarusian. At least Mitrichev coached in grassroots programs for IOI which then translated to ICPC performance. Maybe India wasn't as dominant but I believe they were at least a considerable contingent in the Asia-regional levels.
So it seemed to me the competition format favored these countries over US universities, which focused on research. Not to mention China and Russia loved hosting big ICPC events, if not the World Finals itself.
Do elaborate on your statement please. I am curious why you'd make that claim.
Rephrased as I understood it in context, it says: "unnamed colleges in northern America has better chances at getting to WF than India, Belarus, or China".
Which is a surprising statement to me. At my time (2008-2012, followed it a few more years thereafter), the heavy hitters were from Belarus/Russia, China, and India to a smaller extent. I remember getting news that Shanghai Jiao Tong really dedicates time to training, almost like a sport. Petr Mitrichev is Russian and tourist (forgot his real name) is AFAIK Belarusian. At least Mitrichev coached in grassroots programs for IOI which then translated to ICPC performance. Maybe India wasn't as dominant but I believe they were at least a considerable contingent in the Asia-regional levels.
So it seemed to me the competition format favored these countries over US universities, which focused on research. Not to mention China and Russia loved hosting big ICPC events, if not the World Finals itself.
Do elaborate on your statement please. I am curious why you'd make that claim.
You can check out the rating of teams going to world finals in previous years.
https://codeforces.com/blog/entry/73791
https://codeforces.com/blog/entry/64909
The problem is that certain regions just have too many slots relative to their density of competition programmers.
For example in less competitive regions, a rating of around ~2100 gives you a decent shot at world finals.
But if you were in a region with a lot of other good schools, then even if you had a rating of 3000 you might not even be able to represent your own school, let alone your region. See MIT's result where their top 3 teams dominated their region but their school can still only send at most one team to world finals: https://nena20.kattis.com/standings
https://codeforces.com/blog/entry/73791
https://codeforces.com/blog/entry/64909
The problem is that certain regions just have too many slots relative to their density of competition programmers.
For example in less competitive regions, a rating of around ~2100 gives you a decent shot at world finals.
But if you were in a region with a lot of other good schools, then even if you had a rating of 3000 you might not even be able to represent your own school, let alone your region. See MIT's result where their top 3 teams dominated their region but their school can still only send at most one team to world finals: https://nena20.kattis.com/standings
Isn't this how most international competition works? I'm most familiar with the olympics and this is exactly how it works there. People from uncompetitive countries for their sport have an "easier" time going to the olypmics.
lol my team even made to this stage here - https://nadc21.kattis.com/standings- and we did practically nothing, haha
it's Macalester btw
it's Macalester btw
The idea is that the bar for getting there is much higher - if you're from China or "Northern Eurasia", you get to the finals only if you dedicate time to training and can defeat those "heavy hitters" since you have to compete with them for scarce slots long before the final, but if you come from an unnamed college in northern America, you have a chance to get to WF without being at that level.
> they've trained themselves to look at a program and see the data structures rather than the code, and in my opinion that's a better way to think about a program.
I don't see how this is mutually exclusive to writing readable code. I'm not good at these but I picture good code in your definition to be utilizing data structures in an intuitive way instead of coming up with some novel but wacky performance trick.
I don't see how this is mutually exclusive to writing readable code. I'm not good at these but I picture good code in your definition to be utilizing data structures in an intuitive way instead of coming up with some novel but wacky performance trick.
Yeah, it makes no sense to me. It's like saying if you stare hard enough you can see into the matrix.
For me, i'd sacrifice raw performance for using Python because i love its simple datastructures and protocols and the compbination of code and interpreter is great... and more often then not, it's not much of a sacrifice since compute time is often more affordable than creative programming time...
For me, i'd sacrifice raw performance for using Python because i love its simple datastructures and protocols and the compbination of code and interpreter is great... and more often then not, it's not much of a sacrifice since compute time is often more affordable than creative programming time...
[deleted]
I would say yes. A few years ago I signed up for one of the test sites as an employer and downloaded all their tests. I then solved them myself, well sorta half of them.
It's easy to say that such tests are useless, and they probably are as a tool for judging coder skill. However when I did a few of these it did open my eyes to a few common solutions that I could apply in various places in my code. If you read through an algo book you'll probably find a few things that are a bit surprising like Kadane's algorithm, or some things that you kinda know how to do but you need the last piece of the puzzle for, eg various graph algorithms (is there a loop etc).
I'd say the main benefit is that it illuminates what kinds of things you can solve and what kinds of things are tricky (eg knapsack), which is a useful intuition to have.
It's easy to say that such tests are useless, and they probably are as a tool for judging coder skill. However when I did a few of these it did open my eyes to a few common solutions that I could apply in various places in my code. If you read through an algo book you'll probably find a few things that are a bit surprising like Kadane's algorithm, or some things that you kinda know how to do but you need the last piece of the puzzle for, eg various graph algorithms (is there a loop etc).
I'd say the main benefit is that it illuminates what kinds of things you can solve and what kinds of things are tricky (eg knapsack), which is a useful intuition to have.
I'm a bachelor student, but I trained for the international informatics olympiad in high school. These days, most of the programming I do is in web development where I do not need any of the relatively advanced algorithms I know. I do not think competitive programming has necessarily improved my web development skills, only that I write code faster. However, I do feel prepared in the sense that I would definitely recognise situations where dynamic programming/segment trees/sqrt decomposition would be of help. I thoroughly enjoyed getting the absolute most out of your CPU with C++. Sometimes I miss the obscure pointer arithmetic, bit twiddling with Fenwick trees, thinking of ways such that I can divide by const's instead of int's because the compiler can optimize those further. It's a special kind of feeling to solve problems by combining clever algorithms and pushing the hardware to what it is physically capable of.
I prepared recently for an interview like this and took my time to practice hackerrank puzzles.
I'll admit that and I found myself re-employing one of the things I learned to creatively solve a problem, however this only applies to my personal/passion project which is mostly shader-based and where algorithmic optimization knowledge like this is highly useful and applicable. In every day work however, and the kind of work I'm doing for companies 99% of the time it's not useful, as you'd expect.
I'll admit that and I found myself re-employing one of the things I learned to creatively solve a problem, however this only applies to my personal/passion project which is mostly shader-based and where algorithmic optimization knowledge like this is highly useful and applicable. In every day work however, and the kind of work I'm doing for companies 99% of the time it's not useful, as you'd expect.
I would rather be happy to spend a day or two (or a week) solving their real customer problem & go through mutual learning process. That gives both sometime to understand each other & decide.
In Europe we call that a trial period. In NL I'd expect it to be 2-3 months during which you get normal pay but your employer can let you go any time and you can also cancel any time. In Germany it's apparently more commonly 3-6 months and my contract said the cancelation term was 2 weeks which kind of defeats the purpose. As a Dutchman 6 months seems crazy to me, surely you can see if someone can walk the walk after some weeks, even if you're still onboarding them? And in the unlikely event they managed to hide their lacking skills, you tell them on their performance review, then they either improve or not, and if they don't you can let them go.
Anyway, a trial period like you said seems like a better way to learn whether someone is a good fit for the team (and whether the employer is a good fit for you) as well as technically skilled than trying to do these coding interviews that seem to be overemphasised in the USA (we do them here too, but most of the time they sound very reasonable). It's a bit odd because from what I know of USA law, you're permanently on trial and can be fired with 2 weeks' notice regardless of having an indefinite-term contract. Might as well do two-week trials with anyone that seems promising if it's that easy to let someone go.
Anyway, a trial period like you said seems like a better way to learn whether someone is a good fit for the team (and whether the employer is a good fit for you) as well as technically skilled than trying to do these coding interviews that seem to be overemphasised in the USA (we do them here too, but most of the time they sound very reasonable). It's a bit odd because from what I know of USA law, you're permanently on trial and can be fired with 2 weeks' notice regardless of having an indefinite-term contract. Might as well do two-week trials with anyone that seems promising if it's that easy to let someone go.
> It's a bit odd because from what I know of USA law, you're permanently on trial and can be fired with 2 weeks' notice regardless of having an indefinite-term contract.
It's actually easier to fire someone here than that makes it sound - many US states have what's called "at-will employment", which means that you can be fired from a job for any not-illegal reason with no notice.
It's actually easier to fire someone here than that makes it sound - many US states have what's called "at-will employment", which means that you can be fired from a job for any not-illegal reason with no notice.
I can't answer this, because I never prepped. In a sense I pre-prepped, because I competed in national level programming competitions while in school.
My feeling is that it didn't help at all, because programming competition and programming are quite different skills. But I can't say for certain.
My feeling is that it didn't help at all, because programming competition and programming are quite different skills. But I can't say for certain.
You know how some people think that fizzbuzz is useless, and how no one ever uses fizzbuzz in real life? if you google it, you'll read things like "I have never needed to write fizzbuzz in production in my entire career!" or words to that effect.
Of course, fizzbuzz is just checking if you grok some super basic programming concepts like logic, branching, and iteration.
So what if you want to know if someone knows a little bit _more_ than just the basics? It's the exact same story.
The ability to be able to work with algorithms and puzzle your way out of a problem is kind of important when you're doing some sorts of programming, especially when you need code that scales well (up OR down).
If you're really bad at it, you might write pessimal code that even overheats your regular laptop; but fortunately most people aren't quite that bad. ;-)
Of course, fizzbuzz is just checking if you grok some super basic programming concepts like logic, branching, and iteration.
So what if you want to know if someone knows a little bit _more_ than just the basics? It's the exact same story.
The ability to be able to work with algorithms and puzzle your way out of a problem is kind of important when you're doing some sorts of programming, especially when you need code that scales well (up OR down).
If you're really bad at it, you might write pessimal code that even overheats your regular laptop; but fortunately most people aren't quite that bad. ;-)
> So what if you want to know if someone knows a little bit _more_ than just the basics? It's the exact same story.
> The ability to be able to work with algorithms and puzzle your way out of a problem is kind of important when you're doing some sorts of programming, especially when you need code that scales well (up OR down).
The main issue is that many companies don't do that. They ask leetcode questions because Google does it. But they expect you to have seen the problem earlier and memorized the solution.
> The ability to be able to work with algorithms and puzzle your way out of a problem is kind of important when you're doing some sorts of programming, especially when you need code that scales well (up OR down).
The main issue is that many companies don't do that. They ask leetcode questions because Google does it. But they expect you to have seen the problem earlier and memorized the solution.
Google doesn’t ask Leetcode questions. The directionality runs the other way.
Google is very good at not asking these questions verbatim, but they're only variations of the same patterns. It's not like there are hundreds of unique concepts you can cover over the length of a typical interview slot.
Anyway my point still stands. Big companies ask FizzBuzz++ because they want to see how you solve it, if you're able to communicate and write clean code.
But unfortunately a lot of smaller ones don't invest the time that is necessary to have a good and consistent interview process. And more often than not, being able to regurgitate the solution to a problem you've already seen will definitely score you more points.
Anyway my point still stands. Big companies ask FizzBuzz++ because they want to see how you solve it, if you're able to communicate and write clean code.
But unfortunately a lot of smaller ones don't invest the time that is necessary to have a good and consistent interview process. And more often than not, being able to regurgitate the solution to a problem you've already seen will definitely score you more points.
It’s Leetcode that borrows (steals?) from Google or FB or other big tech companies. Their lack of respect for IP + candidates not adhering to NDAs has brought us to this sorry state. But then .. better it all be public, than privy solely to a handful of well-networked individuals.
I don't think it matters that much. Before Leetcode there were books like Cracking the Code Interview. It's not like Google owns dynamic programming interview questions. Some companies with a similar hiring bar ask Leetcode questions verbatim. What matters is how you do it and what you expect from candidates.
Cracking the Coding Interview is only from 2008.
Before that I remember talking about interview questions with others at college. Also joelonsoftware.com (from Joel Spolsky who later was a cofounder of Stackoverflow) had a sister site called techinterview.org and I'm sure there were other sites.
Before that I remember talking about interview questions with others at college. Also joelonsoftware.com (from Joel Spolsky who later was a cofounder of Stackoverflow) had a sister site called techinterview.org and I'm sure there were other sites.
[deleted]
What LeetCode does really, really well is have a ton of test cases and chances are you will fail one of them and will have to try again. So they may explain a problem to you, but they never tell you the edge cases. For example, question #2 is adding two numbers where each digit of the number is a node of linked list. Simple things like carrying a 1 is easy to forget, but then you need to deal with other edge cases, like what if the lists aren't the same size, etc.
So in terms of testing and finding edge cases to handle, it's really eye opening how deep you may need to go. When I do LeetCode, I try to write my program once and if I fail a test case, I consider my attempt a failure and move onto the next question.
But otherwise, it doesn't make you a better overall programmer. There's no incentive to write maintainable code, and you're incentivized to get the code running as quickly as possible by trying to shave off milliseconds, which usually don't matter as much in real world situations.
So in terms of testing and finding edge cases to handle, it's really eye opening how deep you may need to go. When I do LeetCode, I try to write my program once and if I fail a test case, I consider my attempt a failure and move onto the next question.
But otherwise, it doesn't make you a better overall programmer. There's no incentive to write maintainable code, and you're incentivized to get the code running as quickly as possible by trying to shave off milliseconds, which usually don't matter as much in real world situations.
Do you mind elaborating on why all of these test cases doesn’t make you a better overall programmer?
I think this would be a great thing to help in coming up with requirements and writing code that doesn’t crash because of edge cases or malformed inputs?
I think this would be a great thing to help in coming up with requirements and writing code that doesn’t crash because of edge cases or malformed inputs?
As an engineer you need to know how to be efficient with code. Not every single test case needs to be handled otherwise your code becomes unwieldy and brittle. Sometimes it's okay to handle an exception, write to the log so that you can detect something went wrong, and move on.
Never came up in interviews, but doing a few challenges once in a while are a nice change from my normal job. Both in topic and programming style.
The problems are small, isolated, and usually come with an irritating edge case.
The problems are small, isolated, and usually come with an irritating edge case.
Forced me to learn dynamic programming, which had been completely absent during my CS degree :(
I have 15 years working for a bunch of unknown small businesses under my belt so I'm in a similar situation. The answer for me is a resounding no it did not help in the slightest. I too actually enjoyed doing these problems personally.
I think the types of companies using these tests are the big FANG type companies and they are mostly recruiting more junior people so for them 10, 15, or 25 years experience doesn't matter. They don't care how long you've been working just if you can balance a binary tree or solve NP hard problems in under 15 minutes.
So if you are applying for a FANG type job then yes definitely but the likelihood of you being picked is actually really low. Why you ask ? Because ageism is rampant in the tech sector so the FANG companies almost exclusively hire younger candidates (with 10 years experience you're not young).
What about other smaller companies using similar tests though? That's true but I've found most small companies that do these types of tests don't hire for some reason. I think they reject a lot of employees as they think they will get better candidates. So the likelihood of anyone getting a job there is really low.
I think the types of companies using these tests are the big FANG type companies and they are mostly recruiting more junior people so for them 10, 15, or 25 years experience doesn't matter. They don't care how long you've been working just if you can balance a binary tree or solve NP hard problems in under 15 minutes.
So if you are applying for a FANG type job then yes definitely but the likelihood of you being picked is actually really low. Why you ask ? Because ageism is rampant in the tech sector so the FANG companies almost exclusively hire younger candidates (with 10 years experience you're not young).
What about other smaller companies using similar tests though? That's true but I've found most small companies that do these types of tests don't hire for some reason. I think they reject a lot of employees as they think they will get better candidates. So the likelihood of anyone getting a job there is really low.
My guess for the small companies that don't hire is that it's the incentives. If my outcomes as the hiring person are that a bad hire is a large negative, a no hire is a very slight negative, and a good hire is a slight positive (possibly even neutral), I'm going to prefer no hire most of the time. I believe this is a fairly common decision matrix.
For example:
bad hire lowers managements' opinion of my performance and can be costly to team morale, especially if company culture makes firing difficult
no hire can be blamed on lack of qualified developers rather than a competency issue
good hire is nice, but if current development team can push back on workload, that benefits the company much more than the development team
For example:
bad hire lowers managements' opinion of my performance and can be costly to team morale, especially if company culture makes firing difficult
no hire can be blamed on lack of qualified developers rather than a competency issue
good hire is nice, but if current development team can push back on workload, that benefits the company much more than the development team
> Why you ask ? Because ageism
They expect you to be M1 roles at facebook if you are in your 40s. Not compete with fresh grads.
They expect you to be M1 roles at facebook if you are in your 40s. Not compete with fresh grads.
There’s a french saying: “ qui peut le plus, peut le moins.”
If you can do difficult tasks, you’re capable of doing easier ones.
Leetcode exercises helped me make coding a data structure to solve a problem, second nature.
It gave me a problem solving confidence boost.
Day to day, it will help you much less, but it comes in handy when you hit that use case Leetcode trained you for.
Like realizing that a trie is valuable when doing a prefix name search in a Contacts application. You might have seen it in a CS class, but you won’t “believe” in it until you’ve implemented it yourself.
If you can do difficult tasks, you’re capable of doing easier ones.
Leetcode exercises helped me make coding a data structure to solve a problem, second nature.
It gave me a problem solving confidence boost.
Day to day, it will help you much less, but it comes in handy when you hit that use case Leetcode trained you for.
Like realizing that a trie is valuable when doing a prefix name search in a Contacts application. You might have seen it in a CS class, but you won’t “believe” in it until you’ve implemented it yourself.
Yes and I believe that the skills acquired made me more efficient as a programmer in certain areas - mostly optimisations and game programming.
If you're organised and manage your energy wisely I'd say you could prepare well in ~2-3 months. While a lot might not agree, I think that instead of moaning on how to avoid the technical interviews and how useless the questions are the time is better spent on focusing and getting it done.
If you're organised and manage your energy wisely I'd say you could prepare well in ~2-3 months. While a lot might not agree, I think that instead of moaning on how to avoid the technical interviews and how useless the questions are the time is better spent on focusing and getting it done.
Actually, usually the opposite.
I do more challenging work as a hobbyist than as an employee, by several orders of magnitude. The cause for that is that as a web developer the emphasis on work and capabilities is entirely around knowledge of tools. If fact it is pretty extreme to the point of people often telling you to deliberately avoiding writing original solutions to problems, even if quick and minor, if instead you can download an untested package from the internet.
See:
* https://en.m.wikipedia.org/wiki/Invented_here
* https://news.ycombinator.com/item?id=27310461
I usually excel at the leet code portion of the interview and then immediately bomb the next round of interview when I advocate for writing code, originality, and portability.
I do more challenging work as a hobbyist than as an employee, by several orders of magnitude. The cause for that is that as a web developer the emphasis on work and capabilities is entirely around knowledge of tools. If fact it is pretty extreme to the point of people often telling you to deliberately avoiding writing original solutions to problems, even if quick and minor, if instead you can download an untested package from the internet.
See:
* https://en.m.wikipedia.org/wiki/Invented_here
* https://news.ycombinator.com/item?id=27310461
I usually excel at the leet code portion of the interview and then immediately bomb the next round of interview when I advocate for writing code, originality, and portability.
A resounding no in my case, but that's because my line of work is mostly CRUD web applications. For such roles these tasks are mostly recruitment theatre.
The puzzles are enjoyable though.
The puzzles are enjoyable though.
I have to thank LeetCode for one thing: it made me realise that,
1) preparing for an interview doing LeetCode puzzles two weeks before is like studying for an exam the day before. It's worthless. If you haven't been studying the subject for months (i.e., if you haven't been working as a software engineer for years), then nothing will make you pass the exam. And even if you pass the exam (because, you were lucky and the questions in the exam were the exact bits you just studied in the week before), you don't really know the subject: you'll forget what you studied the following week.
2) I can successfully avoid companies that require LeetCode interviews. I thought I would be out of the market if I rejected such companies, but it turns out that's false! In my limited experience, around 50% of companies out there do not require LeetCode-kind-of interviews.
Don't get me wrong, I do enjoy solving programming puzzles but only on my free time, not because a company is telling me to do so.
1) preparing for an interview doing LeetCode puzzles two weeks before is like studying for an exam the day before. It's worthless. If you haven't been studying the subject for months (i.e., if you haven't been working as a software engineer for years), then nothing will make you pass the exam. And even if you pass the exam (because, you were lucky and the questions in the exam were the exact bits you just studied in the week before), you don't really know the subject: you'll forget what you studied the following week.
2) I can successfully avoid companies that require LeetCode interviews. I thought I would be out of the market if I rejected such companies, but it turns out that's false! In my limited experience, around 50% of companies out there do not require LeetCode-kind-of interviews.
Don't get me wrong, I do enjoy solving programming puzzles but only on my free time, not because a company is telling me to do so.
I'm looking at it like this: if I have to _prepare_ for an interview after being in the industry for almost 6 years, then the interview is testing different skills than what I'm using in my day to day job.
Edit: clarifying a bit: in an ideal situation, my preparation for the interview would involve going over all the work projects and reviewing how to talk about them.
Edit: clarifying a bit: in an ideal situation, my preparation for the interview would involve going over all the work projects and reviewing how to talk about them.
I see interviews a little like pitching a startup or talking about a topic on stage. It's rehearsed, lime juggling. You'll do terribly for any significant role without some practice. God knows I have to rehearse the "tell me about yourself" question every time, and switch it a little based on the interviewer.
That said, more than a week of preparation is too much.
That said, more than a week of preparation is too much.
> I can successfully avoid companies that require LeetCode interviews. I thought I would be out of the market if I rejected such companies, but it turns out that's false! In my limited experience, around 50% of companies out there do not require LeetCode-kind-of interviews.
How do you know this detailed information ahead of time? It's not a surprise companies say they'll do technical questions, but those specific to LeetCode? They don't share that.
How do you know this detailed information ahead of time? It's not a surprise companies say they'll do technical questions, but those specific to LeetCode? They don't share that.
Honestly, at this point, companies should just list it in the job description to save everyone's time.
> How do you know this detailed information ahead of time? It's not a surprise companies say they'll do technical questions, but those specific to LeetCode? They don't share that.
Not ahead of time. When one receives an offer from company X, you just ask: "you do LeetCode?"
Not ahead of time. When one receives an offer from company X, you just ask: "you do LeetCode?"
You need to have done the interview to get the offer.
How do you find those companies ahead of time?
being a software engineer for years and knowing your algorithms and data structures does not guarantee you pass leetcode…
>if you haven't been working as a software engineer for years
i would correct this to "if you haven't been switching software engineering jobs every few years", which forces you to grind leetcode for months every time.
It's always cute to see people saying nonchalantly "oh, i didn't have to do LC at all to get this (FAANG) job", and it turns out they went through the grind many times before, starting from annual internship hunts in college or competing in ICPC for years.
i would correct this to "if you haven't been switching software engineering jobs every few years", which forces you to grind leetcode for months every time.
It's always cute to see people saying nonchalantly "oh, i didn't have to do LC at all to get this (FAANG) job", and it turns out they went through the grind many times before, starting from annual internship hunts in college or competing in ICPC for years.
> i would correct this to "if you haven't been switching software engineering jobs every few years", which forces you to grind leetcode for months every time.
I know how obnoxious this is, but there are engineers out there (hi!) who can pass leetcode style coding interviews without studying because we love this stuff. I love algorithms and data structures. I'll happily discuss the relative advantages and disadvantages of vectors, linked lists, b-trees, etc for different tasks in a job interview. Or over dinner, or at the beach, or any and every time people let me get away with it. I've spent the last month or two optimising CRDTs, and I've used a bunch of data structure changes to improve performance in one of our benchmarks by 4500x (!)
The goal of the interview isn't to "force you to grind leetcode for months". They're trying to filter out candidates who would need to grind leetcode in order to explain how a hash table works. They're looking for engineers like me, who graduate at the top 15% or so CS classes. Algorithm and data structure questions are asked because lots of programmers never touch this stuff in their day jobs. The people who actually know this blindfolded are in demand because we're useful on large projects with novel systems architecture.
Thankfully, there's lots of other jobs out there where all they're looking for is a warm seat, closed jira tickets and happy customers. I go crazy doing jobs like that - so I'm glad lots of folks are around to do that work. If everyone was like me, we'd have 18 different web frameworks for every working website.
I sometimes wish we used two different names for our profession in the same spirit as "electrician" and "electrical engineer" being different roles. Then we might all waste less time applying for the wrong kinds of jobs.
I know how obnoxious this is, but there are engineers out there (hi!) who can pass leetcode style coding interviews without studying because we love this stuff. I love algorithms and data structures. I'll happily discuss the relative advantages and disadvantages of vectors, linked lists, b-trees, etc for different tasks in a job interview. Or over dinner, or at the beach, or any and every time people let me get away with it. I've spent the last month or two optimising CRDTs, and I've used a bunch of data structure changes to improve performance in one of our benchmarks by 4500x (!)
The goal of the interview isn't to "force you to grind leetcode for months". They're trying to filter out candidates who would need to grind leetcode in order to explain how a hash table works. They're looking for engineers like me, who graduate at the top 15% or so CS classes. Algorithm and data structure questions are asked because lots of programmers never touch this stuff in their day jobs. The people who actually know this blindfolded are in demand because we're useful on large projects with novel systems architecture.
Thankfully, there's lots of other jobs out there where all they're looking for is a warm seat, closed jira tickets and happy customers. I go crazy doing jobs like that - so I'm glad lots of folks are around to do that work. If everyone was like me, we'd have 18 different web frameworks for every working website.
I sometimes wish we used two different names for our profession in the same spirit as "electrician" and "electrical engineer" being different roles. Then we might all waste less time applying for the wrong kinds of jobs.
Somewhat related to your experience, does anyone else feel that the present interviewing scene is a lot more focused on algorithms rather than data structures?
Many leetcode questions rely on very specific tricks like using a fast and a slow pointer, or two pointers at opposite ends of a sequence.
So one might know about many different types of self balancing trees and which ones are best to implement a database index on disk, but these things do not come up very often in leetcode style interviews, although these are quite real problems in the realm of algorithms and data structures.
To be fair though I do not know how you can test this kind of knowledge in an interview.
Many leetcode questions rely on very specific tricks like using a fast and a slow pointer, or two pointers at opposite ends of a sequence.
So one might know about many different types of self balancing trees and which ones are best to implement a database index on disk, but these things do not come up very often in leetcode style interviews, although these are quite real problems in the realm of algorithms and data structures.
To be fair though I do not know how you can test this kind of knowledge in an interview.
> They're trying to filter out candidates who would need to grind leetcode in order to explain how a hash table works.
This is obviously a generalization rounded down. Most of my whiteboard interviews were fine, like you’re saying, but some did ask ludicrous puzzles that required specific knowledge of existing algorithms like “largest sum consecutive array”.
This is obviously a generalization rounded down. Most of my whiteboard interviews were fine, like you’re saying, but some did ask ludicrous puzzles that required specific knowledge of existing algorithms like “largest sum consecutive array”.
But you're not passing "without grinding", you're just someone who loves the grind. Good for you I suppose but it's nonetheless very far removed from the skills one would actually find worthwhile even on the highly non-trivial, greenfield projects you're talking about (which BTW are quite rare and not what most people are working on). There's a lot more to CS and software/system design than just this l33tcode stuff.
I don't love leetcode. I've spent maybe 10 minutes on the site in my entire life, because I was curious. I learned all this stuff in CS classes 15 years ago, and I've expanded my knowledge since then by playing with this stuff for work and pleasure. Maybe thats what you're calling "loving the grind"? Its not a grind for me, in the same way playing a video game I love, or reading a great book isn't a grind. Its not a grind because algorithms are beautiful.
I know and agree that algorithms knowledge is rarely useful in practice. Most professional programming work is in feature factories. But people who know algorithms well can usually also figure out react. The reverse isn't true.
> There's a lot more to CS and software/system design than just this l33tcode stuff.
I agree, though I'm curious what else is on your list? My favorite interview question was: "Here's some code we wrote with bugs and failing test cases. You have 30 minutes. See how many of the bugs you can find and fix." It takes some work to write a question like that, but its so worth it. I wish more companies invested the time into assessments like that.
> it's nonetheless very far removed from the skills one would actually find worthwhile
I literally found these skills worthwhile in my job just last week. They're usually not useful at small startups or at most product companies. But the field of programming is bigger than the set of things you and your colleagues work on.
I know and agree that algorithms knowledge is rarely useful in practice. Most professional programming work is in feature factories. But people who know algorithms well can usually also figure out react. The reverse isn't true.
> There's a lot more to CS and software/system design than just this l33tcode stuff.
I agree, though I'm curious what else is on your list? My favorite interview question was: "Here's some code we wrote with bugs and failing test cases. You have 30 minutes. See how many of the bugs you can find and fix." It takes some work to write a question like that, but its so worth it. I wish more companies invested the time into assessments like that.
> it's nonetheless very far removed from the skills one would actually find worthwhile
I literally found these skills worthwhile in my job just last week. They're usually not useful at small startups or at most product companies. But the field of programming is bigger than the set of things you and your colleagues work on.
> I know how obnoxious this is, but there are engineers out there (hi!) who can pass leetcode style coding interviews without studying because we love this stuff
____
> I don't love leetcode.
____
> I don't love leetcode.
What an arrogant comment.
> The people who actually know this blindfolded are in demand because we're useful on large projects with novel systems architecture
> Thankfully, there's lots of other jobs out there where all they're looking for is a warm seat, closed jira tickets and happy customers
As if there is no in between and only your specific type of job is in demand. Why are you so condescending towards any role that doesn't perfectly match your interests and skillset?
I guess product-focused developers, partner engineers, embedded engineers, etc are all useless because they're not working on "large projects with novel systems architecture".
In any case, this is also a false dichotomy. See this person's comment about being a PhD compiler and algorithms student yet still struggling with LeetCode: https://news.ycombinator.com/item?id=27312674
> The people who actually know this blindfolded are in demand because we're useful on large projects with novel systems architecture
> Thankfully, there's lots of other jobs out there where all they're looking for is a warm seat, closed jira tickets and happy customers
As if there is no in between and only your specific type of job is in demand. Why are you so condescending towards any role that doesn't perfectly match your interests and skillset?
I guess product-focused developers, partner engineers, embedded engineers, etc are all useless because they're not working on "large projects with novel systems architecture".
In any case, this is also a false dichotomy. See this person's comment about being a PhD compiler and algorithms student yet still struggling with LeetCode: https://news.ycombinator.com/item?id=27312674
I didn't read his comment as condescending. He said the world needs both engineers and plumbers. The world needs more plumbers than engineers, that doesn't mean that plumbers are useless.
Your example is not a good one because 1 month of practice would not be sufficient for most people to get into FAANG. See: the guy who grinded Leetcode for a year and failed to get into Google (though he did get into Amazon). If you only need to grind Leetcode for 1 month to get into FAANG, then that means you're already pretty good algorithms wise.
Your example is not a good one because 1 month of practice would not be sufficient for most people to get into FAANG. See: the guy who grinded Leetcode for a year and failed to get into Google (though he did get into Amazon). If you only need to grind Leetcode for 1 month to get into FAANG, then that means you're already pretty good algorithms wise.
He classified his work as engineering and everything else as plumbing. That is condescending.
> If you only need to grind Leetcode for 1 month to get into FAANG, then that means you're already pretty good algorithms wise
That's the point. That person should be pretty damn familiar with LeetCode questions, yet they still had to grind for a month and they're scared of it.
> If you only need to grind Leetcode for 1 month to get into FAANG, then that means you're already pretty good algorithms wise
That's the point. That person should be pretty damn familiar with LeetCode questions, yet they still had to grind for a month and they're scared of it.
> He classified his work as engineering and everything else as plumbing. That is condescending.
Most real world programming work kind of is plumbing though? We take data from over here and put it over there. We build pipes. And for good, sensible reasons, most of the pipes we make use standard fittings (REST, JSON, etc).
This is the whole point of this thread - you don't need to be good at leetcode questions to do this sort of work. I agree with that and I think we're all on the same page here.
Leetcode tests something else. That other thing is also a real skillset. I hear you that calling it engineering is condescending. But I still wish we had a good name for it..?
Most real world programming work kind of is plumbing though? We take data from over here and put it over there. We build pipes. And for good, sensible reasons, most of the pipes we make use standard fittings (REST, JSON, etc).
This is the whole point of this thread - you don't need to be good at leetcode questions to do this sort of work. I agree with that and I think we're all on the same page here.
Leetcode tests something else. That other thing is also a real skillset. I hear you that calling it engineering is condescending. But I still wish we had a good name for it..?
no... i’ve worked with a fair number of leet code all stars at startups and they are rarely capable programmers in a product development sense (taken in isolation). I would say the reason the plumber vs engineer analogy is condescending is the implication that non algo work operates with well defined problems and criteria and rarely requires any engineering. my experience has been the opposite. To solve problems effectively and pragmatically it requires understanding the system constraints in addition to the people constraints. Generally speaking even identifying the key problem and constraints is a relatively rare skill, much less selecting a solution that fits the people, budget, and timelines. I’ve since realized it’s that most software developers — algo skills or not — are simply not great engineers. Having accomplished anything rigorous like leet code helps (demonstrates diligence and effort), although it is still no substitute for a history of shipping working software and personally even if i’m tasked with interviewing a candidate using an algo whiteboard, i don’t do it.
Engineers are rarely good plumbers.
Huh? Who said there's no in-between? Or that other jobs aren't in demand, or valuable? I mean, you explicitly quoted text from me saying "there's lots of other jobs out there" - aka, other skills are in demand.
To be explicit, I love that there's so many engineers out there who are keen to do product work, or work as partner engineers or whatever. Thats really important stuff!
I personally prefer to spend my time with interesting data structures. And as luck would have it, lots of engineers really struggle with data structures and algorithms. So I do that work instead whenever I can. Why is my love for this stuff such a threat to you?
And sure, real roles usually don't have us doing one thing all day. Very wise. But, so what?
> See this person's comment about being a PhD compiler and algorithms student yet still struggling with LeetCode
PhD candidates are humans too, like the rest of us. We all struggle at some things. Algorithms are hard. Getting a PhD doesn't magically change that.
And what point are you trying to make in bringing this up? Do you think that nobody is good at, or enjoys leetcode style algorithm / data structure puzzles? I'm walking proof that thats wrong.
To be explicit, I love that there's so many engineers out there who are keen to do product work, or work as partner engineers or whatever. Thats really important stuff!
I personally prefer to spend my time with interesting data structures. And as luck would have it, lots of engineers really struggle with data structures and algorithms. So I do that work instead whenever I can. Why is my love for this stuff such a threat to you?
And sure, real roles usually don't have us doing one thing all day. Very wise. But, so what?
> See this person's comment about being a PhD compiler and algorithms student yet still struggling with LeetCode
PhD candidates are humans too, like the rest of us. We all struggle at some things. Algorithms are hard. Getting a PhD doesn't magically change that.
And what point are you trying to make in bringing this up? Do you think that nobody is good at, or enjoys leetcode style algorithm / data structure puzzles? I'm walking proof that thats wrong.
> Thats really important stuff!
Based on your previous comment, I don't believe you.
You describe your own work as "large projects with novel systems architecture". Large (Important), novel (New and difficult) and dealing with architecture (Complicated and important).
You describe other work as "all they're looking for is a warm seat, closed jira tickets and happy customers". Warm seat (Low skill/easily replaceable), jira tickets (No creativity or thinking, just follow the ticket), happy customers (Isn't this important for everyone?).
The difference in tone is massive. It's hard to believe this wasn't intentional.
Based on your previous comment, I don't believe you.
You describe your own work as "large projects with novel systems architecture". Large (Important), novel (New and difficult) and dealing with architecture (Complicated and important).
You describe other work as "all they're looking for is a warm seat, closed jira tickets and happy customers". Warm seat (Low skill/easily replaceable), jira tickets (No creativity or thinking, just follow the ticket), happy customers (Isn't this important for everyone?).
The difference in tone is massive. It's hard to believe this wasn't intentional.
Do you believe all programming work is equally difficult? I don't.
I graduated alongside some people who work on SeL4. They wrote an operating system kernel in Haskell, then used proof systems to formally prove its correctness. Then rewrote the whole thing in C and mathematically proved their C code is equivalent to the haskell code they wrote. The result is an entirely fully formally verified operating system kernel. This has never been done before, and its a massive achievement. Its a first for humanity.
I'm not sure I'm smart enough to work there. I certainly don't know enough math. I think most programmers I've worked with throughout my career aren't good enough at programming and math to work there either.
I think formally proving the correctness of an OS kernel is more difficult than implementing a B-tree. And implementing a b-tree is more difficult than styling a button in CSS. Knowing how to style a button is a more useful skill. Its important. Its valuable. But I stand by my comment. There are more people who know how to style a button in CSS, and they're given less respect, they're more replaceable and usually less well paid.
And for good reason. My friends on the SeL4 team could probably do my job if they wanted to. I don't know if I could do theirs.
The fact that most of us in this thread aren't good enough hackers to work on sel4 is something we have to live with. It doesn't make us worse people, or less deserving of love. And it doesn't mean our work isn't valuable. It is.
But if all you know how to do is style a button, you are valued less in the jobs market. Some people are actually better at programming than other people. And some jobs in our field are genuinely harder than other jobs. Hard interview questions are asked when they only want someone who's excellent to fill the role. Its absolutely not fair, but thats life.
I graduated alongside some people who work on SeL4. They wrote an operating system kernel in Haskell, then used proof systems to formally prove its correctness. Then rewrote the whole thing in C and mathematically proved their C code is equivalent to the haskell code they wrote. The result is an entirely fully formally verified operating system kernel. This has never been done before, and its a massive achievement. Its a first for humanity.
I'm not sure I'm smart enough to work there. I certainly don't know enough math. I think most programmers I've worked with throughout my career aren't good enough at programming and math to work there either.
I think formally proving the correctness of an OS kernel is more difficult than implementing a B-tree. And implementing a b-tree is more difficult than styling a button in CSS. Knowing how to style a button is a more useful skill. Its important. Its valuable. But I stand by my comment. There are more people who know how to style a button in CSS, and they're given less respect, they're more replaceable and usually less well paid.
And for good reason. My friends on the SeL4 team could probably do my job if they wanted to. I don't know if I could do theirs.
The fact that most of us in this thread aren't good enough hackers to work on sel4 is something we have to live with. It doesn't make us worse people, or less deserving of love. And it doesn't mean our work isn't valuable. It is.
But if all you know how to do is style a button, you are valued less in the jobs market. Some people are actually better at programming than other people. And some jobs in our field are genuinely harder than other jobs. Hard interview questions are asked when they only want someone who's excellent to fill the role. Its absolutely not fair, but thats life.
I think there is a certain lack of imagination you show when you say that having a good, immediately reference able working knowledge of general data structures is a prerequisite of being a good programmer.
I'm not a particularly good programmer, but I think I would never be particularly good in your estimation, because I generally remember where I read something, rather than the matter in detail. This is obviously more efficient, as you always have books available when you're doing actual work, but isn't always that great for extremely broad quizzes over a broad range of subjects.
I'm not a particularly good programmer, but I think I would never be particularly good in your estimation, because I generally remember where I read something, rather than the matter in detail. This is obviously more efficient, as you always have books available when you're doing actual work, but isn't always that great for extremely broad quizzes over a broad range of subjects.
> This is obviously more efficient, as you always have books available when you're doing actual work
To be clear, I look stuff up all the time too. But the downside of the “I can look it up” approach is that if you don’t have an intuitive grasp on various algorithms, you can’t use those algorithms as building blocks to make something else. Recently I took a btree and instead of using it an associative array I used it as a list of spans. The result let me do arbitrary inserts and deletes at arbitrary locations without linear scanning (like in a linked list) or shuffling other elements around (like in an array).
Most people can’t do that. But that’s ok - you can be an excellent product engineer without this weird knack I have. It doesn’t help me write clean CSS.
In some ways it makes me actively worse at my job. I did some client work a few years ago. I helped write an indexing system for the search box on their website. I wrote a real-time indexer which streamed changes. After I left I got feedback that nobody at the company was able to maintain the code I wrote, because they couldn’t understand how it worked. I should have just written a simple bulk indexer for them in a cron job instead of getting clever with it. My “good programmer” instincts made me a worse contributor on their team.
To be clear, I look stuff up all the time too. But the downside of the “I can look it up” approach is that if you don’t have an intuitive grasp on various algorithms, you can’t use those algorithms as building blocks to make something else. Recently I took a btree and instead of using it an associative array I used it as a list of spans. The result let me do arbitrary inserts and deletes at arbitrary locations without linear scanning (like in a linked list) or shuffling other elements around (like in an array).
Most people can’t do that. But that’s ok - you can be an excellent product engineer without this weird knack I have. It doesn’t help me write clean CSS.
In some ways it makes me actively worse at my job. I did some client work a few years ago. I helped write an indexing system for the search box on their website. I wrote a real-time indexer which streamed changes. After I left I got feedback that nobody at the company was able to maintain the code I wrote, because they couldn’t understand how it worked. I should have just written a simple bulk indexer for them in a cron job instead of getting clever with it. My “good programmer” instincts made me a worse contributor on their team.
I think your point is actually a good one. You do need deep proficiency to be able to use data structures creatively. I think your tone is just giving me an aneurysm.
My objection is that somebody who had been working with a narrow intensity in a specific field could be a very capable programmer without having the sort of general proficiency to do well in this kind of interview. That doesn't mean they are a 'product engineer'. It just means they are somewhat specialized.
My objection is that somebody who had been working with a narrow intensity in a specific field could be a very capable programmer without having the sort of general proficiency to do well in this kind of interview. That doesn't mean they are a 'product engineer'. It just means they are somewhat specialized.
The question 'what is a good programmer' comes up regularly, and I've seen answers from 'people who can make stuff that nobody understands' to 'people that make stuff nobody uses' to 'people who make stuff everyone understands and uses'.
I guess it depends on how we look at it.
I guess it depends on how we look at it.
I think the implicit difference between you and the other guy there is:
He is implicitly trying to say (just my hunch) that a lot of those leetcode interviews don't land jobs that actually need a lot of algos and data sturcutres but are just glorified CRUD boys.
What you are saying is that some jobs are indeed very hard and need some screening during interview to weed out inadequately educated candidates.
I, as a hobbyist, actually agree with you. Hobbyists like us can learn whatever we want to learn, and usually we pick tough topics (for God's sake why would I learn to make a button?) such as compilers, algorithms, operating systems, database systems and such over web development and CRUD, because the formal topics have more FUN, and we don't care about real usage (this is different from you guys -- we don't care if our toy OS get used by anyone else :D).
Damn I'd die for such jobs if they can withstand my stupidity and teach me :D
He is implicitly trying to say (just my hunch) that a lot of those leetcode interviews don't land jobs that actually need a lot of algos and data sturcutres but are just glorified CRUD boys.
What you are saying is that some jobs are indeed very hard and need some screening during interview to weed out inadequately educated candidates.
I, as a hobbyist, actually agree with you. Hobbyists like us can learn whatever we want to learn, and usually we pick tough topics (for God's sake why would I learn to make a button?) such as compilers, algorithms, operating systems, database systems and such over web development and CRUD, because the formal topics have more FUN, and we don't care about real usage (this is different from you guys -- we don't care if our toy OS get used by anyone else :D).
Damn I'd die for such jobs if they can withstand my stupidity and teach me :D
no need to be arrogant: I graduated among the 1% of my class in CS and did not pass FAANG leetcode BS recently. These interviews do not test if you know your basic CS stuff but rather if you can produce code in under a minute. For most of the leetcode questions you need to know the optimal solution by heart so you can reach their ridiculous unwritten interview deadline.
To me learning algorithms on my leisure time is the epitome of boredom. Not because I wouldn't be able to learn them but because life is finite. I'm happy that you have found your niche but don't look down on people who prioritize getting things done without knowing much about algorithms.
Although I agree that jobs that apply theoretical CS should have it clearly stated. But, contrary to your belief, some seem to just require it for the sake of it. Not because it's needed.
Although I agree that jobs that apply theoretical CS should have it clearly stated. But, contrary to your belief, some seem to just require it for the sake of it. Not because it's needed.
>who graduate at the top 15% or so CS classes.
I have totally no idea what does it even mean
is top 15% good?
In $my_country, maybe 2 "schools" of CS are good, the rest is mediocre at best (I guess) so it'd be like 1% is really good
I kinda compare edu with ELO based games like chess or even league of legends
In league of legends top 1% people are somewhat decent, but still nowhere even close to $PRO
>Algorithm and data structure questions are asked because lots of programmers never touch this stuff in their day jobs.
Why not Security then? it's way more important - poorly performing algo can be rewritten, leak cannot be reverted as easily if at all
I have totally no idea what does it even mean
is top 15% good?
In $my_country, maybe 2 "schools" of CS are good, the rest is mediocre at best (I guess) so it'd be like 1% is really good
I kinda compare edu with ELO based games like chess or even league of legends
In league of legends top 1% people are somewhat decent, but still nowhere even close to $PRO
>Algorithm and data structure questions are asked because lots of programmers never touch this stuff in their day jobs.
Why not Security then? it's way more important - poorly performing algo can be rewritten, leak cannot be reverted as easily if at all
And the damage of a security issue can be much larger than less-performing code.
Yeah I 100% agree. Ideally in a good interview you want to assess a whole range of things - data structures, security, personal background, systems design, real coding, communication skills, etc. Most people are weak in some areas, and you want to give candidates lots of opportunities to impress you.
> They're trying to filter out candidates who would need to grind leetcode in order to explain how a hash table works
Well if anything they select these people because grinding leetcode does work
Why do they presumably even need to select people who doesn't need to prepare to do a specific job? Is that because at those companies you're supposed to do that kind of work without preparation? I don't think that's anything more than what you think they think.
Well if anything they select these people because grinding leetcode does work
Why do they presumably even need to select people who doesn't need to prepare to do a specific job? Is that because at those companies you're supposed to do that kind of work without preparation? I don't think that's anything more than what you think they think.
Short answer: Yes, it's useful sometimes.
Longer answer: I always enjoyed these types of questions, and I sometimes solve them in my free time, e.g. Google's Codejam. So when I interviewed I didn't need to prepare specifically for the technical questions. Therefore it's a bit hard for me to say exactly what contribution these questions made to my skills, because it's something I've always done. Also, it's probably not relevant for 95%+ of my work. But once in a while when I do a code review, I see some convoluted piece of code that does something that can be done in 3 lines, like transforming some data from one structure to another. I feel that doing those types of programming tasks helped me find the most straightforward solution in these cases, where other people might only find more difficult solutions.
By the way, a skill that is relevant to only 5% of my work is not as bad as it sounds. I'm currently finishing reading a book about presenting information visually. Doing presentations is probably less than 5% of my work.
Longer answer: I always enjoyed these types of questions, and I sometimes solve them in my free time, e.g. Google's Codejam. So when I interviewed I didn't need to prepare specifically for the technical questions. Therefore it's a bit hard for me to say exactly what contribution these questions made to my skills, because it's something I've always done. Also, it's probably not relevant for 95%+ of my work. But once in a while when I do a code review, I see some convoluted piece of code that does something that can be done in 3 lines, like transforming some data from one structure to another. I feel that doing those types of programming tasks helped me find the most straightforward solution in these cases, where other people might only find more difficult solutions.
By the way, a skill that is relevant to only 5% of my work is not as bad as it sounds. I'm currently finishing reading a book about presenting information visually. Doing presentations is probably less than 5% of my work.
The basics are essential.
If e.g. you don't know what an hashmap or a balanced search tree is, or that you can find common items between two sequences or find a shortest path in a graph with non-negative edges in O(n log n), or that you can't (as far as we know) solve SAT, max-clique or subset-sum in polynomial time then you should not be programming software to be used by others.
Advanced algorithm design skill however is generally only useful if you are doing specifically algorithmic work.
If e.g. you don't know what an hashmap or a balanced search tree is, or that you can find common items between two sequences or find a shortest path in a graph with non-negative edges in O(n log n), or that you can't (as far as we know) solve SAT, max-clique or subset-sum in polynomial time then you should not be programming software to be used by others.
Advanced algorithm design skill however is generally only useful if you are doing specifically algorithmic work.
>then you should not be programming software to be used by others
I think that is a very broad statement that belittles the work of many developers. You don't present this as your opinion, you state this as fact. Your dictatorial attitude is exclusive and not helpful in a discussion about the usefulness of leetcode.
I think that is a very broad statement that belittles the work of many developers. You don't present this as your opinion, you state this as fact. Your dictatorial attitude is exclusive and not helpful in a discussion about the usefulness of leetcode.
I think this is too strong an opinion to hold. I think there is great value in being able to put problems you face into some sort of detailed taxonomy, and either know directly or be able to find the correct/optimal solution for those problems. To be able to do that, you do have to be exposed to what exists in the body of computer science knowledge. But while I disagree with anti-leetcode people who just claim googling is enough, I do believe it's enough to know that something is a graph/tree/optimisation/whatever problem and google a valid implementation. Having an intuition for performance and complexity is also very useful, but not knowing the exact complexity of an algorithm isn't a blocker to good work.
I think it's essential to have a good map in your mind. I don't think it's essential to have a photographic memory of every route through that map.
I think it's essential to have a good map in your mind. I don't think it's essential to have a photographic memory of every route through that map.
[deleted]
I would recommend you to read the classic books about algorithms and data structures instead (or whatever the topic is you want to learn about). In the long term it's better because:
- well, those are classic books written by people who know. You'll learn a lot of high quality material
- your future engineer peers (the good ones) will give a damm whether or not you know LeetCode puzzles inside out. They do care about you knowing the fundamentals
- LeetCode is short-term planning: bread for today hunger for tomorrow. Make your future self a BIG favour and stop doing LeetCode, and start learning from trustful sources (whatever the topic is)
- well, those are classic books written by people who know. You'll learn a lot of high quality material
- your future engineer peers (the good ones) will give a damm whether or not you know LeetCode puzzles inside out. They do care about you knowing the fundamentals
- LeetCode is short-term planning: bread for today hunger for tomorrow. Make your future self a BIG favour and stop doing LeetCode, and start learning from trustful sources (whatever the topic is)
> LeetCode is short-term planning: bread for today hunger for tomorrow
Considering it helps you getting into some of the highest paying companies in software engineering, I don't agree with that part. From what I understand getting into FAANG is harder than staying in them, in which case it makes sense to grind leetcode, and once you're in focus on classic books about algorithms and data structures.
Considering it helps you getting into some of the highest paying companies in software engineering, I don't agree with that part. From what I understand getting into FAANG is harder than staying in them, in which case it makes sense to grind leetcode, and once you're in focus on classic books about algorithms and data structures.
If you're fresh out of school, sure, all you have is rote memorization and you're competing as such.
If you're an engineer with years of experience, just go and apply.
FAANGs aren't impossible to get into
And to be honest, they're not the highest paying or best jobs either.
I know smaller companies that pay more, give more, have more free time and you're closer to product/service/customer and more engaged - some even pay you to take vacation and reward you for things you do outside of work.
If you're an engineer with years of experience, just go and apply.
FAANGs aren't impossible to get into
And to be honest, they're not the highest paying or best jobs either.
I know smaller companies that pay more, give more, have more free time and you're closer to product/service/customer and more engaged - some even pay you to take vacation and reward you for things you do outside of work.
Do you have any recommendations on classic books about algorithms and data structures? I would be interested in checking some of them.
Any recommendation for these classic books you mentioned?
I don't want to publicize any website in particular, but if you Google "best books algorithms", you'll probably get the ones everyone knows about:
- Introduction to Algorithms by Thomas H. Corman
- Algorithms by Robert Sedgewick & Kevin Wayne
- The Algorithm Design Manual by Steve S. Skiena
- Data Structures and Algorithms. Aho, Ullman & Hopcroft
- ...
Simiarly, just Google "best books software engineering".
- Introduction to Algorithms by Thomas H. Corman
- Algorithms by Robert Sedgewick & Kevin Wayne
- The Algorithm Design Manual by Steve S. Skiena
- Data Structures and Algorithms. Aho, Ullman & Hopcroft
- ...
Simiarly, just Google "best books software engineering".
Thank you!
leetcode classic books are are ctci and elements of programming interviews. I really enjoyed the latter, don't let the name distract you.
Introduction to Algorithms by By Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest and Clifford Stein (https://mitpress.mit.edu/books/introduction-algorithms-third...)
For me it was brushing up on the basics that helped (by following the theoretical classes). Both to be prepared for the interview and for general skill.
I find it's usually a signal that:
* The company is cargo culting Google or it is Google, in which case it's cargo culting hunting down people like Larry and Sergey.
* The company makes decisions based upon safety in numbers. "Everybody" interviews this way, so if you're worried about justifying your process in future, it's a safe option.
* If this system selected me for a $200k / year job, it can't be all that bad.
* It does correlate somewhat with ability.
* The company is cargo culting Google or it is Google, in which case it's cargo culting hunting down people like Larry and Sergey.
* The company makes decisions based upon safety in numbers. "Everybody" interviews this way, so if you're worried about justifying your process in future, it's a safe option.
* If this system selected me for a $200k / year job, it can't be all that bad.
* It does correlate somewhat with ability.
Also it's a standardized test to prevent bias. HR could've pushed for it too.
LeetCode is that stuff you cram into your head for an exam, spew onto a page, and then have forgotten by the time you are walking out of a room.
So, no.
So, no.
I'm working with the hiring without whiteboard interviews list here, and linked it up to available jobs. It's a bit tough to target it for EU, so if anyone has a company that fits, please let me know
https://www.arbeitnow.com/hiring-without-whiteboard
https://www.arbeitnow.com/hiring-without-whiteboard
There's also curated list here: https://github.com/poteto/hiring-without-whiteboards
yep, that's the list that I use as a source
I feel like they do but I haven’t “measured” it. They can be a great way to quickly learn a new language for sure though. Practice is good in basically all domains and these problems can be fun so seems good.
I interviewed with 3 companies recently, and all had some kind of coding test, although not all of them were Leetcode-style problems. But I did practise on Leetcode before, and it was useful for passing the interviews.
However, in my experience those kinds of problems don't make you a better developer. They are almost the opposite of what you do day to day as a developer.
I've written more about it here: https://henrikwarne.com/2021/04/19/recruiting-software-devel...
However, in my experience those kinds of problems don't make you a better developer. They are almost the opposite of what you do day to day as a developer.
I've written more about it here: https://henrikwarne.com/2021/04/19/recruiting-software-devel...
Apparently, I have a very different perspective than most! I get the criticism, that was me for a long time, but nowadays I decided to give it a fair shot and have made up my mind. Disclaimer: I never got a job with them, but do practice them from time to time.
What it doesn't train:
- Software architecture (do Factorio and/or systems design interview questions)
- Huge codebases
- Library integration
- Volume (aka lots and lots of code)
What it does train (YMMV):
- Precision: The goal is to write bug free code, this used to be a weakness of mine and now I'm less weak at it
- Simulating code in your mind: related to precision, I use the debugger less and my mind more.
- Finding ways to like the grind: nowadays I see data structures as micro-organisms or plants, they're so much fun to visualize that way! It taught me something about my personality (fantasy, whimsicality are my jam). If you know Vihart, that's how I think about data structures now. Because of this "epiphany" I suddenly find a whole new mode of liking abstract things that I previously didn't like that much.
- Learning how to make small programs that do something meaningful-ish and reason about them. Opening a file and doing a for loop and do some manipulation is IMO not meaningful enough. Tweaking a binary tree is, because it simply doesn't feel trivial. Normally I have this feeling when I look at large codebases.
- Practicing space/time complexity skills. This is super important, there have been moments where I really needed to rely on these skills because other engineers did some dumb things and where hogging the network or the CPU of the user's browser :/
- Muscle memory for the standard APIs of a language. My interview language is in JavaScript (on purpose because I'm a web dev). It's much easier now for me to write a map or a reduce. Before this, I needed to consult the docs, now I don't. I've subconsciously learned a lot of small little templates that allow me to write code quickly yet accurate.
- There have been weird moments where I did need to rely on data structures (e.g. creating an efficient trading bot or making a computer graphics application for drawing on a canvas in a performant way)
---
Is this the best way to get better at coding? No. But given that it does have some benefit to me and it might allow me to double or triple my income, why not try it? What I also like about it is that: if you know leetcode, then 50% of the companies open up to you. The other 50% are way more heterogeneous and the interview process feels too random. From the position I'm in, randomness is usually a bad sign (and sometimes it means I don't need to do anything to pass the interview, but that only happens once every 50 companies I apply for).
What it doesn't train:
- Software architecture (do Factorio and/or systems design interview questions)
- Huge codebases
- Library integration
- Volume (aka lots and lots of code)
What it does train (YMMV):
- Precision: The goal is to write bug free code, this used to be a weakness of mine and now I'm less weak at it
- Simulating code in your mind: related to precision, I use the debugger less and my mind more.
- Finding ways to like the grind: nowadays I see data structures as micro-organisms or plants, they're so much fun to visualize that way! It taught me something about my personality (fantasy, whimsicality are my jam). If you know Vihart, that's how I think about data structures now. Because of this "epiphany" I suddenly find a whole new mode of liking abstract things that I previously didn't like that much.
- Learning how to make small programs that do something meaningful-ish and reason about them. Opening a file and doing a for loop and do some manipulation is IMO not meaningful enough. Tweaking a binary tree is, because it simply doesn't feel trivial. Normally I have this feeling when I look at large codebases.
- Practicing space/time complexity skills. This is super important, there have been moments where I really needed to rely on these skills because other engineers did some dumb things and where hogging the network or the CPU of the user's browser :/
- Muscle memory for the standard APIs of a language. My interview language is in JavaScript (on purpose because I'm a web dev). It's much easier now for me to write a map or a reduce. Before this, I needed to consult the docs, now I don't. I've subconsciously learned a lot of small little templates that allow me to write code quickly yet accurate.
- There have been weird moments where I did need to rely on data structures (e.g. creating an efficient trading bot or making a computer graphics application for drawing on a canvas in a performant way)
---
Is this the best way to get better at coding? No. But given that it does have some benefit to me and it might allow me to double or triple my income, why not try it? What I also like about it is that: if you know leetcode, then 50% of the companies open up to you. The other 50% are way more heterogeneous and the interview process feels too random. From the position I'm in, randomness is usually a bad sign (and sometimes it means I don't need to do anything to pass the interview, but that only happens once every 50 companies I apply for).
I did my engineering in Electronics and Communication, knew programming but was not that much into algorithms. When I started leetcoding for interview prep, at the start I found it hard, but now I actually find it interesting. Also was able to apply some of the algos to my actual work. So all in all leetcoding actually improved my skill.
Take your CS degree and get an MBA.. operate a higher level for
Higher pay.
Let’s say you have some interesting challenges in a new space in deep learning and you like to hire people who can ramp up and learn the area relatively quickly.
Or let’s say you have a massive set of services you need to integrate with to solve your next set of business commitments for the coming year.
How do you hire folks who truly have the motivation and speed of learning to solve these areas on your team? Both are proprietary subject matters. Both haven’t really been done before and require a tenacious self-starter.
In that sense leetcode + team player/leadership qualities might make more sense.
Yeah it’s CRUD more or less 80% of the time re: code. But the ability to tackle ambiguity in an overwhelmingly large space and still be inventive: that’s what’s being tested. And as you get more experienced the technical assessment skews to system design which is also a good bar for just - how do you consistently simplify technical and organizational complexity?
It’s why FAANG + unicorns’ compensation is high. It’s a correctly-priced asset in the market. To the business these are important functions.
Does it have anything to do with pure programming for having fun’s sake? Why Linus created Linux? Only loosely.
Or let’s say you have a massive set of services you need to integrate with to solve your next set of business commitments for the coming year.
How do you hire folks who truly have the motivation and speed of learning to solve these areas on your team? Both are proprietary subject matters. Both haven’t really been done before and require a tenacious self-starter.
In that sense leetcode + team player/leadership qualities might make more sense.
Yeah it’s CRUD more or less 80% of the time re: code. But the ability to tackle ambiguity in an overwhelmingly large space and still be inventive: that’s what’s being tested. And as you get more experienced the technical assessment skews to system design which is also a good bar for just - how do you consistently simplify technical and organizational complexity?
It’s why FAANG + unicorns’ compensation is high. It’s a correctly-priced asset in the market. To the business these are important functions.
Does it have anything to do with pure programming for having fun’s sake? Why Linus created Linux? Only loosely.
leetcode style interviews do not test the skills you need for what you describe, those skills come with experience, not by practicing leetcode until you can produce solutions in under a minute.
He literally explained why they make sense. People who can "just do it" and learn fast and get it done.
leetcode trains you to prematurely optimize and cannot teach you the skills that come with years of experience, which is what you need to be able to do what the above describes.
No it doesn't lol. "Don't prematurely optimize" is like a single sentence that you keep in your mind. Being good at leetcode is probably lightly correlated at most (college nerds), with premature optimizers.
Of course years of experience matter, that's why they also care about experience and have you talk about design a bit. But mostly leetcode.
Of course years of experience matter, that's why they also care about experience and have you talk about design a bit. But mostly leetcode.
lol gives away you are probably in your mid-20s. That's OK, you'll understand what I mean as you enter your 40s.
it doesn’t matter that you can solve them, you need to be able to solve them in under a minute while your interviewer is constantly distracting you. so basically, it has nothing to do with being able to build software.
I have been writing code for more than 25 years now and graduated top of my class in CS. I also have a degree from a US ivy league school on top of my CS degree from europe. I developed and launched 4 succesful products. I won awards for my work and I’m a semi celebrity in my niche.
I recently went through several FAANG loops and did not pass their retarded leetcode questions. each time i had the feeling it had to do with not being FAST enough or not producing the EXACT solution the interviewer wanted.
what is funny is that I got one interview where the guy asks me to solve a problem that gayle mcdowell (cracking the code interview) spent ONE HOUR solving in a video provided as “training material” to candidates, YET they wanted me to do it in a few minutes WHILE EXPLAINING what i was doing.
the above is why I no longer participate in coding interviews.
for all those who think people who pass these interviews are “better” engineers: this particular FAANG has shipped broken SaaS products for years, despite having the “smartest” engineers on the payroll.
I have been writing code for more than 25 years now and graduated top of my class in CS. I also have a degree from a US ivy league school on top of my CS degree from europe. I developed and launched 4 succesful products. I won awards for my work and I’m a semi celebrity in my niche.
I recently went through several FAANG loops and did not pass their retarded leetcode questions. each time i had the feeling it had to do with not being FAST enough or not producing the EXACT solution the interviewer wanted.
what is funny is that I got one interview where the guy asks me to solve a problem that gayle mcdowell (cracking the code interview) spent ONE HOUR solving in a video provided as “training material” to candidates, YET they wanted me to do it in a few minutes WHILE EXPLAINING what i was doing.
the above is why I no longer participate in coding interviews.
for all those who think people who pass these interviews are “better” engineers: this particular FAANG has shipped broken SaaS products for years, despite having the “smartest” engineers on the payroll.
it doesn’t matter that you can solve them, you need to be able to solve them in under a minute while your interviewer is constantly distracting you. so basically, it has nothing to do with being able to build software.
I realized that my issue with this style of interview are not the questions, but this exactly. I can solve lots of Leetcode problems, some just take me longer than others.
It’s even worse when the interviewers behave like you described. Most I’ve met, luckily, were cool and just followed what I was doing eventually asking some questions and sometimes giving me pointers; the worse I’ve found would not accept any solution I proposed and would keep asking “how about not using extra space or how about solving in O(1) or how about you solve this in 5 seconds”. So freaking annoying.
I realized that my issue with this style of interview are not the questions, but this exactly. I can solve lots of Leetcode problems, some just take me longer than others.
It’s even worse when the interviewers behave like you described. Most I’ve met, luckily, were cool and just followed what I was doing eventually asking some questions and sometimes giving me pointers; the worse I’ve found would not accept any solution I proposed and would keep asking “how about not using extra space or how about solving in O(1) or how about you solve this in 5 seconds”. So freaking annoying.
exactly, I had one interviewer who wanted me to write a function to divide x by y without using / or %. I proposed the obvious solution with a loop, which he quickly dismissed. I then proposed to try to do something with bit masks and shifts which he dismissed as well: "I don't think we'll be able to do that in the time we have, I never saw someone do that before in the time we have, etc". He then wanted me to guess that I should use a binary search for this. The resulting code was convoluted and hard to understand and made no sense to me. He had to drag me through it. The experience had nothing to do with how I develop software and write code on a day to day basis.
Could anyone summarize for me what modern interview prep is like? Last I heard, it’s “learn Java only for the interview” then grind leetcode for 3 months. Whiteboarding probably doesn’t matter during a pandemic but that means you need correct runnable code to enter into some web ide?
Reddits cscareerquestions sub seems obsessed with leetcode. As a Canadian my experience may differ from Americans, but for the jobs I applied to I don't think it often helped. Then again these were not faang jobs which are another Reddit obsession.
No
I found that preparing for LeetCode type of interviews improved my skills of solving LertCode type of problems and did not change how I performed in my day to day job. IMO the type of work is so dramatically different that I don't think they will bring any value, maybe except in the cases where you're dusting off some language you haven't been using in a while.
Should I treat them as brain gymnasiums such as Number Theory which few people ever needs for their career, but could improve problem solving ability in general?
From my understanding those brain gymnasiums make your brain work harder and you have to concerntrate for longer period to get them solved. They also open new ways of thinking about the world.
From my understanding those brain gymnasiums make your brain work harder and you have to concerntrate for longer period to get them solved. They also open new ways of thinking about the world.
I see some comments saying that Leetcode is not related to real life questions. Just curious how do I get real life questions, or to be more realistic, how do I get simpified real life questions? Is CodeWar a better alternative?
A recently completed starter task for the project you are working on usually is a good idea. However, you need to make sure that the task is truly a starter task, not just a task that doesn't require much code. It is easy to create a task that requires too much time to do.
As for simplification, I think it's a trap and not worth thinking about. The problem with LeetCode is that it's the result of oversimplifying. People focused too much on a "hard" part of software engineering, that, over the years, they filtered out all of the other skills that matter: making sure that the new functionality makes sense, figuring out how to make code testable, reading other people's code, already knowing existing protocols, making progress even if you don't know everything, knowing when the quality isn't good enough, and asking good questions.
As for simplification, I think it's a trap and not worth thinking about. The problem with LeetCode is that it's the result of oversimplifying. People focused too much on a "hard" part of software engineering, that, over the years, they filtered out all of the other skills that matter: making sure that the new functionality makes sense, figuring out how to make code testable, reading other people's code, already knowing existing protocols, making progress even if you don't know everything, knowing when the quality isn't good enough, and asking good questions.
I came into software as a dropout. I'll spare you the back story, but it was for good reason. I dropped out junior year.
1. I think professionally testing algorithm knowledge is fine, but it needs to be one and done. I want a certification and I don't want to have to do it again.
2. This knowledge is largely useless in actual programming. It does teach me how to interrogate data structures and how algorithms work well with certain data structures. This kind of knowledge will only be relevant later in your career and at a certain type of company though.
So, am I better? Yes, I think I am, but I don't think I'd thank algorithms for that. I thank an innate desire to learn that happened to be briefly applied to algorithms and data structures. The hyperfocus on algorithms misses the forest for the trees.
1. I think professionally testing algorithm knowledge is fine, but it needs to be one and done. I want a certification and I don't want to have to do it again.
2. This knowledge is largely useless in actual programming. It does teach me how to interrogate data structures and how algorithms work well with certain data structures. This kind of knowledge will only be relevant later in your career and at a certain type of company though.
So, am I better? Yes, I think I am, but I don't think I'd thank algorithms for that. I thank an innate desire to learn that happened to be briefly applied to algorithms and data structures. The hyperfocus on algorithms misses the forest for the trees.
LeetCode didn't exist back when I was in high school doing programming contests. The team of 3 people I was part of did a few rather unusual things in part because of my exposure to Linux at the time, namely making use of tools like yacc and bision to quickly come up quickly with concise solutions to a number of the string parsing problems we encountered in the contests.
I've never felt the need to explicitly study for interviews. Given the wide range of programming tasks I've encountered over the years, along with countless hours spent reading programming books and magazine articles, I know enough to be dangerous, and where to look when I'm not sure. Simply being aware that there is somewhere to to look is half the battle.
I've never felt the need to explicitly study for interviews. Given the wide range of programming tasks I've encountered over the years, along with countless hours spent reading programming books and magazine articles, I know enough to be dangerous, and where to look when I'm not sure. Simply being aware that there is somewhere to to look is half the battle.
Useful for refreshing concepts I'd learnt/coded at Uni, 20 years ago and not used since ... which isn't as snarky as it sounds.
Basically with a bit of drilling, a competent programmer should be able to get the hang of those questions, and maybe the fact you can get competent at doing tricky, niche things is a useful indicator.
I wouldn't say doing leetcode would in anyway make you better at writing clean, well structured code, which is what we typically interview for in non FAANG. Probably does help sharpen your cracking out gnarly inner loop type coding skills i.e. better at writing a difficult function, doesn't do anything for how you would write the rest of the program.
Basically with a bit of drilling, a competent programmer should be able to get the hang of those questions, and maybe the fact you can get competent at doing tricky, niche things is a useful indicator.
I wouldn't say doing leetcode would in anyway make you better at writing clean, well structured code, which is what we typically interview for in non FAANG. Probably does help sharpen your cracking out gnarly inner loop type coding skills i.e. better at writing a difficult function, doesn't do anything for how you would write the rest of the program.
It prepared me for leetcode interviews but I've still never encountered many of the problems they write problems for in the real world.
As I'm doing some Hackerrank/LeetCode exercises, I'm actually enjoying solving these puzzles. I'm wondering if anyone who went through this prepping for an interview ended up being technically better overall. I know that I rarely needed this kind of skill in my career, but also I'm wondering if there were cases where I did need them and I didn't know.
Cheers!