At the time, I had been coding for 15 years in multiple languages. Out of the blue I got poked by a Facebook recruiter and on a lark decided to go through the process. I made it through the phone calls and screen-share coding sessions just fine. I went onsite and had a several interviews that went swimmingly.
Then near the end of the day, I ended up getting a whiteboard coding challenge that involved pretty simple array manipulation and my brain absolutely locked up. In retrospect it was comical, but at the time it was incredibly humiliating. There I was just alternately staring at the whiteboard and the interviewer with what I can only imagine to be the most hopeless expression. My brain fog absolutely impenetrable.
At this point in my life, I'm fairly familiar with the condition. Basically for some random reason, the thought pops into your head just how disastrous it would be if you failed at this thing you're being asked to do. Then your consciousness inevitably becomes obsessed with this thought and it's all you can think about. You start panicking and soon you have absolutely zero mental bandwidth to accomplish the task and your mind is basically singularly focused with getting out of this terrible situation. It sucks.
So, I'm always a little annoyed when I hear people say, "what's the big deal with a little leetcode?"
I mean, I get it, if I actually could not solve those problems, I would not be eligible for the job. But the reality of whiteboard leetcode is that you're not screening for people that can code, you're screening out people that can have panic attacks. In my opinion, it is borderline disability discrimination.
This is such a relatable description.
I don't think you even need a panic disorder to have this happen to you, this has happened to me a handful of times and it's absolutely the worst. It really is humiliating, totally ruins your day and you end up kicking yourself for several days after. I think this is just something that a lot of people do, like stage fright or something. The only way I know to avoid this is to do a lot of interviews with different companies that you don't really care about to get more confidence before you finally do get to the interview you care about, just so you don't choke during the one you want.
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
Is that part of the job description now?
What are these characteristics that:
1. Are present in the day-to-day work of a great many impactful software engineers that employers want to hire?
and
2. Do not discriminate against gender, gender identity, race, national origin, faith, sexual orientation, veteran status, age, and any and all other characteristics that employers are forbidden from discriminating against?
and
3. Are present and can be easily recognized in a leetcode-style interview keeping in mind that the number of similarities/amount of overlap between leetcode-style and day-to-day software engineering work is very close to zero if not zero?
Having said that, I am sympathetic to companies not knowing what to do that is better. There are real tradeoffs with all approaches.
I kind of think if I were to design the hiring system from scratch I would 1. Hire essentially anyone interested at the entry level for low paying 6 months apprenticeships, and 2. Hire more senior people based on their resume alone, with aggressive use of performance improvement plans for underperformance after 6 month or so probationary periods. I'm sure this idea sucks too.
I couldn't even remember how to write a for loop in bash, something so familiar it would be like asking me to recite the alphabet. Utterly humiliating yet comical experience looking back.
A few years ago I was hiring for a non-coding role with a company that pops up here on HN periodically. The interview was entirely leetcode. I completely blew it because I was so flummoxed that this was how they were interviewing for the role. I tried asking some non-code related questions about the role and company and was shut down from even being able to ask - it was clear their expectation was that the interview process was a one-way street.
It wasn't the straw that broke the camel's back, but it was a chain of things that led me to finally conclude it was time to move on in my career. That is, jumping through these kinds of interviews might have been something I'd do at 20-something, but at 40-something I've got other options and am not willing to put up with it. The hiring process in the software industry is completely broken in how it assesses talent.
Can I write pseudo code that doesn't compile, is an amalgamation of various languages and probably understandable by anyone that can code even though there's probably no language w/ that syntax out there but it get the idea across perfectly? Sure!
foreach (number in numbersYouWantMeToFizzBuzz) {
if(number MOD 15 eq 0) print fizzbuzz
else if(number MOD 3 eq 0) print fizz
else if(number MOD 5 eq 0) print buzz
else print number
}
Don't have the {}? Who cares, you might be a python guy. Don't have the indentation? Meh you pass but my next question will be about formatting and what you think about applying a standard code style (and fail PRs automatically if it doesn't etc). You used % because your language uses that for MOD? Sure.Despite being fairly experienced and having a rather solid grasp of Python/Go/JS/etc I still have to look up basic things like file modes (with bash syntax being especially notorious for being forgettable to me).
What I'm good at, however, is keeping references in my head, i.e. I know precisely what to Google to get the exact answer that I want. This way I compensate for my bad memory.
And for the record, I'm in my 20s. Sometimes I worry if it's going to take a toll on my career in the long run but so far it hasn't been much of a problem (apart from being a source of insecurities).
It's true for people working in technology due to the rapid pace of progress. As soon as we learn something it's out of date!
This happens to me all the time! You’ve described it so succinctly. How do you cope?
Ultimately, it is in the company's best interest for an interviewer to look past things like nervousness-induced panic attacks, and I've heard on numerous occasions that good interview sessions involve the interviewer and candidate working together rather than adversarially.
Once it gets past a certain threshold it gets harder, so being mindful that one is coming on and routing it before it gets into a positive feedback loop is very important. Leave the situation you're in, e.g. tell others that something has come up and you have to go.
I am really grateful that you brought up this point as well sharing as your own experience 'ryandvm. My own experience when I fail to think of an answer to a leetcode question is extremely similar if not identical. I would add that my own experience is always a silent panic similar to how I experience going on a rollercoaster. Many people will scream out loud when they are going down a rollercoaster; I just clench the safety/restraining bar really, really tight and look onward while clenching my teeth. I am surprised that it took this long in my career to hear similar feelings expressed by someone else, but I am grateful that it did.
Thanks again 'ryandvm! I really appreciate it.
[EDIT] What I'd liken an interview to isn't an emergency, but a date, a visit to the bank for a mortgage application when you're very much not sure whether you'll get it, participating in a talent show, and shopping for a car, all rolled in to one. That's closer to what it is, than an emergency. That also makes it very unlike nearly all activity anyone engages in at work, emergency or routine, social or solo, except for certain high-pressure sales or top executive jobs, maybe.
Great quote. Those feeling pretty much summarize to perfection the current fad of interviewing pressure.
As for those who code without guns to our heads, I'd take the candidate who ships well-tested code over the candidate who ships emergency code. Prefer few large fires over frequent small ones and just roll back.
Edit to add: The kinds of pressure experienced on the job are not at all the same as those experiences during an interview. "Doing well under pressure" is not a generic skill. Someone who freezes up during an interview may be the coolest head in the company while restoring a database backup during an outage, and vice versa.
It's completely different, not even remotely comparable.
The pressure during a real-world outage is not a big deal. It's collaborative, we're all trying to solve this. And the work that needs to be done is actual real work. I'm extremely good at that, so I basically feel no pressure at all no matter how high the stakes are.
Interview pressure though? Whole different monster. It's confrontational and I'm expected to basically do improv acting on topics that have nothing to do with the actual job while someone nitpicks and eyerolls every irrelevant nonsense.
It's probably correct to answer "the person with 5", but does it automatically prove that "# of languages under the belt" is a great metric for evaluating engineering prospects?
We can come up with all kinds of justification for the current state of engineering interviews, but most everyone conducting the intervews know that our methods are extremely primitive and are thirsty for a better path forward.
But just blanking when suddenly put on the spot happens to everyone. Human memory retrieval is a complicated process, nothing like a computer. You can have vast expertise in there but not be able to retrieve it instantly, unless of course you've practiced interviewing that very subject a lot recently.
This rings pretty true to me, thank you for sharing your experience.
Like a driving test and the training with parents/adults beforehand.
Even with some judgmental/skittish passengers its the same.
We need a credential that counts as passing a technical interview, so we don't have to take these tests for every single job that we apply to.
If I pass a coding test, stay at a company for a year, then apply to other companies, I'm going to subjected to coding tests even though I just passed one only a year ago. It's like companies are afraid that programmers will spontaneously forget how to program.
A credential's test is not limited by the very time constrained format of interviews. This means it could ask more questions to reduce false positives. People would be willing to invest time because it saves them the hassle of interviews in the future. A centralized testing entity could work to reduce cheating instead of every company having to do that themselves. Plus, administering this test would be full time jobs for folks, so it would likely be a higher quality test than what most companies give.
Well it’s not like the company you’re applying to has access to the test results from the company you’re leaving
> It's like companies are afraid that programmers will spontaneously forget how to program.
To be fair, I think most leetcoders agree that you need to practice regularly to keep your skills up. So if the point is to see how good you are at thinking algorithmically for the job you’re applying for, it makes sense that they’d want to see recent test results.
Every skill degrades without usage, but if you can verify that I've recently used it successfully, I'm not sure why I'm being tested on it again.
Which is a better signal? Passing a leetcode style interview, or 5+ years in a development role at a reputable company?
Yes, of course. If you have a degree from a recognized schools and many years of experience at the job, why would you be hazed on undergrad trivia you've forgotten decades ago?
None of my high school friends who went into accounting, finance, medicine, law, etc have this problem. What is it with the dysfunctional hiring BS in software development?
A surgeon with many experience at a top hospital most certainly does not get grilled on organic chemistry trivia from their undergrad classes when chaning jobs.
The reason I would ask this because I don't want to join a team that writes bad code.
They would tell me that each engineer did the same test and passed.
I would then say, "I don't believe you, I demand a live exercise so you can't cheat and help each other out". After all, their skills could have deteriorated since they joined!
People are only offended because companies don't believe our past demonstrations of competence.
So we could call that a degree? And have institutions that specialise in testing for it? And because some of those institutions will be better at measuring this, we could rank them?
I thought most people complaining about the current approach didn't like this one either.
Having a Medical Degree (Doctorate in Medicine), doesnt mean you are credentialed to be a practicing doctor either. Doctors btw dont get asked to "go diagnose this patient real quick" during their interviews.
Credentialism in tech is an interesting rabbit hole. We basically do have nurses vs doctors with degrees of speciality, but some places pay them all the same. Some places do pay the backend engineer differently from the front end guys.
Its well known that bare metal C engineers are not making as much as React devs in alot of cities, and most people seem to broadly agree the C engineer has a harder task than the React one.
So we would need to figure out whats the CNA/LPN/NP, doctor, general doctor, brain surgeon, and veterinarian of our fields. But it's not quite so simple right? We might think front end where you are grinding out simple React or PHP apps is easy, but if you are a front end dev on a billion plus dollar selling system or with very high stakes stuff going on you probably do want a "doctor level" dev right? You probably dont need the AI dev though (the brain surgeon) if we continue the analogy.
They might not be asked to do this because their board has already done it for them: https://www.abim.org/Media/h5whkrfe/internal-medicine.pdf
A US-centric view. My (Swiss) engineering degree certifies me as a software engineer ("ing. info. dipl. EPF", whose use is legally restricted to actual graduates).
At least in California, you don't have to go to law school to take this exam, and if you pass it you are just as qualified to practice law as someone who did go to law school. I doubt that happens very often but at least it's possible.
OTOH a Software Bar Exam would probably be much worse than the leetcode grind because it would inevitably become something you can only realistically pass right after finishing a very good CS degree, or equivalent study, in your 30's at the very latest. And it would become a de facto requirement for the better jobs, making the privilege bias even worse.
https://www.calbar.ca.gov/Admissions/Examinations/California...
A qualitative hiring interview would be perfectly fine if the interviewers had no discrimination in their minds. The real solution is having minds without it. It's probably a goal hard to achieve with grown up people. Easier with newborns. So any solution starts from their parents, grandparents, etc and will stretch over many generations. Education, mingle with people from every origin and background, etc, pick your favorites.
How many generations? Limiting ourselves to the USA think how long it took for women to get a vote since the Constitution and for an Obama to become president since the end of slavery. We can hope that the trend is accelerating but who knows what's going to happen next. The state of the rest of the Western world is not so different.
This is the optimum. Now the good because there will be interviews to do this year. Any stop gap solution would do but don't invest too much into it because if you don't remove the real problem any fix will be worked around.
Agree in that if discrimination is the problem, then thats the problem that needs fixed. But, if these companies really wanted to solve the problem of discrimination then they would be making efforts to do so besides leetcode.
I saw it mentioned earlier in this thread, people can subconsciously discriminate without necessarily realizing it from something as simple as seeing someone's name, their voice, appearance, etc. It's not that the hiring manager is consciously racist but they may have a picture in their head of what a "software engineer" looks or acts like, and if the candidate doesn't fit that mental model they are dismissed regardless of their skill.
In that case, why not anonymize the candidates as much as possible? Don't let the interviewee and interviewer see each other during the technical interview, don't even let those making hiring decisions see their name, distort the voice, etc. Make it as close as possible to "anonymous person A being asked technical questions from anonymous person B." Make the hiring decision and only then de-anonymize the candidate.
I recently had an interview for an ops role (sysadmin type) and was asked a series of PowerShell questions, normally no problem - but the interviewer wouldn't accept "I don't remember the exact cmdlet, but I could do Get-Command Get-xyz* to find it" as if they expected an encyclopedic knowledge of every powershell cmdlet ever made. On the actual job built-in help exists, google exists, KBs exist, etc. Why would I ever be expected to have all this information in memory when the resources to find the information I need is a keystroke away. Test for understanding theory and methodology, not specific commands/language function.
People still have to see people to work together unless we spend all our time in Matrix like cocoons. When they see each other and don't like what they see somebody gets fired or mobbed.
We can't expect companies to solve social problems. It's not what they are built for. They can hack around problems, create plausible deniability or anything else and that's all.
People solve social problems. I wasn't alive when they happened in the 50 / 60s but I saw recordings of people doing Civil Rights marches etc, not companies.
What we really need is for companies to stop trying so hard to find the absolute best most perfectest candidate that they screen out huge numbers who could have done the job but who missed some arbitrary keyword or coding test by a fraction.
If we could take a gamble on people and see if they sink or swim we could give a lot more opportunities.
It is very easy to fire someone, especially in the first 90 days. Most states are "at will," meaning you can fire anyone at any time for any reason (outside protected classes) and the employee can leave at any time.
Unfortunately, my company is not unusual in this respect.
This idea already exists in many forms. Pick any language, platform, or technical concept and there's someone offering training and certification.
It also describes the whole recruiting industry. "What if there was one person who did a lot of interviews and then presented just the best people to employers?"
It's an extremely human incentive alignment problem. Any certification program, interview farm, or bootcamp that makes more money when they produce more candidates will make quantity the goal, not quality. If you can figure out that problem, maybe there's a niche. Otherwise, it puts us right where we already are.
Most of the recruiters I deal with are only doing screens and maybe soft interviews -- I may be on the lower rungs of the ladder here though.
For the last point, I'll offer Offensive Security as an example because I have one of their certs. OS wants people in its programs as we're a source of income, obviously, but they don't get revenue from people passing. In fact, they get more revenue if you don't pass because they charge per attempt. They offer training for organizations too.
They also act as a verification service for their certifications:
https://help.offensive-security.com/hc/en-us/articles/360040...
The idea for a programming credential would be the same: an organization that offers training, doesn't make money on pass rates, and also is a trusted point of verification.
Some companies have offered to do technical interviews, then pass you to employers. This is a start, but it isn't industry wide.
We could call this a degree, perhaps in computer science?
This seems like an excellent idea!
Unfortunately my CS degree from a very-top school (CMU) counts for nothing in so many companies.
https://people.engr.tamu.edu/d-walker/Quals/GRE_CompSci_1.pd...
I guess one upside of these types of interviews is I've been able to disqualify candidates just because I don't like them and saying they didn't do well on the algorithm question as justification is a easy way to reject them without much explanation.
And what about every other field that doesn't use leetcode style interviews? Does a biotech company make their interviewees do lab work live? What makes software engineering so special that we need a different interview process?
Google had this process because they are very academia inspired and want to hire the best academics, with a college campus but better work experience, because they had very high back end scale requirements, where algorithms do matter. They also had a shit ton of applicants and favored the false negative over the false positive, which they explicitly and publicly state. You might be able to argue that scale doesn't matter as much at google anymore, but google has no reason to change its process since it first established it, and back then they really had those hard scaling problems to scale up.
The reason why the software profession tends to have extensive interviews is because we don't trust credentialing or even prior experience. [0] We don't want to hire the unskilled bozo who can talk and have brand name credentials but when you actually put them to work find they are not that good at all. So we actually test their skill as directly as possible with various forms of work sample testing with as long as an interview process the market will tolerate, which has stabilized to 5 - 7 hours, or an entire working day.
The beauty of this is that you don't need to get into a med school equivalent with it's crazy requirements, spend 10 years-ish of training and go into 6 figures of debt, get a residency / hazing ritual in a few limit slots in the USA and can come from almost any poor background or country even and eventually make more than most surgeons. In that light, needing to spend 3 months to hard core leetcode doesn't seem so bad.
[0] https://blog.codinghorror.com/why-cant-programmers-program/
And willing to take false positives -- good at grinding for interviews, bad at actual work -- and just carry that dead weight forever in order to get the true positives who keep the money machine whirring along.
I've come to realize this is hard for many to swallow, but as much as it feels unfair -- just like only hiring from Stanford and MIT -- it was an enlightened business decision for Google. The cost of the dead weight is a rounding error on some distant Sheet, and the opportunity cost of the false negatives can't be measured anyway.
I think they realize their process isn't perfect, and worse of all, all processes are imperfect and this is the tradeoff set they've chosen. Google also tracks how successful people are after the interview process, so there is a feedback loop inside it. I think it's partly why they dropped the degree requirement from applicants, because their internal data showed no correlation with internal google success.
I think leetcode is bad, and I've tried to get interview processes to change to go full work sample at my big tech with relevant coding exercises, but it's hard to do! And in some sub-specialites where you are implementing graph algorithms and more, a subset of algorithms is in many ways a relevant interview question.
I think slowly the industry is moving away from no-leetcode, but it's going to take a generation or two of startups to really succeed at that, and most vital of all, it has to become a FB / Google level company that defines the industry for the next decade. The current millenial and gen z wave suffering under the leetcode regime and think it's bad need to become the next directors of companies and push for no leetcode in their interview processes. This is just starting to happen which why you see some companies like slack doing no-leetcode in their interview process.
Before leetcode we had microsoft defining the industry interview process with bullshit lateral thinking puzzle questions, and now nobody knows about their existence, nobody complains about them on HN and you never, ever run into them. I think in 10-15 years, leetcode will be the same and we will all complain about impossible work sample coding exercises and take homes.
in other countries LC is not that common
I've never been challenged with algo questions - just purely day2day stuff, but those were software houses interviews mostly.
Leet code is the equivalent of math word problems. What they show is problem solving ability with algorithms and code. That's a different skill set. Almost like an IQ test.
>Does a biotech company make their interviewees do lab work live?
Not biotech, but according to my cousin, pharmaceutical research interviews are even more arbitrary. He had chat with 5 employees who asked questions about their own rather esoteric specialties. Most of the questions were completely unrelated to the work that he ended up doing, and my cousin thought that the interviewers themselves were unlikely to be able to answer each other's questions. Unlike leetcode, this isn't something you can predictably study. It just so happened that the labs my cousin had worked in happened to specialize in those same niches. There are so many qualified postdocs that want to move to industry that interviewers can afford to be picky.
The combination of absurd profitability (of which the tiny slice allocated to employees still seems like a lot) and a complete lack of any actual objective measure of quality.
Because there's no way to really test whether someone is good at programming other than hiring them and seeing how it goes, and because there is an effectively limitless amount of money to spend trying to organize a "solution" to this problem, and because learning enough about each candidate to make a properly educated guess doesn't "scale" enough for fast-growth companies, senior management has plenty of room and lots of incentive to look like they've got it figured out.
For some, this is following their creative whims; for most, it's "do what FAANG does because it must be working, look at all the money they make."
Anyway that's my opinion on it. If I ever have the power to change hiring at any large scale, I'll probably follow my own creative whims and make it even worse.
Leetcode style tests meanwhile are simply a waste of time. I might as well ask someone if they have seen that problem before and know the trick.
Here's an actual study with real data. All women failed the leetcode challenge when grilled (probably by a man). They all passed when allowed to do it in a low stress environment.
Just because a criteria doesn't match one's notion of "fairness" doesn't mean it's inherently a bad criteria. If Google wants to only hire people that are good at cracking leetcode and that ultimately leads them to have their current reputation of being out of touch, that's kinda on them.
The problem isn't discrimination, it's unfair discrimination -- that is, discrimination on the basis of something that should have no bearing on a decision to employ someone.
Any criteria you choose will rule out people who aren't able to optimize for those criteria for whatever reason. I believe that's OK, as long as you are aware of the tradeoffs and try as much as possible, in good faith, to minimize unfair criteria while maintaining those criteria that help you hire people who have the best ability (or potential ability) to do the job.
As for leet code vs an actually relevant test - I think this is probably laziness on the interviewer's part. Coming up with a good test (and keeping it up to date) is hard, and leet code questions are "good enough" to filter out the people who don't know what they are doing. Remember, most companies are fine with a high false negative rate if it keeps false positives low.
That is also my understanding, but everyone except young white males are in a protected class. Granted, young white males are pretty common in tech, but you would still be wise to design your HR practices in such a way as to avoid lawsuits.
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.
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.
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.
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'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.
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.
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.
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.
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.
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.
That's how your manager is going to be hired, as well as all of his bosses on up.
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.
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.
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.
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.
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.
[EDIT] fixed a mis-labeling.
If they want to be really undiscriminatory, the interviewer and interviewee need to not be able to see each other, and even real names (which can indicate gender and ethnicity) must be hidden.
When orchestras started doing auditions with candidates anonymous and behind screens, they ended up hiring a LOT more women and minorities - even when the selection committees had previously thought they were trying to be nondiscriminatory.
Deeply embedded biases are really hard to root out, even for ourselves.
The number of women increased, not so much the number of minorities[0].
[0]https://www.nytimes.com/2020/07/16/arts/music/blind-audition...
For others: https://www.eeoc.gov/age-discrimination
U.S. Equal Employment Opportunity Commission
Age Discrimination: <<The Age Discrimination in Employment Act (ADEA) forbids age discrimination against people who are age 40 or older. It does not protect workers under the age of 40, although some states have laws that protect younger workers from age discrimination.>>
* German academia has some incredibly stupid rules related to time-since-graduation, but age per se is a protected class.