I would hope no company relies solely on leetcode questions, but the common understanding was that Google was, at least in the not-so-distant past, among big tech companies, the closest to that style.
The weight that a company allocates to communication skills can also be measured on a spectrum. What I suggested in the comment to which you responded may be considered extreme by engineering interview standards, but the more you can probe an engineer’s communication style during an interview, especially in an adversarial conversation, the higher confidence you can have in their interpersonal compatibility with your team.
It’s one thing to answer questions about behavioral characteristics, which can be prepped. It’s another to induce the behavioral characteristics you’d like to test and see them for yourself. That’s a lot harder to fake.
This begs the question though: how do you evaluate communication skills better than this to encompass what you miss on technical discussions? It's easy to look like a team player in an interview setting where disagreements are low-stakes and theoretical. People do prepare for these behavioral interviews, there are whole sections in the same old reference book used for leetcode interviews. I honestly doubt people can tell between a well-prepared candidate from one that's a genuine team player before actually working with them.
I also want to reiterate the point that I don't know of any company that solely uses leetcode-style interviews, so they do tend to evaluate some kind of communication skills in another one.
The issue with LeetCode style interview is that almost EVERYONE can solve those questions after studying a couple weeks/months.
The only thing that LeetCode questions predict is if the candidate has been training for LeetCode questions.
The fact that Google, Facebook etc still use it as a gatekeeping mechanism makes me believe they want to find cogs that will specifically spend hours studying for it. Making sure that those engineers will be ready to execute their mindless coding tasks at the company.
For one thing, if by your own analysis, these companies' interviewing processes aren't effective, there's logically a conclusion that yours also aren't, given that interview processes are fairly similar among big tech companies. I've even also heard of an interviewer trying to tell a director with a straight face that a high level IC candidate (L6/L7 IIRC) from a prestigious big tech couldn't solve a "simple" problem at one of those companies. Leetcode style questions aren't even necessarily good proxies for whether an engineer is actually effective at their job or not (and yes, a good number of FAANGers openly admit here and elsewhere that they needed to grind leetcode to pass interviews at these companies).
Another thing is that Uber and Amazon are fairly competitive w/ other more prestigious FAANGs in terms of compensation. A decent staff eng at Uber isn't going to be very interested in grinding leetcode for a equivalent role at Google, the compensation delta is just not appealing[0]
I think that leetcode-style interviews probably used to be more useful/more predictive when they weren't super common. Also, if you're one of the most-desirable employers in the market [as Google was at the time it popularized this type of interview], nearly any aggressive interview strategy will be at least moderately effective, as the most dedicated candidates will invest lots of effort in preparation for your interview specifically, and if you reject tons of candidates that would have been effective, it costs you ~nothing, since, as a top target for candidates, you'd never run out of top talent to hire.
Google also had an initial product which was primarily based around having a really good algorithm. Actually, several of their top early internal products also were about solving difficult problems with interesting and novel algorithms -- which gave them a huge bias in terms of what they were seeking.
Of course, at Google's scale and popularity, books were literally published about their interviews and both how to pass them and how great they were -- so naturally others who either were or wanted to be top-of-market adopted similar strategies. Lots of top companies also had Ex-Googler founders or early hires, which helped perpetuate the familiar structures throughout the industry.
For myself, I really dislike leetcode-style interviews. I think there is some value in asking, say, two different leetcode easy problems to verify that the candidate can produce reasonable code samples, and that they can express their ideas in code (and hopefully, also, verbally either while they code or in response to probing questions from the interviewer).
Hot take: I like leetcode-style interviews and I've spent a lot of time in them on both sides of the fence (tens of hours as a candidate, hundreds as an interviewer).
> But yet, these interviews quiz me on things that I can easily Google that I may not know off the top of my head. It’s absurd.
I don't work at Google so I'm lucky to have freedom in the way I interview engineers and usually I try to squeeze out the quiz aspect as much as possible.
If a candidate doesn't know the algorithm for a given problem and can't quickly come up with one, I usually proceed to give a detailed explanation for it. In the end the task is reduced to "write between 6 and 10 lines of code that do X in your favorite language" and yet a majority (80-90%) of inbound candidates for software engineering fail at it (for non-inbound sources a picture can be very different of course).
Contrary to a common view, I believe that this approach actually imitates my daily interactions with a developer quite well and the correlation between interview performance and job performance is very strong in my experience.
And interestingly I've seen many people who shine in oral interviews (tell me about your experience) and then fail to produce any code at all, both during the interview and at work. So even if I wanted a good alternative approach to engineers I haven't seen it so far.
Granted I didn't ask if that was standard interview prep for them prior to interviewing, so this is partly my own biases filtering through, but I didn't get the sense that the seasoned 30-40 yold engineers were on leetcode for 6 months to pass interviews. I'm not saying none of them do that, but I found the Google interview process pretty standard fare for any place that has a similar quality bar.
I remember my interviews with Google & Facebook as a new grad & they felt far more grueling than as a senior engineer (that & 10 years ago they were still asking those brain teasers like find the voltage between two points of an infinite lattice circuit).
At this stage in my career, I've found the interview questions are all about how to design large pieces of software with the coding aspect being a smaller piece of the pie to make sure I'm not BS'ing.
> The companies that use them as a strong signal are the ones that will be absolutely demolished in engineering because they are on a fast track for a staff full of rote memorization rather than strong creative problem solving.
What metric are you using to measure this? I think its a positive correlation at best as far as good business outcomes are concerned, and maybe uncorrelated at worst. Google and Meta have been known to ask contrived puzzle questions for years, even before Leetcode (and Meta now is infamous for having a high standard for Leetcode interviews), and I do not see Engineering being "demolished" here, as far as results are concerned.
What people don't realize is that Leetcode selects for generally positive traits, no matter how its solved. In my mind, here are things LC selects for:
1. Actual innate skill. If someone never practiced leetcode before but can solve an arbitrary new coding question, they probably have a pretty decent aptitude for problem solving.
2. Determination. If someone practiced leetcode for hours a day just to pass an interview, thats commendable. Does it really matter that they don't "know" the problems if they studied hard and passed? They might be more likely to work hard on the job given the right rewards.
Leetcode style interviewes were basically initially created as a thinly veiled aptitude test, and in theory they are still good at that. If you _can't_ solve an easy to medium leetcode question then what does that say about you, assuming it basically is the inverse of the two singals above?
leetcode and puzzle-based interviews are indicative of thoughtless interview process that are lacking evidence as to their efficacy. Google used to focus on puzzles so everyone followed. Eventually google thought to look at the efficacy and realized it was poor, so google focused much less on the puzzles and it's taking a long time for folks to catch up. If an organization claims to respect evidence (as most large tech companies do) but have lackluster or nonexistent feedback loops around interviews, that hypocrisy is a red flag.
Take home tests like leetcode show a lack of respect and trust in the engineers, which I consider a bad work environment.
The high pay is usually because the organizations have tons of cash and are rarely indicative of interesting work (or the work is interesting but the product is discarded after completion). Most large, high paying, highly respected software companies have been stagnating for over a decade and sailing through on their monopolies. Then there are ethical considerations. At least that's how I justify avoiding that world. Maybe I'm totally out of touch with reality.
Why do you care if you're good at leetcode? Are you finding that it correlates with bad performance on real interviews?
Last time I interviewed (at ~5 YoE) I found that while Facebook and Google still have several "leetcode" style interviews, many other high-tier companies only do one interview of that type (e.g. Stripe, Dropbox). The rest are some combination of practical coding, discussing your experience, and working through design problems. And even the FB/Google interviews aren't as bad as they sound, because you often have an intelligent and engaged person on the other end who is trying to help you demonstrate your skill, unlike the relative vacuum of working through Leetcode problems by yourself.
You should be able to get really detailed information on the interview process up-front, either on Glassdoor or by talking to recruiters. Pick companies whose interview process emphasizes your strengths.
I wonder that as well. I don't see any significant connection between Leetcode or Leetcode-style questions and anything resembling what a company theoretically should be looking for in an engineer. The only thing I can come up with is that being able to memorize or otherwise internalize so many different problems is a proxy for intelligence (general mental ability). If so, I suspect it's a fairly weak proxy.
But, is that it? In the US, at least, not a lot of employers will give a straight up test of general mental ability (IQ test), likely because they see it as potentially attracting lawsuits. This is because IQ tests show a well-documented racial disparity in scores, which has not been shown to be correlated with anything genetic. Rather, the problem is either traced back to differences in family socioeconomic status growing up, or cultural bias issues with the tests.
Everything in the previous paragraph can be verified in a few minutes of Googling, so, I'm not going to litter this comment with citations when the obvious keywords will produce the information mentioned here. But, everything else, including what's to follow this, should be considered pure speculation on my part.
Given all this context, I can only think of 2 obvious reasons companies resort to using LC or LC-style interviews:
1. As a proxy for a test of general mental ability, as previously mentioned, or
2. Cargo culting, as with the whole "How would you move Mt. Fuji?" phenomenon.
I don't personally have a great deal of insight into which it is, or, if there's a third explanation that I'm completely missing. I also don't know whether there's any research supporting or refuting the idea that LC puzzles provide a valid interview signal for software engineers. All I really know is that these type of problems exercise skills that are not what one uses on the job as a SWE, so, it seems rather illogical to use them as a main component of your hiring process.
I'm not opposed to leetcode questions, but if a junior engineer asks me a question literally from leetcode without changing the test details (IE, they just copy/pasted from the site instead of coming up with something slightly different), I exit the interview and email the CEO with an explanation (I'm very senior, so it makes sense to go straight the CEO).
Because of this, I have instead written my own interview questions that I administer. You won't find them in leetcode, and they're not particularly challenging- and it still filters out many terrible candidates.
The proliferation of LeetCode for interviews means that we have an army of employed software engineers who are great at solving toy puzzles, but when it comes to actual business and / or customer problems, they stumble and falter. Management only have themselves to blame for spreading this kind of culture of interviewing around.
Fair. And no, I haven't worked at a publicly traded company nor would I really want to. The optionality makes for good leverage in salary negotiation though.
From what I can tell when interviewing engineers, most over-index on the algorithms. Sure we all ask an algorithms question, but it's more of a checkbox. It's the other 6 interviews that tell us way way more about the candidate.
And yes, I could get more at Facebook, Google, or Apple, but then I'd have to work for FB, Goog, or App.
On HN and elsewhere, there are so much deeply personalized emotions regarding LeetCode-style interviews. Instead of focusing on personal specifics, I am more curious about it from a social and systemic perspective.
1. If LeetCode problems are not only irrelevant, but actually turning away good employees, why aren't more companies shunning LeetCode problems? Tech is a very competitive field, and in the current climate of low interest rate, we (at least in the West) have more money than talent available. An employer with non-LeetCode interviews would have a significant market advantage. Is Google (and Netflix) being completely stupid even with their rigorous introspective take on hiring? If LeetCode is terrible for both the employer and the employee, why is it so popular? Are we all cargo-culting?
2. What is a better solution? How do we know it's better? There are proposed solutions, here and elsewhere, that make the candidates feel better about themselves, but for employers interested in hiring technically competent engineers, what is the solution? Requiring everyone to have a popular git repository?
Yeah, leetcode type of test got popular because hugely successful Microsoft and Google used to use them to pick the smartest geeks for amazing technical challenges for their times. Now that leetcode is being abused by both companies and candidates, we really should find a different way to interview.
I completely agree with his, as someone who has recently completed several interviews for senior level. I used to think everything depended on Leetcode questions, but I was surprised to find out how much of the focus was on design, past experience and leadership.
Leetcode is "easy" to crack with some (considerable) amount of hard work and they know that. But you can't make up past experience in behavioral interviews as you get found out very quickly.
The weight that a company allocates to communication skills can also be measured on a spectrum. What I suggested in the comment to which you responded may be considered extreme by engineering interview standards, but the more you can probe an engineer’s communication style during an interview, especially in an adversarial conversation, the higher confidence you can have in their interpersonal compatibility with your team.
It’s one thing to answer questions about behavioral characteristics, which can be prepped. It’s another to induce the behavioral characteristics you’d like to test and see them for yourself. That’s a lot harder to fake.
reply