Leetcode doesn't measure "smart and determined to succeed". It measures "has enough extra time and energy to devote to practicing pointless brainteasers for weeks."
In other words, whatever it's intended to do, one of its primary functions in practice is to screen out people who are bright, driven...and poor, working long hours and trying to keep themselves and/or their families going.
Weeks? There are stories on Blind and the LC forums of people taking upwards of a year with pretty hefty real-life constraints. And why wouldn't they, given the opportunity to essentially double comp over standard industry jobs? That's a life changing opportunity if you're in a somewhat unfortunate life situation.
That it's a bit of a sacrifice is the point. If you're naturally smart enough this stuff comes quickly, great. If not, you're going to have to work for it - that requires discipline most people don't have.
Whether you realize it or not, you're advocating for keeping people who aren't already mid-to-upper-middle-class (among others) out of these kinds of tech companies. Anything that's designed to make you work hard extra, outside of work to learn separate skills just to pass interviews is guaranteed to make it disproportionately harder for people who are, for whatever reason, unable in practice to devote many hours of their free time to fairly complex technical studying.
No matter how "disciplined" they are, people already working 80 hours/week just to put food on the table don't have the luxury to be doing that. No matter how "smart and/or determined to succeed" they are, people raising 2 kids by themselves would be irresponsible to be doing that.
Now, maybe you think that kind of person should be denied an opportunity to join the super-1337 hackaz' club that is FAANG or whatever. Personally, I think that kind of classist gatekeeping is disgusting.
While I certainly wouldn't presume to claim that no programming jobs are remotely related to Leetcode—I'd be perfectly willing to believe that you, personally, have to engage mentally with "classic" algorithms on a daily basis—from everything I've read about them, I doubt very much that more than a minuscule fraction of programmers and other tech workers do anything on a day-to-day, or even month-to-month, basis that would be close enough to Leetcode that they could be considered similar skills.
I've been working as a programmer—largely PHP, Java, Objective-C, and Swift—for over 20 years now, and never, in my work, have I been asked to invert a binary tree, reverse a singly-linked list, or any similarly contrived scenario.
There's a huge difference between "thinking about algorithms" in the most general sense of that phrase (which means basically any programmer who does any of their own design work) and in the sense of the particular "algorithms" that we learned in CS classes and are featured in Leetcode problems.
In no circumstances did I ever make algorithmic decisions in an informational vacuum and then cowboy code my way forward, or rather, one seeks to avoid the mistakes of one’s youth.
Search engine: read material about the heart of the problem from domain experts, try different approaches and then decide.
I only took 1 CS class in college- Cybernetics with Huffman. I failed! So clearly, that was a strong predictor for my future 12 year career at google (where I failed to do quicksort, or virtual ants problems). Nowadays I take a lot of extra time to come up with questions that aren't in leetcode, are easier than leetcode, and give far more signal than any leetcode would, for anything except for a 10X Staff Engineer.
To be honest? every programmer needs to be able to pass FizzBuzz.
Beyond that, I add some more basic work around byte representations of data (I have 4 symbols... how many bits do I need to encode a symbol?).
I will typpically also include one major bug in a piece of code and ask the user to identify it (with hints).
I once interviewed a guy- a CTO at a biotech- and he wouldn't answer the question "I have a million DNA sequences and want to count the number of occurrences of each sequence" (could be hash table, could be any number of other solutions; he just balked and exited the interview).
Only if the person can get all that right would I even consider asking something more complicated.
I once interviewed a guy- a CTO at a biotech- and he wouldn't answer the question "I have a million DNA sequences and want to count the number of occurrences of each sequence" (could be hash table, could be any number of other solutions; he just balked and exited the interview).
Maybe he's just been around the block a sufficient number of times to have gotten tired of the standard SV "here's a hoop, jump through it, now do it again, and again and again" ritual that it likes to call "interviewing" for some reason.
Seriously - your questions are fine for junior or mid-level roles, but beyond that, you should have more important thinks to talk about. And both of you should be able to tell if the other is a bullshitter and/or a lightweight within about 30 minutes at most (and often far quicker than that) of a normal, focused technical conversation -- without having to specifically grill the other person, or otherwise put on the pretension that you're one whose bona fides are established beyond question, and they're the one who needs to jump through a sequence of hoops to prove that they are worthy of your time and attention.
Just cut the crap, get down to brass tacks, and talk what needs to be done as if they're a peer. That's all you have to do.
I agree liking to ask simpler stuff first. But what about this more complicated stuff? My problem is that when we talk about stuff having more "signal" - how are we determining if those questions are giving us more signal?
My question is fairly open and allows me to continue asking significantly more complicated questions. So far, nobody has (for example) asked enough clarifying questions to determine that a bloom counting filter could potentially solve the problem- most people just store ASCII string keys in a hash table, which wastes tons of memory and requires a lookup for every string.
So usually I end up after 45 minutes finding that the candidate has more or less tapped themselves out at "make a hash table of string keys, use it to store counts" (OK for a very junior programmer) or "make a perfect minimal hash" (I help them get there if they don't know what those are) or "use a probabilistic counting filter". This is about all I need to make a determination.
The problem with this question is that outside the junior people who won't understand the hints, many good programmers would pass or fail just based on whether they have seen a similar problem or know what a Bloom filter is. CS is so broad that you may have been working for many years and never come across one topic that the interviewer deems standard.
I don't fail people who don't suggest a bloom filter. What I meant was: knowledge of probabilistic data structures and knowing this is a situation where they could be used is a sign of a more experienced programmer (likely one who's worked in clickstream processing).
If all you do in my interview is know that a hash table or other associative data structure is good for maintaining counts, that using a full ASCII byte to store symbols from { A G T C } is wasteful and compress the letters to 2 bits each, you can pack multiple 2 bits into bytes, and can write a function that codes and decodes such data, I'm happy and you get a pass. I'm even happy to sit there and help people through nearly all the steps of the codec. Not trying to trick anybody or select for obscure CS knowledxge.
To me the real question is, how much hinting is reasonable for the coding and decoding function? Many programmers (including senior ones) struggle to implement:
x <<= 2 # left shift the int to make room for the next item
x |= pattern # or the new 2-bit item into the accumulator.
Since I never use bit munging in my day job (it's 90% python data science) should I really ding somebody for not knowing about left shift or or-assignment?
What I really don't get is why people immediately jump to trying to implement huffman coding, RLE, or lookbacks as a solution to reduce the size of the DNA string. I still wonder if how I present the question is giving everybody a fair chance to shine.
I am 100% certain that your questions are not giving everybody a fair chance to shine. You have to start with the area of expertise they have already worked in and not the area that you happen to have experience in or be interested in. I could (for example) ask “simple” dynamic optimisation questions that are “easy” for me and I know that 95% of great experienced developers would fail. So obviously I don’t do that. I want to hire smart developers who can learn. Not developers who happens to have the same experience/interest that I do.
I hope you realised that your questions are extremely narrow and in no way filter for competent developers. Imagine yourself going to an interview and being asked similar narrow specific questions but in a different area you have no previous experience in. You would probably fail. For example: how would you represent a lambda closure when compiling a functional language to machine code? It is a super easy question for me but I know most people would fail. So I don’t ask questions like that when interviewing.
This sounds like a perfect question for a company that's hiring engineers who want to focus on optimizing DNA storage. If that's your goal you should just put that in the hiring criteria. You'll get more candidates that know those type of algs. If your goal is know if the candidate knows about bloom filters a better question might be "What do you know about bloom filters?" Definitely seems like you'd get answer in less than 45 minutes.
I think "key/value counts" is absolutely the correct starting answer. Anything after that is optimization. In the real world optimization comes at length through research, learning, grokking, reading, benchmarking, sleeping, mulling things over. The only way to short change that is knowing about those optimizations in advance, so might as well just ask about those algs specifically.
All that being said, I think it's an enlightening question. Thank you for sharing it! You've educated me. I've been coding a loooooooong time and didn't know about bloom counting filters specifically.
But have you had a chance to look back and see if those questions worked out? Like, are they a good predictor for how the person actually performed in the job?
Exactly. I honestly think no one is entitled more than software developers. Not even that chick from Mean Girls. Hell which other similarly paying field can you double compensation in like three or four months. Six months if you are slow or have a demanding life. Lawyers? Hahahaha. Doctor? Hahahaha. At least with LC there is an end goal. Those 75 questions. Or well I think 150 questions.
I hate LC personally but also am able to recognize that it is a silver platter handed to me. The article above mentions all the negatives. Ya bro who didn't know them?
yep. And you typically do change jobs every few years just to get a raise or promotion.
Which means... Always. Be. Leetcoding. Do the bare minimum at your job and then do LC the rest of the time. Because your job is just your job, but your career is LC. These companies don't yet realize they are optimizing for mercenaries that have no loyalty to the code nor the company.
On a slight tangent, some of the people over on Blind would sell their own mother for a tiny bump in TC. That mentality used to be limited to Wall St. or maybe Big 4 accounting firms, etc. But now it's the whole tech industry. I remember having a software job was a lot more fun, back around 2007ish. That culture is so foreign to me now.
It's what happens when an industry is awash in dumb money. Startups are seen as either half-baked schemes trying to get a cut of the VC funding pie, or cheap R&D labs for the big tech companies in search for inevitable acquisitions. The big tech companies who originally made their money delivering goods or services of real value, squander that goodwill through oligopolistic rent-seeking, engaging in shady anti-competitive or anti-consumer behavior, and endlessly building derivative, short-lived products that users don't actually want in hopes of inflating their moats. In a milieu such as this, engineers become mercenaries because "making the world a better place" has become a tired old cliche, both false and naive. Just a lot of cynicism all around.
I'm quite certain that making people dread interviewing is part of the point. Else why keep making people who've already passed multiple times, do it again? First FAANG to start routinely letting people who've already passed a couple similar interviews at peer companies in without repeating the leetcode-hazing, then the other companies have to do it, too, now suddenly the rate-of-increase of software developer pay's even faster than it already is, which none of them want.
Even having to pass such a test on a very aggressive set schedule—say, every 5 years—but only at those set times, would be better—for developers. Not for the companies hiring them.
Being able to quickly come up with efficient algorithms to domain-relevant problems are not pointless brainteasers.
Being able to quickly invert a binary tree and that kind of nonsense belongs in library code (at best). It's not something that the average developer should ever need to worry about the actual implementation of, let alone have to implement from scratch in under 30 minutes.
In other words, whatever it's intended to do, one of its primary functions in practice is to screen out people who are bright, driven...and poor, working long hours and trying to keep themselves and/or their families going.