Live data from Hacker News

I am sick of LeetCode-style interviews

nelson.cloud

591–600 of 625 posts

Re: I am sick of LeetCode-style interviews

#591
post #471
post #77

Earlier quoted context omitted.

They do produce plenty of false positives - just not "you hire an idiot" kind. You will hire a person completely unsuitable for the actual job, but is good at leet. Issue is not the lack of intelligence. Issue is not being software engineer despite being good at algorithms. Or not being good at whatever your position requires. I do work in a team where majority was hired by puzzles of sorts. All of them are smart. Th…

So how do you find, in an interview setting, good software engineers? (And better than with LeetCode-style questions?)

Real-world problem, likely related to what you do. Simulate day-to-day problems. E.g. you are a marketplace business, ask them to do a simple basket system, or a checkout or a product catalogue etc. Ask them to review some code and provide their analysis.

FWIW I think LeetCode problems can make sense for some businesses, but most not.

Re: I am sick of LeetCode-style interviews

#592
Same here. I miss the days when you were given a take home or, god forbid, a real world problem, something the company has run into that you can work through with an experienced interviewer.

Some of the worst interviews I've had I've felt like I was a lab rat, just being evaluated for specific traits/reactions. The worst part is, like you said, every Tom, Dick, and Henry does this, its somehow become some kind of lazy industry standard hiring practice, hence the explosion of these interview aid services. Some people will argue it serves a purpose, but I really don't see how. It's like memorizing an answer sheet and doing well on a test. Is that really the type of problem solving you're looking for? Don't get me wrong, I do think its important to understand foundational concepts and algorithims, but like.. it's also the first thing thats abstracted away for good reason in the real world. Anyways its shit.

The worst part is even with my experience I still feel like shit after these calls though I should know better.

Re: I am sick of LeetCode-style interviews

#593
post #237

Earlier quoted context omitted.

