Live data from Hacker News

Stop Interviewing with Leet Code

fev.al

491–500 of 675 posts

Re: Stop Interviewing with Leet Code

#491
I've interviewed at three FAANGs.

None of them asked any leet code questions (I was actually looking forward to the silly puzzle questions MS was notorious for at the time because I love those puzzles, even if I think they're bullshit in an interview. Alas it turned out all those questions were basically for PM positions :( ).

The only question I got that seemed particularly bullshitty was at Google, where it was one of those questions where basically you're expected to work out "the trick", it seemed to me to be very gotcha like. But that was just one question among many, across many people.

I've also interviewed many people over the years, and no one has asked any of those stupid questions. They are completely and utterly useless - I see a few comments here saying we're testing for conformance and that has never been involved in any of it, because again it doesn't provide any knowledge of technical skill. As an interviewer you're also aware that the person on the other side of the table is often extremely stressed or nervous. So we understand that you might make mistakes, or stumble on answers, etc - failing to account for such issues simply means potentially discounting good candidates.

As far a whiteboard coding goes, for myself, and I believe many of my co-interviewers a lot of what is actually being looked for is your thinking and problem solving - seriously, I cannot emphasize enough how you should talk through all your reasoning as you write. That allows us to know whether a logic error is a failure to understand/do the correct thing, or just a standard typo-style mistake that everyone does from time to time (again recall we know you're stressed). Also by and large we aren't looking for /perfect/ code (ok, some do but in reality it's worthless metric - I only got this from the gotcha interviewer at G).

Personally my interviewing I often don't care about the language, I'm interested in the solution, and generally accept pseudo code, or your preferred language.

Just a few general tips as an interviewer:

* When asked a coding question, repeat back what you're being asked, you want to confirm it (I've had people try to solve the wrong problem before), and have (where reasonable) some follow up probe/clarification questions.

* Follow on from above coding question. If you're answering on a whiteboard, remember that the interviewers know that the nature of the format means you might make simple/silly/"stupid" mistakes. Listen for any feedback they give you while answering.

* Additional follow on. Another cannot be emphasized enough point. Write test cases for the problem you're solving. Do it before you start the solution. It demonstrates that you understand the need for them, and provides another opportunity to ensure there's agreement on the problem being solved. It also lets you clarify things like the expected API - not part of the actual problem, but something needed for any implementation. Try to make your test cases cover "normal" and edge cases.

* Be aware that if you are nervous, stressed, or worried, the interviewers are aware of that, and know that that can cause errors you wouldn't normally make

* Try to have a reasonable awareness of the job that you're being interviewed for, some of the relevant things the company does/how it does [software dev, engineering, product management, etc], if at all possible. Either so you can ask questions that indicate you have some understanding, or so you can tie in what the company does as it relates to a particular question (if appropriate, don't just shoe horn things in)

* Be polite - this is a "be subservient" thing, this is just if you act like an asshole the interviewer won't like you, and that will impact what they report. I believe it's consistent across FAANGs that immediately post interview every interview send an email that is basically "Yes/No. Reason: .."

* Don't be sexist, racist, homo-/transphobic, or just generally a bigot - I am aware of one woman interviewer having a candidate assume she was an admin, and treated her as such. Another case where a woman was interviewing someone for a position reporting to her, where a candidate asked who his manager would be, found out it was her. Then told her to her face that he didn't think he could work for a woman. That indicates not just incredible sexism, but also just a complete lack of judgement and common sense. The latter alone would warrant a no hire.

Re: Stop Interviewing with Leet Code

#492

Earlier quoted context omitted.

It'd be a fun social experiment if one of the big tech companies replaced the leetcode-style rounds with something arbitrary. Let's say: The "jumping jacks" round. You have to turn your webcam on and do 100 jumping jacks in 60 seconds. Only then will you potentially advance to the next round. The person watching on the other end can evaluate how far over 100 you got, whether or not your form matches best practice, an…

I'm pretty sure that most of the benefit of FAANG-type interviews is narrowing the candidate pool to almost exclusively people who'd be OK to hire. IOW they could just hire randomly from the pool with no leetcoding at all, and likely do about as well. The trouble is, they actually can't do that because then the pool would change, quickly.

Google actually kept statistics on how much they liked candidates and how well they did after hiring. This has the obvious problem of not tracking those they turned down, or those who turned them down, but they published a paper on the results and IIRC basically found no correlation at all.

But I think like you say, what they did do was create a filter that only very patient and technically qualified candidates could get through. Beyond passing the filter, their very standardized process did not derive any useful information about candidates. But I feel pretty certain if they made an offer to every candidate and not just those on the pass side of the filter line, they would have seen some differences.

Re: Stop Interviewing with Leet Code

#493
post #239

Earlier quoted context omitted.

> More than obedience, it probably is the aspect that they're smart and determined to succeed. Yup that's what it's about! The problem with trying to test how good you are at the job is that you simply can't do it in a 1 hour (or even a 1 day) interview. You can however assess how smart somebody is, which is definitely correlated to job performance. It's also connected to growth potential - even if it were somehow po…

> You can however assess how smart somebody is Why not just give candidates a standard IQ test then? They are probably more reliable than Leetcode...

Because people are under the impression that it's illegal. That and I think a lot of people will make its use be about race, so people avoid it.

Re: Stop Interviewing with Leet Code

#494
On the flip side, I'm about to start interviewing some engineering candidates, and I have no idea what to do. I've been in the field for 8+ years now but interviewing for technical positions is hard and I've never seen a company really get it right. How do you have high standards without a ton of false negatives? How do you avoid reductive coding exercises without selecting for charming incompetence? Genuinely asking, are there any good resources on this?

Re: Stop Interviewing with Leet Code

#495
post #481
post #408

Earlier quoted context omitted.

I agree liking to ask simpler stuff first. But what about this more complicated stuff? My problem is that when we talk about stuff having more "signal" - how are we determining if those questions are giving us more signal?

My question is fairly open and allows me to continue asking significantly more complicated questions. So far, nobody has (for example) asked enough clarifying questions to determine that a bloom counting filter could potentially solve the problem- most people just store ASCII string keys in a hash table, which wastes tons of memory and requires a lookup for every string. So usually I end up after 45 minutes finding t…

But have you had a chance to look back and see if those questions worked out? Like, are they a good predictor for how the person actually performed in the job?

Re: Stop Interviewing with Leet Code

#496

Earlier quoted context omitted.

I'm pretty sure that most of the benefit of FAANG-type interviews is narrowing the candidate pool to almost exclusively people who'd be OK to hire. IOW they could just hire randomly from the pool with no leetcoding at all, and likely do about as well. The trouble is, they actually can't do that because then the pool would change, quickly.

Google actually kept statistics on how much they liked candidates and how well they did after hiring. This has the obvious problem of not tracking those they turned down, or those who turned them down, but they published a paper on the results and IIRC basically found no correlation at all. But I think like you say, what they did do was create a filter that only very patient and technically qualified candidates could…

My guess is that by the time the self-selection of people who think they're ready to apply and have a good enough shot to make it worth all the time the interviews take, happens, and they get to an in-person (having perhaps passed a less-harsh phone-screen leetcode question), most further leetcoding isn't doing much aside from keeping the self-selection effect strong.

The other parts of the interview might be doing something per se useful, I suppose.

Re: Stop Interviewing with Leet Code

#497

Don't get me wrong I hate LeetCode-style interviews as much as the next guy. In fact I really, really, really suck at them! Not sure if that says more about my ability then anything but c'est la vie In the defence of LeetCode-style questions, I do think they work, and very well may I add - with the caveat you have the throughput of candidate to make it work well? Their ability to filter out 'those who can't code' in…

I have had a great experience in a recent interview that used Byteboard. The format was two parts: First there was a design document in a Google Doc for a hypothetical system with three implementation options. All options were defendable, you just had to defend one in an essay-style answer. There were also various comments to respond to throughout the document.

The code part was a small existing codebase simulating the system in said design document. You you are given three tasks, and explicitly told you are not expected to complete all of them. I ended up using virtually all of the time (70 minutes) completing the first two tasks, and using my remaining minutes writing comments about how I'd complete the third task. When that was complete, I was given 15 minutes or so to describe what I would do if I was given another 15 minutes of time to work on the project.

My only real complains were that the time limit added some pressure (that I was able to manage reasonably) and that the grading process is opaque. I know a human grades it according to a rubric, but I don't see any of my results. The company I was interviewing for just said "Everything looks great, we're moving you forward to the next stage of the interview process".

The code didn't involve writing any fancy algorithms, but instead getting to know a (very small) existing codebase and understanding how to use it to add functionality. This is much more realistic a gauge of how good of an employee you are than how well you can implement a search algorithm from memory.

Re: Stop Interviewing with Leet Code

#498

Earlier quoted context omitted.

Cheers for clarifying :) I'll admit that surprises me greatly, I can't see why it's considered more efficient, but hey, Google.

