> It's just as easy to argue that leetcode-style interviews are because companies are afraid of being discriminatory in hiring
From the hiring side, this is 100% correct. Giving everyone the same coding interview is one of the most effective ways to remove interviewer bias.
A lot of HN commenters advocate for a “just trust me” hiring process where they want the interviewer to just read their resume and have a quick chat to decide if the person should be hired, without any type of technical interview. That results in people hiring other people who are as similar to their own backgrounds as possible (everyone likes to think their own background and learning style is optimal).
We know LeetCode style tests aren’t perfect, but they’re repeatable and the study material is free and widely available.
> or give take home work (because it's discriminatory against people with time constraints)
IMO, this complaint is baseless. A lot of companies give the option of LeetCode style interviews or take-homes and almost everybody chooses the take-home.
The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.
> Giving everyone the same coding interview is one of the most effective ways to remove interviewer bias.
I'm sympathetic to the hiring side argument. But, I don't think the parent comment is insinuating that no technical question or test be asked of the applicant. They're not insisting on trust, they're insisting on showing their own intelligence. They're saying that the test or technical question should be directly applicable to the job at hand, for the company at hand. You can just as easily ask every single person who applies the same specific questions for the role at hand in your company. You don't need to rely on generic leetcode questions if they don't specifically apply to the job at hand.
In other words, hiring needs to actually be specific and targeted rather than adopting the "cast a wide net and catch whatever we can" strategy that many places seem to employ.
9/10 it feels like the insistence on leetcode from hiring comes as an excuse for rather weak recruiting standards and practices.
Leetcode or "just trust me" feels like a false dichotomy.
Biotech interviews, for example, are usually conversational: what have you worked on before[0], how would you tackle this new problem, or troubleshoot a particular problem. There's this persistent meme that charlatans can BS their way though such an interview, but I really don't see how someone could learn enough to parrot their way through 4-5 x 45 minute meetings, often with fairly probing questions. It felt quite a bit like a thesis defense, in fact.
It's true that these aren't "repeatable": each applicant won't have exactly the same experience. This is "unbiased", in a sense[1], but has enormous variance: you're not only testing the applicant's aptitude, but also whether they've encountered this particular problem before. OTOH, tailoring the interview to each applicant' strengths might inject a little bias in exchange for a massive reduction in variance.
[0] It does help that candidates for these jobs had masters/PhDs, and therefore had at least one project they could discuss publicly.
[1] But not really...There's a subjective element to "code quality", fluency, whether the applicant wrote "enough" tests, etc.
My guess (I have no experience in the biotech industry) is that this is largely because you can't run an hour-long experiment with the candidate to test their competence. They must rely on a conversational technique. I don't know how much we can compare software with other industries.
The software industry is unique (or so we think) in that we can directly test a candidate to judge their competency in an hour, either by white-boarding or going over a take-home problem (or similar).
I think you could dream up some one-hour tasks if you really wanted to. The issue is that they'd be so obviously unrelated to overall job performance that the process would be self-evidently silly.
I'd argue that software is similar: projects don't falter because it takes someone five extra minutes to run a gel (or implement a red-black tree); they fall apart because people don't think about whether they ought to be doing that at all.
The most effective hiring process I've been through is one where there was basically no interview, I was given contract work to perform during which I was compensated for necessary company tasks with no real expectation of enduring relationship. After a few days of performing tasks to the satisfaction of the company, I was offered a permanent position.
Not only did this process eliminate the BS, it allowed me to perform a task in a relatively low-pressure but high yield setting while simultaneously not exploiting me (I got paid) and allowed the employer to see how I would actually behave as an employee. This is also the longest and most successful position I've held, partially because there is no lingering bitterness and hatefulness I've harbored at those expecting me to solve bullshit problems for free, like some kind of performing monkey.
> We know LeetCode style tests aren’t perfect, but they’re repeatable and the study material is free and widely available.
One of the things that gets me here on the hiring side is that the ease of “grinding leetcode” as a strategy seems to defeat the entire purpose of it as an interview question. I don’t want to dismiss the value of someone being able to study a skill and learn it, but I see a lot of people fixated on rehearsing leetcode answers like they were magical incantations you recite to get jobs, there’s not always a lot of real learning happening. That’s not reflective of the kind of candidates I’d want to hire or the peers I’d want to work with.
> A lot of companies give the option of LeetCode style interviews or take-homes and almost everybody chooses the take-home.
If true I’d like to see more of this. No hiring process is good for everyone and I think flexibility can be a better way to make a process fair, but I haven’t seen much of it personally. I don’t think I’ve personally gotten a leetcode problem at an interview in years- takehome problems have been the more common screening tool, but I don’t think I’ve ever been offered a choice in the matter.
> The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.
I’m not sure this is entirely on the mark. On problem with takehome a is asymmetry. Most take home assignments I’ve gotten have come toward the end of an interview process, and there fine, but when I talk to more Junior folks it seems like they are often given hours long takehome problems before they ever talk to a human. That seems disrespectful of peoples time- it’s a lot to ask from someone who doesn’t even know if they are a fit or want your job yet.
In any case the hours long takehome is usually in addition to an bourse long set of interviews- not in lieu of them. Another common problem pre-Covid was that a lot of people just weren’t set up to work from home so it was harder to get the space and time to work on a project at home. I expect that’s probably changed a lot these days though.
> One of the things that gets me here on the hiring side is that the ease of “grinding leetcode” as a strategy seems to defeat the entire purpose of it as an interview question.
I think that's irrelevant for FAANG and friends. They pay so high that they can afford to make their interviews so miserable and time-intensive to prepare for that tons of people never even try, purely as a first-pass filter. They don't care that you can prep for it, they just want it to be (exactly the right amount of) scary and unpleasant. The resulting, self-selected group probably is, in fact, far better on average than the set of all software developers, including those who never apply to those sorts of jobs (but might if the interviews were less awful). Furthermore I think that's why some results show that they could randomly select candidates and do about as well as the interview process does—sure, maybe, but they could not do that if the set of people applying wasn't already heavily biased to have a fairly high average skill level (& IQ, that's absolutely part of what they're filtering for).
Now, companies paying half or less what FAANG does and trying to do anything remotely similar, are simply making a mistake. People with a tolerance for and ability to pass those kinds of interviews are going to apply to the much-higher-paying options, not to your company.
> They pay so high that they can afford to make their interviews so miserable and time-intensive to prepare for that tons of people never even try, purely as a first-pass filter. They don't care that you can prep for it, they just want it to be (exactly the right amount of) scary and unpleasant.
This is something I completely agree with. I'm not so sure about the motivation though.
> The resulting, self-selected group probably is, in fact, far better on average than the set of all software developers, including those who never apply to those sorts of jobs (but might if the interviews were less awful). Furthermore I think that's why some results show that they could randomly select candidates and do about as well as the interview process does—sure, maybe, but they could not do that if the set of people applying wasn't already heavily biased to have a fairly high average skill level (& IQ, that's absolutely part of what they're filtering for).
This is where I disagree, and my disagreement comes in two parts. First, is programming skill what this is actually measuring, and second, is programming skill what this is intended to measure? I don't have hard data, but I'd guess no in both cases. I've certainly known plenty of early career people who get obsessed with leetcode grinding, and I've never known them to be any better on average than the people who don't fall into that trap. What they are better at is letting themselves be convinced they need to work long hours and burn themselves out for an opportunity. The cynic in me says that's what these companies are actually selecting for, although it's likely at least some people involved in the decision making aren't doing it consciously.
> First, is programming skill what this is actually measuring, and second, is programming skill what this is intended to measure?
Yeah, no, and, no. I agree.
I don't think it's measuring programming skill. I think there's a strong enough correlation between that skill and being willing and able to study for & attempt their interviews that simply conducting them the way they do yields a set of candidates who would practically all be acceptable hires—but they can't drop the unpleasant and/or useless parts and make them easier, or that would stop being true. There are definitely lots of people who'd be good, or even great, that it excludes, but I don't think they care, probably regarding the cost of finding those folks as too high to be worth it. As it is, it barely even matters how good a job they do of weeding out candidates who show up. Most of them are probably good hires (for what FAANG is looking for, which is some combination of IQ and "how bad you want it", as far as I can tell).
> The cynic in me says that's what these companies are actually selecting for, although it's likely at least some people involved in the decision making aren't doing it consciously.
Heh, yeah, I agree that's likely part of it.
I think there's also a hazing component. Hazing is effective at creating strong in-group sentiment and bonding, in a hurry.
Overall, I think measuring programming ability has almost nothing to do with why they do what they do. I also don't think that necessarily means it's ineffective at achieving their goals. I think complaints about FAANG-type hiring, when directed at companies that pay in the top-tier, are misguided for that reason. I also hate them, and don't think they're good at measuring actual programming ability, but I think there's likely a non-crazy (though a smidge sociopathic or cruel, maybe) point of view from which they are the right thing for those companies to do.
It sounds like we’re mostly in agreement. I’m not sure they are actually the right choice, because I tend to think that companies that are trying to operate at such a large scale would be better off having a broader set of type of people working in engineering, and they necessarily limit themselves too much by insisting on their interviewing approach, but I’ll admit that I’m bringing a lot of my own bias about what a good company looks like into that view of the world.
> The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.
I personally like take-home problems. It's hard for an employer to time-box them without resorting to basically leetcode though. I know that, as a student, I definitely spent many hours on them.
> A lot of HN commenters advocate for a “just trust me” hiring process where they want the interviewer to just read their resume and have a quick chat to decide if the person should be hired
That's how your manager is going to be hired, as well as all of his bosses on up.
SWE manager here, at multiple well known companies, and this isn't how it's worked at any of them. Some of them I've had to do leetcode interviews while at others, it was important to know aubergine who could vouch for your work. Could just be me but I've never experienced the "I just have a good feeling about this guy" supply t if interview.
"He goes golfing with Jerry" isn't going to eliminate bias, but you can absolutely get jobs in management on that basis. I don't think any of my managers could do a leetcode hard off hand, I may have worked at the wrong companies.
I assume your CIO also took a LC interview as well. I believe parent's point is that this front line hazing commanding competency is moot when orgs are hierarchical in nature and you needent step far up from a leaf node in an org chart to find someone hired on "just trust me, here's where I worked and what I did."
At some point a technical interview rightfully doesn't make sense for a role (at least by itself), some transition up the chain typically needs someone who trusts a technically competent person below them and uses their advice. These transition layers really require someone with business acumen and technical acumen which are often unicorns, not in these positions and if they are, are not in a position to command change upwards. You need to really understand business direction, financials, market pressure and so on while also understanding all the technical challenges. You also need people who don't override your assessments frequently.
What usually happens though, from my experience, is you have an interface in the hierarchy where someone above understands a touch of tech but is primarily business and human management focused and a person below them knows a little business but is primarily technical. The bias will typically ignore, override, or pressure the technical challenges based on business focus in this structure. That bias comes from someone who didn't take LC and doesn't understand the technology or problems often at all.
There's this weird mindset in the software industry that by hazing one another and pushing for only the most skilled engineers at leaf nodes of an org, we can command change upwards or at least make our lives better by filtering out incompetent teammates that make our lives more difficult. Meanwhile, none of this matters to me in the big picture if someone is technically incompetent up the chain yet is pushing technical decisions either directly or indirectly that makes life miserable for very technically competent staff. You can have the most competent staff in the world with incompetent leadership. In a best case they're hands off and have a nice gig where their department makes them look good while they do nothing. In a worst case, they get actively involved in areas they shouldn't.
One may argue this only happens in bad orgs, and that could be correct. In that case, the bad orgs vastly outnumber the good orgs. I don't think this is the case though. Technology is typically to some degree considered a cost center for any business, even technology focused companies (its a cost center until certain efforts prove their value). It's a means to an end to keep afloat and make money so business interests will always override technical interests and this is very often embedded in the very power structure of a given org. Someone above you didn't LC, someone just trusted them during their interview, and now they tell you what to do. Maybe they're competent and didn't need to, maybe they're not.
I have a good friend who was a world class (quantum) chemist well recognized in his field and a technologist by heart in an S&P 100 scale org. He held the role essentially akin to a Fellow or Senior Fellow at a place like Google in a Fortune 100 chemical industry leader (the next step up would be something like VP research IIRC). He was frequently overriden by VPs that had no inkling of the science or technology needed to accomplish the baseline innovation business that made them money. So no matter how competent he and his staff may have been, someone who didn't care or was incompetent around the issues commanded decisions that effected him and every department he lead. This is in an org where someone doing real daily scientific and technical groundwork was able to interact at executive levels. Some of this leadership probably couldn't identify lead on a periodic table if their life depended on it (and they might not need to, assuming they listen to people who can), yet to get to the role just below them, you needed to be a leader in your discipline.
Irrelevant - a CIO's job isn't to be a hands-on coder, it's to set a strategy and manage an organization. Companies do a good but if due diligence on that, which is why it's really hard to break into the executive ranks - you have to find an opportunity that can grow into leading a large team because no one will hire you to do so if you haven't before.
Purely by chance, the last place I worked that had a CIO title, my LOB CIO probably would have had a good chance at passing a Leetcode interview, despite managing 10,000+ people.
This strikes me as one of those linguistic squabbles - along with changing the definition of literally to include figuratively - where we just need to accept that language evolves, and usages that may be historically correct aren’t necessarily justifiable in a modern context.
I also only use literally literally. I refuse to tell my daughter that "One small step for a man, one giant leap for mankind" effectively equates to "this one is for the bros!" or that "all men are created equal" doesn't apply to her. You've got 1400 years of English language momentum to overcome if you want to change the meanings of established words.
> I refuse to tell my daughter that "One small step for a man, one giant leap for mankind" effectively equates to "this one is for the bros!" or that "all men are created equal" doesn't apply to her.
No reasonable person is suggesting that we need to eschew historical context and nuance to redefine statements like these. At the same time, we should acknowledge that language isn’t immutable - as 1400 years of English language momentum can attest - and there’s nothing inherently wrong about its generational evolution.
> and there’s nothing inherently wrong about its generational evolution
If you make literally mean figuratively as well, it loses all meaning. In what context is that word ever useful? It describes literally everything. Making the language less expressive and more difficult to use is wrong.
In the same sense, is the idea that I now have to look when a particular piece was written to understand how to interpret the pronouns? How does that make the language better?
I'm all for improving the language. Slang, new words, new idioms, have at it. I just don't see how either of these changes improve the language.
> In the same sense, is the idea that I now have to look when a particular piece was written to understand how to interpret the pronouns? How does that make the language better?
We already interpret language through the lens of its era all the time.
For example, when's the last time you heard someone use the word "gay" to mean "happy" or "awful" to mean "awe-inspiring?" They have very different colloquial definitions today, but when I hear the Flintstones theme song I know what "have a gay old time" means, and when I go to church I know that the hymn "God of awful majesty" isn't sacrilegious.
Including the definition of literally to include figuratively reflects how it is used by many, and dictionaries should do that. But it's possible (and my hope is) that it eventually goes out of fashion as a filler word for twitter-facing teens trying to sound smart, and effectively goes back to meaning what it meant before, since its literal meaning is very useful and specific, and will stay relevant beyond historical use. The new "meaning" is really to be meaningless, which is not what I'd consider an advantageous mutation in the evolution analogy.
Thank you. I noticed this a lot on HN, but I don't know how to react. There is a common presumption that co-workers and managers will be men. It bothers me. I work in Asia where there are lots of talented women engineers. Each time I read one of those sentences, I do a double take!
I'm pretty sure most people over ~30 in the US were taught that was the correct form. Common usage has changed only very recently. At any rate, as long as using the feminine is fine, so's using the masculine. Some writers even use both, switching between them. Me, I much prefer the singular-they, because I don't think keeping masculine the standard is tenable or desirable, and I find writing that uses the feminine harder to read (because there's a vast body of existing writing that defaults to masculine and it's by far the bulk of all material I've read in my life, so if I see a feminine pronoun it throws me off for a second as my brain reflexively starts to try to figure out who exactly we're talking about—this is getting better as the practice is wider-spread, but c'mon, let's just use the singular-they) and because it doesn't tend to generate discussion about pronoun choice.
The issue with take homes is that they are at the beginning of the process where you might have hundreds of candidates. I won't invest several hours in that. Whereas on-sites are the last stage in the process, so it's better than 50-50 that I'll get an offer out of it. So in that case I'm happy to take the time.
Ace Greenberg from Bear Stearns (former US investment bank) used to say the trouble with hiring friends and family: "You get 100% of the dummies." Sure, you get a few good ones, but you also get the lousy ones.
From the hiring side, this is 100% correct. Giving everyone the same coding interview is one of the most effective ways to remove interviewer bias.
A lot of HN commenters advocate for a “just trust me” hiring process where they want the interviewer to just read their resume and have a quick chat to decide if the person should be hired, without any type of technical interview. That results in people hiring other people who are as similar to their own backgrounds as possible (everyone likes to think their own background and learning style is optimal).
We know LeetCode style tests aren’t perfect, but they’re repeatable and the study material is free and widely available.
> or give take home work (because it's discriminatory against people with time constraints)
IMO, this complaint is baseless. A lot of companies give the option of LeetCode style interviews or take-homes and almost everybody chooses the take-home.
The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.