Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

> I bag on Amazon a lot on here (which if I were to review with my therapist is likely because I had an absolutely HORRENDOUS experience in an interview loop with them my first step out of college that still makes me nervous in interviews, even 15 years later).

Hey, I had a similar experience with Google! It was my first technical interview for my first job out of college. The interviewer laughed at my code, and then after going through the logic said "Wow I can't believe this actually works."

Personal grievances aside, I've come to think that the Leetcode interview style has morphed from a "let's see how you handle problems at scale" test into an ego-driven hazing ritual. My biggest gripe is that Leetcode is systematically favoring candidates who have months of free time to memorize arbitrary logic puzzles. It makes me sad for the less privileged candidates who might be working a job while also trying to break into the IT field.



sort by: page size:

> "My biggest gripe is that Leetcode is systematically favoring candidates who have months of free time to memorize arbitrary logic puzzles. It makes me sad for the less privileged candidates who might be working a job while also trying to break into the IT field."

I told google that this style of interviewing is discriminatory, especially towards people with families, or other commitments. Never got another call for an interview since ^_^


> some people are completing 500-1000 leetcode problems before heading into interviews.

Over the course of one year, I completed, classified, commented 200 leetcode problems. I also taught algorithms to third and fourth year university students not too long ago. I believe I write readable code, I know perfectly the language I'm using (at least for that purpose), I'm totally fine with complexity, and I know most methods involved in these algorithms, including more advanced algorithms such as KMP.

Yet... I failed my round of interviews at Google. After this preparation, I'm still not able to solve quickly any leetcode problem in the context of an interview. On a whiteboard, with an interviewer in my back, in a stressful situation. I need to practice more if I want to get consistent results.

So I agree with your conclusion. We are competing with a lot of people who train using the same resources. Including young graduates who have a lot of free time on their hand.

On a positive side, I'm thankful to Google for giving me a shot. Based on my resume (40+ with little experience in software industry), I'm not sure I would have been interviewed in a more traditional company, let say a bank.

To come back to my interviews, system design went very well. Algorithms quite well too but not well enough. Couldn't solve one problem, and a bit slow on an other one.

The recruiter first told me I passed, and that they were going to find a team for me and make me an offer. But they finally asked me to re-take the algorithmic interviews a few months later, to "make a stronger point to the hiring committee".

Never heard from them since then, about 8 months ago. Recruiter doesn't answer emails. I think she moved to a different position. Not sure what to do now?


> every company's interview process has become like Google's

although the leetcode hiring model is too often cargo culted by orgs trying to emulate faang this is not representative of the industry at large. if it seems true you may be considering too narrow a slice of it

> What would be your advice be to fresh college graduates, or anybody for that matter, who are good at programming but not at leetcode?

consider applying to roles that don't use the leetcode hiring model

personal anecdote:

first job out of undergrad, small shop whose software you probably haven't heard of but have almost definitely interacted with if you live in the US: phone screening, remote technical session with 2 hours (own time) to write 3 functions, on-site interview given a laptop, an hour, and instructions to write a toy API then asked a few questions about solution and general concepts

second job, cold emailed a professor asking about openings for a programmer/research software developer, asked to clone and build a project repo and sketch a simple (<1 hour) feature

third job, also research software, online application, 1 hour video interview, entirely qualitative, no coding component, having work from the previous role on Github likely obviated the need for a technical session

I'm not a great leetcoder, I reason fairly slowly, I struggle under time pressure and observation

if you're like me, play to your strengths, you're still competent and you can find work


>I don't get why so many developers hate Leetcode.

Because they think that the employer should recognize their greatness by just looking at their resume and having a simple conversation with them, instead of assessing them on some skill that they have to brush up on.

After being on the interviewer side myself recently, I think those people just don't realize how hiring actually works. I've seen some people with impressive resumes and who could bullshit their way around a conversation greatly, to the point where they make you believe they are one of those magic 10x-ers. And when you get to algorithmic problems, they struggle to figure out when or how to use a hashmap and cannot even do some super basic bruteforce parsing of binary trees or even know what they are used for.

Of course there are some edge cases where a great developer would fail a leetcode-style interview, but those exceptions are very rare and only seem to affirm the rule. I know that leetcode style interviewing is far from perfect, but I struggle to think of anything that would work better. A take-home coding project sounds like a great option, until you realize that each one of them takes about a week of working on it a couple of hours a day, which is an unacceptable time sink for any adult with responsibilities and who interviews at more than one place at a time.


> The system is _highly_ prejudiced towards suppressing false positives

I wonder if the algorithm centric interview style at Google can really achieve that. From my experience, algorithm centric questions + plus white board coding have bias towards academic people. (Maybe that’s fine for google) However, the way to crack that kind of interview is really just practice like hell on leetcode. Just take a minute and think, who are most motivated in doing that? Good, experienced engineers have no trouble finding jobs in Bay Area, and why would they waste their time on leetcode for skills that are mostly going to be useless in real work? New grads and engineers that have trouble finding jobs are most likely to spend hell of their time on leetcode. I think the interview style at Google is in fact increasing false positives instead of suppressing it. It also has high false negative for sure.

