Live data from Hacker News

Stop Interviewing with Leet Code

fev.al

121–130 of 675 posts

Re: Stop Interviewing with Leet Code

#121
post #75

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…

Asking contrived algorithmic puzzles might prove nothing, but the examples in TFA are actually pretty basic programming:

“I have an array with positive numbers, find the n^th largest”

Re: Stop Interviewing with Leet Code

#122
I once failed a leet code graph problem because I solved it with a genetic algorithm.

The problem wasn’t that I was incapable of solving the problem, it was the narrow view of possible solutions. The interviewer was looking for the CS101 solution.

My biggest gripe with leetcode is they tend to filter diversity of thought.

Re: Stop Interviewing with Leet Code

#123

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

And last but not least they are geared towards puzzles of the type encountered during CS education. Thus they are age discriminating and they are non CS discriminating.

Re: Stop Interviewing with Leet Code

#124

Earlier quoted context omitted.

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

And last but not least they are geared towards puzzles of the type encountered during CS education. Thus they are age discriminating and they are non CS discriminating.

Even with my CS education, it's been over 15 years since I graduated, to say i'm rusty on the more academic things would be an understatement.

Re: Stop Interviewing with Leet Code

#125
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!

There are candidates that can talk circles around many questions and yet can't really write code.

Re: Stop Interviewing with Leet Code

#126
Whether someone gets a correct answer with a code challenge should only be a single factor in hiring. You should also look at how the attempt to solve the problem. Do they ask further questions? Do they talk it out?

There’s probably other factors I cannot think of too.

Re: Stop Interviewing with Leet Code

#127
post #75

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…

Asking contrived algorithmic puzzles might prove nothing, but the examples in TFA are actually pretty basic programming: “I have an array with positive numbers, find the n^th largest”

yeah, but in real world when this kind of problem will need to be solved people will most probably sort O(NlogN), or use priority queue O(NlogK), or even will go with something like O(N*K), almost no one will go with O(N) algo and because usually N and K are rather small and this code will not be called too often time complexity may be ignored. Still any solution shorter than O(N) will be called inefficient. And in real world they will know N and K from this what kind of problem they are solving, and this will not be hidden in mist of abstraction with assumption that "candidate should ask".

Re: Stop Interviewing with Leet Code

#128

In my team we do technical interviews in three steps: - an algorithmic challenge. It's related to what we do day to day. I work in domain names so we ask to parse a domain name. There are oddities with domain names so we check multiple things: does the candidate know what basic string manipulation functions exist? do they ask questions to get more info? how do they react when we give additional info that break the co…

This is great, I would totally like to interview like this.

The best one I had was a task where you have to basically brute force an api endpoint that uses a semi known password (you have to generate all permutations of a string with alterate spellings ex "pA$Sw0rD" and one of them will match), if you succeed the endpoint returns a url & token to upload your zipped solution. So you end up with a console application that has: network requests, string manipulation, concurrency/parallelism/throttling if you want (I did it to impress, wasn't a junior role), file access (zip & attach & send async), some error handling, good console outputs/logging and comments.

When you go to the interview we basically discuss the code I uploaded with one of their senior developers, what compromises I made, how would I improve it and so on. I got the job back then but since moved on. But that was the best interview process I've seen in my career. No leetcode etc, just a basic application that test if you know how to do a bunch of different things, without it being a whole framework mess or a whole product in some cases. it took about two hours, so the balance between spending time on and getting judged for my skill was good; it felt fair & realistic.

Re: Stop Interviewing with Leet Code

#129
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?

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?

Re: Stop Interviewing with Leet Code

#130

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.

But that's not a problem. These companies pay so much that they have too many candidates applying all the time, so missing good engineers is not a problem, but filtering out false positives is.

Though, I don't agree leetcode is a good interview practice.

Post reply on HN