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

41–50 of 675 posts

Re: Stop Interviewing with Leet Code

#41

Post by haspok »

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.

Leetcode should only be used for easy problems - FizzBuzz types - where you are checking that the candidate can code at all, probably as the very first round of an interview. This way, I think it is totally fair, including a relatively tight time limit. The harder the problem is, the more you focus on the special skill of leetcoding, and not much else.

Re: Stop Interviewing with Leet Code

#42

Post by ChrisMarshallNY »

cik wrote: post #30

Instead, I offer to share a private GitHub repository, (if not some open source) with the prospective employer. It offers them the ability to see how my code changed over time, how it ended up, and the quality and calibre I may or may not devote to projects. It invites a conversation, in depth, about software construction, quality, and decision making from the point of view of real work. It also tells me if a company…

My experience is that employers refuse to do this (I have dozens of repos, with tens of thousands of lines of code, entire shipping applications, a decade of checkin history, dozens of Web articles, and hundreds of pages of documentation and project planning artifacts). I even had one indicate that “I probably faked it.” It was jaw-dropping.

In fact, I have so much stuff out there, in the public realm (I’ve been doing open-source software for decades), that employers could easily evaluate me technically, without ever contacting me, and all they’d need to find out, is whether or not I’d be a decent team fit.

I suspect that the main reason they ignore my portfolio, is that they have already decided that they aren’t going to hire me, and don’t want to waste their time, reviewing my work.

Re: Stop Interviewing with Leet Code

#43

Post by jgilias »

AlexTWithBeard wrote: post #24
padjo wrote: post #16

Just talk to the person, ask them about projects they’ve worked on, problems they’ve solved etc. you’ll learn far more about them that way than getting them to put on a dog and pony show at a whiteboard!

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, instead of just letting them produce canned stories and responses.

But, yes, this is more work on the recruiting side.

As a side note, I totally get it why large organizations would use Leetcode though. It does help filter out false positives if you're willing and able to bear the cost of passing on many good candidates.

Re: Stop Interviewing with Leet Code

#44

Post by BlargMcLarg »

Beltalowda wrote: post #35
sdrothrock wrote: post #21

Earlier quoted context omitted.

> I am also not sure of any good alternatives because someone will always object to any alternative which they cannot achieve for some reason. When I was on the market, a couple of companies actually gave me a variety of options, which I appreciated. I don't want to spend hours on a take-home and I also don't want to do leetcode, but an open question/answer plus some code review and live debugging was an acceptable c…

Whenever they ask me to do a take-home I make a mention that I have about 150k lines of code on GitHub; this is usually ignored. Now, I somewhat understand why larger companies just "follow procedure, even if it doesn't strictly makes much sense" for various reasons, but what baffles me is that even a lot of smaller companies do this; which seems odd since a lot of places I interviewed at are kinda desperate for deve…

>but what baffles me is that even a lot of smaller companies do this

You named the exact problem with the industry.

No one is going to complain if FAANG does this with top tier, life changing salaries. No one will object to learning and memorizing DS&A at a job where DS&A is used heavily.

What people are upset about is your average no-name company hiring individuals based on things they won't use during the job, of which the knowledge is still incredibly varied[0], and they still complain about not being able to find anyone and play the "woe is me" card.

[0]: Dare I say it, DS&A is such a big topic not everyone learns the same things. Thinking in terms of a tree is different from thinking in terms of a linked list, graph, tree, heap, stack, queue, you name it. Most LC medium/hard require time you won't get, information you might not have. This knowledge isn't as universal among skilled graduates as people like to believe. And we all know the moment candidates are able to just memorize questions about linked lists, hiring will jump to the next topic.

Re: Stop Interviewing with Leet Code

#45

Post by Sakos »

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…

Man, I would rock that so hard and I wish more companies would do this. My current job did a live coding exercise in the interview, which went okay. The interviewer gave me a chance to iterate on the code and improve it after our call and send it by email an hour later. My solution by then was far better than what I'd had at the end of the interview, once I had a chance to gather my thoughts in peace and think everything through thoroughly.

