It's becoming obvious to me that my time is better spent learning to solve these riddles rather than actually becoming a better developer. I have a job search coming up at the end of the year and whilst I've managed to largely avoid companies that ask this type of question, I believe it's seriously constraining my career.
I can't speak for everyone but the whiteboard interview has prevented me from leaving jobs earlier, moving jobs more frequently and left me avoiding certain companies altogether.
One of the big unspoken reasons these questions stick around: they cause little imposter syndrome anxiety for the senior engineers who need to conduct the interview. You ask a candidate to code a toy problem, and the candidate either knows the "trick" to solving it quickly or they don't -- very little risk for you as the interviewer, you're just watching things play out.
But if your interview requires you to pair program on real code like you'll do in your actual job, it opens up a lot of room to look dumb in front of an interviewee. You have to handle bugs on the fly. You have to look up (for the 5000th time in your career) whether you should be using Array.slice or Array.splice in this case. You go back and look at a similar implementation in your code base for a template instead of coding from memory.
And that's a shame because the live coding exercise is both a better predictor of hands-on job success and it's a better recruiting tactic: you've just had a vulnerable, collaborative experience with someone who will actually be working with you on a regular basis and you get a sense of whether you'd actually like to work there. But we keep doing these algorithms exercises because they require such little effort or interaction from engineers who are doing this interview in between two meetings with no prep time.
>And that's a shame because the live coding exercise is both a better predictor of hands-on job success and it's a better recruiting tactic
I'm very interested in this claim. Every interviewing-is-broken thread, someone mentions that pairing, or take-home exercises, or work samples, or their favorite method, are better predictors than algorithm problems. On the one hand I doubt any but the biggest companies could conduct studies on this; on the other hand individuals at smaller companies might honestly remember only those times their hires filtered through this method were successful, due to confirmation bias. So it seems like an inherently difficult thing to study.
Whereas, algorithm questions lend themselves easily to a "rubric" and seeing, 1 or 2 years later, if higher "grades" corresponded to better job performance.
I spent a lot of time practicing leetcode, interviewed a bunch of times (4 times, about 25 technical interviews) at FAANG without getting an offer. They always tell me it was very close (or even that I passed, but they didn't find a team in the following month and asked me to reapply).
What leaves me with a bitter taste is that they don't seem to value the experience on my resume (e.g. OSS and tons of github projects, blog or scientific articles, things written by me they could actually check). It feels like they will favor a candidate who can solve leetcode problems a little bit faster to someone who is a more experienced SWE. Also the whole thing seems pretty random.
Also practicing leetcode feels like wasted time. It's not uninteresting but after you solve 500 problems, it starts to get uninspiring. There are cooler things to do for personal development, especially when you already have a demanding job.
But well, that's part of the game... at least the rules are clear, and the interviewers/recruiter are usually pretty nice.
I am trying to resist cynicism, but I too am thinking that after my upcoming sabbatical if I want to get top dollar I should just invest in power-grinding at the leetcode gym.
Still hoping to find a friendly startup though, since some of the MegaCorps are lifestyle-incompatible and I'm already used to making a lot less than Googlebucks.
> after my upcoming sabbatical if I want to get top dollar I should just invest in power-grinding at the leetcode gym
Given that top dollar can mean potentially a six-figure raise over median salaries, that doesn't exactly seem like a bad deal.
All things considered, Leetcode is remarkably accessible relative to the barriers of entry in other high-paying fields like law, medicine, certain finance careers, and so on. It's a mostly-free website that you can work through at your leisure from the comfort of your home, with plenty of Google results to walk you through the questions if you run into a problem.
Have you spend some time on Leetcode already? I could see how the questions could be daunting to new grads, but I didn't find it all that painful with several years of industry programming experience.
Don't get discouraged by the sheer number of Leetcode problems. You don't have to do them all to get value out of it. The key is to do a couple per day in your free time (lunch break, while you eat breakfast, whatever). Any consistent practice will add up over weeks or months.
Kind of a meta point, but why do you call it the whiteboard interview? I think that was more popular 5 to 10 years ago, actually writing code or pseudocode on a whiteboard. In my experience the leetcode style questions most companies use today have you actually write and execute code in a sandbox environment.
It may be that the algorithms you’re required to come up with are still overkill in that they’re things you would not normally need to write from scratch on the spot without being able to references any resources in your day to day work. But as far as the format goes, this style of actually writing and executing code is clearly an improvement on the write-code-on-whiteboard style of interview.
I feel your pain though, the weeks of study that almost any good engineer needs to put into preparing for interviews can be pretty grueling.
I'm glad that I am not alone. I've done mostly non-UI C++/C#/Java/Python stuff, mostly business level rules and devops and evangelizing good practices such as CI and clean code and git (you would be surprised how many people don't even know how what it is or how to squash and rebase). Having studied computer engineering we did not really focus on algorithm but more on lower level stuff and signal processing.
I do not really fit any of the "standard" interviews. I've done the TripleByte interview and other top 100 corporation interviews and they all seem to assume a computer science formation or if not than assume you are a web dev. So yeah, I know how to implement most algorithms efficiently, I just can't remember how to describe exactly Dijkstra's from memory or how to balance a tree on a whiteboard under stress. I've seen them, I learned them, but 7 years after not using them I forgot (and frankly don't care).
I think these questions are bad for interviews because they cause so much anxiety for candidates.
Minimising that will give you a better interview, as if the candidate is more relaxed that’s going to be a more accurate picture of a day to day working patterns.
I like pairing for interviews on a simple problem in a real app in the tech stack your hiring for. But really spend effort easing the candidate in rather than barking orders as soon as the come through the door (or join the video call these days I guess).
I absolutely love doing Leetcode/HR myself - and think they’ve made me a better programmer. I’ve frequently found times when coding where a “trick” has improved code in my side projects (I’m really interested in making bits of productivity software so trees, graphs and ways of speeding up searching over large portions of text are a real help).
Just grinding them out probably isn’t helpful to everyone but go in with an open mind and you’ll be surprised what you learn.
I would just keep my confidence. After all your job is to develop, not to solve whiteboard-puzzles.
If you have to solve something, and can't because it's dumb, or partially dumb, then just explain your opinion to the interviewer.
If they weigh that against you, then it's not a good company for you anyway.
Example: An interviewer once asked me details about POSIX-portability of shell-commands in devops-pipelines.
I didn't know the answer, but I had done devops successfully for many years so I replied:
"I'm not sure, but I don't really need to know that, because I put all my scripts in http://shellcheck.net/"
Which was a completely satisfying answer for him and one he didn't hear before. So points for me.
FWIW, I've found that companies outside the valley, particularly those that don't see software as their primary product, are more interested in work samples than puzzle solutions.
Try broadening your search to things like aerospace and medical technology companies.
> Try broadening your search to things like aerospace and medical technology companies.
Not sure what the correct name is, but most job listings I've seen for these industries strongly prefer people with prior experience in them because they have to follow strict frameworks / processes for safety reasons.
According to the believers it is an unbiased way of predicting whether people are capable for the job. Google has done a lot of tests and these style of interviews predict job performance best [1].
Assuming this is true then to me it means that universities and work experience are too heterogeneous as a measure of job performance.
In my experience that is true. Not sure how well the argument holds up if everyone is simply going to study algorithms though.
[1] clement mihailescu says it on his YT channel somewhere in a vid.
> [1] clement mihailescu says it on his YT channel somewhere in a vid.
The "co-founder and CEO of AlgoExpert, a website that helps Software Engineers prepare for technical interviews." argues that algorithmic / technical interviews are the best predictors for future job performance?
I think these interviews test whether or not you're willing to work hard-- you can't just use critical thinking to get the answer, you actually need to study to learn all the tricks. That's an important characteristic to screen for imo.
Working at the companies that often ask these questions (FB, Goog, Amazon, MS, Apple) work at scales that many other companies don't. They also develop novel frameworks or work on problems that might interest you.
Example: if you want to work for a cloud service provider you need to jump through these hoops, even though regurgitating Rabin Karp or Tarjan's has little to do with day to day engineering.
Another example: Canonical (Ubuntu) Microsoft (windows) and Apple (OSX) all ask these questions. If you want to have a part in building an OS you will get asked these questions.
Basically if you want to work at "big tech" start grinding and don't stop until you move into management.
I have 2 friends who work at the Amazon office in Denver. Both work on boring projects utilizing internal tools Amazon built over the years and completely hate their lives. But the salary and stock options make them stick around. You can look at this as "Omg, this is total shit. I'd never want to work here." or "I don't mind suffering 4 years to get fully vested, get the fuck out of dodge and enjoy retirement a little earlier than others." Both of my friends picked the latter.
Yes it is. I had to make this decision as to whether I want to work on my personal projects, explore interesting topics or grind leetcode. To actually work on good projects the first step is leetcode.
I have a lot of interesting projects and I can talk a lot about OS kernels and bluetooth. To get to companies working on such interesting projects the gate will be leetcode type judges website. The questions they later ask are rudimentary and none of your effort on going deep into the such interesting topics matter.
For a good developer, those whiteboard problems should not be hard. In my experience, the people who are better at those “riddles” are learning and adapting more quickly.
Surely the generous pay is the biggest factor for retention?
Competition is ill defined in the labor market because people aren’t fungible. So it’s hard to really point to hard evidence, so and so practice leads to so and so change in salaries or increase in retention.
Aside, nobody said this guy was looking for a low paying job. High paying ones want leetcode.
Google will pay a higher salary to a 21 year old than a Miami firm will pay to someone with 10 years of experience. Nobody will ask you these puzzles outside of ~5 markets in the US. They also pay way less.
It would be a "tragedy of the commons"-like effect for companies that don't adhere. I would guess that is just an unintended effect and that there is no master plan behind making recruiting expensive, slow and inaccurate.
That could be part of it, but I don't think it's the primary reason. Rather I believe it's just one example of a more general, emergent phenomenon in capitalism, in which the top decile of jobs in high paying careers converge to interview methods which are a legal proxy for IQ testing.
It is a game of cat and mouse between candidates and companies. The candidates want high pay and interesting work, and the companies want only the top n% of candidates for their work, for some metric of their choosing. However many candidates a company has to choose from, they will devise some way of choosing the best among them. The methods for determining the best become (in my opinion) increasingly pathological as the surplus of candidates increases. In tech, the result is that the past decade has seen a supermajority of the most lucrative, mainstream jobs moving to a local maximum: whiteboard interviews based on data structures and algorithms. In response, candidates have gamified the process of studying for these metrics using Leetcode, and so a cottage industry of adult test prep was born.
Other industries use extreme credentialism or other methods to cut down on the vast majority of resumes they see, and there likewise emerges a cottage industry of professional preparation to break into these careers at the highest level. The companies use these methods because they see an absolute glut of candidates and become risk averse to bad hires - because after all, if they can attract so much talent with high pay and prestige, why should they suffer possible duds? This is how we end up with the, "Google is okay with passing on false negatives but can't tolerate a false positive in their hiring process" reasoning.
I was working on a “startup”/kinda just unemployed for two years. I studied leetcode hard, and got hired into a 300k a year job at FAANG. I know nothing about testing, git, software process, roll outs, dev ops, etc. I barely know how to do software engineering. What an idiotic hiring process.
Interviews are only partially about testing your body of experience. They're also supposed to test your aptitude and ability to grow in the future.
If you were capable of studying Leetcode so hard that you mastered the interview process at one of the most selective software companies in the world in only a few months, it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability to learn quickly toward picking up the basics of git, dev ops, and so on.
Arguably, this is one of the benefits of Leetcode-style interviews. They focus on core software engineering aptitude, while not arbitrarily excluding people because they didn't use the right VCS at their last job.
How did you get past the resume screening? Or are you from the US, because then it's much easier to get past the screeming, or so it seems.
I have yet to be invited for so much as an HR call when it comes to FAANG (bachelor/master CS from a Dutch university). Maybe I'm not getting past the application tracking system?
Let me ask you this: Do you think you are doing OK, or even great, comparing to your peers at your company? If yes, then I would say the hiring process is more smart than idiotic.
Can you share some tips on how you achieved this? What did you do if you got stuck on a question you just couldn't solve? Did you look at the answer and memorized it? How many questions did you solve? Were they mostly mediums or hards? What about system design, any specific resources you used?.
I keep coming back to leetcode every few months but I always get stuck on mediums so I'd appreciate any tips you can share!.
Have you looked into being a software person in a non-software (or only "software-enabled") company?
You'd probably get a pay-cut vs. FAANG or whatever, but it wouldn't exactly send you tumbling into the working class.
I really enjoyed working on software in biotech, for example, where I started my career... and sometimes think about returning with all my software-company chops to see if it's still as fun!
Gosh, I don’t enjoy that there is so much competition in this space. I can’t compete against people who essentially seem to have no life or other interests than getting job at Big N (or enjoy competitive programming).
It feels like this culture has ramped up in the last 5-10 years. When I started interviewing, the questions were easier. It feels like they’ve gotten more difficult - or at least the answer the interviewer wants is less attainable.
And I feel like I know why - go look at the leetcode discussion forums. There’s almost always some post at the top saying, “I did 1000 problems and won’t stop. I got accepted/rejected and learned so much. Believe.” From the outside and inside, it looks like a cult. I feel like these folks are just making it worse for everyone.
Maybe I am just bitter because I’ve passed every mock interview I’ve done but I can’t get an offer from Big N still. Startups are the worst as a non-founder/non-executive.
> I can’t compete against people who essentially seem to have no life or other interests than getting job at Big N (or enjoy competitive programming).
Interview prep doesn't need to be a grind. One of the nice things about Leetcode is that the problems are bite-sized. You can do one or two per day on your lunch break and make a lot of progress in a matter of months, or even weeks.
Don't approach it like a cram session before your interviews. That doesn't work unless maybe you're a new college grad with no other obligations.
> go look at the leetcode discussion forums. There’s almost always some post at the top saying, “I did 1000 problems and won’t stop.
Obviously the Leetcode forums are going to be a hotbed of discussion about Leetcode. You have to keep in mind that many of those people are entry-level developers treating this as an extension of their education. For them, it's basically a miracle that a mostly-free website lets them practice for interviews for $200K-300K+ career paths from the comfort of their web browser. Compare that to just about any other high-paying industry, where getting the right education, credentials, certifications, and test results will take years of your life and potentially hundreds of thousands of dollars of post-secondary education. We really have the easy end of this deal.
Don't let the total number of Leetcode questions overwhelm or discourage you. It shouldn't be approached as a cram session before the interview. It should be approached as a consistent habit or practice over a longer period of time.
If you just don't want to do any Leetcode or whiteboard interviews, that's fine too! There are plenty of jobs out there that won't require any of that.
However, you can't have it both ways: Big N salaries come with a high barrier to entry. All things considered, spending 50-100 hours of your free time solving problems on a free website at your leisure is really a small price to pay.
> All things considered, spending 50-100 hours of your free time solving problems on a free website at your leisure is really a small price to pay.
The problem is - it's not 50-100 hours for most candidates to pass. I've done well past 400 hours of interview prep and never received an offer from Big N. I tried the consistent 1-hour or so a day for months thing - it isn't guaranteed either. Want to emphasize this point to - it isn't like I can't do the problems. I've solved most any problem I'm given - it's that it just doesn't fucking matter. Whatever bias the person has is what they will evaluate on - the problem solving is merely a formality.
I find this little sub-industry building up around, “the coding interview,” to be highly strange.
Where are the papers that correlate this niche, specialized skill to general job performance and productivity?
I get that at certain problem domains the asymptotic complexity becomes a baseline for performance so I’m not against testing people’s knowledge where it’s appropriate. But is it really the dominating skill?
Reading some of the comments of people who went through the pipeline of this cottage industry, it sounds like it’s not even useful after you get hired. In fact optimizing for it to get through the interview sounds like a bad idea! Imagine landing the job and having no other skills.
I’m curious how these algo expert/monster/crushing the interview businesses survive and perpetuate this highly competitive environment.
> Where are the papers that correlate this niche, specialized skill to general job performance and productivity?
I would love to read this research if it existed in the public domain. However, much of this comes down to trade secrets and business practices. It's also not very amenable to controlled studies.
Practically speaking, these companies have a lot at stake in their hiring process. It's strange that so many people are convinced that the Big N companies are shooting themselves in the foot or otherwise making poor decisions with these interview processes.
Leetcode-style interviews might not have supporting research in the public domain, but absence of evidence is not evidence of absence. That is, just because the research doesn't exist doesn't mean that the Leetcode interviews are bad or worse than the alternatives.
Even if companies did eliminate Leetcode-style interviews, they have to replace it with some other alternative. Most of these criticisms fail to suggest actual replacement interview processes.
On your last point, the best alternative I've seen is take-home projects where it would take less than a week to complete. The interviewer is free to frame a problem in a way that allows the engineer to apply their real-world experience and show their fit for the job. It removes all the variables around interview stress/anxiety and as a result is a better (but not perfect) indication of their performance.
>I find this little sub-industry building up around, “the coding interview,” to be highly strange.
You should see the sub-industries around passing a board exam. Most of us really don't understand the privilege we have relative to other high paying professions.
The popular sentiment on computer science knowledge has done a complete 180 in the past several years.
Not that long ago, it was popular to complain that junior SWEs didn't really understand the algorithms, the data structures, and what was going on behind the scenes. The complaint was that they were just copy and pasting from internet searches until things sort of worked on their machine, but they couldn't recognize when an O(n^2) solution was going to work on their local n=10 test set but bring down the main website.
Now that knowledge of CS fundamentals has become valued in interviews, the pendulum has swung the opposite way. We have more free resources than ever before to practice and study CS fundamentals, algorithmic challenges, and even practice your interview skills. It's never been easier for a junior SWE to sit down, put in the effort, and work their way into a $200-300K job with sufficient dedication. Yet people never tire of complaining about Leetcode or having to understand CS fundamentals online.
Personally, I've never met anyone who was good at Leetcode yet produced bad code in production. I'm sure there's someone out there who knows a guy who knows a guy who can somehow ace Leetcode but can't write an efficient website backend, but it's not the norm.
> Personally, I've never met anyone who was good at Leetcode yet produced bad code in production. I'm sure there's someone out there who knows a guy who knows a guy who can somehow ace Leetcode but can't write an efficient website backend, but it's not the norm.
Weird. Ability to leetcode doesn't mean you know what is happening in e.g. an RDBMS. We've had people good at leetcode write a single query to delete hundreds of millions of records in a table with billions of records that was being constantly updated by the live website. Needless to say it didn't go over well. Ability to leetcode doesn't give you any knowledge that doing so might be a bad idea.
> Personally, I've never met anyone who was good at Leetcode yet produced bad code in production.
It's all anecdotal evidence. I've worked with some brilliant people at most places I've been and I can't think of 1 person who even had LeetCode account. Producing great production code is more about experience and knowledge of the domain than knowing how to bang out algorithms.
> I'm sure there's someone out there who knows a guy who knows a guy who can somehow ace Leetcode but can't write an efficient website backend
I don't see what makes you think a person who can ace Leetcode should be able to write an "efficient website backend". These are different sets of skills. You can ace Leetcode and not even know what a backend is.
> knowledge of CS fundamentals
Leetcode is not CS fundamentals. It's a small part of CS fundamentals. Besides, candidates aren't asked to show they know the CS fundamentals. They are asked to show that they spent more time practicing leetcode than the other guys.
Leetcode is not a good indicator of quality code by any means. It's basically a filter. If one can't solve these programming questions, there is a higher chance that they are not good at programming compared to one who can.
But it might come handy when implementing
- route optimization problems
- Building database query optimization engine
You can argue that not everyone is implementing these from scratch every day. But it could be argued that given an opportunity, an engineer should have the skills and ability to build these systems.
> But it could be argued that given an opportunity, an engineer should have the skills and ability to build these systems.
Having the skills and ability to build these systems doesn't mean you can regurgitate all the algorithms required to build them on a whiteboard in 30-60 minutes. It means you have to ability to search for algorithms and apply them to your problem at hand over the course of several days, weeks, or even months.
Do you really think anyone building these systems spent only 60 minutes both deciding upon, and coding ANY of their algorithms and called it a day because they obviously chose the best one?
It has been my personal experience, and the experience of many people I’ve spoken with, that this kind of trivia is learned in order to get a job and then forgotten immediately afterwards because it’s useless.
Anecdotal example: a former colleague is an incredibly talented systems programmer and has had to study leetcode garbage for the last few months in order to feel qualified to interview for a position with a team that he had previously been on at an older employer.
As another commenter said elsewhere, these types of questions are used because they’re legal proxies for “IQ tests”, and because they filter for people who are willing to sacrifice much of their personal time for the sake of the company.
16+ years of experience and won several awards and designed multiple highly scalable systems in retail. Still cannot get into faang. These coding interviews gate keeping me..
9 years of experience, used LeetCode for preparation for two months (solved around 200 mostly medium problems) and got an offer from FAANG. Coding challenges at FB and G are not that hard nowadays.
Online judge is competitive programming like https://open.kattis.com/ or CodeWars or CodeForces meaning a server that takes your source, compiles and runs it, tests if you satisfied all the req of the challenge. There's books for this
https://cpbook.net/#CP4content and despite leetfree claims of being 'useless because no online judge in interview' there is actually 2-3 judges sitting there in the interview performing the same function, telling you if your code does not satisfy the problem requirements
Nice how browsers have trained people to be scared if there's not a lock. It's just an expired cert, not revoked, and you're not entering payment information.
Readit News
I can't speak for everyone but the whiteboard interview has prevented me from leaving jobs earlier, moving jobs more frequently and left me avoiding certain companies altogether.
But if your interview requires you to pair program on real code like you'll do in your actual job, it opens up a lot of room to look dumb in front of an interviewee. You have to handle bugs on the fly. You have to look up (for the 5000th time in your career) whether you should be using Array.slice or Array.splice in this case. You go back and look at a similar implementation in your code base for a template instead of coding from memory.
And that's a shame because the live coding exercise is both a better predictor of hands-on job success and it's a better recruiting tactic: you've just had a vulnerable, collaborative experience with someone who will actually be working with you on a regular basis and you get a sense of whether you'd actually like to work there. But we keep doing these algorithms exercises because they require such little effort or interaction from engineers who are doing this interview in between two meetings with no prep time.
I'm very interested in this claim. Every interviewing-is-broken thread, someone mentions that pairing, or take-home exercises, or work samples, or their favorite method, are better predictors than algorithm problems. On the one hand I doubt any but the biggest companies could conduct studies on this; on the other hand individuals at smaller companies might honestly remember only those times their hires filtered through this method were successful, due to confirmation bias. So it seems like an inherently difficult thing to study.
Whereas, algorithm questions lend themselves easily to a "rubric" and seeing, 1 or 2 years later, if higher "grades" corresponded to better job performance.
What leaves me with a bitter taste is that they don't seem to value the experience on my resume (e.g. OSS and tons of github projects, blog or scientific articles, things written by me they could actually check). It feels like they will favor a candidate who can solve leetcode problems a little bit faster to someone who is a more experienced SWE. Also the whole thing seems pretty random.
Also practicing leetcode feels like wasted time. It's not uninteresting but after you solve 500 problems, it starts to get uninspiring. There are cooler things to do for personal development, especially when you already have a demanding job.
But well, that's part of the game... at least the rules are clear, and the interviewers/recruiter are usually pretty nice.
I think take home assignments are worst in terms of wasted time. At least your leetcode skills are transferable whereas take homes rarely transfer.
Still hoping to find a friendly startup though, since some of the MegaCorps are lifestyle-incompatible and I'm already used to making a lot less than Googlebucks.
Given that top dollar can mean potentially a six-figure raise over median salaries, that doesn't exactly seem like a bad deal.
All things considered, Leetcode is remarkably accessible relative to the barriers of entry in other high-paying fields like law, medicine, certain finance careers, and so on. It's a mostly-free website that you can work through at your leisure from the comfort of your home, with plenty of Google results to walk you through the questions if you run into a problem.
Have you spend some time on Leetcode already? I could see how the questions could be daunting to new grads, but I didn't find it all that painful with several years of industry programming experience.
Don't get discouraged by the sheer number of Leetcode problems. You don't have to do them all to get value out of it. The key is to do a couple per day in your free time (lunch break, while you eat breakfast, whatever). Any consistent practice will add up over weeks or months.
It may be that the algorithms you’re required to come up with are still overkill in that they’re things you would not normally need to write from scratch on the spot without being able to references any resources in your day to day work. But as far as the format goes, this style of actually writing and executing code is clearly an improvement on the write-code-on-whiteboard style of interview.
I feel your pain though, the weeks of study that almost any good engineer needs to put into preparing for interviews can be pretty grueling.
I do not really fit any of the "standard" interviews. I've done the TripleByte interview and other top 100 corporation interviews and they all seem to assume a computer science formation or if not than assume you are a web dev. So yeah, I know how to implement most algorithms efficiently, I just can't remember how to describe exactly Dijkstra's from memory or how to balance a tree on a whiteboard under stress. I've seen them, I learned them, but 7 years after not using them I forgot (and frankly don't care).
Minimising that will give you a better interview, as if the candidate is more relaxed that’s going to be a more accurate picture of a day to day working patterns.
I like pairing for interviews on a simple problem in a real app in the tech stack your hiring for. But really spend effort easing the candidate in rather than barking orders as soon as the come through the door (or join the video call these days I guess).
I absolutely love doing Leetcode/HR myself - and think they’ve made me a better programmer. I’ve frequently found times when coding where a “trick” has improved code in my side projects (I’m really interested in making bits of productivity software so trees, graphs and ways of speeding up searching over large portions of text are a real help).
Just grinding them out probably isn’t helpful to everyone but go in with an open mind and you’ll be surprised what you learn.
If you have to solve something, and can't because it's dumb, or partially dumb, then just explain your opinion to the interviewer.
If they weigh that against you, then it's not a good company for you anyway.
Example: An interviewer once asked me details about POSIX-portability of shell-commands in devops-pipelines. I didn't know the answer, but I had done devops successfully for many years so I replied: "I'm not sure, but I don't really need to know that, because I put all my scripts in http://shellcheck.net/"
Which was a completely satisfying answer for him and one he didn't hear before. So points for me.
Try broadening your search to things like aerospace and medical technology companies.
Not sure what the correct name is, but most job listings I've seen for these industries strongly prefer people with prior experience in them because they have to follow strict frameworks / processes for safety reasons.
Assuming this is true then to me it means that universities and work experience are too heterogeneous as a measure of job performance.
In my experience that is true. Not sure how well the argument holds up if everyone is simply going to study algorithms though.
[1] clement mihailescu says it on his YT channel somewhere in a vid.
The "co-founder and CEO of AlgoExpert, a website that helps Software Engineers prepare for technical interviews." argues that algorithmic / technical interviews are the best predictors for future job performance?
Well color me shocked.
Example: if you want to work for a cloud service provider you need to jump through these hoops, even though regurgitating Rabin Karp or Tarjan's has little to do with day to day engineering.
Another example: Canonical (Ubuntu) Microsoft (windows) and Apple (OSX) all ask these questions. If you want to have a part in building an OS you will get asked these questions.
Basically if you want to work at "big tech" start grinding and don't stop until you move into management.
I have a lot of interesting projects and I can talk a lot about OS kernels and bluetooth. To get to companies working on such interesting projects the gate will be leetcode type judges website. The questions they later ask are rudimentary and none of your effort on going deep into the such interesting topics matter.
Unfortunately, Leetcode only has one of the two languages I'd like to learn, and the one I'm probably less likely to find a job doing.
Deleted Comment
Competition is ill defined in the labor market because people aren’t fungible. So it’s hard to really point to hard evidence, so and so practice leads to so and so change in salaries or increase in retention.
Aside, nobody said this guy was looking for a low paying job. High paying ones want leetcode.
Google will pay a higher salary to a 21 year old than a Miami firm will pay to someone with 10 years of experience. Nobody will ask you these puzzles outside of ~5 markets in the US. They also pay way less.
It is a game of cat and mouse between candidates and companies. The candidates want high pay and interesting work, and the companies want only the top n% of candidates for their work, for some metric of their choosing. However many candidates a company has to choose from, they will devise some way of choosing the best among them. The methods for determining the best become (in my opinion) increasingly pathological as the surplus of candidates increases. In tech, the result is that the past decade has seen a supermajority of the most lucrative, mainstream jobs moving to a local maximum: whiteboard interviews based on data structures and algorithms. In response, candidates have gamified the process of studying for these metrics using Leetcode, and so a cottage industry of adult test prep was born.
Other industries use extreme credentialism or other methods to cut down on the vast majority of resumes they see, and there likewise emerges a cottage industry of professional preparation to break into these careers at the highest level. The companies use these methods because they see an absolute glut of candidates and become risk averse to bad hires - because after all, if they can attract so much talent with high pay and prestige, why should they suffer possible duds? This is how we end up with the, "Google is okay with passing on false negatives but can't tolerate a false positive in their hiring process" reasoning.
If you were capable of studying Leetcode so hard that you mastered the interview process at one of the most selective software companies in the world in only a few months, it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability to learn quickly toward picking up the basics of git, dev ops, and so on.
Arguably, this is one of the benefits of Leetcode-style interviews. They focus on core software engineering aptitude, while not arbitrarily excluding people because they didn't use the right VCS at their last job.
I have yet to be invited for so much as an HR call when it comes to FAANG (bachelor/master CS from a Dutch university). Maybe I'm not getting past the application tracking system?
I keep coming back to leetcode every few months but I always get stuck on mediums so I'd appreciate any tips you can share!.
Edit: assuming it's not your strong area based on the list of things you claimed not fluent with.
Deleted Comment
Your job is to be a clever code monkey. The Process will take care of turning your coding into engineering.
Leetcode interviews are great at testing for just that. A high IQ willing to solve arbitrary puzzles just because someone said “solve this”
You'd probably get a pay-cut vs. FAANG or whatever, but it wouldn't exactly send you tumbling into the working class.
I really enjoyed working on software in biotech, for example, where I started my career... and sometimes think about returning with all my software-company chops to see if it's still as fun!
It feels like this culture has ramped up in the last 5-10 years. When I started interviewing, the questions were easier. It feels like they’ve gotten more difficult - or at least the answer the interviewer wants is less attainable.
And I feel like I know why - go look at the leetcode discussion forums. There’s almost always some post at the top saying, “I did 1000 problems and won’t stop. I got accepted/rejected and learned so much. Believe.” From the outside and inside, it looks like a cult. I feel like these folks are just making it worse for everyone.
Maybe I am just bitter because I’ve passed every mock interview I’ve done but I can’t get an offer from Big N still. Startups are the worst as a non-founder/non-executive.
Interview prep doesn't need to be a grind. One of the nice things about Leetcode is that the problems are bite-sized. You can do one or two per day on your lunch break and make a lot of progress in a matter of months, or even weeks.
Don't approach it like a cram session before your interviews. That doesn't work unless maybe you're a new college grad with no other obligations.
> go look at the leetcode discussion forums. There’s almost always some post at the top saying, “I did 1000 problems and won’t stop.
Obviously the Leetcode forums are going to be a hotbed of discussion about Leetcode. You have to keep in mind that many of those people are entry-level developers treating this as an extension of their education. For them, it's basically a miracle that a mostly-free website lets them practice for interviews for $200K-300K+ career paths from the comfort of their web browser. Compare that to just about any other high-paying industry, where getting the right education, credentials, certifications, and test results will take years of your life and potentially hundreds of thousands of dollars of post-secondary education. We really have the easy end of this deal.
Don't let the total number of Leetcode questions overwhelm or discourage you. It shouldn't be approached as a cram session before the interview. It should be approached as a consistent habit or practice over a longer period of time.
If you just don't want to do any Leetcode or whiteboard interviews, that's fine too! There are plenty of jobs out there that won't require any of that.
However, you can't have it both ways: Big N salaries come with a high barrier to entry. All things considered, spending 50-100 hours of your free time solving problems on a free website at your leisure is really a small price to pay.
The problem is - it's not 50-100 hours for most candidates to pass. I've done well past 400 hours of interview prep and never received an offer from Big N. I tried the consistent 1-hour or so a day for months thing - it isn't guaranteed either. Want to emphasize this point to - it isn't like I can't do the problems. I've solved most any problem I'm given - it's that it just doesn't fucking matter. Whatever bias the person has is what they will evaluate on - the problem solving is merely a formality.
Deleted Comment
Where are the papers that correlate this niche, specialized skill to general job performance and productivity?
I get that at certain problem domains the asymptotic complexity becomes a baseline for performance so I’m not against testing people’s knowledge where it’s appropriate. But is it really the dominating skill?
Reading some of the comments of people who went through the pipeline of this cottage industry, it sounds like it’s not even useful after you get hired. In fact optimizing for it to get through the interview sounds like a bad idea! Imagine landing the job and having no other skills.
I’m curious how these algo expert/monster/crushing the interview businesses survive and perpetuate this highly competitive environment.
I would love to read this research if it existed in the public domain. However, much of this comes down to trade secrets and business practices. It's also not very amenable to controlled studies.
Practically speaking, these companies have a lot at stake in their hiring process. It's strange that so many people are convinced that the Big N companies are shooting themselves in the foot or otherwise making poor decisions with these interview processes.
Leetcode-style interviews might not have supporting research in the public domain, but absence of evidence is not evidence of absence. That is, just because the research doesn't exist doesn't mean that the Leetcode interviews are bad or worse than the alternatives.
Even if companies did eliminate Leetcode-style interviews, they have to replace it with some other alternative. Most of these criticisms fail to suggest actual replacement interview processes.
Can any of you post more info here ?
You should see the sub-industries around passing a board exam. Most of us really don't understand the privilege we have relative to other high paying professions.
Not that long ago, it was popular to complain that junior SWEs didn't really understand the algorithms, the data structures, and what was going on behind the scenes. The complaint was that they were just copy and pasting from internet searches until things sort of worked on their machine, but they couldn't recognize when an O(n^2) solution was going to work on their local n=10 test set but bring down the main website.
Now that knowledge of CS fundamentals has become valued in interviews, the pendulum has swung the opposite way. We have more free resources than ever before to practice and study CS fundamentals, algorithmic challenges, and even practice your interview skills. It's never been easier for a junior SWE to sit down, put in the effort, and work their way into a $200-300K job with sufficient dedication. Yet people never tire of complaining about Leetcode or having to understand CS fundamentals online.
Personally, I've never met anyone who was good at Leetcode yet produced bad code in production. I'm sure there's someone out there who knows a guy who knows a guy who can somehow ace Leetcode but can't write an efficient website backend, but it's not the norm.
Weird. Ability to leetcode doesn't mean you know what is happening in e.g. an RDBMS. We've had people good at leetcode write a single query to delete hundreds of millions of records in a table with billions of records that was being constantly updated by the live website. Needless to say it didn't go over well. Ability to leetcode doesn't give you any knowledge that doing so might be a bad idea.
It's all anecdotal evidence. I've worked with some brilliant people at most places I've been and I can't think of 1 person who even had LeetCode account. Producing great production code is more about experience and knowledge of the domain than knowing how to bang out algorithms.
I don't see what makes you think a person who can ace Leetcode should be able to write an "efficient website backend". These are different sets of skills. You can ace Leetcode and not even know what a backend is.
> knowledge of CS fundamentals
Leetcode is not CS fundamentals. It's a small part of CS fundamentals. Besides, candidates aren't asked to show they know the CS fundamentals. They are asked to show that they spent more time practicing leetcode than the other guys.
I competed with this guy in competitive programming competitions and while he was fantastic at it, he wrote the worst code I've ever seen.
I've also worked with many people who've never even heard of Leetcode or similar and they were fantastic developers.
In my opinion there's no correlation here and it's purely a distraction.
Deleted Comment
You can argue that not everyone is implementing these from scratch every day. But it could be argued that given an opportunity, an engineer should have the skills and ability to build these systems.
Having the skills and ability to build these systems doesn't mean you can regurgitate all the algorithms required to build them on a whiteboard in 30-60 minutes. It means you have to ability to search for algorithms and apply them to your problem at hand over the course of several days, weeks, or even months.
Do you really think anyone building these systems spent only 60 minutes both deciding upon, and coding ANY of their algorithms and called it a day because they obviously chose the best one?
It has been my personal experience, and the experience of many people I’ve spoken with, that this kind of trivia is learned in order to get a job and then forgotten immediately afterwards because it’s useless.
Anecdotal example: a former colleague is an incredibly talented systems programmer and has had to study leetcode garbage for the last few months in order to feel qualified to interview for a position with a team that he had previously been on at an older employer.
As another commenter said elsewhere, these types of questions are used because they’re legal proxies for “IQ tests”, and because they filter for people who are willing to sacrifice much of their personal time for the sake of the company.
Deleted Comment
Challenging but fun.
There should at least be a link to the related Leetcode problem for each section.
Not sure if all quizzes are original, but some of them looks interesting.
> ... don't try to solve it with online judge ...
> ... Try to learn from the solutions we provided as quickly as possible ...
> ... Interviewers only care about your WhiteBoard communication skills ...
Are they implying that rote memorization (memorize all problems and their solutions) is the best/easiest way to do the interviews?
If yes, wouldn't that trip you up the moment you're asked something new/original?
If no, what are they saying? Is the best leetcode stuff paywalled and they're providing a free version?
what's the latest on step-by-step most effective way to get ready for standard coding interviews?
Context: I'm trying to get back into this after many years. I've used leetcode in the past but don't remember anything about online judge.