Google has a giant monorepo. It is too big for git . (Virtually) everything is built from source. Building a binary that just runs InitGoogle() is going to crush a laptop. I believe that there are also a bunch of IP reasons for this policy, but from a practical perspective doing everything with citc and blaze is really the only option.

Can you share the order of magnitude we're talking about here?

Re: Stop Interviewing with Leet Code

#499

Earlier quoted context omitted.

Yeah, there are multiple blog posts from senior engineers who took 1-2 months off to grind LC just to get into Google/Meta etc.

> there are multiple blog posts from senior engineers who took 1-2 months off to grind LC just to get into Google/Meta etc. Don’t read too much into blog posts. This is engagement farming to capture search traffic and trending topics related to LeetCode. Taking months off to grind LeetCode all day isn’t common and doesn’t even make sense. LeetCode can be done on a lunch break. Even one problem per day in the evenings…

> Don’t read too much into blog posts. This is engagement farming to capture search traffic and trending topics related to LeetCode.

If that's true, then it should be fairly simple to defect from this prisoner's dilemma- just publish articles saying, "I didn't have to take months off to grind LC, I completed it through light prep and you can too!" In the realm of blog self-help, simple advice, framed with this sort of counter-common wisdom contrarianism, can be as popular as the ones that follow trends. Often even more popular.

But you don't really see articles like that. You do see some pro-LC articles from interviewers' points of view, but none saying, "It's actually easy! Here's three simple tips," despite the potential for search traffic capture.

Re: Stop Interviewing with Leet Code

#500
There has to be some sort of hiring "gate", what would be the replacement? It used to be a CS degree (which is even more restrictive).

FAANG jobs are in high demand due to salary, so now we have 5+ round interviews and leetcode as a low effort filter.

Post reply on HN