I once saw a post from a Meta guy saying he finished every single LC problem after it surpassed 1k. Some people just love it but perhaps more common are those who are burnt out.
They spent a ton of time prepping for it and it feels like an even bigger sacrifice as an adult with possibly family responsibilities compared to grinding in full time school. Once the job starts, they're burnt out and start to coast. Curious if you've observed much of that.
Currently I am doing Leetcode on a daily basis so it’s kind of related post 😅. I think both Dev and leetcode algorithms should be there in interviews. And Yes you are correct most of the interviewers not only focus on problem solving skills, mostly interviews evaluate our communication, problem solving and thought process.
I definitely understand the argument that "leetcode acts as an equalizer and standardization at scale"
I'd also add that with any process, what is being measured matters a lot.
1. If Leetcode is indeed used but all you measure are "can candidate solve problem with optimal solution yes or no". That binary signal I personally don't agree with since skills like communication, tradeoff analysis, how well you use the interviewer as a collaborative partner rmatter.
2. There could be scenarios where the Leetcode problem being asked required knowing some esoteric algorithm you normally would be able to Google and not knowing that would cause you not to make progress, that in my opinion is not an effective measure of a candidate's skill
That being said, I've also seen examples where a company can still ask a practical like question but scope it down for 45 mins and solving the question only requires knowledge of DSA fundamentals. I wouldn't necessarily say the debate is about Leetcode vs. no leetcode. Rather we should align on what signals should we extract from the candidate in a technical problem and how we can design a process that helps the candidate showcase their skills while being fair
> Rather we should align on what signals should we extract from the candidate in a technical problem and how we can design a process that helps the candidate showcase their skills while being fair
Yep agree with this take. Many other signals aside from just optimal solution or not that are critical for algo interview assessments
I am against LeetCode based interviews based on many points. Here are two main reasons:
1. Relying on standardized testing methods like LeetCode can stifle creativity and innovation, as engineers might focus on memorizing solutions rather than developing original approaches to problem-solving.
2. The emphasis on passing LeetCode-style interviews can disadvantage talented developers who do not perform well in high-pressure, timed environments, potentially excluding diverse candidates who could contribute unique perspectives.
One aspect of solving Leetcode that is often overlooked is that Leetcode is like a 'requirement' -- on any job, we won't like everything that we have to do. A lot of people get into tech because they like coding and building software, but we spend just as much time on design docs, meetings, alignments, stand-ups, etc. These things require a sort of mental stamina and acceptance of the fact that it's a part of the job. Getting through all of this requires discipline.
IMO, Leetcode helps you build discipline. You know you need to do Leetcode whether you like it or not, and if you are good at it, you demonstrate that you have the ability to show up for tasks you may not necessarily like or tasks that are not a core aspect of your job.
Ryan, you can add one more point “LeetCode is saving tons of time for Candidates”.
What I meant by that is, if I’m the employer and want to assess a candidate’s coding skills, I would give them a real-world scenario, such as a six-hour task, and evaluate their response. In that case, it would be frustrating to receive a rejection after spending six hours on a pointless task.
I’ve provided more details about this in my Substack article.
Leetcode is popular since people are mostly lazy, or worse, they'll do everything in their power to not change anything. Another pattern I've seen recently is that interviewers expect a specific solution, which can be a collection class one has never used before, which will fail him the interview (happened to me, never used LinkedHashMap).
Leetcode will only tell you if a developer has either been recently in the DSA class in college, or if he's been practicing enough leetcode problems prior to the interview.
Understanding big O notation is important, but spilling BFS in 5 minutes isn't coding skills for most jobs.
I've seen cases where engineers ran BFS to find the fastest result 4 times on the same dataset, only to filter it further with each run, where eventually a single run on all elements performing all 4 filters at once was way faster.
The BFS was correct, but the code in question never handled more than 100 records, to a simple brute force was better then drilling down a graph 4 times.
While leetcode can tell you if a person remembers some DSA implementations, and can apply patterns to a problem they been given and come out with the best BFS, DFS, or DP solution, at least in the backend, leetcode won't tell you anything about clean code practices, how the persons sees overall data flow, not how they setup dependency injection, or maintains SOLID principles, the skills that really matter in backend.
Another area leetcode "excels" at missing is when people with disabilities such as ADHD take a leetcode test. I have ADHD and PTSD, and when placed under a scrutiny, my thinking process changes completely to "fight or flight". This isn't at all how I work under pressure, just how I perform with eyes on my back.
This doesn't mean I'm not a good developer, nor does it mean my "coding skills" lack.
Also, you can refer to studies regarding correlation between success in interview and success on the job and the results indicate it's probably cheaper to go the extra mile of testing with a problem that as much as possible mimics the real job rather than whether a person can reverse an array in O(n) (I know you can do that with 2 pointers in n/2).
> This doesn't mean I'm not a good developer, nor does it mean my "coding skills" lack.
I believe you missed one of the main points of the article. Leetcode may lead to some false negatives (good developers that fail) but that is by design. These companies need a strong filter because they have so much interest.
> Leetcode is popular since people are mostly lazy, or worse, they'll do everything in their power to not change anything.
If there is a strong business reason to change things, companies would change. Otherwise, why spend the resources?
I learned data structures and algorithms through Leetcode coding challenges. However, I agree that it should not be the only aspect evaluated during the interview process. Sometimes, during the coding challenge, the interviewers are not expecting you to solve the challenge 100% or write the best algorithm; they are also evaluating your soft skills and behavior.
I once saw a post from a Meta guy saying he finished every single LC problem after it surpassed 1k. Some people just love it but perhaps more common are those who are burnt out.
They spent a ton of time prepping for it and it feels like an even bigger sacrifice as an adult with possibly family responsibilities compared to grinding in full time school. Once the job starts, they're burnt out and start to coast. Curious if you've observed much of that.
Yes definitely, have seen this exact thing happen. Opportunity cost of your time goes up as you get older
Hey Ryan!
Currently I am doing Leetcode on a daily basis so it’s kind of related post 😅. I think both Dev and leetcode algorithms should be there in interviews. And Yes you are correct most of the interviewers not only focus on problem solving skills, mostly interviews evaluate our communication, problem solving and thought process.
Nice, that preparation should make it so its easy for you to pass interviews when the time comes. Good luck!
I definitely understand the argument that "leetcode acts as an equalizer and standardization at scale"
I'd also add that with any process, what is being measured matters a lot.
1. If Leetcode is indeed used but all you measure are "can candidate solve problem with optimal solution yes or no". That binary signal I personally don't agree with since skills like communication, tradeoff analysis, how well you use the interviewer as a collaborative partner rmatter.
2. There could be scenarios where the Leetcode problem being asked required knowing some esoteric algorithm you normally would be able to Google and not knowing that would cause you not to make progress, that in my opinion is not an effective measure of a candidate's skill
That being said, I've also seen examples where a company can still ask a practical like question but scope it down for 45 mins and solving the question only requires knowledge of DSA fundamentals. I wouldn't necessarily say the debate is about Leetcode vs. no leetcode. Rather we should align on what signals should we extract from the candidate in a technical problem and how we can design a process that helps the candidate showcase their skills while being fair
> Rather we should align on what signals should we extract from the candidate in a technical problem and how we can design a process that helps the candidate showcase their skills while being fair
Yep agree with this take. Many other signals aside from just optimal solution or not that are critical for algo interview assessments
I am against LeetCode based interviews based on many points. Here are two main reasons:
1. Relying on standardized testing methods like LeetCode can stifle creativity and innovation, as engineers might focus on memorizing solutions rather than developing original approaches to problem-solving.
2. The emphasis on passing LeetCode-style interviews can disadvantage talented developers who do not perform well in high-pressure, timed environments, potentially excluding diverse candidates who could contribute unique perspectives.
One aspect of solving Leetcode that is often overlooked is that Leetcode is like a 'requirement' -- on any job, we won't like everything that we have to do. A lot of people get into tech because they like coding and building software, but we spend just as much time on design docs, meetings, alignments, stand-ups, etc. These things require a sort of mental stamina and acceptance of the fact that it's a part of the job. Getting through all of this requires discipline.
IMO, Leetcode helps you build discipline. You know you need to do Leetcode whether you like it or not, and if you are good at it, you demonstrate that you have the ability to show up for tasks you may not necessarily like or tasks that are not a core aspect of your job.
Ryan, you can add one more point “LeetCode is saving tons of time for Candidates”.
What I meant by that is, if I’m the employer and want to assess a candidate’s coding skills, I would give them a real-world scenario, such as a six-hour task, and evaluate their response. In that case, it would be frustrating to receive a rejection after spending six hours on a pointless task.
I’ve provided more details about this in my Substack article.
Per each interview yes, although preparation for Leetcode interviews can take longer
I couldn't disagree more.
Leetcode is popular since people are mostly lazy, or worse, they'll do everything in their power to not change anything. Another pattern I've seen recently is that interviewers expect a specific solution, which can be a collection class one has never used before, which will fail him the interview (happened to me, never used LinkedHashMap).
Leetcode will only tell you if a developer has either been recently in the DSA class in college, or if he's been practicing enough leetcode problems prior to the interview.
Understanding big O notation is important, but spilling BFS in 5 minutes isn't coding skills for most jobs.
I've seen cases where engineers ran BFS to find the fastest result 4 times on the same dataset, only to filter it further with each run, where eventually a single run on all elements performing all 4 filters at once was way faster.
The BFS was correct, but the code in question never handled more than 100 records, to a simple brute force was better then drilling down a graph 4 times.
While leetcode can tell you if a person remembers some DSA implementations, and can apply patterns to a problem they been given and come out with the best BFS, DFS, or DP solution, at least in the backend, leetcode won't tell you anything about clean code practices, how the persons sees overall data flow, not how they setup dependency injection, or maintains SOLID principles, the skills that really matter in backend.
Another area leetcode "excels" at missing is when people with disabilities such as ADHD take a leetcode test. I have ADHD and PTSD, and when placed under a scrutiny, my thinking process changes completely to "fight or flight". This isn't at all how I work under pressure, just how I perform with eyes on my back.
This doesn't mean I'm not a good developer, nor does it mean my "coding skills" lack.
Also, you can refer to studies regarding correlation between success in interview and success on the job and the results indicate it's probably cheaper to go the extra mile of testing with a problem that as much as possible mimics the real job rather than whether a person can reverse an array in O(n) (I know you can do that with 2 pointers in n/2).
> This doesn't mean I'm not a good developer, nor does it mean my "coding skills" lack.
I believe you missed one of the main points of the article. Leetcode may lead to some false negatives (good developers that fail) but that is by design. These companies need a strong filter because they have so much interest.
> Leetcode is popular since people are mostly lazy, or worse, they'll do everything in their power to not change anything.
If there is a strong business reason to change things, companies would change. Otherwise, why spend the resources?
I learned data structures and algorithms through Leetcode coding challenges. However, I agree that it should not be the only aspect evaluated during the interview process. Sometimes, during the coding challenge, the interviewers are not expecting you to solve the challenge 100% or write the best algorithm; they are also evaluating your soft skills and behavior.
True. Have had friends who didn't finish 100% yet still got an offer
Great post @Ryan Peterman! 100% agree with your sentiment both for the company and the candidate. Coincidently I just posted myself on this exact topic. I had an experience at Life360 where we decided to ignore the algorithm and Data structure signal and it came back to burn us. Here is the post if your interested. https://www.linkedin.com/posts/chadwiedemann_why-i-believe-in-algorithm-interviews-love-activity-7269380890189824003-j3aM?utm_source=share&utm_medium=member_desktop