Leetcode Considered Harmful

That said: I’m tired of the attitude that there is no effective alternative to this style of interview. You do know we hired people to do engineering jobs for many decades before the industry started cargo culting what they observed a handful of Silicon Valley mega-companies doing. Plenty of very competent people were interviewed and hired before this “relive your algorithms class final on a whiteboard” style interview process became the thing to do.

These interview processes are not the only way. As I said: it’s cargo culting where insignificant companies try to act like Google or some other giant in hopes that perhaps the billions in revenue will start rolling in if they mimic them. To me this behavior is no different than “founders” who adopted dress styles and presentation mannerisms imitating Steve Jobs a decade or so ago. …And bloggers who can’t resist the “considered harmful” trope.

If you're hiring at scale, there's nothing else that matches it in terms of difficulty to game and cheapness of cost to implement. And for every engineer who says that they refuse out of principle to do Leetcode, there are ten who refuse to do time consuming take home projects and the nth implementation of a bespoke open source static site generator just to build a portfolio on Github.

Most smaller companies can and must figure out other hiring niches for overlooked/available candidates since they can't effectively compete with large companies for good conventional candidates using the same hiring process (e.g. by offering candidates more flexibility, taking more hiring risks), but pretending it's not a tradeoff isn't taking the problem seriously.

Anywhere else where you use the Lego bricks to build some applications shouldn’t really use leetcode.

If you’re a good product engineer and you enjoy building good products, maybe you should start a company to build good products that solve problems for other people. Let the engineers who enjoy building the bricks do leetcode in peace so that we have solid pieces to build good software.

I’m doing the latter and trying to build a company. I realized I much prefer to build products that customers love, and I want to build useful software for people. I’m not that interested in low level tinkering and re-inventing the wheel all the time.

Coexistence is possible!

I did get an offer from them though, not sure how I would have felt if rejected.

Also, more specifically on this piece: can anyone explain how Theranos fits in here? I don't get the connection. One the one hand we have a massive fraud, and on the other... people studying techniques that are rarely used by normal software engineers? But that nevertheless are, still, programming techniques.

And please no more "considered harmful" titles! It's painful to read at this point.

To me the value of coding interviews are knowing enough algorithms/data structures to apply and adapt them to problems, being able to quickly sketch out your idea, and explain trade-ffs.

We're engineers.

If you don't like something, make something better.

Take home projects and how many marbles in a jar are extraordinarily worse than traversing a binary tree.

I suspect that any interviewing practice will always being in detractors. It's a process of culling, those culled will dislike it.

Am I an outlier? I feel like I actually encounter these kinds of things fairly often, or at least the insights that they represent. (Eg: this week I'm implementing a simple path-finder to deal with a sliiightly overgrown state machine from a vendor. )

So - at least because of that - I tend to think of leetcode problems as more or less a slightly harder and more practical fizzbuzz. Complaints about leetcode do tend to mirror complaints you read about fizzbuzz.

Am I being strange here? Perhaps not. I figure there's at least two or three ways to pass a leet-code-like test: Either you just happen to have just done a bunch of marginally interesting programming somewhere in your past (which is probably what the test was designed for?), OR you did a study in college that ideally allows you to avoid the worst parts of the school of hard knocks (also ~fine), OR you explicitly practice for the test.

I suspect Goodharts law might be at work here: In some cases the measure has become the target.

now there are leetcode grinding courses and books, it no longer serve any purpose than to dissuade those who don't have time, or motivation.

good way to identify the desperate willing for a small % chance in an 8 stage interview when someone may still reject you for some unknown reason.

I think of leetcode as the gym and I try to do one exercise everyday outside of work.

Of course they are not really that fair for people that don't have the time to learn the circus tricks because they have family and stuff but at least there is some appearance of fairness.

Also, compared to other performance based testing, the time requirements on both sides are kind of reasonable. I get more annoyed when the interview process requires me to basically provide free work.

Medicine is an old field, and I think these leetcode style interviews are only the beginning for the computer science based industry, the bar is only going to get higher as years pass which I feel may not be a bad thing overall for the software field.

The LC approach is fair if you only consider the fact that everybody will get these exercises. They are somewhat standard, and you know what to expect. However, you need to spend quite a lot of time to be able to solve difficult problems under a given time. And yet, emotions might get the best of you and you lose it, despite having solved the problem a bunch of times.

LC problems are not really useful as they don't resemble anything you'd do at work. However, if you do solve them, this shows to the company hiring you that you have been persistently training on LC problems, which shows you are consistent. A good quality, despite the uselessness of the problems.

The alternative, take home tests, are a better indicator of experience and engineering capability, although some might say one could "cheat". That's no different than outsourcing your job to somebody, which means this is fundamentally a trust issue -- so the problem lies elsewhere.

I've also seen variants of having candidates do some kind of trial where you get to experience what a typical day of work looks like at a company. This makes sense at a surface level, until you realise that the "typical day of work" is usually pretty atypical. They day of work trial generally can go two ways: the candidate works on an actual thing that needs to be done, or the candidate works on a fake thing users are supposedly asking for.

The latter is problematic, because you can do everything right, but since it's a) a fake problem, and b) you have no actual user feedback or requests to work on, this gets pretty subjective. Unless you read your interviewer's mind, you're left to wonder why you were rejected.

I'd take a LeetCode problem over a fake work day any time, as much as I dislike LC interviews. I guess all of this is to say, it's complicated :)

