I never understood the hate Leetcode gets. Whenever you change jobs, chances are you'll encounter some new technology you do not yet know. You'll have to prepare for it. Algorithmic problem solving is like riding a bike, you only have to learn it once. While it's possible that no one will write Kotlin in a decade, it's very unlikely that knowing how to do a topological sort will go out of fashion.
The counter arguments often mentioned against Leetcode I often hear:
- You are often asked stuff that took PhDs years to figure out: This usually shows up only in Hard questions, and badly designed ones at that. In my experience, Medium ones are usually solvable with solid algorithmic knowledge. It is also usually that maximum difficulty people encounter during their work.
- It discriminates against women/minorities: I don't live in a very diverse country, so I don't know anything about the minorities part, but in my career, I've encountered plenty of women who were as good or better than men in solving algorithmic issues. It does filter people, because it's designed to filter people, but I've never found it discriminatory along gender lines.
- It discriminates against poor people: You're a programmer, you are not poor. Even if you were, the few weeks of time investment it requires is usually offset by the higher salary you can ask for. Think of it as an investment in your future. Or if you are not a programmer, the amount of skills you need to learn to get your first programming job is usually far excess of just learning leetcode.
If you as a normal software engine write a topological sort algorithm
you likely failed your job. Your job is to use existing topological sort
algorithms designed by people specialized in that area, implemented by
people which are specialized in implementing and fine tuning algorithms
(it's its whole own field of expertise, and overlooked field tbh.).
Or to reformulate it the job of an software engineer is to reuse existing
components and basic building blocks to create larger components or programs, but it's not your job to create new basic building blocks. The job requires
you to have an understanding of such components but not to memorize them.
Sure sometimes you have to create basic building blocks, but then doing so from memory is nearly always the wrong approach.
Leet code is not at all representative for "how well someone is suited for given job" (for most companies/offers, there always are exceptions).
While wasting everyone's time.
And favoring certain skill sets/problem solving approaches (memorization) over others (adaptability, deep generic understanding), at least in the way they tend to be implemented. It also strongly discriminates again anyone with exam anxiety and similar. Be aware that the points mentioned here apply to common leet code based screening (especially automatized screening), but not necessary asking people to solve some code problem in interviews (if you handle that appropriately).
This hints at an (IMO underrated) skill: being able to look at a problem and decomposing it into sub-problems that are solved by known algorithms. Topological sort is a pretty fundamental building block for solving many problems that involve dependencies between components, since those can be modeled as a directed graph.
Knowing how to write a topological sort isn't the key skill here (although, I would argue, it's a good skill to know, and it's probably much simpler than you're imagining). The key skill is knowing that a topological sort will solve the problem, or perhaps it's simply knowing that "finding an order of actions that satisfies these dependency constraints" is called a topological sort.
I have always been under the impression that the goal of leetcode-style interviewing was actually to measure a candidate's ability to recognize what algorithmic tool to use, rather than to measure a candidate's ability to implement an algorithm from scratch. When I've been in the position of interviewing in the past, I've always been more interested in that problem-solving approach than in the actual code.
In my experience, most software jobs are 90% figuring out the problem that needs to be solved and coming up with tactics for solving the problem, and 10% actually implementing those tactics. In that context, investigating the ability of a candidate to analyze problems seems like an excellent interview technique.
> If you as a normal software engine write a topological sort algorithm you likely failed your job.
No, because the way topological sorts show up in many systems is not amenable to a library. Sometimes you will have unusual caching strategies available to you or the topological sort needs to work with some weird asynchronicity that no library handles well.
Even if you do just need a topological sort it's often not worth bringing a library in. It's a simple algorithm implementable in a few lines of code in many languages.
>If you as a normal software engine write a topological sort algorithm you likely failed your job. Your job is to use existing topological sort algorithms designed by people specialized in that area, implemented by people which are specialized in implementing and fine tuning algorithms (it's its whole own field of expertise, and overlooked field tbh.).
What standard library ships with it ? I can remember multiple times I've need to implement topological sort in various languages - mostly to detect if there are cycles between dependencies or order actions, it's rather simple, introducing a third party lib for such code is in the leftpad territory and writing a generic interface to generalize graphs would be clunky in a lot of languages.
It might come up in unexpected ways, say cache propagation, or a cyclic dependency in your favorite IoC container. Or in many other possible scenarios that are all real and I see them almost every day
If you're a software engineer and you don't know what topological sort is then you don't know how any sort of dependency structure works and that's a big part of your day to day. Implementing topological sort is a few lines of code and anyone should be able to do it
> It discriminates against poor people: You're a programmer, you are not poor. Even if you were, the few weeks of time investment it requires is usually offset by the higher salary you can ask for. Think of it as an investment in your future. Or if you are not a programmer, the amount of skills you need to learn to get your first programming job is usually far excess of just learning leetcode
This comment does not acknowledge the experience experience of many people who grew up poor or put themselves into major debt because they didn’t receive financial support or live in economically disadvantaged areas.
I grew up poor and took out massive education loans to pay for my education. I still pay off those debts today. Does that mean I consider myself poor now? No, but my economic disadvantage has made me need to work much harder in other areas and I’ve needed to prioritize many other things over leetcode. I haven’t had the luxury of spending multiple hours a week to get “good” at leetcode
So yes, I’d argue that leetcode is responsible for gatekeeping people out of jobs who don’t have time/money to grind on it.
Leetcode prep is less time and money than getting a degree in anything. Anybody with sufficient interest can find the time to get to a basic competence level in leetcode and system design. Getting real life experience or a college degree has got to be the bigger gate.
> Anybody with sufficient interest can find the time to get to a basic competence level in leetcode and system design.
OK. But, it has nothing to do with interest. It's time (which may already occupied with working long hours or a second job to pay off debt or looking after family). Who has extra time to perform leetcode tasks that have no alignment to day-to-day tasks and expectations. People with the luxury of free-time, thus attracting a certain type of profile.
> Getting real life experience or a college degree has got to be the bigger gate.
You don't just get a job doing leetcode. The experience and/or degree are table-stakes. The OP post is asking folks who likely already have experience or a degree related to the field of software engineering.
Interest in getting a job that requires it, not interst for its own sake. The number of people who cannot find 1-2 hours a week over the course of a year to prepare despite an interest in doing so is vanishingly small. Yes you might struggle to find the time if you have two jobs and two toddlers, but kids grow up and the ROI is clearly there. Leet code sucks. But its a solid and relatively cheap (time and money) investment, and in particular is cheaper than any other of the (not quite as) high paying jobs I can compare it to.
Knowing why one would use a "topological sort" is (might be?) important. There is almost nothing important about knowing how to do one. This is the failure of leetcode.
I would take 1 person who can understand problems at a high level and Google the minutia over 10 that try to remember how to re-balance a tree and confidently introduce off by one bugs.
> I would take 1 person who can understand problems at a high level and Google the minutia over 10 that try to remember how to re-balance a tree and confidently introduce off by one bugs.
> it's very unlikely that knowing how to do a topological sort will go out of fashion
It is also vanishingly unlikely I’ll ever have to do a topological sort. 15 years and counting. Meanwhile, being able to read and understand a bit of kotlin has proven useful several times.
Topological sort implicitly comes up anytime you implement a depth-first search on a graph that isn’t 100% guaranteed to be cycle-free. Checking for cycles in a depth-first search is basically the same as topological sort. Having to implement something like that comes up roughly every 3 years for me.
> how often are you actually writing an implementation vs. calling a method from a graph library?
Every time. Because of several reasons: 1. Transforming the graph (which is usually not explicitly represented, but rather the result of navigating entities using some existing API) to the representation required by the graph library is more complex than just implementing the search and the cycle check yourself (it's usually just insertion into a set and checking if the element was already contained). 2. Often there are additional actions you want to take during the traversal, and diagnostics you want to output, which is either impossible or difficult/convoluted to integrate with a graph library. 3. Dependencies incur maintenance cost and should not be added lightly. Adding a graph library just for a simple topological sort is usually not a good trade-off.
Knowing how topological sort is implemented is necessary to make the right design decision here. Otherwise you end up adding a big dependency and convoluted glue code just because you didn't realize how straightforward and maintenance-friendly a custom implementation tailored to the present use-case could be.
Or, in other cases, you may end up implementing a custom algorithm without realizing that it actually corresponds closely to an existing graph algorithm (which would help you double-check your implementation or replace it with an existing library).
> I don't live in a very diverse country, so I don't know anything about the minorities part
I love how you lead with this and then drive a car into every single wall about this issue. Its like the most predictable meme and you are it.
You've encountered women.... proportionally? What stage of the career, entry level, lead?
The only point here is about time, and time commitment available. Forget about the supporting culture you were raised around for "grinding for the job you want", that method discriminates against competent people who have other obligations. When people are interviewing for a job, they are interviewing for many jobs at other potential places, so there is no way to determine passion or seriousness by their willingness to focus on studying for your job, it only determines who has things they can neglect. And basically that is just single men without debts or other distractions.
Many times minorities have other distractions, in your non-diverse country a minority would likely have a time limit to find a job to maintain a visa or comply with an asylum application. Women often have other distractions as well, with only some slim slivers of time being similar to the single men.
Hope that illuminates something for you, or others.
Yeah I don't buy your argument. I don't think leetcode questions are perfect, I also agree that women/minorities have extra distractions and hurdles which as a society we should look to lessen and improve.
However, I find these distractions are much stronger correlated with a person's economic situation rather than race or gender. Also, I agree with the parent of your comment where the time spent with leetcode is a small fraction of the time needed to learn CS fundamentals, which are usually required for the job. Especially when you're not expected the candidate to KNOW the answer, you're observing HOW they solve the answer.
I've failed candidates that memorized solutions, but could explain how they got there. And I championed ones that didn't get the optimal solution, but had a good thinking process that they could properly communicate to me. Guess which candidate spent more time studying?
> However, I find these distractions are much stronger correlated with a person's economic situation rather than race or gender.
Which changes nothing when its a 99% correlation by race and gender.
Its not a dissertation, its acknowledging that something has the result of marginalizes groups disproportionately. Disproportionately means that it doesn't affect everyone, it doesn't 'affect all women and all minorities. It means disproportionately affects, due to their disproportionate representation in these distracting economic circumstances, so lets do something else instead since the reasons why it affects them isn't going to change in our lifetime.
> Also, I agree with the parent of your comment where the time spent with leetcode is a small fraction of the time needed to learn CS fundamentals
If people got formal education they took the risk for that allotted time. It doesn't matter if a time-discriminatory process takes less time, its an additional and unnecessary risk for the candidate.
If people didn't get formal education then they didn't take the risk for the allotted time, they just have exposure to the tasks the company needs. That alone suggests more inspiration is needed to have a different way of determining their compentency.
I love algorithmic challenges and would even compete while in uni and coincidentally last year I even had to do several topological sorts at my company. But I actively hate and avoid leetcode type interviews.
For me it's the time pressure while someone is looking over your shoulder and them asking you to talk and explain your thinking.
I just panic and close up, I need mental space to come up with an algorithmic solution and can't do that if you want me to "talk through my process". Leave me some time to solve the issue and I'll come back to you with a solution, just like it is in a real job.
I enjoy programming challenges and do them for fun and I see their value as an exercise in thinking, but the problems I solve with them aren’t a reflection of the real world work I do or have done. I’ve never needed a topological sort in my day jobs.
If a company asks me to complete a leetcode style code challenge they are not getting a representation of the work I’ll do day to day, so I always make a point in an interview to say, “I may have passed your test but please don’t judge me on that basis, let’s discuss my work”.
They’re garbage as a hiring tool for lots of reasons, but mostly it comes down to the reality that they just aren’t representative by any stretch of the imagination.
This is hugely Silicon-Valley-centric. There are millions of skilled programmers outside that culture, who have never had a six-figure salary, many who have never even worked for a tech company. Just regular (white-collar) working people with the same kinds of burdens that the average American (or European, or person from any other developed country on the planet) has to deal with.
In short, this shows how much you live in a bubble and don't understand what life is like outside of it.
If you have not worked on any topological sorting for the past 15 years you will not remember how to do it under the pressure of time. in a new language etc. you will need some time to remember the correct algorithm, how to adapt the data structures to the current language you are working on etc. And unless the problem is specified exactly as such, the most difficult thing is to come up with the idea that a given problem can be formulated as a topological sort problem, that is 80% of the solution. I am sure that most Experienced engineers when given this problem as a home task will come up with a correct solution even if they fail the time pressured leetcode.
I've been programming computers since I was 10. I am almost 40. I've been working professionally for about 15 years now. I've never done leetcode. But I have done stuff like (hackerrank) and I have to spend an evening proving I know how to write some arbitrary problem that I will never encounter anything close to in the position I am applying for. I can solve them. But I feel like I am wasting my time when I do it for the 10th time. I now refuse to do all coding tests. I have a github and a company page with my work and if that isn't sufficient, then so be it.
As for the counter arguments:
> You are often asked stuff that took PhDs years to figure out: This usually shows up only in Hard questions, and badly designed ones at that. In my experience, Medium ones are usually solvable with solid algorithmic knowledge. It is also usually that maximum difficulty people encounter during their work.
Software engineer are not computer scientists. 95% of my time is normally gluing libraries together to build a product. Most of the time I am just implementing business processes in code and I don't really need to implement anything fancier than a for loop. What is normally more important is implementing the (correct) patterns, good practices and managing changing requirements, implementing a database schema that makes sense.
The sort of problems in leetcode won't help you do any of this. All it proves is that you can solve some arbitrary and unrealistic problem.
> It discriminates against poor people: You're a programmer, you are not poor. Even if you were, the few weeks of time investment it requires is usually offset by the higher salary you can ask for. Think of it as an investment in your future. Or if you are not a programmer, the amount of skills you need to learn to get your first programming job is usually far excess of just learning leetcode.
Many of the people grinding things like l33tcode are looking to get a web development job so they don't have to work frying chicken in the local KFC knockoff. Building most websites doesn't need to learn a bunch of algorithms. What you do need to have is a solid understand of HTML, CSS, JavaScript and how things likes HTTP work. The sort of problems in leetcode are absolutely irrelevant to this sort of work.
It ultimately depends on what sort of jobs you are applying for. A lot of positions won't require the skills that leetcode and similar try to test.
> It discriminates against women/minorities: I don't live in a very diverse country, so I don't know anything about the minorities part, but in my career, I've encountered plenty of women who were as good or better than men in solving algorithmic issues. It does filter people, because it's designed to filter people, but I've never found it discriminatory along gender lines.
No it discriminates against older developers and developers that are self taught. Typically when you are looking for the skills needed to work in a particular field you will look at job postings or talk to other engineers already in the field and they will typically say "You need to understand this language or something similar and how X and Y work" and typically people will buy a book, or do a course on those things.
With older developers a lot of these wanky problems we forgotten how to solve years ago after we left university because the majority of jobs outside of FAANG will rarely require anything more complicated that recursion or a for loop.
You are trying to assess whether people can do a job. Not solve arbitrary problems that don't present themselves in the vast majority of circumstances.
Thank you for putting it so well. I've been developing for the web for 24 years(!) and anytime I have an interview with some stupid leetcode-like challenge, I feel like I'm taking crazy pills. It'd be like trying to get a job as an airline pilot, but in the interview process you'd have to solve aerospace efficiency calculations for a Ramjet engine. It's absolute madness and I can't think of any other industry which accepts this as normal. It's a strange combination of time-wasting, degrading, and insulting all at once.
Leetcode isn't used for html/CSS roles / basic web design roles. It's generally used at large SV companies which use software at a very large scale. Most people who apply aren't poor and have undergraduate degrees or higher. When you are using software at that scale algorithms are pretty important to get right. Not all software jobs require a computer science background, but a lot actually Do. Look at the open source work that FB or Google do, most of it is very computer science heavy. They aren't just hacking together for loops
> Leetcode isn't used for html/CSS roles / basic web design roles.
I don't think this is true. I've a buddy whose bread and butter is web development at small companies (<20 devs, often < 10) and he's been running into these types of problems at just about every role he has applied for in the last year and he's absolutely terrible at coding interviews despite him being able to reliably turn out solid code during his day job week after week.
What's fashionable in SV tends to be adopted by other companies no matter how well it actually fits. See shops with one team of 6 developers trying to turn everything into microservices.
This was my experience during 2020 (companies were being really picky). I ended up temporarily working far below my day rate to pay the bills. It wasn't fun.
I got hired for 3 times the amount based on my previous work. No time wasting tests, just my work.
The complaint is that the skills that leetcode is teaching you / testing you on isn't relevant for a lot of jobs. I am not talking about just basic web development either, that was just an example to illustrate the point.
The whole issue that these sort of tests are used inappropriately accessing someone suitability for a job. Most software people produce is simply implementing existing business processes. This doesn't require anything too smart algorithm wise, but may require good use of gang of four patterns or understanding how best to put a database together.
Knowing How to put a database together of requires you to understand algorithms though. joins /indexes /sharding etc require knowledge of cs theory. Knowing the details is very valuable.
> joins /indexes /sharding etc require knowledge of cs theory. Knowing the details is very valuable.
For the vast majority of scenarios you are going to run into no not really. You normally just need to read the documentation and know how it should behave and think a little bit about how the database is likely to be used. You really don't need any CS theory to be able to do that.
In any event it isn't what a leetcode / hacker rank style questions are testing for.
I don't want to be rude but I swear a lot of people on this site live in a bubble and don't really understand what happens outside of it.
I mean what is an index ? Merge join vs hash join ? These are basic algorithmic ideas that you should know if you're doing any sort of optimization on a database at all. I don't mean to be rude but I hate working with people who have no interest in their craft. They tend to make work harder for everybody else. I'd rather hire people who are actually interested in learning.
> I mean what is an index ? Merge join vs hash join ? These are basic algorithmic ideas that you should know if you're doing any sort of optimization on a database at all.
I have faith that I can read documentation, relevant theory and implement a suitable solution. Whether I score highly on a hackerrank/ leetcode test won't enlighten either of us if I am capable of implementing a suitable solution.
What I certainly don't need to do is prove that I can memorise and implement the some algorithm in some arbitrary timed test that isn't relevant 99% of the time for the tasks that I will be performing day to day while creating software. It isn't a test of whether I can perform the job or not. It is a waste of my time.
I don't really understand how you cannot fathom the difference.
> I don't mean to be rude but I hate working with people who have no interest in their craft. They tend to make work harder for everybody else. I'd rather hire people who are actually interested in learning.
I (and many others) have plenty of interest in my craft and work to improve myself all the time. Just because you cannot comprehend that people can get stuff done without knowledge that you happen to think is important and doesn't mean they are lazy or uninterested.
Scott Hanselman had this analogy of a tap and a sink. Many people's mental models of it is that you open the tap water comes out and water goes into the sink and out the plug hole. They do not know (and most of the time do not need to know) anymore about how the water arrives or leaves.
However knowing a little about what happens before and afterwards might be useful if you need to fix a clog. That doesn't mean I need to be a plumber, nor do I need to know how how the sewage system works. I can fix the clog and get on with my life. That is how most people manage and results are normally sufficient.
These are valuable, you're right. But they're not _necessary_, which is the point here.
I've been working on databases before and come across slow queries and read up on both the general theory and the DB specific practice for improvement. After that I've filed away in my brain "this DB needs this sort of optimisation", then ejected the rest. If I need it again in 5 years, I'll look it up and recap.
The fact that a SWE with decades of experience needs "practice" to pass leetcode indicates two things:
1. Leetcode challenges aren't representative of the actual work. Or else years of shipping working software should be as good a practice as one needs. So is it sufficient grounds for rejecting a candidate?
2. Those who pass leetcode challenges need not have any real experience as long as they can commit to few hours to practice the toy problems. So is it a good criteria for passing the candidate to the next level, given others who were rejected on leetcode basis?
If you don't understand the hate, listen to people more carefully. But I think you actually mean: "I understand why other people hate leetcide, and I think their emotions are invalid". At least own your argument
The counter arguments often mentioned against Leetcode I often hear:
- You are often asked stuff that took PhDs years to figure out: This usually shows up only in Hard questions, and badly designed ones at that. In my experience, Medium ones are usually solvable with solid algorithmic knowledge. It is also usually that maximum difficulty people encounter during their work.
- It discriminates against women/minorities: I don't live in a very diverse country, so I don't know anything about the minorities part, but in my career, I've encountered plenty of women who were as good or better than men in solving algorithmic issues. It does filter people, because it's designed to filter people, but I've never found it discriminatory along gender lines.
- It discriminates against poor people: You're a programmer, you are not poor. Even if you were, the few weeks of time investment it requires is usually offset by the higher salary you can ask for. Think of it as an investment in your future. Or if you are not a programmer, the amount of skills you need to learn to get your first programming job is usually far excess of just learning leetcode.