There are tons of other ways of doing interviews, in which interviewer gets a lot more and very relevant signals from candidates while keeping candidates pressure low, and not wasting their time, but Google is not doing it, like asking practical questions, letting candidates write and test their code in their own computers, has a debug session, etc.


> I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo.

I think companies that break out of the leetcode habit are going to do well. There's a lot of great talent out there that's being passed over by these tests.

If the job is to solve leetcode problems, by all means, test the candidates for that. If the job is to solve real life problems, there's almost certainly a better measure.

I will never judge someone based on that kind of problem. I believe the data that results is just bad.

Edit: I should add that leetcode is useful for developing programming and problem-solving skill. I've done tons of problems, myself, and have fun solving them... and learn from them. So I do recommend it for a challenge. But not for interviews.


> It's been obvious for over a decade after they built an interview process that is heavily biased towards those who recently took an algorithms class.

What would you do instead? Threads about tech interviews are always the same: we all complain about the process with no real alternative when you want to hire at that scale.

In particular about:

> Just about every other skill that is needed to be a good software engineer.

How would you assess them better than current common processes like leetcode interviews?

If one could do better hiring at the same cost or less, the whole industry would be interested, even if they'd have to delegate some of their hiring to an external company. The fact that leetcode interviews are still so common indicates that maybe something is missing from alternatives, be it scalability, fairness or even whether they actually provide more signal than leetcode interviews.


> How would you assess them better than current common processes like leetcode interviews?

OP said "just about every other skill that is needed to be a good software engineer", for which leetcode is useless.

Communication skills, organizational skills, hell, even general knowledge isn't covered by leetcode-like interviews.

Personally, speaking as someone who doesn't like but has to interview potential hires, I have found that there is zero overlap between people doing well in leetcode interviews, and hires doing well in their first year.

> If one could do better hiring at the same cost or less, the whole industry would be interested

I think this is a naive perspective. If there is any takeaway from the recent wave of layoffs, it would be that company wide decisions may be driven by factors that have no relation with actual financial performance. Google could have kept all these engineers and still make an absurd profit.

The notion here is that some company, at some point in time, started putting their applicants through these kind of puzzles, and it became trendy.


> the distinction between something being "bad" vs "just not for me." Your comment made me think of that.

> If you really perceive algorithmic live coding as torture, then it makes all the sense in the world to avoid it. "It's not for you."

I wasn't aware of this concept, but I can assure you that I don't have such a mindset. I tend to enjoy finding difficult challenges and complex topics to dig into which are way outside of my comfort zone. Leetcode practice is different though, and yes, it does feel like torture to me and some other developers who tend to be rather quiet in general. While it's really tempting, I don't think I'm the right person to act as a community voice on this topic, although I do chime in sometimes.

When you're just starting this career path, it feels like homework. Heck, it's even exciting to solve problems which are a bit more complicated than whatever you're exposed to in school. However, try to spend several years in a row (8 in my case) trying and failing to pass such interviews (several in-person ones each year) and it will feel like torture. "If you'll spend a little bit more time on Leetcode, surely you'll pass next time..." No thanks! I'm done. The issue is not the lack of training, but the way in which these interviews are conducted by certain people which causes me distress and severe anxiety. I moaned about this before in various HN threads related to interviews and I might bother to blog about it some day.

> In this case, the cost of avoiding opportunities that require such interviews is that you may have fewer opportunities and they may be less lucrative on average.

Hasn't been my experience, but I'm not looking to maximise my income. I looked for advice on negotiation strategies and whatnot and felt happy with the offers I got. Others might have a different experience in this regard, but I think asking for less money in exchange for a psychologically-safe interview process is nonsense. At the end of the day, you get what you pay for and there are review sites anyway.

> For example, if the thing that makes this "torture" for you something like anxiety when being watched? If so, probably something like that shows up in other places in your life and maybe valuable to tackle anyway.

I think you're making certain assumptions here. I don't need to "tackle" my perception of what's safe and comfortable. We're all different and that's a good thing.


>I see this argument all the time, but I can't find any other place that it comes from other than disappointment from those that didn't or can't pass those interviews.

I have passed these interviews. Had offers from multiple FAANGs, worked at G. The algorithms interview is idiotic. It is a way for them to gate the jobs to people who have CS degrees while being able to say they do not require CS degrees.

I rarely come to the to the optimal solution on my own for a leetcode problem. It is about learning the techniques so you know how to speak about the solutions, then basically learning (by reading) the right answers to different problem types.

This isn't from being hurt, I pass these interviews. I've worked there. It is a horrible selection criteria for what you actually do at the jobs - design docs, meetings, tickets, tests, and code reviews. It creates a ton of false expectations too, you do not need to know advanced algorithms to work on some internal user interface, close maintenance tickets, or to write 10 lines of test code for a 2 line change. You get in there and realize none of the work you are doing is as clever as the interview.

The tasks described above are the reality of working in a large organization. They shouldn't be, but they are. The interview should more closely match that.


> Ever since 'Cracking the coding interview' was released, every company's interview process has become like Google's and Google didn't have a particularly great interview process to start with.