It clearly works for them so they continue doing it and able to grow their eng organisations to thousands of engineers. Any other solution to this problem wouldn't be without its trade offs. If he really wants to contribute to tech industry he is more than welcome to found his own company and hire the way he wants, instead of saying "I don't like this FAANG find a new way!".

If you wernt such an evil company you wouldnt need to pay people so much money to work on your ad data scam.

It also doesn't help that, as previous HN comment sections prove, a staggeringly high number of people who ace these tests actually just outright cheat. And then they come here and talk about the necessity of using LC to filter out 'unqualified candidates' (ie not them).

I've used Leetcode personally as a source of problems I can think about at a leisurely pace in my head. I like to have a few such things (algorithm or coding problems, math problems, physics problems, music theory problems, electronics problems) that I can use when I'm lying in bed but not quite falling asleep yet or stuck in a slow line somewhere to pass the time.

For the Leetcode problems I've used for that, usually from the "hard" or "medium" categories, it is almost always the case that I can easily and quickly come up with an algorithm that gives the answer and I could easily code but is O(n^2).

It is getting down to O(n log n) or O(n) that is difficult. (I'll give a couple of examples below for your amusement of problems where O(n^2) was easy but doing better took me weeks or months).

Are most interviewers satisfied with O(n^2) that produces the right answer or are they looking for something better than that?

Now for your amusement two problems that took me ages to get past O(n^2).

1. You are given an array of integers and are to find the smallest positive integer that is not in the array. For example given [1, 9, 4, 7, 2, 5] the answer is 3. Your answer should run in O(n) time and use constant extra space.

2. Find the longest palindrome in a string. No time or space constraints are specified.

For the first missing positive integer problem without the time and space constraints the answer that quickly comes to mind is to sort the array (O(n log n)) then scan for the first i such that the element at the i'th position is not i ((O(n)).

What really threw me was the constant space requirement. I had always assumed the inputs were constant in Leetcode problems and could and so could not think of a way to do this without using O(n) space.

I even ended up spending a while trying to prove that it could not be done in constant space hoping that when I could not prove that seeing why I could not would point me toward what I was missing. But I was able to sort of convince myself that a Turing machine could not do it in constant space--"sort of convince" because I'm rusty enough with Turing machines I could not be sure I was missing something.

It turns out that inputs aren't constant in Leetcode problems. You are allowed to modify input arrays. It was then not too hard to figure out the O(n) time and constant extra space solution.

For the palindrome problem an O(n^2) is quite straightforward. But I've got a couple of other approaches that seem faster.

Let's call the two halves of a palindrome its "arms". So an even palindrome consists of two arms that are mirror images next to each other and an odd palindrome consists of two mirror image arms that are separated by one character.

If you have an even palindrome with arms of length n, and you want to check for an odd palindrome one over to the that is longer than the even palindrome, you can move the right arm over by one and check that it is still a mirror of the left. If it is you have found a longer odd palindrome.

It the shifted arm does not match, you can then shift the left arm over and check for a match. If they match you have an even palindrome of the same length. You can then check to see if the arms can be extended while still matching.

By inching the arms across the string this way, extending them when possible, you can sweep the string finding the longest polynomial. If verifying that the arms are mirror images was O(1) this inching approach would be O(n). But comparing the arms the most obvious way os O(L) where L is the length of the arm, which would be 1/2 the length of the longest palindrome found so far, which would be O(n), so the inching approach with the simplest arm matching is O(n^2).

But can we do better? What if we maintain for each arm some kind of hash. We can compare the hashes of the arms and only if the hashes match do we need to then do a character by character check that the arms really match. But this doesn't seem to buy us anything because hashes are O(L).

But maybe we can take advantage of the fact that we are moving the arms one character at a time through the string. We need a hash H that given a H(S) for some string S allows as to compute H(S') where S' is S with a single deletion from one end and a single addition at the other end. For example, our hash might simply be the sum of all the characters in the string. Computing that for an arm after sliding it one addition and one subtraction.

I'd rather have a hash where strings that are just permutations of each other hash differently, so spent a while on that. I came up with something that seemed pretty good, then realized that rsync has such a hash and I should use grab that. It turns out though that the one I came up with is the one rsync uses.

I'm now stuck trying to figure out the run time of this. In most cases I think it will be somewhere between O(n) and O(n^2). Where depends on how often the hash gives false positives on arm matching.

The other approach I'm playing with is completely different. Suppose we scan the string and build a frequency table of all the characters. This is O(n). Now look at the least common character and note the constraints that it puts on the possible positions of long palindromes.

For example suppose the string is 1000 characters long and it only has 3 'X's, which are at positions 10, 200, and 700. We can immediately deduce that if the first X is part of a palindrome that does not include the second X it is an odd palindrome of at most length 19. If the first two X's are part of a palindrome it must be odd and up to length 219. We can make similar deductions for the rest of the cases, and we can rule out any palindromes containing all three X's.

We can check each of those cases to find the longest palindrome involving X. That leaves us with the string partitioned into 4 sections where we then need to check for palindromes larger than the largest X-containing palindrome.

We could then do a similar thing with the lest frequent character in each of those regions, and so on.

Or maybe better is to start with the two least frequent characters and consider their distribution in the string together.

In general the idea here is that the distribution of any particular character in the string imposes constraints on where long palindromes might be and maybe we can build up a set of such constraints to cut the number of palindrome checks we have to do sufficiently to get an efficient algorithm.

That's about as far as I've gotten with this approach. I feel there is probably something there but it might take someone way smarter than me to find it.

All I see is anecdote after anecdote in both directions.

In god we trust, all others must bring data.