Re: Stop Interviewing with Leet Code

#46

Post by franga2000 »

totorovirus wrote: post #14

I keep seeing this kind of article that leetcode is not the answer. Yes it is not the answer but the best strategy to filter out not dumb, low IQ people who are going to panic when you give a vague, open ended problem. There are many people who call themselves engineers while trying to talk everything out instead of diving deep into problem.

You know what else will filter out dumb people? A vague open ended problem that is relevant to the position you're hiring for. Have them write an abstraction layer for two different implementations of [insert relevant problem here] or refactor messy duplicated code into reusable [methods/components/modules]... Better yet, find an actual problem that your engineers actually had to solve in the past and see how they do it.

Re: Stop Interviewing with Leet Code

#47

Post by nivenkos »

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…

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" approach doesn't really exist here in Scandinavia, even though there is a probation period it's still frowned upon to use it for anything but extreme circumstances, and if done en masse would likely raise issues with the trade unions.

Re: Stop Interviewing with Leet Code

#48

Post by unwind »

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…

So you basically implemented an analog version of Stack Overflow? :) That sounds really nice, once you get over the idea that people will show deliberately broken code (most folks on SO just don't know better, or at least that's my hope). Thanks for sharing!

Re: Stop Interviewing with Leet Code

#49

Post by sdrothrock »

Beltalowda wrote: post #35
sdrothrock wrote: post #21

Earlier quoted context omitted.

> I am also not sure of any good alternatives because someone will always object to any alternative which they cannot achieve for some reason. When I was on the market, a couple of companies actually gave me a variety of options, which I appreciated. I don't want to spend hours on a take-home and I also don't want to do leetcode, but an open question/answer plus some code review and live debugging was an acceptable c…

Whenever they ask me to do a take-home I make a mention that I have about 150k lines of code on GitHub; this is usually ignored. Now, I somewhat understand why larger companies just "follow procedure, even if it doesn't strictly makes much sense" for various reasons, but what baffles me is that even a lot of smaller companies do this; which seems odd since a lot of places I interviewed at are kinda desperate for deve…

> what baffles me is that even a lot of smaller companies do this

Thoughtfully creating an interview process and the procedures/questions is a skill that has to be learned... and when people haven't or don't have the opportunity to learn that skill, it makes sense to turn to resources like books or articles, the most popular of which are often based on FAANG practices.

I also know from my own experience structuring and performing interviews that there can also be a lot of pressure from the top to eliminate candidates following the belief that "the last one standing" is the best, rather than actually trying to evaluate the strengths and weaknesses of every candidate.

That way tends to lead toward interviews of 5-7 rounds that act as sieves.

This is all just my limited personal experience though and I'd love to hear from other people who've done interviewing at/for smaller companies!

Re: Stop Interviewing with Leet Code

#50

Post by andrewingram »

tick_tock_tick wrote: post #15

I don't really understand the point almost all of the thing they list as downsides of using Leet Code are actually benefits. If someone can't manage to code some simple questions during an interview I can't imagine they'd ever make real contributions.

I haven't done many Leet Code-style interviews, but the ones I have are usually simple-ish problems I'd have no difficulty with under normal circumstances, and yet I fail them at least 50% of the time.

There are a couple of things at play here:

1. I'm regularly complimented on how sharp my mind is, but I can't reliably recruit that sharpness on-demand. If I get any kind of brain fog during a timed problem (with no opportunity for a break), it's game over.

2. Coding in an unfamiliar environment, like Coderpad.

The problems are hard enough to make them easy to fail if you can't spot a good approach immediately, but easy enough that a "good" answer gives very little signal relative to the time being dedicated to the problem. I've done interview processes where 50% of the total process is given over to these kinds of problems, and the process concluded with me feeling I didn't get any real opportunity to demonstrate my strengths.

Post reply on HN