> The no-whiteboard companies are very few, hardly ever seem to have openings and not hiring junior engineers.

Both those statements are false.

There are plenty of places, both small and large, that don't do leetcode interviews. There are places that don't do whiteboard interviews at all; there are far more that do have you go to a whiteboard but don't have you do leetcode there (my own company is such a place).

Personally, I don't grind leetcode at all. I know what I know. If a company wants that, fine; if they don't, I'll work somewhere else. But I am far from junior. For a junior programmer, it may be harder to get the first job, and leetcode may open some doors. But the absence of leetcode doesn't close all doors - far from it.

What we care about is, can you code at all. We give a problem that is a step above FizzBuzz, but not all that far above it. Can you write code that does something like that? Can you think through the problem? It's not a "you have to find the trick" problem at all. We don't care about whether people can find tricks. But can you code at all?

We aren't alone.


> My biggest gripe is that Leetcode is systematically favoring candidates who have months of free time to memorize arbitrary logic puzzles.

For me, leetcode is basically just what is taught at university level. So they're hiring people based on if they know stuff they would learn and forget from university.

The thing is, it's not about having free time, it's about being so dedicated to getting the job that you'll spend ages learning things you would never do during your day job and if you did do them during your day job you would be considered a cowboy because there are predefined libraries that are optimised to do those things.

For me, the main reason I don't want to work for FAANG is they have a reputation for long hours and that the hardest thing at the companies is the interview process.


> Does someone with my experience really have to grind leetcode and memorize algorithms to prove his capability?

Unfortunately yes, this is necessary for all of us at our level of experience. I have 15 years in the industry at great companies, and I still need to put myself through the horrible coding tests and take-home assignments even for engineering management roles.

The good news is that in my recent experience, the better companies are doing a better job of these nowadays. I had to do lots of technical interviews, but only a handful had horrible algorithmic stuff while the smarter companies had me do things like reviewing a merge request and suggesting edits and architectural changes. There seems to be some recognition that the leetcode style interviews aren't necessarily returning the right signals.


> If you want actual human beings who are able to think abstractly, critically, and contribute to the team and help the company grow, then look for people who have been working long enough to know that leetcode is a dead end.

I am very against Leetcode style interviews. I promise every candidate interviewed by the org I lead that they won't be asked academic CS trivia.

But, I don't think what you said here is accurate.

If it were true, these other companies where all the critical thinkers have been flocking to would have displaced the FAANGs.

There are good reasons to dislike Leetcode, but your comment reads like sour grapes to me.


> Leetcode Medium, Leetcode Hard, Cracking the Coding Interview ...

I feel like there is something wrong with the industry. Here is a person applying to do mobile development and they need to spend weeks and weeks drilling binary tree inversions and trapping rain water (https://leetcode.com/problems/trapping-rain-water/) etc.

I was interviewing at AWS and I don't think most of the people I talked to even looked at my resume and asked about the projects I worked on, happy customers etc. It was mostly palindromes, buckets of water and various trees, and parroting back Jeff's 14 leadership principles. Now obviously these companies are around and lots of smart people are working there and delivering great products but it just seems so strange.


> One of the things that gets me here on the hiring side is that the ease of “grinding leetcode” as a strategy seems to defeat the entire purpose of it as an interview question.

I think that's irrelevant for FAANG and friends. They pay so high that they can afford to make their interviews so miserable and time-intensive to prepare for that tons of people never even try, purely as a first-pass filter. They don't care that you can prep for it, they just want it to be (exactly the right amount of) scary and unpleasant. The resulting, self-selected group probably is, in fact, far better on average than the set of all software developers, including those who never apply to those sorts of jobs (but might if the interviews were less awful). Furthermore I think that's why some results show that they could randomly select candidates and do about as well as the interview process does—sure, maybe, but they could not do that if the set of people applying wasn't already heavily biased to have a fairly high average skill level (& IQ, that's absolutely part of what they're filtering for).

Now, companies paying half or less what FAANG does and trying to do anything remotely similar, are simply making a mistake. People with a tolerance for and ability to pass those kinds of interviews are going to apply to the much-higher-paying options, not to your company.


>we can come in with over 10 years of verifiable experience, talk eloquently about that and our abilities, and still be met with these ridiculous and demeaning puzzles.

This happens because a lot of people have stories of the engineer who passed everything but failed FizzBuzz. Some people spend a decade being on the periphery of projects and memorizing how the people who actually did the work talk about those projects.

More practically work is filled with BS and the larger the company the more BS there is. If you find leetcode demeaning then I suspect many hiring managers would be glad of having used it to filter you out. You can consider it to be a waste of your limited time to study it, but demeaning implies an emotional component and a certain elitism on what tasks are too lowly for you to do. Leetcode is a pain in the ass but so are many things and dealing with them rationally is life.


> I never understood the hate Leetcode gets

Getting leetcode questions at an interview is ridiculous if the position doesn't require it.


> maybe I should start grinding LeetCode anyway

You should start grinding LeetCode if you plan on interviewing for industry jobs, because it might help you survive those awful white board/algorithm puzzle interviews.

next

Legal | privacy