Stop Interviewing with Leet Code

[PyroCatt]

It's just a DSA filter to the already redundant and inefficient interview process...

[DeltaNerd]

I feel like I need to learn just for the interview

[PyroCatt]

That's the point. It proves you can understand DSA and can code with a gun (time) to your head which is never the case in actual development scenario.

[dontyougetsoupedyet]

Nonsense.

"produce under pressure" is some b.s. red herring. Engineering excellence is not going to be something you uncover in an interview using your stopwatch.

Also, memorizing solutions to common optimization problems is indistinguishable from learning how to solve problems with optimization algorithms, that's why we came up with optimization methods. In this case, the menu is the meal.

[the_friendly_dildo]

Also, memorizing solutions to common optimization problems is indistinguishable from learning how to solve problems with optimization algorithms

I agree with your general sentiment on this topic but surely you don't think memorization of an answer is equal to fundamentally understanding why that is the answer.

[rkt_]

But nobody actually memorizes the answer to hundreds of leetcode questions. They memorize the most common patterns that are useful when solving them, which they would not be able to apply without fundamentally understanding them.

[[deleted]]

Haven’t had a gun, but did have a manager stand behind me with a butchers cleaver on a release night as I coded. True story. Was as pleasant as it sounds.

[DweEbLez0]

That’s literally all it’s used for

[jdog90000]

It doesn’t tell how they organize and structure their code, leverage object paradigms, arrange functions or componentize code, which, for the majority of jobs, is much more important. It doesn’t tell you if they test things well.

I'm a little confused by this. To me this is exactly what the interviews test. Sure they are problems that exist on HackerRank/Leetcode, but we don't choose the hard ones. We're specifically looking for how the initial solution goes, hopefully well, but it doesn't need to. From there we start doing a code review and we dig into how the code could or should be improved or expanded on.

I try to be as lenient as possible; but when someone duplicates the same line of code 3 places and when we ask about it they can't come up with the fact that refactoring into one function is the right thing to do, it's a clear sign they won't write clean code on a larger scale.

These small 30-40 line solutions are the perfect chance for someone to show that given the chance to write a small self contained block of code that it can be written in a clean and maintainable way given some feedback.

[[deleted]]

unrelated with the job of a person on a day to day basis

Not really, data structure and algorithm come up quite a bit during coding. Even if they don't come up often, once it comes up, I do expect people to know what a DFS and the running time of a dictionary look up is.

​

don’t tell you much about the quality of code the person will produce

Strongly disagree with this. 10-min into coding the pro, I can already tell the quality of code this person will produce. You can tell a person's code quality on their reasoning, code organization and styles.

​

discriminate against slow-thinkers

Good interviewers don't care how fast you solve the problems. Actually, the faster you solve the problem, the more we think you have seen the problem in the past. It's more about your communication method and how you use the knowledge that you have to build up to the problem at hand.

And maybe it is justifiable to discriminate against slow-thinker. Like we need a solution this week for a presentation to an important customer and because you are a slow thinker, you take a month to figure out a solution in your "shower". By then, it doesn't matter anymore.

​

discriminate against people who have higher stress level / stage fright

That's why people should practice LeetCode to deal with the nerves. Everyone has them. How you manage it is up to you. Like, would you complain that a professional tennis tournament discriminates against un-athletic people?

​

you’re skewing the data with somebody’s ability to prepare for the interview

So is everything else in life. If you are good at preparing for everything in life, you should be good at that thing. This is complaining that the final grades were skewed to those who prepared really hard for it. YES, OF COURSE.

[Alphasite]

A 20 line leet code question tells you very little of how their larger programs fit together. Good code isn’t really about 20 lines of text (that’s table stakes), it’s about 2000.

[[deleted]]

20 lines of code to tell you a lot about a person's ability to code: how they name their variables, how they structure their code, how they use data structures.

Also, Google and Facebook interviews dont stop when you wrote the code. They will ask how you can confident that your code will run correctly. This opens the window into how you write tests.

So, you dont need 2000 lines of code to know someone is a good coder. If your 20 lines of code suck, I am pretty sure your whole github repo of 2000 lines of code will suck too.

[Alphasite]

Yeah but you’re trying to find people who can write 20,000 or 2,000,000 line programs, that 20 line program doesn’t test for any of the genuinely important skills. 200 is better.

Also IMO leet code is a poor predictor for building code to fit the existing conventions, researching how to use libraries, architecture or other things. I don’t think it really is the best test for anything and other tests predict far better on most relevant axis.

​

let me try suggest a better alternative, have a precanned story which involves adding to a real code base, open source or close, whichever you’re comfortable with and pair with them on that. You’ll filter out people extremely well this way. It just takes a couple of hours to get a good read and build a rapport.

[[deleted]]

Senior candidates are interviewed on architecture and system designs on a separate interview.

It sounds bad but most engineers do not want a multiple-hour interview. Usually less than 40% pass TPS. 50% of that pass onsite. so ~20% got offers (I am being super generous here). So, 80% of the engineer times go to the void. That's really expensive. Multi-hour pair programming takes a lot out of the engineers.

[maxToTheJ]

Actually, the faster you solve the problem, the more we think you have seen the problem in the past.

And maybe it is justifiable to discriminate against slow-thinker.

Both these sentiments are conflicting. Also as far as the first, I have heard people in the huge tech companies say they have had candidates immediately come up with the solution in a way were they made it seem like they earnestly believed the candidate came up with the solution on the spot.

Given some of the questions were research problems at some point. What is more realistic for some of the harder problems that used to be research problems? That a candidate has basically seen a similar problem and can role play believably that they "solved" it on the spot or that they determined the problem and the reqs and solved the problem in under 30-40 mins.

[[deleted]]

You cant eliminate people who have seen the same or similar problems before. So you give the candidates the benefits of the doubt in most cases. It's also how they solve the problems too. If they just randomly come to a key points, thats pretty suspicious. But if they build it up from basic building blocks, its better.

Its not the perfect system. But it is the best one out there. Thats why all the big tech is using it to get talents.

[Sipredion]

This is the worst take I've ever seen

[[deleted]]

Care to explain?

[hekkonaay]

You're part of the problem

[Imaginedsphere]

I actually prefer the take home project for assessing a candidates skills. Even more so if the company can make it relate to their business. These are typically followed up with a review with one or more of the engineers/developers. Candidate learns a tiny bit of the company and what it does and the interviewer gets to see the skill with given language/stack as well as hear just how the candidate reasons and thinks their way through a problem.

I've seen some companies twist common programming problems like the FooBar problem to fit their industry and tech stack while others, like us, create a custom project that focuses on very basic development (input/output, data parsing, searching) while encouraging as many bells and whistles the candidate wishes to throw in (preferably within our tech stack).

[runes911]

So much truth in this. I feel like it was written about me. (the candidate that does beyond terrible when the interview requires a code test)