In my experience, any alternative to leetcode provides a better signal-to-noise ratio. You are better off asking trivia questions.
Additionally, this is the common narrative among leetcode advocates - "If no leetcode, then what?" As a hiring manager, you think harder and do better, that's what.
> Please remember that while some of us would do well and prefer some live pair programming or debugging sessions, it stresses the hell out of some folks and penalizes them unfairly.
So does leetcode. And a candidate that is truly a good fit for the role would be more at ease with the interview than if they saw a leetcode question they haven't seen before.
> Take home tests penalizes people with families and other responsibilities...
So does studying for leetcode for hours.
> ...and probably has a racial bias as well in countries where different races have different societal loads.
Share some sources before making a claim this ridiculous.
> In the end, even if these coding challenges might not reflect the actual work you do, they might still be predictive of success in the job, as much as any other method can be when we look for unbiased markers.
In my 6-ish years of experience, this is false. I have actually tested this theory in practice, and through my anecdotal experience, leetcode is a poor signal for job performance.
I can usually usually accurately screen a candidate for success in about 45 mins. And, unlike leetcode, you can't pretend like you haven't seen the question before, bc I can push the candidate to their limit, which is where you will find hire / no-hire signals. I love talking about this stuff, but I find that my peers engineering peers do not give a shit and would prefer to stay in leetcode hell.
> You honestly do not have to do this to pass the LC interview. I didn't.
You were able to prep for 2-4 hours and still pass LC interviews? I find this hard to believe given that I, and peers I know, took much longer to prep.
Having just passed Google's algorithmic interviews, and established a leetcode account specifically to prepare for that, I have a good record of how much leetcode I did:
3 easy problems, 4 medium problems, and 3 hard problems.
It would make sense to count 2 additional hard problems that I worked on (with pencil and paper) but didn't submit a working solution for.
This is more than four hours of work, but it's much less work than people suggested was necessary. (For example, my recruiter strongly believed that candidates needed a minimum of 5 weeks to prepare for an interview.) I wasn't really able to make myself do more leetcode, because whenever I started working on it, what I really wanted to do was to write up proofs that the algorithms were correct, not to submit a solution to one and move on to the next one. (OK, it passed all the test cases, but what if that's just a coincidence?)
But writing up a formal proof can easily chew up most of your day, and it does nothing for you in terms of practicing getting the code out. So I found the whole process fairly demoralizing.
I can answer for myself as GP, didn't interview with G but got into a similar company.
> L3 vs L4
Slightly above L3 would be the equivalent ($200-$260 salary band)
> * How many LC questions were you given per round? I would expect 2 is the norm.
6 interviews, 5 were technical -> 3 were algorithmic style, 2 were domain specific. Usually they had 2 questions, but really the first question was very easy and often related to the second one.
> * Did you have optimal solutions or were you nudged to a solution by the interviewer?
No clue, there was one I was struggling on because string parsing is annoying in C++. Not much nudging. I believe my solutions were generally pretty efficient.
> Did you pass any other FAANG / leetcode interviews?
Yes, the only other one I was in. I found actually getting interviews (as entry-level) to be much harder than passing the interviews once you got them.
> What's you educational background? Do you have computer science / STEM degree from MIT or similar?
Yes to the second and I did take a DS&A class in sophomore year of college.
> Not saying you're a liar, but if you got into G with that little prep, I have some follow up questions
First off, I didn't get in. I passed the algorithmic interview, I was told to expect a round of "team fit" interviews, and then they notified me that instead of having team fit interviews they were just rejecting me. From what I understand, after passing the algorithm round you're supposed to collect "statements of support" from team leaders at Google, and then your file with the statements of support included goes to a centralized hiring committee. I would guess the difference between passing the algorithm round with no team fit interviews and failing the algorithm round is largely in whether you get rejected before or after that committee sees your file at all.
I can answer the questions anyway:
What level were you applying for?
L3.
How many questions per round?
Well, this depends on what you mean by "round". I had a day consisting of 5 interviews with 5 people. One of those was the behavioral interview; the other four were algorithm questions. Each (non-behavioral) person asked one question, for a total of four questions.
Did you have optimal solutions or were you nudged by the interviewer?
Question by question:
- Near-total failure.
- An interview involving a lot of verbal problem solving verging on system design. But technically not a system design interview. L3s don't get those. The problem was less difficult (which makes sense since the design of the interview allows less time for it) and I didn't need much in the way of help. Preparation was relevant here; one of the things I had done to prepare was to write out a binary search, which came up in this interview.
- A question for which I had a good solution offhand, which the interviewer nudged to a perfect solution.
- A question for which the interviewer did not want an optimal solution. He specifically remarked to me that when he gives this question and the candidate appears to be familiar with the solution, he substitutes a different question. This interviewer spent some time talking to me once my solution was written (and I had taken help from him). I had used a brute force approach. He remarked that my approach was atypical, but that the typical approach was also a brute force solution, and he described the optimal solution for me.
Have you passed any other FAANG / leetcode interviews?
No. I don't do well in interviews. I have worked for Amazon in the past; I got in by winning a programming contest they held at my school. Notably, you do not have to speak to anyone to win a contest. I did not continue to Amazon after graduating for a couple of reasons, but it seems to have been more or less a guarantee for everyone who was hired under that program and chose to continue there.
What's your educational background?
I have a BA in computer science (and in math; double major) from a poorly-regarded school. You might find it relevant that, although I didn't go to a good school, I had good standardized test scores: 36 ACT; 1600 SAT; 800 on each of 3 SAT subject tests.
In my experience, any alternative to leetcode provides a better signal-to-noise ratio. You are better off asking trivia questions.
Additionally, this is the common narrative among leetcode advocates - "If no leetcode, then what?" As a hiring manager, you think harder and do better, that's what.
> Please remember that while some of us would do well and prefer some live pair programming or debugging sessions, it stresses the hell out of some folks and penalizes them unfairly.
So does leetcode. And a candidate that is truly a good fit for the role would be more at ease with the interview than if they saw a leetcode question they haven't seen before.
> Take home tests penalizes people with families and other responsibilities...
So does studying for leetcode for hours.
> ...and probably has a racial bias as well in countries where different races have different societal loads.
Share some sources before making a claim this ridiculous.
> In the end, even if these coding challenges might not reflect the actual work you do, they might still be predictive of success in the job, as much as any other method can be when we look for unbiased markers.
In my 6-ish years of experience, this is false. I have actually tested this theory in practice, and through my anecdotal experience, leetcode is a poor signal for job performance.
I can usually usually accurately screen a candidate for success in about 45 mins. And, unlike leetcode, you can't pretend like you haven't seen the question before, bc I can push the candidate to their limit, which is where you will find hire / no-hire signals. I love talking about this stuff, but I find that my peers engineering peers do not give a shit and would prefer to stay in leetcode hell.