At all the companies I’ve run we’ve used a simple whiteboard example for this reason. Don’t worry about typos; how does the person think. “Trick” questions are dumb, but you want to get an idea of if the candidate knows their stuff (and let the candidate know what we’re like — interviewing is a sales process in both directions). If someone asks a question like “is it ok to modify the argument” (or says “I’ll assume I…

I agree with all of this. Leetcode questions are fine as long as they aren't actually difficult maths puzzles or brain teasers. We also used atoi/itoa loads and it was pretty much the perfect difficulty. Though I still do start with a short fizzbuzz-level question because you would be surprised how many people fail that and it makes it way less awkward if you start with atoi and they can't write a loop. If they fail…

    > We also used atoi/itoa
Do you mean the C function atoi() to convert a string to number? If yes, I also used the same technical interview question for year. It is a nice "fractally complex" (many levels of depth) question. Everyone can understand it in 10 seconds, but you can really show your experience when you get into the edge cases and unit tests. Plus, if the candidate is a bit junior, you can push their boundaries by asking about different edge case and watch how they react. Similarly: I had a teammate for a few years that asked people to program a very simple linked list class. He was shocked how many mid-level devs couldn't do it. As I recall, he never sent me a bad candidate, so it was good enough for us.

Re: I am sick of LeetCode-style interviews

#594

I understand the frustration, but at the end of the day I think they do serve a purpose. They're not great at that purpose, but they're good enough and they generally produce false negatives (smart people fail) rather than false positives (you hire an idiot). And this makes sense, because a false negative is low cost (maybe you spend 50% longer interviewing candidates) but a false positive is high cost (you hire an i…

Okay, do do quizzes, but let people google goddamn stuff because that's just how software engineers operate. Don't make it an exam. Don't mimic the worst thing about the education systems. Both in the school and in the university, these goddamn exams were the worst because they tested memory first and everyone else second , and I'm such a kind of person that I could never remember things on command. It was a real str…

I like this idea as the more advanced version of whiteboard programming from the year 2000. Even if you still do whiteboard programming, give them a PC / tablet, and allow them to do some Google searches. Then, you could even make the problem a bit harder to solve. Again: You are looking at the candidate's problem solving process holistically. I also very much agree with your second paragraph. Some of the most pleasant surprises I had during interviews were candidates who had very limited domain knowledge, but tried as hard to possible to make educated guesses, or ask intelligent questions. It shows a lot about a candidate.

Re: I am sick of LeetCode-style interviews

#595

Earlier quoted context omitted.

Were those juniors with no experience developing features? Leetcode doesn't test if they have experience, you need to check both if you want someone that can do everything. Someone who does well on leetcode is usually easy to teach so they will become good/great in a year or two, but if you don't have that time then go for leetcode+experience just like everyone else is.

Leetcode deselected too many good experienced candidates, which is really who I prefer to hire. I have hired good leetcode juniors that did not improve and are no longer working in software.

Did you select candidates with easy / medium / or hard LeetCode problems? Honestly, without studying, people need to be top 5% of candidates to solve hard problems. You can find real algorithms stars with those problems, but you will also pass on a large percentage of "good enough" candidates who can do a medium problem with a bit of hinting.

Re: I am sick of LeetCode-style interviews

#596

Earlier quoted context omitted.

Giving people real world problems and pairing with them on finding a solution.

I'm retired now, but I used a variant of this that worked well for me. In my experience, much of what we do as engineers is learn new tools and application domains and apply what we learn to solve problems. So I wanted to test how good a candidate is at leaning and whether they appear to enjoy it (good and enjoy often correlate). We would work together at the whiteboard, with me teaching them the basics of our applic…

    > One thing that I think leet code interviews get very wrong is that interviews involve two sides trying to evaluate each other. Wearing people down with leet code is not a good pitch for your work environment.
This is huge and is underrated. Even when I have (_rarely_) passed the most bruising interview process, my emotional state was so negative towards the company. Part of the OP's emotional state (exhausted / burned-out) is the result of an adversarial interviewing style. With your style, you can gently push people to the edge and see how they perform. Your style is more dynamic, which more closely matches real world working conditions.

Re: I am sick of LeetCode-style interviews

#597

I understand the frustration, but at the end of the day I think they do serve a purpose. They're not great at that purpose, but they're good enough and they generally produce false negatives (smart people fail) rather than false positives (you hire an idiot). And this makes sense, because a false negative is low cost (maybe you spend 50% longer interviewing candidates) but a false positive is high cost (you hire an i…

>because a false negative is low cost (maybe you spend 50% longer interviewing candidates) this would make sense if they filled these positions in 2,3 weeks tops. But that's the insane part; I hear of interviews going on for 6-7 stages now, lasting almost 6-10 weeks. At that point I feel you are no longer avoiding false positives, but simply hiring the most desperate programmers willing to jump the hoops. The best ca…

First, I am sympathetic to your experience. It must be difficult.

    > I hear of interviews going on for 6-7 stages now, lasting almost 6-10 weeks.
From this story, it is clear that your market is clearly in favour of the employer. One year ago, it was a different story: half the time. Another thing that will hurt: If you are amazing, that 6-10 weeks will suddenly become 1-2 weeks. In my experience, nothing hurries the interview process more than telling an employer about late round interviews (or offers) at another competitor.

Re: I am sick of LeetCode-style interviews

#598
post #471

Earlier quoted context omitted.

So how do you find, in an interview setting, good software engineers? (And better than with LeetCode-style questions?)

12 hour take home assessment

Are you trolling? Do you pay for that? Sheesh.

Re: I am sick of LeetCode-style interviews

#599

I understand the frustration, but at the end of the day I think they do serve a purpose. They're not great at that purpose, but they're good enough and they generally produce false negatives (smart people fail) rather than false positives (you hire an idiot). And this makes sense, because a false negative is low cost (maybe you spend 50% longer interviewing candidates) but a false positive is high cost (you hire an i…

Hard leetcode questions hire grinders, not thinkers. Many of those questions were thesis/publication-worthy decades ago when first solved; it's unlikely for even a very intelligent person to produce a similar result in just tens of minutes. So if someone solves it, it's much more likely to be because they saw it or a similar question while grinding practice questions than that they genuinely derived the optimal solut…

    > Many of those questions were thesis/publication-worthy decades ago when first solved
The hare and tortoise (cycle detection via Floyd's) is a legendary impossible interview question. It wasn't solved until the 1960s with a PhD thesis. It is a hard problem to face in an interview. I had seen it twice in my career. I failed the first time. The second time I had the answer memorised, then put on my very best Morgan Freeman stage acting to pretend I was discovering the answer during the interview. What a joke. I was laughing to myself as I was "stumbling" towards the answer while the interviewer was providing minor hints.

Re: I am sick of LeetCode-style interviews

#600

Earlier quoted context omitted.

Hard leetcode questions hire grinders, not thinkers. Many of those questions were thesis/publication-worthy decades ago when first solved; it's unlikely for even a very intelligent person to produce a similar result in just tens of minutes. So if someone solves it, it's much more likely to be because they saw it or a similar question while grinding practice questions than that they genuinely derived the optimal solut…

I disagree with this. I can solve the majority of leetcode hard problems in under an hour despite not having seen them before and I'm far from the smartest person I've met.

You had to know this was going to get a lot of downvotes.

However, I have a real question as a follow-up: Have you been able to profit from this skill? If true, you should be able to crush any "whiteboard" programming interview. If I had it, I would move every 2-4 years and get large pay rises. You should definitely be able to pass FAANG interviews with that skill.

Post reply on HN