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

71–80 of 675 posts

Re: Stop Interviewing with Leet Code

#71

Post by padjo »

galoisgirl wrote: post #58
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!

Why not both?

Opportunity cost and candidate experience.

I think an extra hour to talk will give me more information than watching them balance a binary tree.

For many people the stress of the leetcode session is just awful, I don’t think it’s a nice thing to inflict on someone if you’re ultimately going to disregard the outcome anyway!

Re: Stop Interviewing with Leet Code

#72

Post by BlargMcLarg »

rethab wrote: post #55
BlargMcLarg wrote: post #27

Earlier quoted context omitted.

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 g…

You obviously can't take the above in a vacuum and think it's fine. You could say the same for the advice of "give people work which resembles what the company does" leading to a situation akin to having interns doing minimum wage work for free, putting pressure on others as a result.

But as things stand, nothing is preventing companies from doing the above anyway. If they think you're a bad fit, they will use the probationary period to cut ties with you. This is perfectly viable today. Your example assumes current filtering methods do in fact increase the ratio of true : false positives, and taking some of them out would decrease that ratio. This is not something that has been proven, and I'd even argue it's something that can't be reasonably proven within the next few years. This is even worse when considering a few interview rounds can only filter for the most obvious dummies, but can't decisively tell you the performance of that individual a few weeks down the line.

What your example does show is how much power employers have over employees. It just isn't healthy for individuals to have to carry this amount of risk while corporates continue to reap the benefits.

Re: Stop Interviewing with Leet Code

#73

Post by varjag »

padjo wrote: post #33
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.

Right and it becomes your job to spot bullshit and bring people out of their shell. It’s not easy to do that, but who said hiring was easy!

Technical interview might not bring people out of their shell but sure helps filter out bullshit.

Re: Stop Interviewing with Leet Code

#74

Post by sdevonoes »

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.

If you hear bullshit, then that's easy: you filter out such people.

Not really silver-tongued candidates? Well, what's the problem? Unless you are looking explicitly for silver-tongued candidates, you should ignore this "trait".

Re: Stop Interviewing with Leet Code

#75

Post by Dowwie »

Someone who builds a truly novel technology solution involving hundreds of hours of effort gets filtered out of an interview involving contrived scenarios. You may have built the next generation X, but given an array of strings and a fixed width, can you format the text such that each line has exactly maxWidth characters and is fully justified -- in the next 30 minutes? Maybe you should have cultivated that skillset instead, because around here we value parlor tricks more than real world accomplishments.

Re: Stop Interviewing with Leet Code

#76

Post by j245 »

water8 wrote: post #51
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. th…

“Absolutely hilarious” that you’re forgetting there is usually a system design round that tests things like “setting up infrastructure on an enterprise-level”.

The coding round is supposed to test that.. you can code.

For the record I’m also not a fan of the Leet Code style rounds, even though I actually find completing them (outside of an interview) quite fun.

Re: Stop Interviewing with Leet Code

#77

Post by padjo »

varjag wrote: post #73
padjo wrote: post #33

Earlier quoted context omitted.

Right and it becomes your job to spot bullshit and bring people out of their shell. It’s not easy to do that, but who said hiring was easy!

Technical interview might not bring people out of their shell but sure helps filter out bullshit.

Does it though? Often times all it tells you is that this person probably saw this question before.

Re: Stop Interviewing with Leet Code

#78

Post by stevekemp »

Sakos wrote: post #45
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 everyt…

I've had a couple of sysadmin-interviews which were pretty interactive.

You're presented with a laptop connected to a remote VM, and told "Fix MySQL", or "Rewrite the git history in this repository".

Usually these are simple problems, which have obvious solutions. Every now and again you might get a surprise like an immutable-bit set on a file, or SELinux blocking access to specific files/paths, but the good thing about these kind of "challenges" is that you'll usually also have full google access.

I guess l33tcoding isn't really a thing for sysadmins, but I do appreciate a (fair) simple test like that, especially being given the opportunity to talk through the process.

Re: Stop Interviewing with Leet Code

#79

Post by pjmlp »

DarkWiiPlayer wrote: post #8
yieldcrv wrote: post #7

Earlier quoted context omitted.

Oh you focused on the “polishing” and not the “there’s nothing to show” part People good at their jobs because they do their job: nothing on github People in the business of performance theatre because they dont have a job to be good at: plenty on github. It can be legit code they wrote, that was not the point at all.

I half agree with this. I don't like the idea that every developer has to have code on github. If they want to code for work and nothing more, then that's fine and shouldn't disqualify them from any jobs. We shouldn't expect people to spend years of employment building up a portfolio for the next time they're looking for a job. However, I don't see how looking at the code people write isn't informative. You can see m…

The stuff I have on Github is a mix of university projects (about 30 years ago), forked stuff I keep in sync with main repo (just in case they go away), a couple of half baked projects that I occasionally touch on rainy days and lack the rigeur of what gets deployed into production at work.

But hey, maybe HR will be happy I have a GitHub account.

Re: Stop Interviewing with Leet Code

#80

Post by alphalima »

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…

Yes, I do exactly the same with a contrived example in a take-home coding assessment (with some failing test cases to not waste their time). Always seems to be a good indicator, especially of their ability to communicate technical concepts.
Post reply on HN