Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Interviewing with Leet Code

fev.al

Post reply on HN
Print view View original

51–60 of 675 posts

Re: Stop Interviewing with Leet Code

#51

Post by water8 »

nivenkos wrote: post #22

It's much better than the alternative and ideally only one part of the interview process. Ultimately the proof is in the pudding, I've had loads of candidates that could barely code and Leetcode-style problems are a great filter against that. Otherwise you risk just getting PM-style bullshitters as engineers, who talk persuasively about projects that other people actually implemented.

It’s absolutely hilarious you think leetcode would give you the skills to design anything larger than a simple website. I don’t recall leet code ever talking about how to set up an infrastructure that has reliability on an enterprise-level where seconds of downtime means millions of dollars lost. But you’ll be really good at hash maps and quicksort which make for good worker drones, not necessarily good engineers. that requires outside the box thinking, The opposite of the type of memorization leetcode encourages

Re: Stop Interviewing with Leet Code

#52

Post by BlargMcLarg »

nivenkos wrote: post #47
seer wrote: post #38

Earlier quoted context omitted.

People who can do leetcode challenges are only roughly correlated with great engineers. The more I learn about software development the more I try to _not_ have leet code style parts in my code - in the very rare circumstances would I see something like that and say - yes there is _no_ other library out there that has a battle tested algo to solve this particular problem, _and I have to code my own_. Worse people who…

I think it's fair to do two Leetcode Easys - ideally with problems that allow you to ask further questions about memory management (when are allocations triggered, etc.), recursion, stack frames, adjacent memory location for efficient reads and so on. The problem is that a take-home task can be impossible for some people already in a full-time job with kids, etc. and so has its own bias. And the "hire fast fire fast"…

>memory management (when are allocations triggered, etc.), recursion, stack frames, adjacent memory location for efficient reads and so on.

This sounds incredibly specific. Most places requiring at most LC easy don't really need any of this, and I'd be worried about the interviewer looking for key words and specific answers over actually testing whether the candidate grasps things or can learn what is necessary.

Re: Stop Interviewing with Leet Code

#53

Post by mrtksn »

jamesdhutton wrote: post #28

In a previous job of mine, we would show candidates a printout of some buggy code, and ask them to find the bugs. We would leave the room and let the candidate work through it on their own. The code in question was basic algorithms and data structure stuff in C++, such as inserting into a doubly-linked list. I always thought it was a good exercise. Suits slow-thinkers and nervous people, and it's a good test of codin…

Was the bug in the algorithm resulting in wrong results? Was it a kind of implementation bug that happens due to peculiarities in the language/compiler?

Re: Stop Interviewing with Leet Code

#54

Post by jeanloolz »

meowtimemania wrote: post #26

I think for large companies where they want to reduce the number of false positives, leetcode style questions work well.

Was contacted by Facebook recently for a data engineering position and was told I had to grind some leetcode to prepare for the interview process. I just could not be bothered and I can not be the only one who made that decision. My guess is that companies relying on leetcode style interview are also missing on some very capable engineers who just don't want to grind leetcode outside working hours.

Re: Stop Interviewing with Leet Code

#55

Post by rethab »

BlargMcLarg wrote: post #27
lbriner wrote: post #13

These articles always seem to have an underlying assumption that really great people are being denied access to jobs because they can't get through these interviews but it is implying that the people who do get through these are not also great but are less hassle, easier to measure their ability and so what if they have swatted up on LeetCode to help their application? That means they are driven, that they have learn…

The alternative is to push companies to pay for long interviews, be realistic with their requirements (stop asking LC for simple CRUD work), have some faith in schooling, start carrying some risks again, and use the probationary period for what it's designed. What's happening is companies are putting the burden of the risk on candidates more and more. Because they can. If candidates would put their foot down and stop…

> use the probationary period for what it's designed

This is probably fine in an environment where the candidate has lots of other options, but think about this scenario: a person applying to multiple companies, possibly rejecting some offers, possibly relocating or otherwise changing their life, accept that one offer, and then be let go in their first weeks. Changing jobs can be emotionally difficult and being let go even more. If you have to restart your job search, because you were let go during the probation period, all the other roles you have applied to might have been filled. On top of this, contrary to when you were looking for a job last time, now you're actually unemployed and potentially under pressure to find something new.

So, in essence I don't think this is good for candidates.

Re: Stop Interviewing with Leet Code

#56

Post by jamesdhutton »

mrtksn wrote: post #53
jamesdhutton wrote: post #28

In a previous job of mine, we would show candidates a printout of some buggy code, and ask them to find the bugs. We would leave the room and let the candidate work through it on their own. The code in question was basic algorithms and data structure stuff in C++, such as inserting into a doubly-linked list. I always thought it was a good exercise. Suits slow-thinkers and nervous people, and it's a good test of codin…

Was the bug in the algorithm resulting in wrong results? Was it a kind of implementation bug that happens due to peculiarities in the language/compiler?

It was a bug in the algorithm, resulting in wrong results. For example, I recall that to fix the linked-list insertion code, you needed to add a line of code to increment a pointer.

Re: Stop Interviewing with Leet Code

#57

Post by tecleandor »

jgilias wrote: post #43
AlexTWithBeard wrote: post #24

Earlier quoted context omitted.

Talk to the person and you will (1) hear a lot of bullshit and (2) filter out a ton of good but not really silver-tongued candidates. P. S. I hate coding interviews.

I've found that it's relatively easy to figure out if someone is bullshitting. It just takes some work on your end by researching the candidate's application a bit deeper, thinking about relevant questions beforehand, and then drilling down during the conversation. I've hired 'non-silver-tongued' candidates this way, as well as filtered out people who were bullshitting. The key is to actually have a conversation, ins…

Yep. I've found that you can give someone enough rope to hang theyself. If you let them explain their processes and ways of working, most of the bullshitters will out themselves :D

Re: Stop Interviewing with Leet Code

#59

Post by lordnacho »

meowtimemania wrote: post #26

I think for large companies where they want to reduce the number of false positives, leetcode style questions work well.

Has this ever been tested properly? Has anyone ever given a failed candidate the job and monitored how they did compared to candidates who passed the LC?

Re: Stop Interviewing with Leet Code

#60

Post by mellavora »

seer wrote: post #38
nivenkos wrote: post #22

It's much better than the alternative and ideally only one part of the interview process. Ultimately the proof is in the pudding, I've had loads of candidates that could barely code and Leetcode-style problems are a great filter against that. Otherwise you risk just getting PM-style bullshitters as engineers, who talk persuasively about projects that other people actually implemented.

People who can do leetcode challenges are only roughly correlated with great engineers. The more I learn about software development the more I try to _not_ have leet code style parts in my code - in the very rare circumstances would I see something like that and say - yes there is _no_ other library out there that has a battle tested algo to solve this particular problem, _and I have to code my own_. Worse people who…

> c) but I've put a human being in a very uncomfortable position just to _test_ them. There _has_ to be a better way.

> ...

> Or even "hire fast fire fast" approach works too.

Comment "c" shows a high level of care/concern for the candidate. "hire fast fire fast" does not.

What if the candidate left an unsatisfying but steady job to join your company? And they get fired in the first few weeks. Now they are unemployed. This is much more uncomfortable than an awkward interview question.

Post reply on HN