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.

Bet you most people would disagree with just trivia.

> So does studying for leetcode for hours.

You honestly do not have to do this to pass the LC interview. I didn't.

Certainly not as much as a takehome test.

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.

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.

Your recruiter believes this for a reason and they have probably seen many candidates go through the process.

Not saying you're a liar, but if you got into G with that little prep, I have some follow up questions:

* Where did you level when you got your offer? L3 vs L4 vs L5 makes a big difference.

* How many LC questions were you given per round? I would expect 2 is the norm.

* Did you have optimal solutions or were you nudged to a solution by the interviewer?

* Did you pass any other FAANG / leetcode interviews?

* What's you educational background? Do you have computer science / STEM degree from MIT or similar?

* Did you crush the system design interview?

* How do you feel behavioral interviews went?

> 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.

> Did you crush the system design interview?

Probably was my weakest.

> How do you feel behavioral interviews went?

Well, I am good at talking.

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.

Did you crush the system design interview?

L3s don't get those.

How do you feel behavioral interviews went?

Iffy.

I generally give (mostly) simple questions where I explain how to solve them. Assuming you're a competent programmer in the language we're dealing with, you should be able to figure out how to solve the problem in your head in a minute or two. The trick is that I'm gauging accumulated skill, not memorized algorithms.

For example, I'll explain how to use a data reader, explain the constructor for a simple object, and provide a SQL statement. Then you need to write the code that reads a few values from the data reader and constructs and object. After that we discuss edge cases and error handling, and if you should throw an exception or return null. Easy-peasy! (And if it's not easy-peasy, you really shouldn't be here.)

Another example: I'll explain an older API for running a lambda in a background thread, and then an API for running a lambda in the main (UI) thread. (Mac, Windows, iOS, and Android all have the same threading model for their UI.) Easy-peasy if you understand basic scoping and threading. (And if it's not easy-peasy, you shouldn't be working in any job where you have to deal with threads.)

In both cases, the candidate can ask any many questions as they want, and I'll happily steer a candidate.

The point is, I'm not relying on memorized algorithms, or requiring prep. What I'm doing is relying on, and judging accumulated skill. Only a novice will have trouble with my questions; and I wouldn't use these questions when hiring interns or entry-level engineers. If you've programmed with a database before, you should understand the basic concept of a data reader. If you've programmed for awhile, you should understand scope. And, if you've programmed with threads, you should understand running a lambda on another thread. (You probably should understand lambdas, too.)

That's a decent way of interviewing. It depends on the skill of the interviewer though, I can easily imagine someone handling it very poorly.

> 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

They are snake oil. You cannot predict success at some job by asking candidates to prove their ability at something that is only tangentially related to the actual job.

> The Validity and Utility of Selection Methods in Personnel Psychology: Practical and Theoretical Implications of 100 Years of Research Findings

> On the basis of meta-analytic findings, this paper presents the validity of 31 procedures for predicting job performance and the validity of paired combinations of general mental ability (GMA) and the 29 other selection procedures. Similar analyses are presented for 16 predictors of performance in job training programs. Overall, the two combinations with the highest multivariate validity and utility for predicting job performance were GMA plus an integrity test (mean validity of .78) and GMA plus a structured interview (mean validity of .76). Similar results were obtained for these two combinations in the prediction of performance in job training programs. A further advantage of these two combinations is that they can be used for both entry level hiring and selection of experienced job applicants. The practical utility implications of these summary findings are substantial. The implications of these research findings for the development of theories of job performance are discussed.

I've seen PhDs melt under pressure at two different jobs. Which tells me that an exceptional IQ or work ethic doesn't necessarily equate with success in the industry. Those two people had something in common, and it was their poor communication skills, both input and output. If your brain cannot process some coworkers feedback efficiently and it cannot spit out feedback efficiently, the logical / mathematical side of your brain is not going to make up for it.

In the case of JEE, kids spend pretty much anywhere from 2-6 of their teen years preparing for the exam. Leetcoding on an average, takes a few weeks to a few months depending on the person. And you're going to have to repeat the prep every time you interview (maybe spending less time than you did in the beginning but the ramp up takes time).

I see only one "scalable" solution to this problem: Something like a bar exam that people can take at regular intervals. This could have different levels that could unlock different jobs. Companies require that you pass the exam at a certain level and if there are too many applicants, a lottery picks the lucky numbers.

Basing an assumption out of thin air like this, we can throw the opposite argument: 'they might be predictive of failure in the job'.

Writers of bad code and choices mentioned by OP were likely hired out of a fantastic hacker rank score, and yet failed to produce good output.

A take home test requires spending free time for everyone. A whiteboard interview requires variable amounts of free time. I would wager that, on average, the people inside companies using these processes require less time to "grind leetcode" than the people outside those companies do.

You gotta be able to convince the folks on the inside, not the ones on the outside. To them, it being hard to "grind" might even seem like a good thing! "It's hard to cram for this compared to other sorts of tests!"

A common example brought up here on HN is binary search. It is usually simple to figure out that a problem requires Binary search and even which variant. But the differences between the variant are really small and you can very easily make a mistake when implementing it.

I have passed enough of these interviews myself and used to think similarly (all you need to do is learn the fundamentals and the rest will follow) but my hit rate went up substantially when I realized that I had to do the same problem again and again and it almost became part of my muscle memory. Looking at a new problem, analyzing it and then coming up with a novel solution takes a lot of time, and there are several mistakes you can make on the way. The interviewing culture today is to reject "false positives" so anything apart from a perfectly coded response results in a mixed/negative response.

This whole leetcode thing is a farce and has to end. Let's be honest, the Google guys used it because they wanted "like-minded people". In short, they discriminated based on their own criteria and successfully brushed it off as a "fair and unbiased" way of selecting people.

For leetcode, I can study once for a week or so, and then do a bunch of interviews at different companies, where each onsite is gonna take me a single day (4-5 hours or so).

For take-home projects, it usually takes way more time than that (about a whole week of a few hours every day). And it doesn't reduce the more I study or do those projects.

So no, thank you, I would rather take a single day to do a full loop with a company, as opposed to spending a week doing the same. Back when I was heavily interviewing last year, I could easily do leetcode interviews with about 1-2 companies a week without breaking a sweat. I did a take-home project a couple of times, and I am never going to do it again. The time sink on take-home projects is insane, and it is a much weaker signal. Given a lot of people here heard those stories last year where people were even trying to cheat on leetcode interviews (by asking other people to take those for them, and they eventually got caught), I imagine the cheating on take-home project is much more common and is much more difficult to detect.