> We never had any real body that could certify proficiency
Good!
> having to resort to leetcode and other such styles of interviewing
Such test filter out the obvious frauds.
Good!
> having to resort to leetcode and other such styles of interviewing
Such test filter out the obvious frauds.
I know everyone says that, but I really don't think that they do a good job filtering out shitty engineers. I have worked with plenty of incompetent people who managed to get past the leetcode challenge but are wholly unable to do anything useful involving software.
I feel like what leetcode primarily tests is "does this person know how to use a hashmap in a way that you shouldn't actually use it because you lose cache locality", and that's literally all they test.
Generally they are just wanky bullshit from some middle manager’s slightly-incorrect recollection of their first “data structures and algorithms” class, and the solution is almost invariably “use a hashmap” or “use a minheap”, even though the scope of these problems is usually so small that in a real implementation you would probably do in a more naive big-O-unfriendly fashion because constant factors are going to matter more. Let’s ignore the fact that most of the people who are designing these leetcode problems haven’t actually done any actual optimization and optimization is virtually never part of the job you’re interviewing for.
I don’t know what the “correct” way to interview is, but I am fairly certain that the masturbatory leetcode problem is not correct.
The best interview method I've seen is getting the candidate to work for a day or two alongside the team. The second-best was picking a bug from the current repo and working it out together with the candidate, getting them (or in this case, me) to work out why the bug was happening, work out a solution, code up the solution, and commit it back to the repo as a PR.
That doesn't scale - what if you have 100 applicants? The leetcode will narrow down the field.
The "pick a bug and fix it" scales better, though still not to 100 applicants.
Though I'd say putting 100 people through leetcode interviews would still break a talent acquisition process. I've been part of this kind of process before (though with arbitrary code problems not leetcode) and it was hell for the entire team going through it. Nothing got done for weeks while they were dragged into endless tech interviews.
> the solution is almost invariably “use a hashmap” or “use a minheap”
And you wouldn't be wasting your time on candidates who:
1. don't know what a hashmap or minheap is
2. didn't bother to study up before the interview
Sure, but none have been more thoroughly condemned (and correctly) than the idiotic leetcode whiteboard challenges.
> And you wouldn't be wasting your time on candidates who: 1. don't know what a hashmap or minheap is 2. didn't bother to study up before the interview
OR, and hear me out, you actively filter out people who know how stupid these problems are and know that big-O is misleading for a lot of these problems. You're selection-biasing towards people who are going to regurgitate bad answers, and the middle manager conducting the interviews is usually too incompetent to understand what a "constant factor" is.
I've been rejected for jobs specifically because I mention that using a hashmap for these things will likely be slower than a naive implementation, even when the I get the problem "right" in the way that they wanted it.
Now we could argue that I'm a bad candidate in general, but (at the risk of sounding cocky) I likely do understand data structures and algorithms better than most mediocre engineers conducting the interview, but because most engineers are pretty uninspired and have never asked "why" for anything in their lives, they will "correct" me. They will assume that me providing nuance is a lack of understanding on my end.
> A quick check shows that Google, Microsoft, Nvidia, Meta, Apple, Anthropic all do leetcode testing.
Yep, can confirm. I've worked at a FAANG, and they did indeed leetcode testing for the interview. It turns out that big corporations are fully capable of doing stupid things in perpetuity.
After all, would you get on a jetliner piloted by a handsome fellow with a firm handshake who failed to pass all the written tests, but really knows how to fly?
It's not that hard to study the leetcode books. Doesn't the prize of a top shelf salary make it worthwhile? It's a good investment in your career.
My dad flew 23 airplane types - single engine, multi engine, 2 wings, 1 wing, bombers, fighters, jets, and piston engines. In his papers I found some of the written exams he had to pass to get certified to fly them. Just "knowing how to fly" is a good way to get yourself killed.
There was one incident where his F-86 Saber jet had its engine quit. He was faced with the choice of bailing out or gliding back to base. Having passed the written test, he knew how to calculate the best gliding angle, the best velocity, the best configuration of the airplane, took into account the wind, the altitude, and the weight, and figured he could bring the bird in. Which he did, safely.
All that boring stuff that requires study and it has to reside in your brain.
You are arguing two different points here.
I am, generally speaking, reasonably good at the leetcode stuff, because I agree that it’s not that hard to get good at it. As a practical thing for society as it currently is, sure, studying up on the idiotic leetcode stuff is a relatively good investment.
But that pays little bearing on whether leetcode is a good test, and whether it should be something that we are using as a metric. I am arguing that it’s a dumb test and we should stop doing it at a systemic level.
Would you feel differently if you owned the company, and you'd be paying the salary for months for someone who talked a good game but was incompetent?
In your hypothetical the implication is that the leetcode would be effective at removing people who “talked a big game but are incompetent”. I disagree with that.
I could be wrong about leetcode, but for me to realistically engage with your argument would be a tacit agreement with the premise, and I cannot engage with that in good faith.
The secondary challenge in the kitchen (beyond the challenge of hiring someone who'll simply show up when scheduled, ha) is hiring someone who has a genuine interest in cooking as a craft. It's true that being a line cook isn't especially glamorous work, but I absolutely need someone who has enough love for it that they're proud to show off what they can cook when it isn't my menu.
I interviewed someone who made nothing but scrambled eggs, hash browns, and grits, but they were cooked and seasoned to absolute perfection. This individual was one of my slower line cooks starting out, but the fact they had the drive to learn this level of cooking was good enough for me to invest time in them to improve that speed.
I look for the same love for the craft in software. Literally everyone who's worth their salt has something they've worked on that they will happily show off, or some technique (like, e.g., abusing generics to implement monads in Ada and why this is more interesting than the typical approach using interfaces), or some pet data structure (e.g., critical bit trees and what their pathologies look like vis-à-vis hash tables) that they try to shoehorn into everything, or some bit of code they've read (e.g., SQLite and the Tcl interpreter) that left a lasting impression on their practice.
There's a snag though: being worth one's salt only starts at being able to cut code. I need to witness a candidate write about and walk me through that very technical aspect of the craft that they want to show off.
Assessing craft requires interviewers who understand craft, and the literal only reasons I can see for using LeetCode are when the interviewer is themselves not an expert in the domain (perhaps for reasons of scale, among others), the interviewer cannot (or will not) engage in heavily technical conversation with a candidate, or the job is plainly not about writing software that works.
The role of an engineering degree is to teach you the things you should know about engineering. And an engineer should understand data structures and algorithms.
if you need garbage like leetcode to filter out "obvious frauds" you got a whole lot of problems in your company/team/...
He did so. He aced the test. He got the job with a huge offer. He agreed that the ROI was out of the park!
P.S. I'm curious what your test is for obvious frauds?
...and everybody clapped?
I have news for you: passing an online leetcode is now so easy that an AI can do it. If you think you're catching the cheaters, you're just wrong.
Leetcode was always a stupid test of competence, but it was cheap and it had a high true-negative rate, which filtered the riff-raff. That isn't true anymore.
Man, there are times when I really hate this industry.
Or as I'd like to call it - Wednesday :)
I'm sorry, but if I'm doing the hiring, the person who isn't willing to come on site to do an interview will be one of the first people off the list to hire (I mean, unless it is a remote job, and the person is nowhere near the employer, obvious exceptions would apply).
In-person interviewing can be extremely valuable. Will it filter out every bad candidate? No, some people excel at faking it. However it can be a big help in finding a good candidate.
Nobody said anything about not coming on site. That's how we used to do it, in the ancient pre-history of 2019. What I said was that if you bring someone on site only to leetcode them, you deserve not to hire anyone.
The downside, of course, is that you don't have the cheap, dumb pre-filter of a memorization test anymore, so you'll have to figure out a better way to winnow down the applicant pool whom you're willing to pay to bring on site.
Maybe finally software engineering will achieve a level of interview maturity seen in other professional fields...but I doubt it.
So this is a new presentation of an old problem, I guess is the takeaway there.
A dice throw and some chitchat would be better recruiting.
Then universities dropped the SAT requirements. Even MIT was suckered into dropping them. It was a disaster. It turns out the SATs were a very strong predictor of college success. MIT and others reinstated the SATs.
- you can take it ~3 times and most colleges will give you the best score without penalty
- you can use your result to apply as many times as you want
- if you feel stuck you can still get a good score by moving on to the other problems
- it's administered uniformly across the world
- you don't need to narrate your thinking while you're still processing information
- you get an objective score instead of a pass/fail that may be subjectiveAlso, if someone is unwilling to do the work to pass the leetcode test, they likely don't have the ambition to get the high pressure jobs.
If the bar is that low, just use an accredited degree, certification, references, or a proctored quiz with questions like "define a linked list in < 3 sentences," and it would be just as effective at filtering the very lowest, while more pleasant for everyone involved and maybe cheaper. Crammable puzzles that don't represent real software engineering don't provide much more value than those filters would.
What absolute drivel. I've done plenty of leetcodes. I don't care about writing a qsort algorithm, I know the trade-offs, unless you're working for a FAANG or FAANG-adjacent company, the need to write your own sorting algorithm implementation is probably zero or near zero.
That wasn't the point. Would you wash your car before picking up your date for the first time? A dirty car would drive just as well, but your date will figure you don't care about the date going well.
(Edit: Perhaps I should have written in my original comment: I'm nobody's code-producing monkey, I'm not dancing for money or peanuts)
Your friend would have spent three weeks practicing their sketching, right? And they would have made a decent drawing at the interview. And that would have the exact same ROI as spending those weeks on practicing leetcode.
The point is not that studying leetcode is good ROI. The point is that large orgs are testing for something that isn't relevant to commercial coding.
This is classic Streetlight Effect [0]. Just because it's easy to test leetcode, and it appears to have something vaguely to do with coding, it gets used.
Like I said in other posts, I would use the "pick a bug and fix it" method. But I'd also screen down from 100 candidates to ~20 or so before getting into technical interviews.
And, again, I don't think leetcode will scale well to 100 interviews either. You need technical staff in that interview room, and if you subject your team to 100 technical interviews using leetcode they're not going to be happy about it.
I interview them and ask questions! Seems good so far.
Exactly what we do on day-to-day basis is what we do when we are trying to grow the team. I would guess that 85% of my team would fail leetcode-style screening right now (which is good cause it is garbage)
After they rejected me I had to point out that their test is selecting for the cheaters.
When you check in at the airport, the machine asks you to certify you are not carrying banned items. Of course, one wanting to break the law and carry banned items would certify it. The purpose is that if you get caught with the banned items, and you certified you did not, it's an extra charge they can paste you with.