Live data from Hacker News

Stop Interviewing with Leet Code

fev.al

201–210 of 675 posts

Re: Stop Interviewing with Leet Code

#201

Earlier quoted context omitted.

It seems like a huge inefficiency in the economy that thousands of people are studying and practicing for an entrance exam that has no value in the real work that the companies actually do. But overall that may be a good thing for society. If Google fired all their leet coders and replaced them with real engineers they would not need as many. And the biggest problem may be that there is a limited number of real engin…

> replaced them with real engineers nice gatekeeping. Shame on them for working to get a job they want.

I want the airplane I am about to board to be flown by a real pilot.

Re: Stop Interviewing with Leet Code

#202
post #116
post #88

Earlier quoted context omitted.

> Someone who builds a truly novel technology solution involving hundreds of hours of effort This person should already have enough of a reputation to get a job at many companies, if their work is public enough. What do you suggest for the 99%+ other candidates?

> This person should already have enough of a reputation to get a job at many companies, if their work is public enough. But then why do people with that kind of reputation still (at certain companies) have to jump through these hoops? https://www.theregister.com/2010/04/21/ken_thompson_take_our... > What do you suggest for the 99%+ other candidates? What about (instead of forcing a months long decision process upon…

True Probationary period / uncertain employment is

1. Untenable for employees - of I have a mortgage or family or plans or obligations let alone a current job, taking this kind of risk is unacceptable

2. Untenable for companies - that's way too much investment.

Companies do have probation periods formally but they are exceeeeedingly rarely invoked, for above reasons.

Re: Stop Interviewing with Leet Code

#203
> you can pick a ticket and pair program. Have them review an actual PR. Etc.

This seems so obvious. If you pick a leetcode question, there’s always the risk that your candidate has memorized the answer to that particular question. But if you pick an actual bug/PR from your codebase, that problem disappears completely, and you get to see how they would perform on the actual job you’re hiring for.

Can anybody think of any negatives here? The only thing that comes to mind is that it might be seen as the employer trying to get free labor if they use a bug report that hasn’t been resolved yet.

Re: Stop Interviewing with Leet Code

#204

Earlier quoted context omitted.

I have over a decade of experience, including driving big technical change at one organisation, and was filtered out by a timed leetcode test. I put together a repository of leetcode practice, as I had a feeling that I would have bad luck on the day. They didn't look at this. The internal recruiter said it kept happening for seniors and people with a lot of experience, but his hands were tied, as the leetcode process…

>it kept happening for seniors and people with a lot of experience Why would this be? Old brains not being as "flexible" to think up novel solutions?

The tests aren't testing for competency at the job, and after a decade of experience writing software you have long ago realized that party tricks and cute algorithms are a fairly rare part of the job (generalizing here of course), so you stop thinking about them as much and get out of practice. When they do show up, you certainly don't have to do them in 10 minutes, and I think everyone would rather you didn't anyway, so that you write a robust solution rather than a clever one.

Students are often better at leetcode because school has been drilling this shit into them for the past three years, but it will probably be the last time they see such a compelling algorithmic challenge until their next leetcode exam.

Re: Stop Interviewing with Leet Code

#205

Earlier quoted context omitted.

Anyone using a Mac for tech related jobs has a high probability of using brew. That includes a lot of googlers

Google doesn't allow any code on laptops. Everything is done via web IDEs or ssh into a linux machine. So nobody is using brew to obtain dependencies.

Is the code being in a VM mutually exclusive with having homebrew installed?

Re: Stop Interviewing with Leet Code

#206

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…

Finding the bug was always my preferred interview problem.

Followed by "this code needs refactoring, go nuts, and then let's talk about what you did and why afterwards".

Re: Stop Interviewing with Leet Code

#207

All of these supposed "flaws" of leetcode are by design. Big companies want people who are smart enough to do the work, but obedient enough to put up with all the bullshit that comes with working at a big company. What person better matches that than someone who's able and willing to study for and pass a tech version of the SAT? Every anti-leetcode article I read is some version of "leetcode is bad because it measure…

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, and assess how you were breathing in case... you know... they hire you and then there's a business need for you to do 500 jumping jacks in five minutes.

They might not even end up hiring anyone different than they otherwise would.

Re: Stop Interviewing with Leet Code

#209

Considering the normalization of spending hundreds of hours grinding LC questions and the industry built around whiteboard interview preparation, my (n=1) conclusion is that LC interviews is not about technical assessment at all. It's an assessment that's designed to find people who are ready to submit to an endless grind with little to no skepticism. Developers who question the technical usefulness of LC interviews…

> Considering the normalization of spending hundreds of hours grinding LC questions and the industry built around whiteboard interview preparation, my (n=1) conclusion is that LC interviews is not about technical assessment at all. The “hundreds of hours” grinding LC is largely for juniors without experience. I don’t know any senior engineers who had to grind LeetCode like that for their FAANG interviews.

Assuming one needs to be a junior to become a senior that would be using the same filter twice.

Re: Stop Interviewing with Leet Code

#210

Earlier quoted context omitted.

It seems like a huge inefficiency in the economy that thousands of people are studying and practicing for an entrance exam that has no value in the real work that the companies actually do. But overall that may be a good thing for society. If Google fired all their leet coders and replaced them with real engineers they would not need as many. And the biggest problem may be that there is a limited number of real engin…

In your opinion, what's the difference between a leetcoder and a real engineer? In my mind, a real engineer really shines in the non technical aspect of things, like coordination, communication, prioritization, and getting hard questions answered. But that's just me, I'm curious what everyone else's experiences are.

I agree with all of those things. A real engineer has soft skills and the ability to look beyond the immediate problem to see what is at the heart of the issue. They can see the effects of a solution and see the problems that might arise from it. They see connections.

Leetcoders just find the most efficient solution for the problem at hand. They don't see connections to other problems, whether current or potential. They're a scalpel when you really need a massage.

I've seen leetcoders throw away less-efficient, safer solutions just to implement something more efficient and clever. And when things fail, they're nowhere to be found. Too busy with whatever current Story they're on.

Post reply on HN