Hacker News new | past | comments | ask | show | jobs | submit login
Poll: Is the leetcode grind necessary to land a high paying remote job?
297 points by throwawaynay on Jan 27, 2022 | hide | past | favorite | 607 comments
I live in western Europe.

I've worked for 4 different companies, for European salaries, without doing any leetcode type interviews(I ditched any company that was doing it), it was either take home tests about real problems, technical questions, or sometimes just trust in my abilities given my previous experiences.

I've never really trained for leetcode(or not consciously at least, I did do a bit of algorithms/data structures of course), mostly because I know that I would panic and perform poorly in this kind of interview, so I don't really see the point of practicing for that.(it's not really about whether or not I can solve a hard leetcode problem, it's about if I want to do it live in front of a recruiter, it make me anxious just to think about that and I don't want to inflict that on myself), I'd much rather have a hard take home test than an easy leetcode interview.

+If I have to spend a few hundreds hours of hard work on something I'd much rather work on an useful and potentially profitable side-project, rather than on pointless problems already solved thousand/millions of times.

Do you think grinding leetcode is an absolute necessity to land a good job at a company hiring worldwide remotely? I'd be aiming for salaries around 80-100k$. In my country the only companies paying that are FAANGs.

Thanks for your answers

No
623 points
Yes
234 points
Depends(please give more details in comments)
50 points



I believe leetcode is a way to skirt around discriminatory hiring practices. It’s not at all representative of most work environments. Some want to pretend they’re cognitive wizards, but many of the algorithms used to solve problems took years to develop. If you haven’t seen a particular problem before or had time to research it, it’s unrealistic to expect a candidate to solve it in twenty minutes in a high pressure situation. This process benefits individuals who have the luxury of time to spend preping. Something minorities, working parents, etc. don’t have.

I’ve been a software engineer and now architect for 15 years. Studying leetcode like problems won’t help me at my current job or a future employer once I get past their interview processes. What leetcode does do is make it difficult for minority candidates, those with external obligations, or those with families to get into firms. For example, I work 50+ hours a week with two kids and a parent with cancer. I work hard at work and have a lot of external obligations. I don’t have time or to study leecode problems.


It's just as easy to argue that leetcode-style interviews are because companies are afraid of being discriminatory in hiring. If you aren't allowed to consider culture fit (because it's discriminatory) or education (because it's discriminatory) or give take home work (because it's discriminatory against people with time constraints) or trust your feelings in a qualitative interview (because they're discriminatory), what can you do? Solving real engineering problems takes too long for an interview, and full-day interviews are also discriminatory against people with time constraints. You can candidates give some automated algorithms problem solving test- that's what you can do.


If leetcode is intended to avoid discrimination, in my opinion it fails miserably. As the parent poster mentioned, it certainly rules out people that don't have the resources to study, but it also rules out another class of people prone to panic disorders. I'll share my leetcode horror story to illustrate.

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.


>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

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.


No. Some people have panic and anxiety disorders and need professional help and/or medications to help them. It is this kind of tone deaf advice, “just prepare more, you’ll eventually get it!” that prevents people with a panic disorder from seeking professional help for years. It is like telling someone with diabetes to just try harder to produce insulin.


And how beneficial is telling people they have a mental disorder if they experience common issues that even healthy people experience? A mental disorder has to significantly impact your life for a long period. A symptom list that consists solely of freezing up when put on the spot in a rare high-stakes situation is not going to qualify. Any teacher can tell you this happens to everyone. Stop right in the middle of lecture, point at one student suddenly, and ask them a quick question that demands a quick answer and wait. The most common response will be "uh!uh!..." even when they know the answer. It's about the situation itself that people weren't ready for, not the specific facts they were asked about. You indeed need to practice retrieving information under the particular circumstances to build the confidence to not freeze up like that.


Could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.

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...


Spoken exactly like someone who has never had the pleasure of experiencing the vicious and debilitating feedback loop of a panic attack. Of course everyone gets nervous when put on the spot; panic disorders go well beyond that, to the point where you might believe your death is imminent during something like a routine interview, and your fight or flight response kicks in. Rather than concentrating on the problem at hand, your mind is focused solely on survival.


> You indeed need to practice retrieving information under the particular circumstances to build the confidence to not freeze up like that.

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?


True, though a lot of times the professional help will mostly consist of coaching you through how to "prepare more and eventually get it." The block is around taking the steps that help you improve. Yeah, medication is sometimes necessary, but exposure is a huge component of many different kinds of therapy.


Meanwhile on the job nobody is surprised or angry if you need to look up basics because they know you have five languages under your belt and are actively using three of them.


Yeah exactly this. "Figure stuff out without looking anything up or running test cases to see what they produce or going on a walk to think about it" is just not a useful skillset at all. I have zero, and I mean zero, times done actual work under those conditions.

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 experienced this recently in a surprise 'shared screen' coding exercise the interviewers threw in at the last minute.

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.


At this point I'm convinced "candidate froze up" is the cause of most of the cases behind the "LOL 2/3 of our candidates can't even write a for loop" stories. I think it's really common.


Allow me to pile on here for perspective, in hopes there might be people who hire people on here who can take this into account...

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.


YES! If it seems shocking that so many experienced developers can't even do fizzbuzz, that's because it's BS; interviews just suck.


My crowning glory for the interview-stupids was relatively early in my career going in for a PHP interview, which was the language I was by far the most familiar with at the time and had written many thousands of lines in, and not being able to come up with the "->" syntax for method invocation & property access when I was up at the whiteboard. I used a dot-style instead, and realized only after I left that I'd totally fucked it up (writing some OO code on the whiteboard was just about the first thing they asked me to do, and the interview was really short after that...) I'm pretty sure I also mis-named some built in functions. I'm bad at retaining language-specific details and have since started reviewing a relevant language syntax minutes before an interview, which won't stick by the next day but usually does for a couple hours so I don't do anything too embarrassing. Not being able to put together two non-syntax-erroring lines in a language I wrote a few hundred useful lines of the day before, without a reference, is otherwise the norm for me. This has mattered zero times—except in interviews.


Do you want me to write fizzbuzz in proper syntax in some language I have on my resume and 'can do' but don't actually do every day without the help of an IDE? Forget it.

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.


If it makes you feel any better, I can never remember BASH syntax. I have a gist where I keep all the common junk like for loops and array manipulation. Never had that problem in other languages as I can generally remember after 3 or 4 repetitions but my brain just can't grasp BASH syntax.


BASH is the most unforgiving syntax on earth, I would never even try and memorize that stuff.


The correct way to write more than 5 lines of bash is to delete the file and write it in python. You will thank yourself when you have to modify it later.


BASH and Regular expression syntax are two things that mysteriously expire from my memory after two weeks. It’s almost comical.


For some reason, I just can't remember things for life.

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).


Your post reminds me of a joke punchline which was something along the lines of "an engineer doesn't actually have to remember very much, they only need to know how to efficiently find the information when required"

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!


> 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

This happens to me all the time! You’ve described it so succinctly. How do you cope?


Some perspective from the interviewer side: just tell us straight up that you're panicking. While I can't guarantee that an elitist smug interviewer is going to always respond appropriately, I at least would make an effort to try to help you calm down, be it by removing trivial blockers (e.g. fixing some syntax blooper for you) or trying to paraphrase whatever you're trying to say but not finding the words for, or asking leading questions in the hope of bringing you back on track. A little dirty secret among interviewers is that we're supposed to be accountable for managing the direction and quality of the interview (i.e. one that devolves into a awkward staring contest is a failure on the interviewer's part for not interjecting appropriately)

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.


Slow breathing exercises and grounding (e.g., look at the things around you and name what they are) work well for me.

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.


This topic of “is leetcode necessary?” and the more general topic of software engineering hiring practices appear regularly on this forum, but this time is the first time I am seeing someone mention panic disorders/panic attacks as part of the interview process. Other people might have mentioned it before here, but I do try to peruse the threads that relate to interviewing.

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.


If you as a hiring manager have the choice to pick between two candidates, one of whom stays cool and productive under pressure, and the other who goes blank in emergencies, which would you prefer to have on your team? Stressful situations can occur in software engineering, including for example a moment where you realize production services are broken because of code you just deployed.


Interview pressure is nothing like an emergency. I'm cool as a cucumber in an emergency. Hell, I kind of love them. Interviews are another thing entirely.

[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.


I’m normally cool under pressure and able to solve technical problems quickly. But in a situation where what matters isn’t actually solving the problem but evaluating my performance and my brain goes into overdrive with perfectionism/meta thinking about what they are thinking about me to the point where I sometimes can’t even do basic math.


Exactly, I have been in such high pressure situations several times with directors and CIOs breathing down my neck, but surprisingly I am quite composed in such scenarios. Severity of the problem at hand is in fact liberating as it is easier to focus. But that is not the case with interviews, when there is a strong "me" factor in the thought process.


> 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

Great quote. Those feeling pretty much summarize to perfection the current fad of interviewing pressure.


Okay Password Swordfish. :P

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.


If I were that hiring manager I would have the wisdom to know that this provides no signal whatsoever of how successful those people would be on my team.

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.


> If you as a hiring manager have the choice to pick between two candidates, one of whom stays cool and productive under pressure, and the other who goes blank in emergencies, which would you prefer to have on your team?

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.


Your comment is not factually incorrect, but it takes a lot of logical leaps. Let's say: if all other things were equal, would you want to hire a candidate who has worked with just 1 programming language throughout her career or someone with experience on 5 different programming languages?

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.


I think I'd want the smarter candidate regardless in a job like software development that is overwhelmingly based on quiet focus time. It's easier to help them work through the rare emergency, than to help a less-skilled employee work through literally everything else.

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.


In the production issues I've been involved with, I was not forbidden use of Google, API docs, consultation with others, etc., and I did not have to work out anything on a whiteboard.


> In my opinion, it is borderline disability discrimination.

This rings pretty true to me, thank you for sharing your experience.


> 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.

Like a driving test and the training with parents/adults beforehand.

Even with some judgmental/skittish passengers its the same.


>what can you do?

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.


> 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.

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.


Well, the test result is pass/fail, and if you can verify I worked at a previous company, then you know I passed. The legwork might be finding out what their interview is like.

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.


> Well it’s not like the company you’re applying to has access to the test results from the company you’re leaving

Which is a better signal? Passing a leetcode style interview, or 5+ years in a development role at a reputable company?


Are you proposing waiving technical interviews for people who worked in "reputable" companies?


> Are you proposing waiving technical interviews for people who worked in "reputable" companies?

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.


There seems to be a class of engineer here on HN that is offended by being asked to demonstrate their competence.


I mean, if I ask each of the engineers at a company I'm about to join to do a live coding test, they'll just tell me to go away.

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.


You get to see their standards when you interview with them. You are free to decline their offer if you feel that the bar was too low, and maybe their engineers write bad code. On the other hand, they do not know the standards of the company you came from.


In 20+ years, I have rarely seen a technical interview actually be indicative of a team’s standards. I’ve seen good, bad, and much in between, but mostly I’ve found the “standards” communicated during the interview to be purely aspirational at best.


Both. Barack Obama calls this a "false choice". There isn't a single best signal. Both have positives. Ideally, you want a candidate with both.


A never ending high pressure gauntlet, of course! The dream of dreams!


> We need a credential that counts as passing a technical interview

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.


An Engineering degree from even a prestigious University doesnt make you an Engineer in many disciplines. You have to go do a different credential to start putting together buildings and bridges.

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.


>Doctors btw dont get asked to "go diagnose this patient real quick" during their interviews.

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


> An Engineering degree from even a prestigious University doesnt make you an Engineer in many disciplines.

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).


who exactly is going to refuse to hire you as a software engineer if you dont have that degree again?


I think the suggestion is for something more like the Bar Exam.

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...


I think that most people here are mistaking the finger for the moon. If discrimination is really the reason why we have this kind of interviews, the problem to solve is discrimination and not the hiring process that is attempting to fix it or to hide it.

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.


> I think that most people here are mistaking the finger for the moon. If discrimination is really the reason why we have this kind of interviews, the problem to solve is discrimination and not the hiring process that is attempting to fix it or to hide it.

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.


Anonymity gets us not very far.

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.


No. One of the reasons those leetcode interviews happen is because existing credentials, such as a bachelor's degree, don't work. Adding another one that some hirers will value highly and others will be skeptical of doesn't solve anything.

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.


IMO, I think we just need a way of easily firing people if they suck. It's very very difficult to termi ate without fear of retribution so the barriers to entry just keep getting taller.

If we could take a gamble on people and see if they sink or swim we could give a lot more opportunities.


It's not hard. At virtually every small company I worked for, not only is there no leetcode bullshit, firing wankers is as easy as giving them the termination slip. US has at will employment, 'you've been fired' is literally all you need to say, no explanation is required. You get hired after a conversation with a CEO, in my experience the hiring and firing process are both completed in under an hour.


I work at big companies. It's basically impossible. You have to transfer them to Milton's basement office and pray their inflated self-evaluations make them look for a new job.


>I think we just need a way of easily firing people if they suck.

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.


Legally, it's easy. But getting the HR bureaucracy to go along with it is a long and unpleasant process. The last time I fired someone for doing no work at all and arguing over everything, it took about 8 months.

Unfortunately, my company is not unusual in this respect.


There are a lot of companies without HR. Due to my background I haven't been hired for for a company with an HR (other than contract work) for probably a decade. If you want to hire and fire people easily, look for small companies, usually less than 20 people. Beyond that the CEOs tend to get tired of dealing with human administrative tasks, so it gets offloaded to HR. CEOs have a lot more risk tolerance so naturally when HR gets involved they focus on saving their own asses (which usually means taking low-risk rather than highest profit) rather than the good of the company.


If Leetcode becomes a credential onto its own, then at least job seekers aren’t asked to retake it at every company they interview for.


> We need a credential that counts as passing a technical interview

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.


The trainings and certifications won't let you bypass technical interviews though. There's still inherent distrust of them. We need a credential good enough that companies can trust.

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.


Maybe run the testing and evaluation side of things at cost. The certifiers instead get profit from companies that subscribe to their certification verification program. There's a small fee for the employer to verify someone's certification is genuine. Part of the employer's contract with the certifier would be that anyone the employer hires who has been verified to be certified, when they've been employed at the company for a year, they owe the certifier a bonus. There's a second bonus at five years and that's the end of the payments. The certifier is incentivized to only certify workers who have genuine skills as those are the ones most likely to hit the one and five year milestones. Talent acquisition is expensive, as is employee turnover, so employers will not have an incentive to layoff employees right before their employment anniversary in an attempt to avoid the fee they owe the certifier. They'll find that the anniversary fee is a small price to pay for having been matched up with an employee with the actual skills the employer needs.


They are useless because the bar is so low that anyone can pass. Your credential only has value if few people can obtain it.


> 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.

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.


But they do forget how to program. Or maybe they never knew and got lucky to get the previous job.


Why don't they just use the computer science GRE?


I took a brief look at a CS GRE test prep book from a Google search, and it probably doesn't cover the same things leetcode does, nor does it really test code writing ability (because it's multiple choice):

https://people.engr.tamu.edu/d-walker/Quals/GRE_CompSci_1.pd...


The CS GRE was discontinued nearly a decade ago, e.g. https://www.reddit.com/r/cscareerquestions/comments/176c13/d...


If the true purpose of algorithm tests was to be non-discriminatory, the interview and interviewee should not be able to see each other, their voices should be masked to hide nationality/accent, and resumes should not be viewed when solving the problems. I assure you I can still discriminate against a candidate both consciously and subconsciously during a live algorithm question now.

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?


I don't think that much thought has been put into it IMO. It's cargo culting the google interview process, and no standout success since google has a very different interview process to cargo cult copy.

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/


> favored the false negative over the false positive, which they explicitly and publicly state

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.


When they say they favor the false negative, that doesn't mean that false positive wont happen, is they would rather tradeoff a with a process that produces more false negatives if it produces less false positives because they have a firehose of applicants to chose from.

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.


>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.

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.


I have yet to meet someone who can talk the talk but can't walk the walk. But I am technical, so I think you need a technical person to evaluate that. The risk is when non-technical folks evaluate the technical and they can be fooled.

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.


It's very rare that people intend to be racist. Rather, they have intuition of what a "good programmer" is in their head, which is subjective, and thus more likely to be discriminatory. If you give them an leetcode question and a rubric to grade their performance, it's hard to deviate from that rubric to much unless if you're intending to discriminate.

>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.


This is probably very dated, but when I worked in biotech the interview process was just about 100% trying to find a "culture fit" (to be fair, in an industry about a thousand times more diverse than software) and politics. If the hiring manager brought someone in then you assumed it was on them to have screened for competence, and you wanted to figure out which candidate you'd like to work with, and/or figure out which candidate was favored by which person in power so you could vote advantageously.


It is common for up to mid-level jobs in finance and consulting to require doing on-the-fly modelling and analysis in Excel. I am pretty sure things like structural, mechanical, or chemical engineering also have substantial technical components to their interviews. While it is not done directly by the employer, board certification for doctors entails 8 hour long tests. Similarly, tradesmen like plumbers and electricians require in-depth written and practical tests for licensure. You can definitely dispute the practicality of these for the job vs. leetcode, but I really don't think that the rest of the world is getting jobs with a resume and a firm handshake.


> What makes software engineering so special that we need a different interview process?

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.


I have conducted a fair number of interviews and never been surprised at their on the job skills. I really don’t see much of a difference between interviewing people for coding positions and management etc.

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.


https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/

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.


Interviews are, by definition, a way to discriminate candidates based on some criteria (using the dictionary meaning of word here). There are certain classes that are illegal to discriminate against (e.g. religion, ethnicity), but things like education are totally fair game. Airlines, for example, use physical fitness as a discrimination criteria under the rationale that a flight attendant must be able to function in the rare event of an emergency.

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.


I think the problem here is that any criteria you use to choose one person over another is discriminatory -- that's the dictionary definition of discrimination: the choice between multiple competing options.

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.


In that case couldn’t you give an automated test that more pertains to the job requirements and the applicants’ prior experience?


Giving each applicant a tailored test also opens yourself to allegations of discrimination.

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.


Is discrimination even illegal? I thought unless it was a protected class, discrimination is ok. Unless you're giving all black people a shittier test or something I feel like it's a long and expensive road ahead of someone pursuing legal action, with probably not much to gain and no attorney particularly interested unless it is some class action against a big company.


> I thought unless it was a protected class, discrimination is ok.

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.


Agreed it would be wise to consider lawsuits when hiring. I do think though that's only one part of the equation. What you want to really optimize for is maximizing profit. Maximized profit may mean paying out lawsuits is cheaper than losing good candidates or implementing a poor or ineffective hiring process. There's also the risk of implementing a hiring process for which the expense of minimizing lawsuits is greater than the potential lawsuits themselves.


> 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.


I don't think that's accurate.

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.


Plenty of other industries could come up with barely-related-to-your-day-job stealth-IQ/how-bad-do-you-want-this test, but don't.


> 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.


*their bosses.


https://en.wikipedia.org/wiki/Gender_neutrality_in_languages...


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.

[EDIT] fixed a mis-labeling.


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.


In the context of the parent comment which described how leetcode-style interviews are discriminatory, you have just nicely described nicely why the leetcode-style interviews are because companies are afraid of APPEARING discriminatory in hiring, and provided other methods of plausibly-deniable discrimination.

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.


> When orchestras started doing auditions with candidates anonymous and behind screens, they ended up hiring a LOT more women and minorities

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...


Wait isn't it only illegal to consider Race/religion/sexual orientation? Have these other criteria become officially illegal or just a possible lawsuit? I can't see how any company looking to build a good team wouldn't consider culture fit. One bad hire could tank a team so I'd imagine they are very cautious?


It's illegal to use proxy metrics that impact a protected class more than others. This is to prevent companies from discriminating by hiding behind tests whose main purpose isn't to match on skills needed for the job but to filter out members of protected classes. An employer can prohibit the wearing of a turban if it is a legitimate safety hazard. They can't prohibit it if the purpose is to ensure no Sikhs get hired. What's the purpose of leetcode? Does it map directly to a job's primary task or is it a way of filtering out certain protected classes such as those of an older age?


Age (>40) and family status are definitely on the list as well.


I assume you are referring to United States employment law?

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.>>


Yes, but it's similar in Canada and Germany* too.

* German academia has some incredibly stupid rules related to time-since-graduation, but age per se is a protected class.


What's legal varies by location, but even if it's not illegal to discriminate against the other criteria in the GP's list, a company may consider those factors and try to avoid that discrimination anyway. After all, you want the best candidate, regardless of what their home life is like.


Like anytime you're evaluating someone's compentency, find out what they view as a good example of their work and judge on that. Don't stick to any standardized hiring process, instead get to a burden of proof.


Yes it’s a substitution for practices that are illegal for the same reason we use the substitute. No need to be defensive about achieving intended results.


Yeah I agree I'm similar to you in that I'm a parent with 2 kids 16 years exp and these leetcode tests kick my butt.

The companies making you do this though likely don't want someone like me. They want someone young who will burn themselves out working 80 hours a week for them.

So I guess it's a good filter for me as well.


Facebook and Google don’t expect 80 weeks and they do leet code interviews. I’d think most people do 40 hour weeks there.


I'm doing the hiring for a small company. We do coding tests as part of our interview process. I know it can show false negatives but it rarely shows false positives (wrt coding ability).

However, we don't ask employees to work anything like 80 hours a week. In fact, we track overtime hours (> 40hrs/wk) and pull the red "panic" lever when it goes above a threshold as a control for burnout.

But like you said, you're applying a filter too (if no coding test -> low overtime required). It probably has false negatives (my company), but it's worth it for you because you have found that it rarely shows false positives.


Almost nobody would stay productive coding 80 hours per week.


Almost nobody is productive past the 30 hours a week stage (excl meetings and lunch hour and whatnot).


Ignoring whether leetcode itself is useful or not. Do you believe it's inherently unfair to discriminate in favour of people who dedicated more time to e.g. studying CS theory, contributing to open source projects, working on hobby projects, earning advanced degrees etc. ? All of those things require time and money (in opportunity costs).


No, I think those are great ways to stand out and demonstrate interest and side projects and degrees are more representative of actual work. Leetcode itself though seems to be used as a gatekeeper benefiting those with the luxury of time to do the grind. It doesn’t mean you’re necessarily getting more qualified candidates and are possibly excluding some folks who would be more than capable.


Finding people with too much free time is the entire point of leetcode. Companies want employees who will dedicate their life to their work. If you don't have time to grind leetcode employers feel that you won't have time to work 60 hours a week and spend your free time thinking about work.


I think it's more common that people just have the unexamined assumption that programming skill is more of a natural talent than it is, and also that these tools are an effective way to test for that talent.

I'm sure what you're talking about happens too, but I've seen the other thing first hand a couple times so I know it can be less malicious than that.


I think people have over updated on spending free time on leetcode is the only way to solve these problems, but as a undergrad doing internship interviews, the problems weren't that hard?

Has it gotten worse in the last 5 years?


There are boot camps for developer interviews now. The practice is bad and it is inhumane. They will eventually go the way of other unintended gatekeeping disasters like the standardized high school/college tests.

The practice is just a veiled hazing ritual meant to strip you of dignity and agency.

If it isn't meant to do that...well, guess what? That's what it is doing.

And if I study real hard and maybe take a boot camp, I can join one of the illustrious paragons of internet virtue such as Facebook (sorry, meta block chain addicts inc.) or Google to spread ad-tech throughout the known universe.


I do think it’s inherently unfair that high-paying jobs are placed behind arbitrary leetcode gates. Dedicating time because you’re passionate is great, but I’m not here to feed your hobby. My experience is that people who dedicate lots of time to development outside of work burn out around the senior engineer level because they never get to use the cool techniques they play with on their own time.

Most development jobs require very little CS theory or hobby projects to do the actual work. Most of what software engineers build are glorified CRUD apps. What those things tell a prospective employer is that you’re willing and able to grind yourself to the bone.

Case in point: I’ve been hiring people from local minority jobs programs for entry level dev roles. Yes they’re green as heck (usually just a coding bootcamp) and we have to handhold them for a few months, but it gives mentorship opportunities to our mid-level devs and after 6 months of project work you’d be hard pressed to tell the difference.

Not everyone can take a couple years off work to go get an advanced degree. These jobs are not so hard they require one. Credential inflation is out of control, and trying to hyper-optimize individual achievement often ends up building poor teams. Give me someone with good work-life balance and priorities outside work any day.


"people who dedicate lots of time to development outside of work burn out around the senior engineer level"

Word. I left the industry to sit around my farm and raise my kids for about ten years. When I came back and started working with people I was shocked at how long it takes to learn anything about tech on the job. I was working on my own trying everything while I was away.

I noticed that my "senior" co-workers who had been working the previous whole ten years knew far less about the inner workings of the various tech they used daily than I did. I would rattle off something and expect a comment or answer and would repeatedly see architects and lead devs freeze up. I watched as they completely botched implementations simply because they didn't read the manual. The surprises were many because they used the same mental model to understand everything.

One implementation with a vendor required socket programming. They snapped and threw up their hands immediately in a big huff. I pointed out that C# had libraries to support that and that it was fairly trivial and probably way more fun than consuming a HTTP API. It took a few of us to calm them down and get it working but the dev who was assigned to it continued bitching. They were incensed at having to program against a TCP stream. It was so easy and trivial (imagine a binary string the size of an encoded JWT). He fucked it up bad and blamed the network for weeks.

In another instance, they were having trouble selecting a protocol for an external message passing framework. After selecting one at random I started asking about the protocol, mentioning that it sounded like it was based on "remoting (RMI binary non-routable transport). They had no idea. That concept of not having any idea about the underlying libraries and tech they selected was spread across an entire project, causing many real life disasters.

This all worked out great for me because I got use my deep knowledge a lot to identify root causes and fix thier messes which led to mahoosive salary increases and bonuses.

These bros were trying to leetcode everyone they hired. I couldn't do fizzbuzz to save my life. Just not interested in it. Is leetcode a filter to make sure you can work on the same old boring shit without losing it?


>I couldn't do fizzbuzz to save my life

I don't understand. You clearly could take a spec "output numbers ..." and turn it into code, as you can take more complicated specs and code against them no problem.

If asked in an interview "Why should we use jitter when doing exponential backoff when packets fail", is that a more interesting question?

Is it the blank editor with no compiler/docs which makes it hard to write code, or the interview stress of someone watching?

How would you try and separate out the best of your co-workers from the rest in a day or two?


I would submit that humans cannot easily be ranked from “best” to “worst”; and even the most genuine attempts at doing so will only capture it for a moment in time as both the individuals’ skills and the business’ needs are constantly in flux.

And yeah, I feel you can adequately gauge someone’s skill level across a technical subject area in 4 or 5 simple “how would you” questions. The way they explain it will tell you a lot about their understanding of the subject matter. In the old days (when we were in-person and I was still a technical SME) I would have them use a whiteboard to explain a technical concept to me.

This job is not that hard. I think a lot of companies have an overly fond view of themselves and most of these complex interview processes are for their own ego.


You can discriminate on skills relevant to the role. The issue here is that these are extremely weakly relevant, but discriminate on features not relevant to the role.

The argument is that leetcode is a means to dress up the latter as the former. Prima facie, this seems plausible. I dont think it's racially/etc. motivated -- I just think interviewers like people "like them", and leetcode selects for "like them".


Another way to look at it: If you were running your own small business, given the choice between a candidate who had more of "studying CS theory, contributing to open source projects, working on hobby projects, earning advanced degrees etc" compared to another candidate... which would you choose?

Hiring is not about absolutes; it is about relatives (local maxima). When you work at an "elite" company, you quickly realise that you don't need to be a genius. For each open role, there must be 100 qualified candidates. As a candidate, you need to be a more-than-a-little-bit lucky to get the role! How does the hiring manager choose? Start with a baseline. Then pick the best.


I think you're right that it's a filter in favor of people who are willing to waste more time for their employer. I don't think it's unfair, just a bad hiring practice.

Be curious to see numbers on burn-out rates between people who do practice leetcode to get hired and people who don't bother with it.


I'd argue that exactly the opposite. It allows those who don't look or speak a certain way to shine. It allows people who don't have good contacts and family networks to demonstrate their capabilities.

Our firm has every candidate take a quiz of five coding problems. Two of which are quite easy and the remainder a bit more difficult but none of them even approaching "leetcode" levels of difficulty. Even so, let's just say that most candidates don't do very well.


I too am supportive of using LeetCode-style easy problems. FizzBuzz used to be all the rage, but dummies have memorised that now. :)

For a long time, I used an easy-to-understand, but hard-to-be-perfect interview problem: Please implement the classic C-function atoi() [string to int] in any language. (The candidate cannot use a built-in to do the parse!)

The best candidates immediately dissect the problem and start to ask about edge cases. The worst ask no questions and very rarely do a good job, and never think about test cases.


As someone who broke into the industry without formal CS education, contacts, or family networks and struggled to speak confidently and coherently in interviews, leetcode didn’t do anything for me except stress me out that much further.

I’ve been able to stay comfortably employed and even climb the ranks in software dev for 7 years now, but had it not been for the company that first hired me eschewing the leetcode in favor of practical exercises in their interview, I wouldn’t have gotten in until a couple years later at minimum, assuming the resources required to continue studying held out (I was extremely cash-bare at that point, so absolutely not a given).

Now that I have years of experience under my belt it’s not as much of an issue — lots of places want to hire me regardless, but if I really had to I could drill leetcode for a couple months to prep for an interview. Back in the early days that wasn’t really practical, though.


Having been in charge of hiring a few times I can absolutely tell you that coding problems are not motivated by a desire to "skirt around discrimination". There is no need to skirt around it, we could just do it, via whatever method of interview you want to propose.

However I have seen the "leetcode" process defeat discrimination at least once in my career, when HR was assuming a black guy was not qualified but he was able to prove himself on the white board.

There are plenty of good critiques about the whiteboard process, many of which I agree with, but this critique is silly.


> I’ve been a software engineer and now architect for 15 years. Studying leetcode like problems won’t help me at my current job or a future employer once I get past their interview processes.

Perhaps. I've been building software for over 30 years and I still find that I learn a lot when I practice and push myself to work quickly and efficiently.

> If you haven’t seen a particular problem before or had time to research it, it’s unrealistic to expect a candidate to solve it in twenty minutes in a high pressure situation.

Someone just slipped a bug into production. We now have $12,399 per minute in transactions that will not be processed. CEO needs a report for a board meeting in 20 minutes. Junior dev didn't show up and four team members were waiting for the commit he was supposed to have in yesterday. Dealing with high pressure problem solving is really every day, and practicing against the clock is a great way to learn to be calm and focused when it matters.

> For example, I work 50+ hours a week with two kids and a parent with cancer.

So sorry that you are dealing with cancer in your family's life. Cancer sucks.


If you have a major bug in production and have to report to the CEO in 20 minutes, all kinds of soft skills that you can show in interviews are going to serve you vastly better than knowing a leetcode algorithm.


> Someone just slipped a bug into production. We now have $12,399 per minute in transactions that will not be processed. CEO needs a report for a board meeting in 20 minutes. Junior dev didn't show up and four team members were waiting for the commit he was supposed to have in yesterday.

While it's helpful to have rockstar devs that fix that kind of situation in 5 minutes, I'd say you still have to have boring people who test thoroughly, document properly, and have deployment procedures and rollbacks figured out, none of which is something you identify from a Leetcode type test; yet these practices which lower the chances for that scenario to happen in the first place.


Hey Mr CEO, I have no idea how that bug slipped into production but I see you have a whiteboard here… let me show you how to invert a binary tree.


> $12,399 per minute in transactions

> Junior dev didn't show up

Why is the junior dev in charge of something so important? What were the senior people working on instead that was more important than this? Sounds like he cracked under the pressure. Where was leadership?


> Why is the junior dev in charge of something so important?

I think you are blending all of those problems together (there are three - hopefully not all of them at the same time... that would be a worst day ever). It's pretty normal that someone can't get to work, and you end up with a last second scramble to get something fixed. When something ships into production and is buggy, what matters is fixing it quickly.

The point is that most developers do end up having to work under pressure from time to time, and the higher up you get, actually, the more critical it will be.


The situation you describe is not what you face in leetcode. The key here is "a problem space not seen before". Bugs in production by definition are problems in a domain on which you are currently working and are familiar with. So yes in that case I would expect someone to work efficiently even under pressure. But a problem in a completely new problem space no. Someone may know for example that a presented problem can be seen as graph traversal problem but may be blocked for the moment on the actual implementation of it. This is a context switching problem and not a performance problem.


I don't think it is fair that you are downvoted, the parallel you are presenting is a real question, eg. how much does being good at leetcode correlate with being good at solving production issues timely and efficiently? (Even if real life production issues are _not_ leetcode problems, but nobody said that.)

I don't think that there are any conclusive studies covering this, so both sides might be correct for all we know.


Sounds like an organization problem to me. Roll back to the last working state. You have CI right... right?


Roll back prod?


What do you do when that fails?


If you don't occasionally test your rollback capabilities, you don't really have any.


Your comment reminds me of the video where they ask white people in Berkeley, CA if voter id laws are racist. They say yes of course they’re racist because African Americans don’t have id as often, don’t have as much access to the internet, don’t know where the DMV is, etc.

Then they go to Harlem to ask people what they think of those comments.

https://youtu.be/yW2LpFkVfYk

As for your claims themselves, In 3 months I studied 350 hours to pass the hardest test in finance while I was married, had three young children and worked full time. Nobody has time to do the things required to advance your career. You have to make the time.

For years, I also recruited and mentored students from an inner city bootcamp near me where the students spend 80-90 hours per week for 12 weeks learning software engineering. The vast majority of students are minority and there is fierce competition to hire graduates by local companies.


> Then they go to Harlem to ask people what they think of those comments.

Maybe they should have asked in one of the states that is actually passing restrictive voter ID laws, and that is at the same time closing DMV offices in minority areas, limiting the hours that DMVs issue IDs, and has nearly non-existent affordable public transit.

The might have gotten different answers than asking in a state that is pro voter rights, in a neighborhood that has a DMV office, and that has excellent access to public transportation if for some reason the neighborhood DMV is not available.


How are all these people that are unable to get an ID able to finance a car, pass an apartment background check, open a bank account, buy alcohol, obtain govt. assistance etc?

In order for me to add my family to my insurance I had to provide identification for each of them, including a marriage certificate and drivers licenses for myself and my wife. All that just to get health insurance.

In order to vote you should have to identify yourself and that you are eligible to vote in a US election. It's complete nonsense that getting an ID in the US is just too much of a burden.


Can you actually name a specific town/county that has this problem or is this imaginary?


It's happening in multiple states. Finding examples is trivial.

https://www.aclu.org/blog/voting-rights/voting-rights-act/al...


In public opinion polls black voters strongly favor voter ids.


Those polls also show that they strongly favor free IDs that are easy to obtain.

Almost no one opposed the idea of voter ID if it is free and easy for everyone who is eligible to vote to obtain such ID.

It's when shenanigans like those in North Carolina described in footnote 360 in this report [1] take place that it is a problem. The government knew that 25% of black voters lacked DMV-issued photo ID but the law provided that all government issued IDs would work (even expired ones), so that was fine. Then with race data in hand, the legislature amended the law to exclude most of those non-DMV IDs that black voters had, and retain the non-DMV IDs that white people were likely to have.

[1] https://www.usccr.gov/files/pubs/2018/Minority_Voting_Access...


You can select people to display in your man on the street interview segment to make it look like the average American doesn’t know who the President is.

Regardless of what some people in Harlem think, data shows that minorities are in fact much less likely to have government ID.

https://www.brennancenter.org/sites/default/files/legacy/d/d...


data shows that minorities are in fact much less likely to have government ID.

The study you provided was a phone survey of less than 1,000 people that occurred 15 years ago. It along with other studies showing similar results were debunked by researchers at Stanford, Yale, and the University of Pennsylvania.

http://stanford.edu/~jgrimmer/comment_final.pdf


That comment paper isn't actually debunking that specific survey. It's just essentially saying that proving that voter ID laws suppress minority votes is hard.

The phone survey of less than a 1,000 people is still a perfectly valid piece of evidence. The methodology wasn't obviously flawed and the delta was so large that the sample size was more than enough.

Here's another survey from 2012 that shows a similar number.

http://www.projectvote.org/wp-content/uploads/2015/06/AMERIC...

Sure as your comment paper points out, you can't use nation wide data to prove state level causation, but there's still good evidence that minorities are much less likely to have government ID.

It's not a shocking result either. We know that not having ID correlates with low income, and minority status also correlates with low income (on average, sure there are some minorities that actually have higher income).


There are other studies. See some of the references here [1].

[1] https://www.aclu.org/other/oppose-voter-id-legislation-fact-...


There are other studies.

The first reference on your link is the exact link to the exact study the other commenter provided.

The second reference on your link itself uses as a reference the exact link to the exact study the other commenter provided.


Hmm. I dare say you could make the same video in the UK but not about race, instead about about how "poor people can't afford ID". But, statistically it's still true, and the people who can't afford ID are working one of their two jobs (or unemployed) not walking around town during the day.

Free, state issued ID is part of the answer but the opportunity cost getting to a photo booth (!) is still a surprisingly large inhibitor given the stringent requirements on photos. (I do my own photos at home, you have to have a reasonable colour printer, I edit on the computer but you could probably do it on a smartphone nowadays).

If people of a particular background are over-represented amongst the [very] poor (such as "White Irish" in the UK) then they'll be disproportionately disenfranchised.


The claim was always about undocumented immigrants voting and the Democratic Party gave up on that because even immigrants started hating them lol.


What’s the hardest test called?


Google "hardest test in finance" and the CFA exams are the first several pages of results.


The hardest test in finance is a physics/math PhD defence, from MIT or Caltech.

CFA is just a decoy.


You could possibly make the same video about literacy tests used in Jim Crow. The key thing is having a racist outcome and then finding metrics to achieve it with plausible deniability (I don't find it plausible that leetcode was put into place like this, but for voting it has a long history).


It’s somewhat unhelpful to lump all the questions that leetcode asks in one bucket. I’ve been coding for 25 years and have never once needed to apply any dynamic programming methods. But I did some leetcode prep recently when looking for a new job and reviewing some of the tree and graph algorithms wasn’t totally useless because those things do come up from time to time in regular dev work.


I'm with you on this.

I don't remember much of algo questions before 2010 outside of actual GOOG. If anything, OOP design like "for a game of chess" were common in LNKD-like companies. And j.u.c-like real life knowledge.

I remember being asked to implement quick sort or reverse a list in 2010 or so. Then to do DFS on a graph or detect all connected subareas of a matrix in 2015. DP questions were so new I din't know what they were back then. I had interviews last year with two out of three rounds being DP puzzles.

I don't know about junior engineers but I want to go outside at least on weekends and not think much about computers. So the hours I have for "studying" can be spent either on learning something new and useful (Flink? ML? golang generics?) or memorizing this mindless leetcoding. I've done development for too long to have any interest in algo trivia or problems not based in real life situations.


I would say going further back in time, for example, MSFT during the early 2000s, the interviews were far worse, it was "fermi" types of questions (e.g, https://www.innovativeteachingideas.com/blog/an-excellent-co...)

Often the same thing in for example, typical wall street firms before 2008.


That's fair, but you also don't usually get the luxury of telling the interviewer that you only studied the tree and graph problems so you won't be doing any dynamic programming questions they happen to ask.


Have you ever done much optimization or worked on solvers? DP tends to come up often in that type of work.


What does being a minority have to do with freetime? Most of the people I worked with at my first faang were minorities. Seems like weird pandering. Also, If i'm going to pay someone 3-400k a year they better be able to whiteboard out some honestly pretty basic algorithms. They're paying the best, want to hire the 'best', and the 'best' can do this in addition to having systems knowledge or whatever. If you don't want to prepare or find it too difficult then you aren't worth 3-400k because there are enough people that can pass the bar at that price range. And to be honest, I don't think 'grinding' leetcode is really too much to ask for how much you are going to be paid. These complaints always come across as whiney people that want something for nothing. You have to compete.


You mentioned "minority candidates" twice there. Both times it was in reference to them being at a disadvantage.

I read that to mean that the tests are geared towards white candidates! Is that really what you mean? Coz I can't wrap my head around that!


It's woke nonsense. These tests are obviously color blind.

And I bet Asians (a minority) , as usual, do better on them on average than the white candidates. Not because the tests are designed for Asians, but because of culture of studying hard.


Uhh, this is a model minority myth.

https://thepractice.law.harvard.edu/article/the-model-minori...


So their argument is "Asians are diverse, with a wide range of earnings, therefore it's myth". Sorry, but it makes zero sense. You should stop reading obvious illogical propaganda from race activists.

Also Asians isn't the only minority group that outperforms whites.


HN won't let me reply to the parent, but I thought your model minority myth was potentially interesting.

In this case, it just doesn't stand up to facts. Yes, Asians have greater income disparity, because the top 1% of Asians are way at the top 1%. According to the U.S. Census (https://www.census.gov/data/tables/time-series/demo/income-p...) in every single year, Asians have out-incomed White and all-race averages in the 20th, 40th, 60th, 80th, and 95th percentiles.

That's a pretty compelling picture of "Asians make more money than whites," full stop.


I also noticed that. It's very racist the assume that all minority candidates are disadvantaged.


Familial wealth is correlated with race.

Familial wealth provides an individual with more free time, generally.

More free time before a big interview means more leetcode prep time and memorization of the answers.

More leetcode prep time leads to passing leetcode interviews more often.

This isn't that complex.


> This isn't that complex.

It really bums me out when people reach for this kind of "how are you not getting this" slight. You could have just explained the reasoning without implying that the asker is an idiot. You're just making yourself harder to hear.


It really bums me out when people don't understand basic microeconomics


Bullshit! Absolute utter woke bullshit!

I don't have familial wealth and I can study for stuff. I happen to spend around an hour a day (most days) studying programming-related topics.

I'm sick of this woke nonsense pervading society.

Studying for a Leetcode exam has sweet-fuck-all to do with race!


The keyword was ‘correlated’, thanks for the anecdote though


> minority candidates

I guess 'poor [edit: low on money] candidates' would be more precise.


How does having ample time to prep for leetcode like problems make you a better candidate exactly?


I’m not him but I read his comment as simply taking issue with the idea that it’s minorities in particular who don’t have time for that, rather than simply poor people. (The terms are not interchangeable, since there are many wealthy people who are members of a minority, and there are many poor white people)


Yes thank you. Sometimes you should just write out things explicitly ...


I think GP meant 'poor' as in poverty. It goes with your examples of economic hardship and not having the free time for leetcodes. My charitably interpreting 2c, anyway.


Oh ye. I didn't think you could interpret what I wrote as "poor [quality] candidates".


I think the GP likely meant "poor" in the sense of "destitute", not "poor-quality".


Financially poor


I don't remotely understand how.

You literally can get good at leetcode with an hour a day for a couple of months provided you studied computer science or even just like took AP Computer Science in high school. And even that just requires an internet connection.


How do you not understand that many people with families or other external obligations wouldn’t have the luxury of spending 7 hours a week for multiple months on leetcode?


Like everything else, it's an opportunity cost. Personally, I think LC is a great return on time invested. It takes far less time and money than say, any of the traditional gatekeepers, even for example a CS degree, or even perhaps a good data structures and algorithms class that is semester long.


If they need to spend that level of time in order to do a few search or sort problems on a whiteboard I'd be concerned that they don't actually know algorithms or datastructures.

The kinds of questions most companies ask are not hard.


I am 35 years old and never even heard if a high school computer science course. I spent one period of my last semester assisting the network admin with maintenance tasks, which was the closest thing we had to AP computer anything, and only 2 students in my class had the privilege.


My pet conspiracy theory is that leetcode is used to exploit imposter syndrome in candidates. After going through an hourlong session where you came up with the less-than-optimal but correct solution, I think it's easy for the interviewers to seem "disappointed" and lowball the candidate with a worse position/salary.

I think this partially explains the phenomenon of external candidates at Google entering Google at the college-hire tier when they may have been repeatedly promoted at their prior employer. Of course the comp is usually more so it's not a big deal...


> I believe leetcode is a way to skirt around discriminatory hiring practices.

Can you flesh this out because you claim it but then provide nothing to back it up other than saying minorities don't have time, which just seems to be a strange and unsubstantiated claim.

To me these are far better for eliminating discrimination as the interviewer and interviewee can't see each other over a phone screen so there is no racial bias introduced, all you have is can the interviewee code. Plain and simple with far less chance for discrimination than a face to face interview.

It's about as close to the famed blind music auditions as we currently have.


I would say it is the other way around.

Stephen Jay Gould's "Mismeasure of Man" appears to be defensive of minorities for protective colorization. The real problem Harvard has is that it is flooded with legacy admissions who couldn't test their way out of a paper bag -- people like Gould get funding because their work supports the interest of those people. By saying it is about minorities they get support from the general public.

Standardized testing is a path to opportunity for poor people and other outsiders to demonstrate their talent. It's true that some rich people can improve their results by spending money, but also true that some of them are as dumb as a post and the only way they are going to beat standardized tests is bring in a ringer to take the test for them.

In every other aspect of education rich people are much more able to "achievement launder" and use their parents money and connections to appear to punch above their weight. Standardized tests can keep the bottom 40% of those people out.


Yep, I'm waiting for the next Duke Power type case to happen. When I worked for an Am Law 50, we were prohibited from giving coding tests during interviews for developer positions because they could be considered a proxy for a discriminatory metric. Fizz Buzz was the most we could get away with. Even then, it had to be a pencil and paper evaluation.


The time commitment is pretty minimal. It takes at most 50 hours of studying to get up to speed on leetcode style problems. There are only about 20 different types and once you learn the patterns they get a lot easier. Professional organizations in other fields require continuing education in excess of that to keep your credentials. If you can't free up 50 hours over the course of a few months that is a time management problem. Worst case you could just spend 1 hour of your work day preparing. Lots of people spend more than that on HN and other sites.

The bottom line is there are more qualified applicants than there are spots available. No matter how people are selected some group is going to feel unfairly treated.


"What leetcode does do is make it difficult for minority candidates, those with external obligations, or those with families to get into firms. For example, I work 50+ hours a week with two kids and a parent with cancer. I work hard at work and have a lot of external obligations. I don’t have time or to study leecode problems."

This is actually such a bizarro answer I’m surprised it is getting tons of upvotes. All the techniques you learned in school can solve nearly every leetcode problem. You can get good at it with an internet connection and an hour a day. If you're going to work at my company for 2 years you better demonstrate you can do some preparation when there's literally 400 of you applying.


This is always the response, but it still doesn’t make any sense.

It’s been 15 years since I’ve been in school, and probably about 5 since the last time any of the things I learned there were relevant outside of interviews.

You can certainly get good at it with an internet connection and a hour every day. But that is 50% of the time I have left to myself after all my obligations are fulfilled.

Anyway, that’s not the issue. The issue is that the alghoritms tested for in leetcode are never relevant to the performance of my application.


If you're not willing to spend an hour every day practicing to get the job the employer doesn't want you. That's the point of leetcode interviews. Find the candidate who wants it the most.


Yes, thanks, we got that. The point is that it is inherently discriminatory against people who don't have the free time to devote to that.

....And it's also kind of disgusting to say that jobs should go to the people who are willing to sacrifice their free time to study utterly pointless interview questions just in order to "prove" to the employer that they "want it most". That's essentially selecting for those willing to worship at the altar of the company—corporate bootlickers. (Don't get me wrong, I can see why employers would want to select for bootlickers. I just think it's disgusting and shouldn't be allowed.)


I suspect a lot of answers defending leetcode style interviews are cases of survivorship bias.


In my case it's drastically simpler and easier than the types of interviews I've had at places with even higher applicant demand like say Game Companies.

There really is no comparison in difficulty from getting a few simple binary search or iteration questions from a FAANG company and the kinds of things higher end game studios ask you.


Yes you are given the tools but given a novel problem from leetcode, how likely are you to solve it within the pressures and time constraints of an interview environment? And how is the problem solving process indicative of engineering competency? It misses on some key points, for example integrating DB queries, refactoring, clean code, good git commit messages. And I’d argue the biggest miss is evaluating how well you can read other peoples code.


I think it's a bit more nuanced than that. Speaking as someone w/ experience on the interviewer side, there are two types of interviewers: the smug ones that evaluate on whether the presented solution matches the one on the answer sheet and the experienced ones that evaluate on signals that correlate to job relevance. I aim to always have interviewees solve the question, even if it means I'm dictating parts to get them unblocked. Because the things I'm looking for are things like fluency w/ the tools, communication, basic understanding of how to apply techniques to a problem, etc, rather than whether they can capitulate on some very specific eureka moment.

On the interviewee side, I think many candidates fall into the same mental trap as the smug interviewers; they think of it as a school test where you have to match the answer sheet. In reality it's more about selling yourself to the interviewer in between the lines.

I don't really buy the busy family argument; my wife finds time to practice leetcode despite having a full-time job and two kids in the house for a good half of the day. In my experience, people that work more hours per week than the local standard on software roles either have trouble setting expectations w/ stakeholders (and this ability is evaluated in unicorn interview loops for senior level and above) or they just volunteer to overwork when it isn't really necessary. I've seen high-paced environments where the family folks did a consistent 9-to-5 no problem. Extenuating circumstances like family cancer are indeed a valid concern, but at the same time, a minority of cases.

I've seen plenty of bitterness along the lines of "some ethnicities/age groups/etc just work too hard" or whatever, but at the end of the day, if we're talking about roles paying north of 200-300k/yr, the dynamics of the incentives will pretty much guarantee that one needs to put above average amount of effort into getting one of those jobs.

The thing is there are companies out there like Duolingo or Zapier that are willing to hire from non-hub locations and pay 6 digit salaries, and they may not even ask leetcode questions per se, but their hiring bars are very high nonetheless.


Why do you think it makes it more difficult for minority candidates than other interview process? I'd argue it's the opposite. Minority candidates have the same access to leetcode than anybody else.


You wrote: <<many of the algorithms used to solve problems took years to develop>>

I completely agree. Many years ago, I was challenged during a telephone interview to determine if a linked list contained a cycle. At the time, I did not know about Floyd's cycle-finding algorithm. Of course, I failed the interview miserably, but the experience stayed with me for many years.

In 2014, there was a blog post about this exact algorithm and interview question: https://www.nomachetejuggling.com/2014/06/24/the-worst-progr...

I pounded the desk when I read it!

It was even discussed on HackerNews(!): https://news.ycombinator.com/item?id=7953725

One way to think about LeetCode is that it helps to expose you to 100+ obscure algorithms that might come up in an "elite-level" interview. Knowing them off the top of your head will either make your look like a robot / genius / both(!). Also, for interviews that require keyboard or whiteboard programming, "kata"[1] is undeniably good for your performance. Like anything, the more you practice, the better your performance will become.

Currently, we are interviewing at my office for software engineers. I always interview as a pair with the same person. We have slowly evolved our interviewed in an attempt to find a "local maxima" during a one hour time slot. No, we don't do whiteboard programming -- everything is f'in Zoom/WebEx these days!

I struggle with this: With the advent of Java and C#, a lot of average programmers know "enough" algorithms and data structures to get through an interview. How can we push harder to find better than average candidates? I don't know a good way without take-home programming assignments. Asking people to memorize 100 obscure computer science algorithms before an interview is just silly.

I would struggle to explain how a sorting algorithm works, but I know all about O-notation for time & space complexity of the best sorting algorithms. (My sort sizes aren't very large, so TimSort[2] works 99% for me.)

[1] https://en.wikipedia.org/wiki/Kata

[2] https://en.wikipedia.org/wiki/Timsort


> How can we push harder to find better than average candidates?

Just ask them where they needed to solve a problem with an algorithm, why/what they did, how they implemented, tested, validated. What other problems could use the same approach, how could the problem be changed to invalidate assumptions, and so on. etc.

(While writing I realised that this fails in cases where the interviewers are not competent enough to follow along in random directions, which then gives the rationale for a leetcode quiz - basically a battleship-game that the interviewer prepares in advance so that he can pace the discussion and grade the candidate.)


Great follow-up, and great idea! I never considered asking that type of question. To extend further, ask people when they used the wrong data structure, how did they notice, and how did they fix.


>This process benefits individuals who have the luxury of time to spend preping. Something minorities, working parents, etc. don’t have.

How is that different from learning any skill/profession?

Everywhere you gotta put time / effort.

The difference is that LC questions allow you to get highest paid jobs.

Average software shop probably does not require them.


Griggs v Ohio made employer IQ tests unlawful, so employers started requiring college degrees. With the push to "give everyone a degree", standards have dropped so now employers can no longer use a degree as a filter for IQ. Thus: leetcode interviews.

The solution is to overturn Griggs v Ohio.


> IQ tests unlawful

So making a test to see who you'll recruit is unlawful. I don't know what to say.


This is kind of like saying requiring a bachelor's degree is a way to skirt around discriminatory hiring practices. Ignoring your racists and offensive remarks, getting a job does require studying and prepping, whether you simply study the fundamentals or leetcode.


> skirt around discriminatory hiring practices

Yes, maybe we should consider leetcode interview as something of a rorschach-blotch. The interviewer can take the discussion in any direction he wants, under the pretence of "evaluating technical competence" or whatever.


How does leetcode make it difficult for minority candidates? My understanding was that its designed to do the opposite, to level the playing field.

Note: this is a genuine question, I am interested in understanding your view point.


"This process benefits individuals who have the luxury of time to spend preping. Something minorities, working parents, etc. don’t have."

The soft bigotry of low expectations.


I moved into running development at my company two years ago - and one thing I quickly learned is that I had to do some level of skill verification with job applicants. Why? Because many of the applicants I was interviewing could breeze through anything non-technical, and would do well if we stayed on the happy path (i.e. show me things you've built, tell me how this function you built works). When I asked them simple questions like, what type will this python expression return (and yes there was -> int: in the signature, they would be incorrect.

So, I gave a few interviewees a code test, and they failed miserably. Mind you, nothing hard - it was a test can I give you a simple function to write, and can you 1) declare a function or class that accepts the right inputs, 3) does what the spec asks, and 3) has the correct output format. The test took 10 minutes to an hour, and was totally open book. The result was pretty staggering. 2/3 of developers would fail the test, and not for esoteric reasons. They would fail because they used the wrong boolean operator, make simple type-casting mistakes, or fail to return data in the correct type (i.e. return a string and instead return a bool or an int). When they failed, it wouldn't be just one thing, it would be two or three mistakes.

So, now I code test everyone, and it has nothing to do with your salary. If we expect you to program in your job, we will verify that you can actually string together 10-15 lines of code. I've only had a handfull of applicants call the test leetcode (I think it's a lot simpler than that), but the reality is there are just a lot of people who can't really code out there.


I've had similar experiences to yours, but maybe this doesn't fit the leetcode people are complaining about.

We hire with a similar setup, but we try to keep the test extremely simple and close to reality. Something they would likely encounter on their day-to-day.

The majority of the developers fail at it. Senior, mid-level, juniors, etc. It doesn't matter. Which always surprises me. People who claim to have 5-6 years of experience can't even refactor some code. Or they can refactor and can't explain why they'd do it. It's bizarre.

But I would never classify this as leetcode because these are common tasks that any developer should be able to solve and not purely algorithmic questions that will rarely (if ever) be used in real life.


If you have 0 passion for programming and land a gig at a corp that doesn't care about code quality at all, you could do that job for few years and just coast/do bare minimum.

I'm an IC and I could deliver software with all methods in a single class, nobody would care I think, as long as it worked as intended. I happen to like programming and as I am improving my skills every time I touch an existing project I look for things I could have done better. If major changes are being made, I often upgrade frameworks or do a partial rewrite to improve things.

I know people who just do stuff without trying to understand why. If I cannot explain why I am using dependency injection and what problem it solves, I am not doing it correctly.


I have had the same experience. Some things I've witnessed:

- multiple "senior" data scientists who cannot write a function definition in python

- a "senior full stack engineer" with 5+ years of web dev experience who took 20 mins to change the width of a div in a web app

- many "mid/senior level" full stack engineers who don't know the difference between sync/async, or have any clue about how the JS event loop works

There are so many candidates out there who have what looks like impressive CVs, but can hardly string a program together.


Your first two are pretty bad (possibly panic induced), but the last one might not be realistic. You can rack up multiple years of experience working on low user count apps without knowing those things. You can still write Javascript and solve business problems without knowing those things.

But also, seniority doesn't determine if someone knows those things. If I asked you for a list of things I should know by the time I get to mid/senior, someone else will have different expectations. Everyone is kind of inventing their own requirements on what someone ought to to know at junior/mid/senior levels.


> You can still write Javascript and solve business problems without knowing those things.

It depends what the requirements of the role are. For some frontend React work maybe, but the engineers we were trying to hire would be working on APIs and processes that handle high volumes of streaming data. In that context using sync methods over async would significantly impact throughput.

When asked "why are you using a sync method here" the answer would often be "I want the code to pause here before the next line executes". It's a fundamental misunderstanding of what's happening under the bonnet that IMO is required for this sort of task.

Also - I agree that labels like "mid" or "senior" shouldn't carry a specific list of knowledge requirements, but they are useful to set benchmarks for what a candidate should be able to roughly offer in exchange for the level of comp they are requesting.


If you don't know the difference between sync and async you're not qualified to solve problems with any realistic level of scale (>10 concurrent users which is a very low bar) or complexity (have you really never had to code logic that uses 2 or more concurrent network calls?). Might be excusable for a junior engineer but definitely not someone who describes themselves as senior.


you google it and understand it or re-understand it in 5 minutes after trying 20 iterations in the IDE.

thats representative of the job, so it should be represented in the interview. open book interviews test for resource finding and implementation skills.


You shouldn't have to google a basic concept that, if you truly were senior level, you would be using on a daily basis. This is not some obscure language syntax or feature.


They shouldn't be penalized for it either, using reference should be a force of habit.

The main problem with your response is that the threshold for "basic concept" is arbitrary by framework, by language, by time, by interviewer. Revert back to interviewing things relevant for the day to day job, look at what developers actually employed there did over the last few weeks, and interview on that.


Knowing the difference between async and sync is relevant to any JavaScript developer's daily tasks. If you are hiring a JavaScript developer it's 100% a fair question to ask. If you are hiring a generalist maybe not, but if they have JavaScript experience in the last 3 years listed on their resume, I again say it's fair to ask.

Asking about async/sync in JS is completely different from asking someone what obscure features like finalizers are in Java. One is used on an hourly basis when writing code, the other one is never used except in obscure legacy code.

If you do what you're proposing and just ask about projects I think you'll find it's easy for incompetent people who are floundering around and copy pasting from stackoverflow without understanding what they're copying to pass your bar. I copy from stack overflow all the time but I understand what I'm copying and why it works and when it doesn't work.


> Revert back to interviewing things relevant for the day to day job, look at what developers actually employed there did over the last few weeks, and interview on that.

`async` questions are the most day job relevant questions I can imagine for a javascript developer. It is so pervasive, a such a simple piece of syntactic sugar over basic asynchronicity, that not knowing it is damning along a number of axes.


If you have made it through multiple years of building UIs without ever needing to google that, then you must have a profound lack of curiosity.

You can certainly stumble your way to a semi-working app without knowing that, but your mental model of how Javascript works is fundamentally lacking if you don't know that.


its still about the syntax and referencing that, there are like 3-5 ways of doing asynchronous code in JS

and its also not my point about "async in JS", thats a symptom in a field where ever random person pulled in to conduct an interview has their own random threshold of competence, when simply conducting an interview that mimics the day to day on the job would be more accurate

"did you google that in 10 seconds" great!

"did the compiler autocomplete your method name or show you a list of likely possibilities?" great!

"did you post a question on a QA website, while you went to work on other parts of the task while the hints and answers rolled in?" efficient!

"did your compiler show you a syntax error immediately that you corrected immediately?" great!

"did you compile it as you went and rapidly iterate towards the write answer like everyone else working here?" perfect!

whiteboarding, and most collaborative coding platforms, fail to replicate 9/10ths of that. so it tells nothing about the candidate.


> multiple "senior" data scientists who cannot write a function definition in python

I definitely would have failed this a few years back, because I spent most of my time in R & SQL.


1: Bad.

2: Could be terrible or totally reasonable... how much of that was "fixed cost of any push to prod regardless of complexity"? I've worked at very few places where I could get a change from my editor to production in less than 10 minutes, except in emergencies. Even at my one person freelancing shop a push to prod took at least a few minutes to go through the pre-flight checklist.

3: Bad but not insanely bad, depending on what's needed for the role. Definitely something they should learn, but not catastrophic especially if they are a huge value add in other parts of the stack.


You can be full-stack with minimal JS knowledge, if you use stuff like Blazor. Lack of knowledge about sync/async would be inexcusable for a mid/senior though.


Why would you quiz on language specific syntax?


I should have clarified in the original comment: the roles all had python experience as a specific requirement and some of the candidates apparently had multiple years of experience with Python listed on their CVs.


Depends on whether the candidate claims to know Python on their resume. If they do so, I'd certainly expect some basic ability to read such code.


Almost all big companies let candidates choose their language for the interview, with assumption it'll be python/java/c++ or similar mainstream lang.


I don't mean this to be incendiary, but, do you think perhaps this reflects on your recruitment pipeline, the standards you hold interviewees during the discussions about their experience, and the way you review resumes?

There is of course a possibility that someone has rehearsed their interview happy path down to the word and they can easily describe complex technical concepts without understanding them because they're quoting a script, but an interview that can be gamed in such a way may highlight a problem with the interview.

If most of your interviewees are failing to write basic code, the issue probably isn't the applicants.


I've had a very similar experience to this, these are literally with candidates that are extremely "over qualified" based on their resumes. We're talking masters degrees, doctorate degrees, etc. They can talk like they have years and years of experiance at this place, that place, you ask about projects they'll dive into high level details about them, everything sounds good (can still filter 80% out with these questions to be fair). Get to the code question, boom fail.

I dislike leet code, but you do need to be able to code something (Even if it's syntactically incorrect) on the fly and reason with me about what and why you're doing something.


For starters having a masters or PhD implies _less_ programming experience, generally speaking. Its a huge plus for a variety of positions but IME PhD or masters candidates were always a little more raw engineering wise. The way you get good at coding solutions quiclky and on the spot is by writing a lot of code.


Particularly PhDs in Math, EE, or areas of CS that aren't engineering heavy. You hire them to solve problems that your engineers can't solve, not (just) to write code.

Masters degrees are a total crap shoot. I honestly ignore them entirely unless there's a thesis.


Not incendiary at all. I've been worried about that, but as we've adopted more skills assessments, the quality of hires has went way up as measured by first year retention. We're not losing people because they can't do the job.


I'm surprised that someone who couldn't say what type a python expression returns could do well on "show me things you've built", "tell me how this function you built works". Do you have an expalanation/guess? Were they giving you rehearsed answers to specific code that, well, they didn't necessarily actually build themselves?


Best guess is someone else did the work and explained it to them.


You’d pop that bubble in a few directed questions wouldn’t you?


You definitely can but it's not easy. These people are really good at bullshitting, that's why you have to back them into a corner. The simplest way to do that is to have them prove, live in the interview, that they can write code.


You mean stuff like asking what type a function returns?


Woah. This is a great post! Zero trolling: Can you share your interview question? We would love to have something similar!

Deeper question: Did you think about why some people are able to "show me things you've built, tell me how this function you built works", but fail miserably on a straight-forward coding test?

Sometimes, during an interview, it seems obvious the person is very intelligent, but having a bad day. Some part of interviews is pure performance to me.


Not OP, but we often include these two in our interviews:

1. Write code that will find the second largest item in an array on ints.

2. Write SQL that selects the second highest number from a DB table.

I'm floored how few candidates can do these. Many end up giving up or fiddling for 10 minutes before giving something like `SELECT table WHERE 2`.


wouldn't be surprised people miss the SQL question. Full stack devs are rather rare nowadays, and it's a bit obscure SQL trivia considering the answer is dependent on which SQL db you're using.


Modulo syntax/keywords, I think the following query would work in any modern dialect:

    SELECT num FROM 
        (SELECT num FROM nums ORDER BY num DESC LIMIT 2)
    ORDER BY num ASC LIMIT 1;
which is actually nearly identical to the simplest Python solution in terms of the computation that's specified:

    lambda xs: None if len(xs) == 0 else sorted(xs)[-2:][0]
I think the reason the question is tricky for some is because they either:

1) haven't used SQL in a long time and forgot all the syntax, or else

2) don't really "grok" SQL as a model of computation (as opposed to e.g. a data structuring language or something like that).

But both of those seem like good reasons to disqualify someone from a full stack role?


A common reason in my experience is that the things they've built were done very slowly. I've failed my share of interviews because I was having a bad day, certainly, but I have direct professional experience with many people who require hours of dedicated working time to produce even the simplest of pull requests. This isn't a complete justification (if I have professional experience with them doesn't that mean they passed our straightforward coding tests somehow?), but I do think that there's a real selection problem there people are trying to solve.


Are you US based?

Here in Europe this sometimes happens (candidates can't code at all), but _very_ rarely, maybe 1 out of 100? Especially as you move eastwards, the base coding abilities start to improve massively for the average candidate - in the UK, if you are stupid you can easily get by on the social welfare system, in Eastern Europe, if you are stupid, you starve. As simple as.

There was a time I used to ask Fizzbuzz-style warmup questions on interviews, but then I stopped because the signal it gave was pretty much useless. The only positive case I can remember was when a tester applied for a dev position.


I worked in Russia and used to think this way too. But once we managed to hire person how couldn't code. At all. He was intelligent during the interview, talked his way through system design section. But during the probation period he basically couldn't do anything, even simple stuff. After that I started to block any candidate, who couldn't provide code solution for at least simple problem.


Er, that explanation doesn’t really hold, considering if you’re stupid you starve in the US too, and we get tons of idiots applying for jobs they’re completely unqualified for.


Agreed you need some tests but what you're asking is a different order of magnitude than leetcode problems.


Not really sure, but it sounds like some of things you are testing might be syntax - which makes sense if it's critical to your hiring need - ex. hiring senior C++ folks to start a new project - otherwise every new job I've started in this industry thrusts me into a new language and I have no problem sending CRs almost immediately (given Google and an IDE).

I'm generally more a fan of keeping skill-based examination too, but making it very easy and language agnostic. Harder than FizzBuzz of course, but nowhere close to dynamic programming.

Ideally, if a candidate has never seen it before, a basic tree traversal is enough. But since 100% of people have practiced that before interviewing, I invent a problem by ripping out a little piece from the codebase I'm working on. It usually amounts to.. Show me some clear control flow, factor that code into a subroutine, iterate over a collection and call that subroutine, contemplate the performance characteristics in a discussion (not bigO complexity, more so consider the I/O device..caching..)


Well, a python return type doesn’t really mean anything except to a type checker.


That was my first thought as well. If someone asked me that during an interview, I might assume the type annotation for the return type was something meant to throw me off.


The value being returned in the correct type is especially important in languages without static type checking. The next line may try to add the dictionary you returned to an integer or something crazy.


Run mypy on it and see if it complains. If it does I think it will even tell you what type is being emitted instead.


The question wasn’t what mypy will do. The question was what type will the function return.


mypy error: function 'x' returns type 'y' expected type 'z'

I don't recall the exact message but I think it will emit something along those lines.


The question wasn’t what mypy will do. The question was what type will the function return.


One common question of this type (I've had it, and heard a few others as well) is: implement a function returning the factorial of its input (so n!). Basically FizzBuzz.

I recently got that question after a homework with about 200 lines of python written. If I had failed at this question, the company would have concluded that I had somebody else do the homework for me, so I understood where they came from with this.


Out of curiosity: this test you gave your interviewees, was it done on a computer or pen & paper?


Computer. Web based, copy/paste enabled, no cheat tracking. So in short we let them use an IDE, cheat and copy/paste and they still flunk it.


Heh. I'll never forget the first time I started an interview process with an automated online test with a "cheat tracker". What it ended up really doing was flunking me for alt tabbing to documentation...


Sorry, I am laughing out loud at this response. I love how you wrote "cheat". Like! I know... not my best HN post. :)


I don't understand your comment, what was funny, I don't see them writing cheat unusually?


Hopefully, cheat isn't a normal state :-)


I know a company that use fizzbuzz and only fizzbuzz as their technical exercise. The people who are going to fail a technical fail at fizzbuzz.

I cant say its perfect... But they have a really great Clojure team and everyone else seems to have a difficult time hiring for it. They IPO'ed last year too...


not complaining about fizzbuzz at all, but this is just a PSA to tell the interviewer to end the interview if the candidate gets a good solution in 5 minutes. Adding this "but can you tweak it moooooore" mess is just awkward and the candidate hasn't seen two dozen iterations from all the other candidates.


> "reality is there are just a lot of people who can't really code out there" ->

reality is there are just a lot of people who can't really code -- IN THE ARTIFICIAL CONTEXT OF AN INTERVIEW - out there.

FIFY.


My pet analogy for this scenario is: Go to all of your employees. One by one ask them to solve a programming challenge for you. Let them know if they don't produce a suitable result (to your liking) in the next 40 minutes, you will fire them immediately. See how they do.

I don't think its wrong to do these types of interviews. But interview stress is real, and it affects people in strange ways. I bombed one of these interviews once and the interviewer was convinced I was "not a front-end programmer". I had just left a job where I had written literally hundreds of thousands of lines of (modern) front-end code, daily, for the last several years. More complex than what I'd be writing at that company (I was eventually hired in spite of this particular interview). And oddest of all, that interviewer was (very soon after) let go. Such is the world of programming interviews.

So yeah. I don't think its necessarily the worst. It might even be the best way to interview candidates. But we all need to take our asessemtns with a huge grain of salt and stop being so judgemental.


Your analogy doesn't really seem too similar to interviews. There will be more stress about getting fired and losing your income than potentially failing an interview which has no effect on your current income, since you still have your current job while interviewing, presumably.


That would be the case for all new grads (substantial portion of applicants), first time applicants (who may be working some other, terrible job), poeple who were laid off / fired, and people who have taken time off. Its not meant to be a perfect analogy, its mean to nudge people into the realization of how stressful interviewing can be. Especially if it is for a company you really want to work for.


You're missing out on loss aversion. Losing something you already have is far more stressful than not getting something that you don't.


Its not meant to be a perfect analogy but to ellucidate why it may be more stressful than you might imagine. But in the spirit of good discussion: Lets compare someone who has 7 years of experience at Facebook, 500k in the bank, and strong interviewing skills with an inbox full of recruiter spam to someone interviewing for Facebook, who has no other interviews, and is currently poor and in debt. Are you so sure the person at facebook would be more stressed than the person applying?


In our case, and this was 20 years ago, it was painfully obvious immediately whether the person knew anything about coding at all; we bent over backwards to do anything that would help (they could pick any language, we'd modify requirements, full internet access, etc) and a good percentage would just flounder.


I'm in my 40s doing the leetcode grind, but weird thing is, I'm actually ENJOYING it. I get a little high when I solve a problem, and I feel good about re-learning / re-discovering data structures and algorithms that I just don't use on a day-to-day basis. I paid for the premium version and enjoy reading the solutions and maybe learning a new trick or algorithm technique or whatnot. And who knows, maybe something that I learn when grinding on some leetcode problem will actually be useful in my day job? Thinking about it, if I ever do land a MAANG job, I don't think I'll stop doing leetcode problems. Sure, I won't go crazy with it like I'm cramming for mid-terms or something, but I'll still hack on them for the pure joy of problem solving, for the sake of problem solving.

I guess where I'm going with this is, maybe change your thinking about leetcode? Don't think of it as a necessary evil in order to land a high paying job that you dread doing each night; look at it as a fun little hobby, with the nice side-effect that you're keeping your data structure knowledge, algorithms and general problem solving skills sharp.


I'm also in my mid-40's and did the leetcode for a MAANG interview a couple years ago. I also looked at it as a thing I'd spend some time on every now and then to shake off the rust and to practice for the hiring process itself.

Like my past studying for SAT or LSAT, it was as much about preparing myself for the test itself vs. trying to gain some specific knowledge. Time management, making sure to test, and knowing that there are almost always naive vs. optimized solutions for these types of problems and learning how to quickly identify the naive solution (i.e prove I can solve) and then figuring out the optimization.

In any case, I enjoyed the process and didn't really practice more than 10-15 hours. I literally just kicked off the rust and got used to managing time. If you get too deep in to "I've optimized systems to process millions of transactions/second, and some 25 year old is sweating me on hashtables" you're going to have a bad time.

The ironic part of the interviews at this level of experience was that the coding portions ended up feeling tough, but I was able to talk work through them. For one company, one of the two system design round was with someone who couldn't have been more than 3 years out of college (with PhD though) and had only been at that big company. That was my hardest interview because the person I was talking to had zero to little actual experience there. They knew the problem and expected answer, but didn't know the space. It was VERY HARD to talk about things that they very obviously didn't understand in terms that they did understand without sounding condescending.


If we're going to change Facebook to M for Meta then we should change Google to A for Alphabet. Then the acronym is MAAAN.


On LinkedIn, FB employees have Meta now; Google employees still have Google.


It reminds me of Pacino in Scarface. Chichi get the yayo MAANG!


Does it really matter enough to correct people? Call it fang, faang, fang+, mang, maang, maaan, top tier companies... They all mean the same thing.


NAAAM, a tour in NAAAM


AMAAN!

I still don't know if I'm reading amen or a man.


Triple A could work as M3AN.


So you got offers from FAANG with only 10-15 hours of actual practice? That’s an exceptionally low amount of practice.

But I hear these stories over and over - the variance is so wildly high. The people who spent the same or more hours studying and didn’t get an offer tend to not talk about it though. So, sampling bias issue.


The more studying you do, the more likely the interviewer asks a question you've seen before.


I'm a little older, and I also do leetcode for fun/practice and find I get a lot out of it.

Have not done a leetcode-style interview yet, and might never do, and might not pass if I do do, but just as a scratching post for your coding claws I think it's awesome.


On the note of leetcode, what other products solve it similarly? How does leetcode rank against, say, Exercism?


Do you also enjoy advent of code?


I do! I did the 2019 AoC in Clojure and really enjoyed it. I plan on getting to the 2020 and 2021 ones at some point.


I never understood the hate Leetcode gets. Whenever you change jobs, chances are you'll encounter some new technology you do not yet know. You'll have to prepare for it. Algorithmic problem solving is like riding a bike, you only have to learn it once. While it's possible that no one will write Kotlin in a decade, it's very unlikely that knowing how to do a topological sort will go out of fashion.

The counter arguments often mentioned against Leetcode I often hear:

- You are often asked stuff that took PhDs years to figure out: This usually shows up only in Hard questions, and badly designed ones at that. In my experience, Medium ones are usually solvable with solid algorithmic knowledge. It is also usually that maximum difficulty people encounter during their work.

- It discriminates against women/minorities: I don't live in a very diverse country, so I don't know anything about the minorities part, but in my career, I've encountered plenty of women who were as good or better than men in solving algorithmic issues. It does filter people, because it's designed to filter people, but I've never found it discriminatory along gender lines.

- It discriminates against poor people: You're a programmer, you are not poor. Even if you were, the few weeks of time investment it requires is usually offset by the higher salary you can ask for. Think of it as an investment in your future. Or if you are not a programmer, the amount of skills you need to learn to get your first programming job is usually far excess of just learning leetcode.


> topological sort will go out of fashion.

If you as a normal software engine write a topological sort algorithm you likely failed your job. Your job is to use existing topological sort algorithms designed by people specialized in that area, implemented by people which are specialized in implementing and fine tuning algorithms (it's its whole own field of expertise, and overlooked field tbh.).

Or to reformulate it the job of an software engineer is to reuse existing components and basic building blocks to create larger components or programs, but it's not your job to create new basic building blocks. The job requires you to have an understanding of such components but not to memorize them.

Sure sometimes you have to create basic building blocks, but then doing so from memory is nearly always the wrong approach.

Leet code is not at all representative for "how well someone is suited for given job" (for most companies/offers, there always are exceptions).

While wasting everyone's time.

And favoring certain skill sets/problem solving approaches (memorization) over others (adaptability, deep generic understanding), at least in the way they tend to be implemented. It also strongly discriminates again anyone with exam anxiety and similar. Be aware that the points mentioned here apply to common leet code based screening (especially automatized screening), but not necessary asking people to solve some code problem in interviews (if you handle that appropriately).


This hints at an (IMO underrated) skill: being able to look at a problem and decomposing it into sub-problems that are solved by known algorithms. Topological sort is a pretty fundamental building block for solving many problems that involve dependencies between components, since those can be modeled as a directed graph.

Knowing how to write a topological sort isn't the key skill here (although, I would argue, it's a good skill to know, and it's probably much simpler than you're imagining). The key skill is knowing that a topological sort will solve the problem, or perhaps it's simply knowing that "finding an order of actions that satisfies these dependency constraints" is called a topological sort.

I have always been under the impression that the goal of leetcode-style interviewing was actually to measure a candidate's ability to recognize what algorithmic tool to use, rather than to measure a candidate's ability to implement an algorithm from scratch. When I've been in the position of interviewing in the past, I've always been more interested in that problem-solving approach than in the actual code.

In my experience, most software jobs are 90% figuring out the problem that needs to be solved and coming up with tactics for solving the problem, and 10% actually implementing those tactics. In that context, investigating the ability of a candidate to analyze problems seems like an excellent interview technique.


Writing topological sort isn't like rolling your own cryptographic hashing... It's literally 10-20 lines of fairly trivial code.

While I get your point, you chose a horrible example.


> If you as a normal software engine write a topological sort algorithm you likely failed your job.

No, because the way topological sorts show up in many systems is not amenable to a library. Sometimes you will have unusual caching strategies available to you or the topological sort needs to work with some weird asynchronicity that no library handles well.

Even if you do just need a topological sort it's often not worth bringing a library in. It's a simple algorithm implementable in a few lines of code in many languages.


>If you as a normal software engine write a topological sort algorithm you likely failed your job. Your job is to use existing topological sort algorithms designed by people specialized in that area, implemented by people which are specialized in implementing and fine tuning algorithms (it's its whole own field of expertise, and overlooked field tbh.).

What standard library ships with it ? I can remember multiple times I've need to implement topological sort in various languages - mostly to detect if there are cycles between dependencies or order actions, it's rather simple, introducing a third party lib for such code is in the leftpad territory and writing a generic interface to generalize graphs would be clunky in a lot of languages.


It's not about topological sort at all.

It might come up in unexpected ways, say cache propagation, or a cyclic dependency in your favorite IoC container. Or in many other possible scenarios that are all real and I see them almost every day


If you're a software engineer and you don't know what topological sort is then you don't know how any sort of dependency structure works and that's a big part of your day to day. Implementing topological sort is a few lines of code and anyone should be able to do it


> It discriminates against poor people: You're a programmer, you are not poor. Even if you were, the few weeks of time investment it requires is usually offset by the higher salary you can ask for. Think of it as an investment in your future. Or if you are not a programmer, the amount of skills you need to learn to get your first programming job is usually far excess of just learning leetcode

This comment does not acknowledge the experience experience of many people who grew up poor or put themselves into major debt because they didn’t receive financial support or live in economically disadvantaged areas.

I grew up poor and took out massive education loans to pay for my education. I still pay off those debts today. Does that mean I consider myself poor now? No, but my economic disadvantage has made me need to work much harder in other areas and I’ve needed to prioritize many other things over leetcode. I haven’t had the luxury of spending multiple hours a week to get “good” at leetcode

So yes, I’d argue that leetcode is responsible for gatekeeping people out of jobs who don’t have time/money to grind on it.


Leetcode prep is less time and money than getting a degree in anything. Anybody with sufficient interest can find the time to get to a basic competence level in leetcode and system design. Getting real life experience or a college degree has got to be the bigger gate.


> Anybody with sufficient interest can find the time to get to a basic competence level in leetcode and system design.

OK. But, it has nothing to do with interest. It's time (which may already occupied with working long hours or a second job to pay off debt or looking after family). Who has extra time to perform leetcode tasks that have no alignment to day-to-day tasks and expectations. People with the luxury of free-time, thus attracting a certain type of profile.

> Getting real life experience or a college degree has got to be the bigger gate.

You don't just get a job doing leetcode. The experience and/or degree are table-stakes. The OP post is asking folks who likely already have experience or a degree related to the field of software engineering.


Interest in getting a job that requires it, not interst for its own sake. The number of people who cannot find 1-2 hours a week over the course of a year to prepare despite an interest in doing so is vanishingly small. Yes you might struggle to find the time if you have two jobs and two toddlers, but kids grow up and the ROI is clearly there. Leet code sucks. But its a solid and relatively cheap (time and money) investment, and in particular is cheaper than any other of the (not quite as) high paying jobs I can compare it to.


Knowing why one would use a "topological sort" is (might be?) important. There is almost nothing important about knowing how to do one. This is the failure of leetcode.

I would take 1 person who can understand problems at a high level and Google the minutia over 10 that try to remember how to re-balance a tree and confidently introduce off by one bugs.


> I would take 1 person who can understand problems at a high level and Google the minutia over 10 that try to remember how to re-balance a tree and confidently introduce off by one bugs.

How do you plan on screening for that person?


> it's very unlikely that knowing how to do a topological sort will go out of fashion

It is also vanishingly unlikely I’ll ever have to do a topological sort. 15 years and counting. Meanwhile, being able to read and understand a bit of kotlin has proven useful several times.


Topological sort implicitly comes up anytime you implement a depth-first search on a graph that isn’t 100% guaranteed to be cycle-free. Checking for cycles in a depth-first search is basically the same as topological sort. Having to implement something like that comes up roughly every 3 years for me.


But how often are you actually writing an implementation vs. calling a method from a graph library?

Knowing when you need a topological ordered list of vertices is (in my opinion) more useful than knowing how to implement tsort.


> how often are you actually writing an implementation vs. calling a method from a graph library?

Every time. Because of several reasons: 1. Transforming the graph (which is usually not explicitly represented, but rather the result of navigating entities using some existing API) to the representation required by the graph library is more complex than just implementing the search and the cycle check yourself (it's usually just insertion into a set and checking if the element was already contained). 2. Often there are additional actions you want to take during the traversal, and diagnostics you want to output, which is either impossible or difficult/convoluted to integrate with a graph library. 3. Dependencies incur maintenance cost and should not be added lightly. Adding a graph library just for a simple topological sort is usually not a good trade-off.

Knowing how topological sort is implemented is necessary to make the right design decision here. Otherwise you end up adding a big dependency and convoluted glue code just because you didn't realize how straightforward and maintenance-friendly a custom implementation tailored to the present use-case could be.

Or, in other cases, you may end up implementing a custom algorithm without realizing that it actually corresponds closely to an existing graph algorithm (which would help you double-check your implementation or replace it with an existing library).


> I don't live in a very diverse country, so I don't know anything about the minorities part

I love how you lead with this and then drive a car into every single wall about this issue. Its like the most predictable meme and you are it.

You've encountered women.... proportionally? What stage of the career, entry level, lead?

The only point here is about time, and time commitment available. Forget about the supporting culture you were raised around for "grinding for the job you want", that method discriminates against competent people who have other obligations. When people are interviewing for a job, they are interviewing for many jobs at other potential places, so there is no way to determine passion or seriousness by their willingness to focus on studying for your job, it only determines who has things they can neglect. And basically that is just single men without debts or other distractions.

Many times minorities have other distractions, in your non-diverse country a minority would likely have a time limit to find a job to maintain a visa or comply with an asylum application. Women often have other distractions as well, with only some slim slivers of time being similar to the single men.

Hope that illuminates something for you, or others.


Yeah I don't buy your argument. I don't think leetcode questions are perfect, I also agree that women/minorities have extra distractions and hurdles which as a society we should look to lessen and improve.

However, I find these distractions are much stronger correlated with a person's economic situation rather than race or gender. Also, I agree with the parent of your comment where the time spent with leetcode is a small fraction of the time needed to learn CS fundamentals, which are usually required for the job. Especially when you're not expected the candidate to KNOW the answer, you're observing HOW they solve the answer.

I've failed candidates that memorized solutions, but could explain how they got there. And I championed ones that didn't get the optimal solution, but had a good thinking process that they could properly communicate to me. Guess which candidate spent more time studying?


> However, I find these distractions are much stronger correlated with a person's economic situation rather than race or gender.

Which changes nothing when its a 99% correlation by race and gender.

Its not a dissertation, its acknowledging that something has the result of marginalizes groups disproportionately. Disproportionately means that it doesn't affect everyone, it doesn't 'affect all women and all minorities. It means disproportionately affects, due to their disproportionate representation in these distracting economic circumstances, so lets do something else instead since the reasons why it affects them isn't going to change in our lifetime.

> Also, I agree with the parent of your comment where the time spent with leetcode is a small fraction of the time needed to learn CS fundamentals

If people got formal education they took the risk for that allotted time. It doesn't matter if a time-discriminatory process takes less time, its an additional and unnecessary risk for the candidate.

If people didn't get formal education then they didn't take the risk for the allotted time, they just have exposure to the tasks the company needs. That alone suggests more inspiration is needed to have a different way of determining their compentency.


I love algorithmic challenges and would even compete while in uni and coincidentally last year I even had to do several topological sorts at my company. But I actively hate and avoid leetcode type interviews.

For me it's the time pressure while someone is looking over your shoulder and them asking you to talk and explain your thinking.

I just panic and close up, I need mental space to come up with an algorithmic solution and can't do that if you want me to "talk through my process". Leave me some time to solve the issue and I'll come back to you with a solution, just like it is in a real job.


I enjoy programming challenges and do them for fun and I see their value as an exercise in thinking, but the problems I solve with them aren’t a reflection of the real world work I do or have done. I’ve never needed a topological sort in my day jobs.

If a company asks me to complete a leetcode style code challenge they are not getting a representation of the work I’ll do day to day, so I always make a point in an interview to say, “I may have passed your test but please don’t judge me on that basis, let’s discuss my work”.

They’re garbage as a hiring tool for lots of reasons, but mostly it comes down to the reality that they just aren’t representative by any stretch of the imagination.


> You're a programmer, you are not poor.

This is hugely Silicon-Valley-centric. There are millions of skilled programmers outside that culture, who have never had a six-figure salary, many who have never even worked for a tech company. Just regular (white-collar) working people with the same kinds of burdens that the average American (or European, or person from any other developed country on the planet) has to deal with.

In short, this shows how much you live in a bubble and don't understand what life is like outside of it.


If you have not worked on any topological sorting for the past 15 years you will not remember how to do it under the pressure of time. in a new language etc. you will need some time to remember the correct algorithm, how to adapt the data structures to the current language you are working on etc. And unless the problem is specified exactly as such, the most difficult thing is to come up with the idea that a given problem can be formulated as a topological sort problem, that is 80% of the solution. I am sure that most Experienced engineers when given this problem as a home task will come up with a correct solution even if they fail the time pressured leetcode.


I've been programming computers since I was 10. I am almost 40. I've been working professionally for about 15 years now. I've never done leetcode. But I have done stuff like (hackerrank) and I have to spend an evening proving I know how to write some arbitrary problem that I will never encounter anything close to in the position I am applying for. I can solve them. But I feel like I am wasting my time when I do it for the 10th time. I now refuse to do all coding tests. I have a github and a company page with my work and if that isn't sufficient, then so be it.

As for the counter arguments:

> You are often asked stuff that took PhDs years to figure out: This usually shows up only in Hard questions, and badly designed ones at that. In my experience, Medium ones are usually solvable with solid algorithmic knowledge. It is also usually that maximum difficulty people encounter during their work.

Software engineer are not computer scientists. 95% of my time is normally gluing libraries together to build a product. Most of the time I am just implementing business processes in code and I don't really need to implement anything fancier than a for loop. What is normally more important is implementing the (correct) patterns, good practices and managing changing requirements, implementing a database schema that makes sense.

The sort of problems in leetcode won't help you do any of this. All it proves is that you can solve some arbitrary and unrealistic problem.

> It discriminates against poor people: You're a programmer, you are not poor. Even if you were, the few weeks of time investment it requires is usually offset by the higher salary you can ask for. Think of it as an investment in your future. Or if you are not a programmer, the amount of skills you need to learn to get your first programming job is usually far excess of just learning leetcode.

Many of the people grinding things like l33tcode are looking to get a web development job so they don't have to work frying chicken in the local KFC knockoff. Building most websites doesn't need to learn a bunch of algorithms. What you do need to have is a solid understand of HTML, CSS, JavaScript and how things likes HTTP work. The sort of problems in leetcode are absolutely irrelevant to this sort of work.

It ultimately depends on what sort of jobs you are applying for. A lot of positions won't require the skills that leetcode and similar try to test.

> It discriminates against women/minorities: I don't live in a very diverse country, so I don't know anything about the minorities part, but in my career, I've encountered plenty of women who were as good or better than men in solving algorithmic issues. It does filter people, because it's designed to filter people, but I've never found it discriminatory along gender lines.

No it discriminates against older developers and developers that are self taught. Typically when you are looking for the skills needed to work in a particular field you will look at job postings or talk to other engineers already in the field and they will typically say "You need to understand this language or something similar and how X and Y work" and typically people will buy a book, or do a course on those things.

With older developers a lot of these wanky problems we forgotten how to solve years ago after we left university because the majority of jobs outside of FAANG will rarely require anything more complicated that recursion or a for loop.

You are trying to assess whether people can do a job. Not solve arbitrary problems that don't present themselves in the vast majority of circumstances.


Thank you for putting it so well. I've been developing for the web for 24 years(!) and anytime I have an interview with some stupid leetcode-like challenge, I feel like I'm taking crazy pills. It'd be like trying to get a job as an airline pilot, but in the interview process you'd have to solve aerospace efficiency calculations for a Ramjet engine. It's absolute madness and I can't think of any other industry which accepts this as normal. It's a strange combination of time-wasting, degrading, and insulting all at once.


Leetcode isn't used for html/CSS roles / basic web design roles. It's generally used at large SV companies which use software at a very large scale. Most people who apply aren't poor and have undergraduate degrees or higher. When you are using software at that scale algorithms are pretty important to get right. Not all software jobs require a computer science background, but a lot actually Do. Look at the open source work that FB or Google do, most of it is very computer science heavy. They aren't just hacking together for loops


> Leetcode isn't used for html/CSS roles / basic web design roles.

I don't think this is true. I've a buddy whose bread and butter is web development at small companies (<20 devs, often < 10) and he's been running into these types of problems at just about every role he has applied for in the last year and he's absolutely terrible at coding interviews despite him being able to reliably turn out solid code during his day job week after week.

What's fashionable in SV tends to be adopted by other companies no matter how well it actually fits. See shops with one team of 6 developers trying to turn everything into microservices.


This was my experience during 2020 (companies were being really picky). I ended up temporarily working far below my day rate to pay the bills. It wasn't fun.

I got hired for 3 times the amount based on my previous work. No time wasting tests, just my work.


Fair enough I agree not all roles need that sort of background


The complaint is that the skills that leetcode is teaching you / testing you on isn't relevant for a lot of jobs. I am not talking about just basic web development either, that was just an example to illustrate the point.

The whole issue that these sort of tests are used inappropriately accessing someone suitability for a job. Most software people produce is simply implementing existing business processes. This doesn't require anything too smart algorithm wise, but may require good use of gang of four patterns or understanding how best to put a database together.


Knowing How to put a database together of requires you to understand algorithms though. joins /indexes /sharding etc require knowledge of cs theory. Knowing the details is very valuable.


You edited this after I replied.

> joins /indexes /sharding etc require knowledge of cs theory. Knowing the details is very valuable.

For the vast majority of scenarios you are going to run into no not really. You normally just need to read the documentation and know how it should behave and think a little bit about how the database is likely to be used. You really don't need any CS theory to be able to do that.

In any event it isn't what a leetcode / hacker rank style questions are testing for.

I don't want to be rude but I swear a lot of people on this site live in a bubble and don't really understand what happens outside of it.


I mean what is an index ? Merge join vs hash join ? These are basic algorithmic ideas that you should know if you're doing any sort of optimization on a database at all. I don't mean to be rude but I hate working with people who have no interest in their craft. They tend to make work harder for everybody else. I'd rather hire people who are actually interested in learning.


> I mean what is an index ? Merge join vs hash join ? These are basic algorithmic ideas that you should know if you're doing any sort of optimization on a database at all.

I have faith that I can read documentation, relevant theory and implement a suitable solution. Whether I score highly on a hackerrank/ leetcode test won't enlighten either of us if I am capable of implementing a suitable solution.

What I certainly don't need to do is prove that I can memorise and implement the some algorithm in some arbitrary timed test that isn't relevant 99% of the time for the tasks that I will be performing day to day while creating software. It isn't a test of whether I can perform the job or not. It is a waste of my time.

I don't really understand how you cannot fathom the difference.

> I don't mean to be rude but I hate working with people who have no interest in their craft. They tend to make work harder for everybody else. I'd rather hire people who are actually interested in learning.

I (and many others) have plenty of interest in my craft and work to improve myself all the time. Just because you cannot comprehend that people can get stuff done without knowledge that you happen to think is important and doesn't mean they are lazy or uninterested.

Scott Hanselman had this analogy of a tap and a sink. Many people's mental models of it is that you open the tap water comes out and water goes into the sink and out the plug hole. They do not know (and most of the time do not need to know) anymore about how the water arrives or leaves.

However knowing a little about what happens before and afterwards might be useful if you need to fix a clog. That doesn't mean I need to be a plumber, nor do I need to know how how the sewage system works. I can fix the clog and get on with my life. That is how most people manage and results are normally sufficient.


These are valuable, you're right. But they're not _necessary_, which is the point here.

I've been working on databases before and come across slow queries and read up on both the general theory and the DB specific practice for improvement. After that I've filed away in my brain "this DB needs this sort of optimisation", then ejected the rest. If I need it again in 5 years, I'll look it up and recap.


no, they're hacking together protobufs, which is much more complicated. \s


The fact that a SWE with decades of experience needs "practice" to pass leetcode indicates two things:

1. Leetcode challenges aren't representative of the actual work. Or else years of shipping working software should be as good a practice as one needs. So is it sufficient grounds for rejecting a candidate?

2. Those who pass leetcode challenges need not have any real experience as long as they can commit to few hours to practice the toy problems. So is it a good criteria for passing the candidate to the next level, given others who were rejected on leetcode basis?


If you don't understand the hate, listen to people more carefully. But I think you actually mean: "I understand why other people hate leetcide, and I think their emotions are invalid". At least own your argument


> I never understood the hate Leetcode gets

Getting leetcode questions at an interview is ridiculous if the position doesn't require it.


100k$ is an achievable target without Leetcode. Freelancing/contracting will get you there. Frankly, contracting in London nets you 120k£ pre-tax easily, and contracting via a limited company means you can significantly reduce your tax exposure.

Beyond that is a bit tricky. It's not impossible, and you can land a high-paying job at a startup or established non-tech company (established tech outside of FAANG is usually terrible pay-wise) through your network or recruiters, but the workload might be higher.

The advantage of FAANG is that beyond the initial LeetCode grind and the relative mundaneness/uselessness of the work (are you really passionate about littering the world with even more advertising?), it being such a huge company means that once past the initial grind you can lay back and still enjoy a very good paycheck for lower effort than in a smaller company which actually produces useful output beyond advertising.


I certainly recommend freelancing. It can take some time to get up to speed, but I'm currently making €95/hr on a long term project, which will probably be over €130k per year (for 32 hr per week). My rate might be the high end (I honestly don't know), but my sister who just started freelancing in test automation (which might be more in demand than developers?) is starting out at €75 or €85 per hour. €80 per hour for is not unusual at all.

Of course as a freelancer you have to arrange your own insurance and miss out on lots of benefits that employees get automatically, but personally I think the trade-off is easily worth it. Though to me the real advantage of freelancing isn't financial, but freedom; I'm less bound by all sorts of company rules and restrictions. Although on the other hand, I'm more bound by the tax service. I think it's a good trade-off.


Man, i feel like i'd be worried about droughts of jobs.Any advice on dealing with that stress? I take a lot of value out of standard jobs and stable companies.


It depends on the market and your skillset. You can test the market right now by polishing up your CV & profile (LinkedIn is actually a good source of leads), getting in touch with some recruiters and seeing if you can get some offers, and adjust your rates & risk tolerance based on this.

At least in the UK, the contract market seems quite good for this early in the year, and usually peaks around summer. YMMV.

It obviously depends on your situation and whether you have any responsibilities; my opinion would probably be different if I had a family, but in my case I have little to lose even if things go sour. I won't be able to do this forever so I make the most out of it while I can still afford the risk.


It's always good to have a financial buffer, but I've never really needed it. Recruiters find me on LinkedIn and call or mail me. I generally blow them off or ignore them, unless I'm actively looking or they have something that catches my eye.

I suppose I could do my own acquisition; cutting out the middle man would probably increase my hourly rate, but that's a lot of work I don't like, and this works well enough for me.


Does it take a certain non-technical aptitude to market oneself better? I think those who fear interviews may find this challenging as well.


Unsure about European prices but as a freelancer in the USA it's not unheard of to charge $120-150/hr


Sure but even then it's low compared to being a senior at FAANG and publicly traded startups, no? (ie $300k+ annually when RSUs are factored in) Especially when you factor in the job risk and lack of PTO (even ignoring lack of health insurance cause in many cases your spouse can cover that)

I personally would like to get to $175-$200 an hour as then it would truly be competitive with the above, but not sure how to get there


For that, I think you'd have to have a unique and highly in demand specialisation, and become widely known for it. Then you can basically ask whatever you want.


Yes, 120k is easy via contracting in London, however almost none of those contracts accept EU applicants even if the role is fully remote.


The main requirement is that you must have a UK-based limited company - I guess for clients this simplifies handling VAT/etc.

Beyond that, it's up to you how you want to structure it and whether you are physically based there - the client doesn't get to see it and couldn't care less as long as the work is done.


Having a UK limited company when your tax residence isn't in the UK is quite complicated. I actually had a tax advisor strongly advise against doing that when I left the UK.


Surely its more like £250k in London if you are in a full time contracting gig?


Your rate would have to be over £1000 a day. Your typical rate is half that, i.e. the person you're replying to is bang on. The only person I heard of on a rate that high was someone doing automated trading stuff for one of the Rothschilds.


Average day rate for a big consultancy is well over £1500 a day (https://www.linkedin.com/pulse/comparison-day-rates-between-...). Basically anybody you know who works for a semi-legit consultancy is being billed out at over £1000 a day.

Its super easy to get £1000-1500 as a freelancer who handles your own sales if you have the right credentials (degree, +5 years experience, do not completely suck at programming, specific domain experience, etc).

But yes, there is a whole industry of middlemen who try an convince suckers to work on a contract basis for around £500 a day.


To be fair it is possible, I occasionally see 1k/day rates but they require either niche skills, a significant amount of experience or just seem like a terrible idea that's guaranteed to fail and you'll take all the blame for it.

In contrast, half that is doable for any mid-level developer and is still a major lifestyle upgrade compared to permanent employment.


Regarding lifestyle, I think if it were objectively a lifestyle upgrade then everyone would seek to do it. I am a contractor myself, and see it as an upgrade, but I've come to realise a lot of people's lifestyles don't come from their work. Having to find new work multiple times a year, putting effort into keeping up with tech, doing bookkeeping etc is hassle most people can't be bothered with.

Horses for courses.

Edit:grammar


Curious what you see as the "lifestyle upgrade" in the contracting route? Is it mainly in the comp (if so, see my comment https://news.ycombinator.com/item?id=30103313), or something else?


Comp is still an upgrade compared to permanent employment for essentially the same workload & skill; for a permanent role at 80k with minimal benefits and the legally-mandated minimum of 25 holidays/year you can get the same by contracting for 7-10 months at the 600 mark and take the rest off. You'll miss out on the pool tables and brunch on Fridays and the company "culture" though - I say that only half-sarcastically because that's off the table in a post-pandemic world anyway.

Contracting also allows you to defer your personal tax liability to the time when you actually take the money out of the company, so you can accumulate money and leave it there, still paying yourself the usual amount to stay within the same personal tax bracket (and use the extra money to keep paying yourself while you take an extended holiday for example). If you're working on your own tech startup and need capital for expenses (hardware, etc), you can use that money directly and essentially pay no personal tax on it. At least in the UK, this is limited to tech though - if you're running a software consultancy company and decide to attempt your own tech SaaS it should be fine, but don't try to use software-company money to start a plumbing business for example - if in doubt, talk to an accountant.

Even setting the money issue aside, simply being able to take months of holiday every year would be a problem for many permanent positions but the opportunity is implicitly there with contracting when switching between contracts - simply delay your search for the next one. If your holiday time is flexible this is even better and you can use the downtime to wait for the right opportunity to come up.

Another perk of switching clients frequently is that you get exposed to lots of different industries allowing you to make connections and gain domain knowledge. There's so much out there beyond just the tech, and those rarely have any good or consistent "documentation" you can learn from - you really need to be on the ground to grasp it. Doing that with permanent employment is technically possible but I hear that switching permanent jobs frequently is a red flag.

Freedom of being able to quit a wrong opportunity is very nice; there are no RSUs or similar that would keep you at a job you dislike. If it isn't working out, it's best for everyone to leave things there. Boredom is also implicitly taken care of as your contracts are short enough anyway.

Essentially, these are my reasons so far. Maybe my opinion will change in the future, but for the time being contracting allows me to increase my comp & gain flexibility with pretty much no increase in workload or extra skills required, as opposed to let's say grinding LeetCode to get into a FAANG, have to deal with FAANG-scale problems that I couldn't care less about (I quite like working on smaller-scale projects) or learn to play the company politics game.


Thanks for your detailed reply!

First off, looks like you're based in the UK, so I think it's quite a different situation than the US – from what I hear unless you can get into a FAANG, Engineer jobs at other tech companies pay peanuts, so contracting is very lucrative by comparison. In the US you can find plenty of pretty decent-paying tech jobs even outside of FAANG.

As far as taxes go, there are some savings, as with an S-Corp you can contribute way more to your retirement than as an employee, but you still have to pay taxes on your entire earnings whether you "take them out" or not, and have to do so quarterly (or at least annually for the portion you didn't pay yourself in "salary"), so sounds like that's another plus for the UK.

Taking all these factors into account plus the fact that the client doesn't have to pay your healthcare or provide equity/RSUs, and can easily let you go at any time, I think the average contractor rate in the US is actually low, which I'm not quite sure how to make sense of in terms of why the market's priced it this way.

Totally with you on the company culture+getting broad experiences part. Alot of company events etc esp for Engineers are pretty cringe. And politics... kill me now. I've also been trying to fulfill my socialization needs outside from my job, but more and more I'm realizing that in the modern world that's actually pretty difficult esp if you have a spouse, as then you need to spend extra time to get that, whereas she gets it from work, overall a pretty sad state of affairs that our society's evolved to be as such, IMO.

(In case it wasn't obvious, I too am working as a contractor now :) But still deciding how I feel about it)


I'm just basing it on my own figures averaging about 9 months of work during a year around the 600/day mark which is seems to be about the max I can do with my current skillset.


Here's my opinion as a well paid west-coast software engineer.

Leetcode is literally gatekeeping to boost the egos of people whose entire identity is that they work at a FAANG. You have probably met such people - I remember these types from high school and college who could memorize a bunch of shit and regurgitate it. Beyond that, I've found maybe 25% of them are good team mates/leaders. They go home, update their bios to read "Stanford CS, Ex-Apple, ex-Meta, now Noogler", and hang out with other similar types.

I've been on interview panels before, and while I prefer administrating the systems design interview, I've also had to administer coding. The way it goes is like this - half have this stuff memorized because they took a FAANG interviewing bootcamp or spent 6 hours a day for 3 months grinding leetcode. The other half are split into another half - one half that struggles but manages to do decently with guidance, and another half that just fails outright due to nerves, lack of knowledge, etc.

Here's the weird, anecdotal experience though - of the people who absolutely kill the coding interviews, maybe half will do well in systems design. They struggle at explaining concepts on the fly, or cannot come up with reasonable solutions. Maybe it is a lack of imagination, because I really do think a lot of people just memorize and get ahead. Then they hit a ceiling, or fly just at the max ceiling while boasting "ex-Facebook, ex-Apple, etc."


Last year when I was job hunting, I did an interview for a small startup. The very first thing the interviewer told me on the call was, I'm an ex-googler.

Then proceeded to give me a crazy leetcode question with basically no guidance or help.

Now, I expect and event want _some_ kind coding test questions. But not some crazy harebrained leet question.


Leetcode is not an 'absolute necessity'. Many firms do timed homework (I have seen anywhere from 90-min to 3-day time limits). I personally have not observed any statistical correlation between salary level and leetcode requirements; or know of any data studies on this.

That said, I have seen that even those firms without rigorous leetcode rounds have mini-leetcode questions during onsite that are the easiest of the easy leetcode problems; e.g. find the sum of an array of ints, find a duplicate item in an array, etc. So, I don't think you can avoid these questions completely, but at the same time, summing up an array seems like a fair sanity check for dev applicants. I saw one programmer (PhD!) from a Top-3 school in Europe that could not find a maximum value in an array. So, yes, some sanity checks, but I don't think this is what you are concerned about.

All those examples I mentioned above pay above (some well above) 150k USD TC.


Am I the only one just googling for this stuff because it's way faster? like, "maximum value in array" gives:

var max = arr.reduce(function(a, b) { return Math.max(a, b); });

which is totally valid for javascript and also pretty neat. I would probably do some funny things with loops instead, wasting time and resources.


That particular question was not supposed to be a trick question. If the answer given in, say, Python was 'max(array),' I would have found the answer acceptable ('max' is an intrinsic function in Python); a better answer would be writing a for-loop. The person facing this question was an applied CS PhD (student at the time) at a Top-3 in Europe with prior working experience (IIRC).


That sounds an awful lot like panic not incompetence.


I didn't realise what it was like to panic in an interview until it happened to me - couldn't write code to detect whether two rectangles were overlapping even though I had been doing graphics programming for 10+ years at that point.

It was a CTO role and I'd just aced a presentation on "How to launch a new product" and I could not context switch to coding mode fast enough.


It happened to me once too, when I was still wet behind the ears, my mind went totally blank, could barely remember my own name. It didn’t help when one of the two men interviewing me said “look, we don’t want bullshitters here”.

I wonder if I’m one of the anecdotes about people in tech who can’t do the basics. That would at least amuse me somewhat.


I appreciate the sympathy, but, in this particular case, the question was part of homework, not on-the-spot pop whiteboarding. To this day, I find this curious. I asked folks at other firms, too, and apparently, this kind of phenomenon is common. Hence, all the damning statistics about the FizzBuzz.


My story: Years ago I went across country (ok it's UK!) for a position with an education startup. It was an all-day-er. The morning went well I aced the in person stuff, we gelled. Then I started to realise why I was there. Was I risking my marriage by taking a cross country position? Is the CEO just a bit too full of himself? What don't I trust about the product manager?

At the end is a hands on leet-code test. I cannot for the life of me remember what it was about. I do remember writing a function to replace 'abs', and realising that my brain was not even in the same county.

Yeah. People fail for all sorts of reasons. But when it's odd, maybe it is them. But beware. Maybe it's you.

I am glad I flunked hard in Bristol. I think I would have hated it. But then if I was a rubbish coder I would say that too.


Proctored homework? If not, I don't understand how he couldn't come up with a solution at all.


You can speculate but anyway there are all kinds of reasons a person can fail to do something that they are in fact capable of doing.

Sometimes people who have DECADES of walking experience just... fall.


No need to waste any time: Math.max(...arr)

Even when I know how to do something, I look it up just in case. Sometimes there's a cleaner approach, or I learn that I don't fully understand the problem.


In this case if you look it up on MDN you'll see that Math.max(...arr) isn't recommended for large arrays (ask me how I know)


I would suspect that. How do you know?

(this sort of discussion is what I'd love to see in a tech interview)


You're not the only one, but it's the equivalent of walking round a foreign country with a phrasebook versus being fluent in the native language. In this case, for example, you seem unaware that reduce is just doing a funny thing with a loop and won't be faster, but you've been seduced by shorter looking code because it looks more clever. There is, in fact, value in the reduce method but it's nothing to do with speed or efficiency (it's because it's declarative). But if this were Python, and the reduce was a call to numpy, then it would be about speed and efficiency. The point of doing stuff like leetcode is (or should be) to test real understanding of the technology, not an ability to copy/paste from StackOverflow.


But if you can grind these what's the point then? All I'm doing at work is building glorified crud apps. I'm sure it's what many, many software engineers are doing. Not all, but many. My understanding of e.g. Django is much more important to my daily work than being able to come up with the fastest way to find a maximum value in an array.


Nobody said anything about the fastest way to find a maximum value in an array. The comment you were replying to was just about finding a maximum value in an array. Idiomatic usage would presumably be a bonus but anything not ridiculously inefficient would be fine. This is absolutely something that someone building a CRUD app should know how to do without StackOverflow.


Sure, in a real world scenario you would Google the most efficient/elegant way to get the max item in an array. However in an interview situation, the interviewer is usually expecting a language agnostic approach, i.e. using loops.


That's my point, those questions are pointless. They don't show anything meaningful besides someones ability to learn a lot by heart. I mean, just based on the fact that someone asked if it was necessary to grind leetcode questions shows that you cannot gain any meaningful insight by asking questions like that.


Actually having to google something so basic makes your experience suspect. That's almost as bad as having to google for loop syntax in a language you say you know.


I have ADHD, I'm glad I can remember to not put the underwear on my head instead of where it belongs. Of course I can't remember how a for loop looks like, that's why some nice people invented code completion.


First, thank you to share so directly. HN is stronger for anecdata like this.

Let us assume that you are a competent worker that other firms want to hire. What is the best way to find people like you and to test/interview people with ADHD?

To be clear, I do not have ADHD, so I have no personal experience with this important topic.


I think homework would be fine, it really depends on the person. You can find people with ADHD who would crush these questions and others who wouldn't.

Personally... I had another profession before and was never asked anything during interviews. They just assumed I was capable because I had a degree, work experience and references. So I'm not quite sure where that even is coming from, it's unheard of in other professions.


Some companies want you to describe your solution, or say pseudo code is fine. But not every company will be completely honest about how much they actually do penalize for improper syntax.


You made two mistakes: You optimise prematurely and your assumption is incorrect.

Premature optimisation:

In most cases the performance would not matter. Instead of optimising for performance you should optimise for readability. IMHO IFs and FORs are way more readable in any context than any language specific methods like REDUCE and MAX.

Incorrect optimisation:

At least in modern browsers, simple IFs and FORs are the most optimised methods of doing anything. See for instance https://leanylabs.com/blog/js-forEach-map-reduce-vs-for-for_... (Operations per second, higher is better).


Conversely if I saw someone use a for loop (especially one with mutation) where a trivial usage higher order function existed, and I was giving a “leetcode” interview (which I refuse to do), I would take it as a signal that there is an important missing concept if it were not corrected when prompted.

The idea that “reduce” is language specific is frankly mind boggling. It’s no more language specific than a loop.


I am talking about my own time and resources, not those of a computer - say, it might take ~one hour to come up with a solution for problem x. It might very well be not the best solution either, just the one that works okay (we've all been there). Or I could look up what other people have done in 2 minutes - say I'm comparing solutions too, that would make it 10 minutes. That's 50 minutes of work I can spend elsewhere. Much more efficient.


I see. I completely agree.


Thank you for the nice exchange and learning opportunity though :)


As someone who prefers constructs like map, reduce, etc to loops this is a key example of why it’s important to a) ask why the candidate went that route and have a conversation about pros and cons and b) recognize that this is one of those no right answer opinion things and not hold it against them if they think different than you

Mind you I’m talking in general and now in browser specifically


Explicit loops are only more readable in languages that suck.


Well, the thread is about Javascript...

I take the exception that on this case in particular, the reduce is much more readable than a loop. Javascript isn't completely on the "anything non-imperative could as well be in machine code" league, but has plenty of problems that appear when you try to write other kinds of declarative code.


I'd go with `Math.max(...arr)` personally. Math.max is a variadic function, no need to add a reduce into the mix.


That implicitly calls Function.prototype.apply(), which will fail if given more arguments than an implementation-specific limit (https://stackoverflow.com/questions/22747068/is-there-a-max-...). Looping with reduce() avoids that restriction.


No, you are definitely not. But some insecure interviewer might feel this is an enormous red flag to be doing so.


Speaking for London, if you would like to have £180K+ FAANG or Hedge Funds / Trading is your only option and unfortunately they ask leetcode questions. Some of them go crazy and ask hard, some like Facebook ask easy / mid but want you to be quickly come up with the answer.

There are eng offices of soon to be IPO'd startups such as Stripe or Intercom in London, those don't ask something you don't do in your day to day job, however comp at this stage would be base + maybe bonus + stock options. You can never know when that stock option will turn into something, so in a way it's even worse than lottery, at least in lottery you know the date to check if you get rich or not.

There have been few IPOs from London startups like Deliveroo, but I would say they perform pretty badly and things are not going well for people who relied on the return from there.

So, I would say Yes to this. Unfortunately.


I agree with you, although you can get near/past FAANG level TC by contracting/freelancing. Even just being a Java dev, you can make around 650+ a day which is about 150k/year. Plus you can expense almost anything IT related. If you branch out into doing trainings, or become a subject matter expert, you can charge 750, 850+ a day which is basically >= FAANG L5 levels. Probably a lot harder to be honest since you need proven experience and results, but it avoids the leetcode.


Yeah, I was talking for the perm roles. If you go to the contractor route, 600, 650 is quite doable. For higher as you said, it's networking, how people see you and what kind of projects you delivered. Depending on the person, it can be something even harder than the leetcode grind. But overall, I would agree.


Disclaimer, I haven't leetcoded - though I kicked around topcoder a long time ago.

Leetcode probably has value - but the real value isn't in your scores. The scores are a heuristic grade for algorithm capability maybe. And it makes sense that hiring parties would take it into consideration. The real value lies in what you learn from completing the challenges. I don't think there's much value in being able to 'invert the binary tree' or implement a hash table from scratch. Nobody should do that professionally unless they're trying to push ahead the state of the art in that field.

BUT knowing about algorithm X,Y,or Z, and its performance characteristics and having that in your toolbox to solve real world problems is the difference between an engineer that spins their wheels for a week before solving a problem badly, and one that doesn't break a sweat making a correct and performant solution. A portfolio of algorithms and their strengths in you're 'inmem cache' is crucial if you want to move to roles more advanced than hocking json blobs between the frontend and DB.

I consult and typically find myself working on problems that the in-house team hasn't been able to work out, and very often I walk in on messes of nested loops and O(n^3) functions, when all it would have taken is judicious use of a Heap here, a Dict there (it's surprising how often a linear search over a list rather than a O(1) hashtable is used in some circles), or maybe a Trie or two. These aren't esoteric academic things, they are the abstract building blocks needed to solve real problems.

So, I digress, but: use LeetCode, work on open source, build challenging things and hang with a crowd that knows more than you and watch what they do closely.

Seek to grow your power and capability, not your credentials. If you grow as a developer then the credentials will come automatically. And if a potential employer can't tell the difference between a stone-cold competent programmer and somebody who just has a lot of acronyms on their CV, then they probably don't have much to teach you anyway.


Three years ago I started rejecting interviews that included banal code challenges unrelated to the positions, leetcode, and hackerrank stuff. Basically anything involving Coderpad et al.

The result in a 40% increase in total comp and having worked for some very high quality folks and with extremely pleasant folks. My job satisfaction has never been higher.


Seconded. I've never done leetcode but have gone through some hiring processes which set challenges that were totally irrelevant to my role. One place asked me to write a simple SPA in angular with a three day (!) time limit. I'm a DevOps guy and it was a DevOps role. I ditched and was reasonably pleased to have done so.


FWIW I think you can absolutely ask practical, grounded coding questions in a coderpad environment (I believe $current_employer does).


In my 21 years in the industry, I've never seen one. Schrodinger's Code Challenge.

There's also the issue of Coderpad et al being a sterile, primitive, unfriendly environment. Not the editor or IDE a candidate is comfortable with. (Additionally, I want to know about a candidate's editor and setup. It reveals a number of things I'm interested in) And I like candidates to be comfortable to be able to be their true selves. Then there's the awkward "wait while you code," folks sitting on the other side that you don't really know, waiting or trying to make some kind of polite commentary to let the candidate know they're not being ignored or forgotten. And the candidate trying to talk through code, again with people they don't really know or have any social basis with. Coderpad is a horrible environment for interviews.

That said, I have seen VSCode's Live Share used successfully, where all parties were engaged and contributing to code in the same session. That was on an actual job-applicable, practical exercise.


Last time I had to do one of these idiotic challenges (on Triplebyte), I had an in-browser text box for code input, and a set of tests (some hidden) as the output on the right. I had no debug capability, no log, no feedback of any kind besides clicking the "run" button and seeing if tests pass or if it doesn't compile correctly. Of course I failed the challenge, because the way I write code is to take a first try, inspect errors, step through lines, and refine to get it as it needs to be. This was all impossible in this "environment" I was forced to use. Even worse, it has a timer ticking down the entire time, taunting you as you come ever closer to "failure".

What a miserable excuse for a test of my abilities. I will refuse to complete these challenges as a matter of course, and encourage others to do so as well.


What I do with such is I copy-paste the challenge scaffolding to my local IDE to make the solution. Once done I copy-paste the resulting code back to the web interface for a run. Worked well during my off-line challenges years ago. Otherwise I would refuse coding over any cr*py interface, especially live coding.


I considered that too; in this instance, I had 7 minutes to complete the "challenge". That wasn't enough time to copy over the test cases and get things configured properly for that. Still terrible that we have to even try to work around these terrible interfaces.


> 7 minutes

There are so few areas of software engineering where a time limit like that is remotely realistic. What a gas.


FWIW $employer is also okay with candidates working in their local environment if they're comfortable screen sharing. IME most people seem to prefer coderpad though, even after being nudged that using a local environment may be more helpful for writing tests.


I just wrapped up the interview process and got a job offer at >150k with 4 years of experience. I interviewed with probably 10 or so companies along the way.

I do not believe that "grinding leetcode" is at all necessary. However, familiarizing yourself with online "IDEs" and the skill of solving (relatively simple) problems quickly while communicating your thought process is necessary.

That being said, I would do a handful of Leetcode-type questions on your own time. Don't aim to solve as many as possible or even bother to hit the hardest questions. Most questions I received were actually pretty simple algorithms that any dev could handle. IMO it's more important to be comfortable in the environment, and be able to communicate well to your interviewer if it's live than to be able to come up with perfect solution instantly.

The better companies I interviewed with made the live coding portion a small component early on, basically as a screen for basic coding skill. After that, the most important parts were design, discussions on previous projects, and behavioral interviews.


150k€? Or are you talking about USD? 150k€ for 4 years of experience is really very high in Europe.


Please define the use of the term 'grinding leetcode'.

Is it:

a) Having a good score on the actual leetcode website as a prerequisite for an offer/interview.

b) Using the actual leetcode website to practice for a technical interview?

c) Practicing some other way using leetcode style data structure and alogrithm problems. e.g. working on the Cracking The Coding Interview book.

Personally I've never seen any recruiter or interviewer mention leetcode by name. But I've certainly been asked to practice leetcode style problems.


Plenty of interviewers have mentioned leetcode by name to me, and some have even said "you may recognize this problem from leetcode" and they proceed to paste in the requirements :)


I used to do bowling then a leetcode hard question for interviews, but I had very little interest in whether they got the right answer. I would try and ask a question that was very unlikely they'd know with the focus on how well they communicated their thought process while working through the code. I did run into a couple of Chinese grad students applying for intern level positions that actually nailed the problem in minutes, but couldn't explain at all how it worked. Really frustrating as I'm sure they were probably capable, but they didn't make it past other steps of the interview either due to inability to communicate. Then for one intern interview where I could see the kid was not even qualified as an intern- I was told during the feedback review process- "oh he's related to so and so, I know that you were a no, but we're hiring him"...I left that job not too long after.


> I would try and ask a question that was very unlikely they'd know with the focus on how well they communicated their thought process while working through the code.

I'd probably do something like that. No actual writing code, more of a discussion with them about ideas for solving it. I'd try to let them take the lead on approaches, just adding ideas to keep things moving if they were getting hung up on something.

After we've got what seems like a reasonable approach and I'm sure the candidate understands it, I'd then have us take a quick look at the official solution and see if it is along the lines of what we came up with.

Finally, I'd go to the discussion area for that problem and take a look at a few of the solutions posted there and ask the interviewee to help me do a quick code review of them.

The discussion areas for Leetcode problems are an often overlooked resource. They are full of proposed solutions with all kinds of issues. Sometimes they just won't work. Sometimes they solve the problem but don't meet the time or space constraints the problem asked for. Sometimes they work except for edge cases.


Nobody cares about (a). I believe OP is referring to coding interviews


Startups are awash with capital at the moment, and remote is the rule rather than exception, as it was 3 years ago.

Plenty of startups don't have leetcode-type coding interviews in their culture, and the job market is such that $100k remote salaries are widespread.

No, the leetcode grind is not necessary in this job market, particularly if you apply to startups rather than FAANGs.


In my experience in the UK, the average startup salary for a senior engineer is around 80k. Not disagreeing that they might be awash with capital, but they don't seem to be willing to share that capital.

Edit: in my figure above that's 80k pounds but from my perspective it doesn't make a big difference for someone living here whose living costs would also be paid in pounds and the prices of most goods (in terms of the number, ignoring the currency) equivalent to the US when you'd expect it to be cheaper given the value of our currency being higher.


I guess it depends on the stage, and funding level.

Those that have raised a large seed round (e.g. YC companies), or Series A, $100K USD for a senior engineer is pretty common.

Most of the remote jobs advertised here will be expecting that, including the UK companies:

https://www.workatastartup.com/jobs/l/engineering

Disclosure: YC Company in London. Not hiring, but our peers are hiring with these kind of salaries in mind. Not happily mind you - employers never like it when the market favours job-seekers!


80k what? £80k is more than $100k. Or did you mean that the UK average is the GBP equivalent of $80k?


I indeed meant £80k, but my argument is more around the purchasing power and lifestyle the money will give you. The currency doesn't really matter in that context as everything you buy will also be in pounds and the unit prices for most things (except specific industries like healthcare) don't seem that different and property prices are also through the roof.

Taxes also seem extremely high. I'm not sure of the situation in the US but 80k£ here already lands you in upper end of the tax brackets despite the rent on a decent 1-bedroom Central London apartment being ~50% of your monthly take home.


Not that it makes things better, but 80K doesn't put you in the highest tax bracket: you pay a higher marginal rate over £100k because you start to lose your personal allowance, plus there's a 45% rate at 150k+


Fair enough, I wasn't aware it gets even worse, but the current level of tax at 80k£ already feels extremely unfair when it's barely enough to rent in Central London.


£2,000 a month after rent and commuting costs (if you live in Central London you presumably walk or bike to work) is hardly "barely enough", as a single person.

£80k is $108k. You get a net (before student loan deductions) of £55,092.76, you keep 69%.

As a single person on $108k, you'd pay $31,779 in San Franciso in Federal, FICA and State tax, you keep 71%

Whether the extra $1847 a year of taxes is "extremely unfair" is anyones guess, but at least you won't go bankrupt from medical costs.


London is one of the most expensive cities in the world - plenty of much cheaper (and to me much nicer) cities in the UK.


There's a c.60% marginal rate at 50k-60k too if you have a couple of kids


£80k is £4600 post tax per month, £4200 after student loan, and is higher than about 95% of the country (about about 97.5% in 2019)

£2100 will get you far more than a 1 bed flat.

https://www.rightmove.co.uk/properties/119215184

for example is a 2 bed flat by Elephant and Castle less than a mile from the South Bank for £1733


If you live in a large city, like London, yes. But for a remote job, you're no longer tied to doing that.

There's obviously this phenomenon of high-salaried tech workers moving farther out of high cost of living places like London and San Francisco.


You can still retire to Costa Rica if you find a way to save a good percentage of that money. And, like everything else you import from China, a Creality CR-30 3DPrintMill costs the same in London as it does in San Francisco.


I suspect you mean that figure for a London Salary. Up here in the cold North there are few people who make that sort of money. I've worked at a company where the director(s) didn't make £80k.


I'm reminded of this

https://www.thedailymash.co.uk/features/how-to-be-poor-on-80...

Which appeared after someone came on Question Time complaining that £80k wasn't really that high


I wouldn't be at all surprised if it's much more expensive to hire an employee in the UK than in the US.


The real money is in the US - their wages dwarf UK's and Western Europe's programmers' salaries no matter how you look at it.


I'd actually be pretty surprised if the fully loaded cost of an employee in the UK was higher than an equivalent in the US.

Mind you - I'd love to see hard figures!


In the UK on an £80k ($108k) salary an employer would have to pay 89,820.08 ($120222), plus pension contributions and the employee would receive £55,092.76 ($73740)

In California someone paid $120k Gross I think would receive $79548, before healthcare deductions (optional private healthcare in the UK is typically about $700 a year for a single person of working age, in the US I believe premiums (employer and employee) are more like $7000 a year)

Overall at the $120k range it seems a similar cost in the UK vs California. Office space in London is probably higher than in SF, but that doesn't apply for remote workers.


It's much more expensive to hire in the US than UK, for engineering in particular.

Context - We have a UK company with US parent, and choose to hire in the UK for this reason.


> Do you mean expensive in terms of taxes, the market commending a higher salary, or other reasons?

The market. The US market for high-salaried knowledge work always pays more, whether is Tech, Finance, Legal etc.

In general, if you're a high-earner/rich, America is a great place to be. If you're poor, the UK offers more support and protections, but this is a digression.


Do you mean expensive in terms of taxes, the market commending a higher salary, or other reasons?


I wonder why would that be or where would that extra money would be going given we're talking pre-tax figures.


For one, UK employers would pay an additional £10k in Employers National Insurance on an £80k salary. https://listentotaxman.com/?year=2021&taxregion=uk&age=0&tim...

(Partially answering your "why", not commenting on whether the original statement is true.)


For the US

"the average health insurance cost for employers was $16,253 annually"

https://www.peoplekeep.com/blog/cost-of-employer-sponsored-h...

Now some employers in the UK add private health care as a benefit of course.


Company private health plans in the UK don't cost anything like those in the US, though: They don't need top cover everything because the NHS will pick up things they don't.


> Now some employers in the UK add private health care as a benefit of course.

https://job-prices.co.uk/private-health-insurance-cost/

Average is £74 a month, or $1200 a year.


Given the same salaries in both countries, it's probably more expensive to hire that employee in the US given that the US firm is expected to pay for fairly expensive health insurance.

UK firms pay for private health insurance too, but that's supplemental insurance on top of NHS coverage.


If you want to make EUR100k/year go on upwork and charge EUR65/hour, take 4 weeks holiday and allow a 40% margin for non-billable hours. You can make that hourly rate doing any number of things that require no CS knowledge.


Ye sure ... Upwork, Elance etc are a wasteland of pennywise and mistrusting clients.


Yeah, there are a lot of cheepskates on those sites, but they're not all that way. Also, I got a clients second contact at least once after a much cheaper dev completely botched the job.

(To be fair, this was all years ago, I haven't done any freelancing recently. But I can't imagine it's changed that much.)


Does anyone even hire you if you are that expensive?


Upwork is flooded with low-quality freelancers just spamming very low-hourly-rate proposals on everything, and the clients typically lack the expertise to vet candidates appropriately.

The ranking system is gamed to death and is meaningless - all those low-quality spammers are highly rated, so having reputation helps very little.

The spammers driving the rates down also mean that even if you do manage to get a higher-paying gig, the client may have significantly higher expectations than what's reasonable (as they were fed a distorted view of the market).

It's pretty much impossible to live on in Western Europe or the US.


It's been years since I went down this route, but after a while I had a list of clients that were pretty good to work for.

For example, one client had a custom CMS/Webshop that was on its ass. It was a data corruption in their MongoDB (of course...) the code didn't really deal well with. They had contacted two people before who looked at it and said it was "unrecoverable" and nothing could be done. I solved it in an hour, and their business was back up and running. This wasn't act of genius on my part or anything: most people here probably would have been able to do it, it's just that the previous people were the software equivalent of quacks.

Needless to say, I earned a lot of points and trust with that, and did more work for them on various things, at reasonable rates.

But you do have to dig through a huge pile of crap to get these kind of things. Overall, it's not really worth it. Plus the cut UpWork takes is not in proportion to the value they deliver IMHO, so I ended up giving up on freelance work (I'm not the kind of person that's good at "hustling" in the tradition freelance sense).


Yes agreed. I had a single good experience with Upwork as well, but I probably spent more time sifting through the crap beforehand than I actually spent on the task itself, and the platform couldn't even handle charging VAT properly.


Thanks. That is what I thought.


Start at EUR20/hour and increase your price as demand increases.

I have never sold my time on upwork but I have bought thousands of hours of time and I have regularly had freelancers move out of my price range due to demand for their skills.

I’m sure there is a cap but the market is global. It is well above what many could earn locally. Over the years I have seen a convergence of rates in developed and developing nations.


Sounds horrible (at my location). Much better to do regular contracting then.


the standard answer would be, yes but you must have a respectable reputation, as the parent commenter has I assume.

it just bugs me to read these comments that makes it sound so easy to earn that much in upwork or similar platforms without context or disclaimers


Where is €65/h considered expensive for a coding contractor?


You would be competing against all the people who offer the same for 20 EUR. Not saying the quality would be the same, but when freelancing you are basically competing against all the lower cost (and salaries) countries.

I think you need to distinguish it from regular contracting.


Oh you meant specifically for that (kind of) site. Got it.


What are the downsides of upwork?


Not getting any work, I'm guessing


They charge high fees, because they’re a labour hire company


Q: Is the leetcode grind necessary to land a high paying remote job?

A: No, you can get a good remote job without it.

---

Q: Is being good at leetcode-style problems necessary to land a job at certain companies (like the FAANGs you mentioned but others too)?

A: Yes, you'll need to be good at these problems.

---

Q: Is "the leetcode grind" necessary to get good at these problems?

A: It depends on your background, on your current level and on how well you want to prepare.


I interviewed in Berlin last year and almost no one asked leetcode type questions. Some companies were even willing to give up take home projects if you asked them.

The alternative was to have system design and technical talks and it seems to work well. I wrote about my experience where we discussed about my side project as well: https://www.arbeitnow.com/blog/how-a-side-project-led-to-a-j...


Have you done upfront salary research before applying to these companies? I am so tired of lowball offers that I tell upfront my daily rate and it filters out 95% of inquiries from recruiters.


Yeah I did, it's a little tricky because the information available is usually stale. You can ask the recruiters directly on the initial call.


I believe there have been studies that these types of programming interviews are better at measuring how well someone manages their anxiety rather than filtering for technical skills.

So don’t feel as though you’re alone there! Even people who are good or decent at these kinds of puzzles will struggle to be successful in an interview situation.

That being said it is also possible to manage anxiety. The first step is to master the skill you need to perform until it is nearly subconscious. The less mental effort you can expend on solving the problems the more you have in reserve for regulating your anxiety.

The second strategy is to raise your tolerance for feeling anxiety. Don’t interview with the company you want to work at first. Instead prepare interviews with several smaller companies that you’re less interested in and would not be unhappy if they decline to send you an offer. That way you get some practice feeling anxiety without the disappointment or worry about failure.

The anxiety won’t go away entirely for nearly anyone. But if you work at it by the time you get to the interview for the job you really want you would be prepared to face the challenge.


Is the leetcode grind necessary to land a high paying remote job?

No. Why? There are companies that know what they do, have a good founding/income and they're willing to pay well if you can make a good impact in the company.

What does it have to do with Leetcode? Nothing. They can give you a development assignment when you're going to use technologies they use every day, the ones you're supposed to be used to and for problems they might be facing right now, saw before or they're expected to overcome probably soon.

What would a Leetcode interview give you instead? I'm all ears.

There are companies that send you generic Leetcode or any type of problems to solve in a couple of hours and you never see a face, nor know more about the business you're suppose to be working for the next time if you perform well (I'm looking at you Sumo Logic/Toptal). I wouldn't even bother if that's the case.

Leave leetcode and related just for newcomers and people learning CS. Isn't viable in most of the cases for day-to-day problem scenarios.


No.

Before I interview, I definitely spend a couple of evenings working through leetcode exercises to sharpen up on those kinds of problems. But it’s just that, a couple of hours to sharpen up working in that format - the foundation that lets me perform in the interviews is my existing skills in the field.

I actually think of it as akin to running - the thing that makes the difference is your base of aerobic fitness, but you perform best in a race if you spend some time sharpening for it.

I’ve generally not found coding interviews to be a barrier to getting good offers either on-site in the Bay Area or working remotely.

I’ve also never felt like the questions I face in interviews are totally out of alignment with the work I do. They’re not the entirety of the work I do, but they’re usually a decent distillation of the hard parts of some aspect of the “writing code” element of the job.

I also think people get way too hung up on them. At the on-site stage, honestly, I think more people fail on the more holistic system design and architecture problems than on the pure coding ones.


If the hiring process uses Leetcode style questions, then yes, it's necessary. It's the game they play and if you want increase your chances to be hired, you have to play by their rules.

You have to weight those few hundred hours of hard work. You can prepare for FAANG interviews and earn 100k+/year or you can do your side project and earn ???/year plus your current job or you can improve your skills and resume and look for another non FAANG job that pays 100k+/year and doesn't use leetcode.

Clearly you have prejudice against leetcode style process. To participate it's better that you be neutral or at least acknowledge that it's part of the game that you have to play. You don't have to like it, but if your mind think it's the worst thing in the world, it'll be much harder.

I recommend you to up you linkedin profile and try to get some interviews around the world to get a feeling of what it's like. Do it without expectations, so that is doesn't stress you much.


I tapped "Depends," but I wanted to tap "No."

I can tell you that requiring leetcode tests means that you won't be working with me. For a lot of folks, that's no big loss. For me, it's shrug. I'm a bit sad, but I don't cry myself to sleep, over it.

I feel these are tests for conformance and pliability, as opposed to actual prowess. To many corporations, that is much more important. They certainly don't test for many practical applications. Take-home tests are a bit better, but, it has been my experience, that the companies look for rote responses, and don't deal well with the way that I tend to solve problems.

When I interviewed folks, I got them to talk about their favorite projects, and asked them about solving unique, real-world problems, which, to me, was pretty damn important. I looked for enthusiasm and the willingness to solve problems. The code we wrote wasn't exactly stuff that you'll find in a textbook.

I also believe that, for many companies, they are a "young-pass filter." I'm old, cranky, nonconformant, obdurate, and probably a pain to work with (although I have decades of experience, working with teams that say different, I suspect that a lot of folks here, would be unhappy with me).

I won't go where I'm not wanted. I have a great deal of skill and experience, and have been shipping (as opposed to "coding") for my entire adult life. I can prove it, too, with a pretty massive portfolio. If you are interested in delivering modern, high-quality, working, maintainable, software, as opposed to FSM worship code, jargon, and excuses, then I'm a good bet.

There's a small possibility that I may know what I'm doing, and could make other people quite a bit of money.

But I'm not a "cultural fit," and that's fine with me. It wasn't fine with me, for a while, after encountering today's hiring process, but I have learned to accept it, and everything will be fine.

I love to work. Since no one wants to pay me to do it, I'll do it for free; but, of course, that means that I do it on my terms.


No, as i've started to reach staff engineer at my company i've been able to influence some of our hiring policy. I've vowed to make hiring policy that is a joy for our candidates. I find the an extremely simple take home project is enough to see meaningful details to have a conversation about and to be able to wave around to internal stakeholders that we've seen something material of theirs. I explicitly tell folks to please stop working after 2 hours very emphatically.


As long as I can be even a bit picky on where to work, I will outright reject all work interviews which demand that I acquire skills that are useful only for the duration of the interview.

My best interviews have all been ones where I have had absolutely no preparation.


Skip the service, don't skip over the theory, the handbook ought to be enough https://cses.fi/book/book.pdf Just be useful.


Not global, but I landed a high paying remote job without a LC-style interview. However, I did spend a lot of time studying data structures & algorithms for such an interview, and in this interview I was tasked with looking at existing code and explaining it. It happened to use an algorithm I had learned in my studying for LC, so it made things much easier to explain. Additionally, just the other day, I ended up using something on the job that I had learned in my LC studies in order to efficiently find duplicate items. It's simple, but I wouldn't have known to do this if I hadn't studied for it. I find it's been very well-worth my time. While preparing to get a job, I still put more hours into side projects.

Also, I don't really get what you mean by saying you don't want to practice because you know you'll be anxious. The whole point of practicing is to get rid of that anxiety. Companies like to see how well you can perform under pressure, and how well you can communicate through that. The LC is a small part of the interview in my opinion.


I live in Western Europe too and I never heard of this Leetcode thing until today.

I make almost the lower end of the scale you gave (or I would, adjusted for working 40 hours, but I actually chose to work just 32), and I could be making a lot more if I had been a little less self-critical and somewhat more persistent with a career.

I'm not a developer though, I'm an Admin type (or precisely, currently a IT Systems Architect) with loads of experience, but no formal education.

My successful job interviews have been a guy in shorts and flip-flops asking me for two minutes about the products and tech I know, in 2008 (okay, that company turned out to be desperate), and a one hour sitting with an HR and a technical guy, during which I was asked to solve the puniest problem in shell, ca. 2015 (I literally wrote down one line of shell and a pipe to awk on a whiteboard).

Though I did also work for Amazon way before this, too, the companies I describe here were medium or large, but not high profile types like Google or Microsoft.

Also, I can well imagine though that the situation is somewhat more formal for developers.


I am currently at one of the FAANGs for almost 5 years, and even got promoted from mid level to senior in that time - I did not ever do any leetcode grinding, nor was it a major focus during my onsite with the team I joined. I also do not ask questions to candidates that require any leetcode grinding (or last minute interview preparation IMO), candidates who focus on being good at their job as a software engineer from a technical & non-technical standpoint have all told me our sessions feel very low stress. The engineering managers I work with also generally do not believe in leetcode style questions either, there is a pervasive belief in my org they are bad filters from what I can tell.

I do happen to be comfortable enough with leetcode style questions, but only because I have failed enough interviews in the past doing them (I seem to do well enough to do onsites at other FAANGs at least, even before joining my current one). I figure it's something I rather optimize for on failure than before the interview.


Where do you work?


I have a different question: is leetcode helpful for landing high-paying jobs, or is it a signal that the company is a low-paying company? Because I'm pretty good at the leetcode thing.


I had a faang recruiter actually suggest to me to grind on leetcode… a week ago. So apparently they themselves think it’s helpful.


That's awesome. Was this for a remote role, and are we talking about an entry-level kind of role or more a senior thing?


Remote, sr role


Thank you very much!


I think it's generally just for high applicant count SDE1 level roles and similar.

Higher level roles and senior roles focus more on system design and offloading more responsibility for you solving their technical stack problems.


Hmm, I wonder if I could land one of those SDE1 level roles despite having a lot of years of experience on my resume. I don't need a lot of money.


It is if you want to work for a FAANG.

Step 0: manage to get an interview

Step 1: do 300 leetcode problems

Step 2: fail ("you're almost there")

Step 3: do 500 problems

Step 4: take interview

Step 5: land $300K job (see salaries on levels.fyi, depends on country and level) and relocate) + tons of benefits, include remote work nowadays

Step 6: Struggle with legacy code, buggy internal tools, stressful performance reviews, strong colleagues who set the bar very high, high turn-over, oncalls. But the money is real, and overall management and colleagues are pragmatic and skilled.

I assume a smart/lucky/fast thinking guy can do with less than 500 problems. I also assume that as these recipe is getting well-known, difficulty of problems is going to increase.

Also not that this work even if you didn't graduate from a top school, even if you don't have significant experience, even if you're an older candidate. In that sense, these companies don't lie on the "equal opportunity" stuff. It's all about how much you're willing to grind these problems.

Other may offer counter opinion, but this was my experience as well as other new recruits.


You're saying that even if you didn't graduate from a top school, you don't have significant experience, or you're older, they'll hire you if you do really well on the puzzle stuff? That's pretty great, probably why those companies are way more ethnically diverse than the news organizations that constantly criticize them for not being ethnically diverse (https://oonwoye.com/2020/07/31/tech-journalism-is-less-diver...).

What if you aren't willing or able to relocate, though?


> You're saying that even if you didn't graduate from a top school, you don't have significant experience, or you're older, they'll hire you if you do really well on the puzzle stuff?

I can't generalise to all the teams and companies, but this was my experience, and I've seen some similar profiles around me. I suppose if you really check all the wrong boxes, it may be hard to land an interview, but once you're in the process, you have a shot just like anybody else and it really boils down at how well you do at the leedcode questions. Concerning diversity, interviewers are trained to avoid common biases on gender, age, and recruiters have incentives to interview people from minorities. I would say that if you come from a minority, you are at an advantage and you're more likely to get an interview.

What is clear, is that not everybody graduated from top schools. There are plenty of SWEs coming from developing countries. Older people are more rare. I was hired at 45, and the bar was a bit higher as they wouldn't hire me below a certain level. I've also heard stories of people hired at 55.. so there's hope.

If you're unwilling to relocate, you may be able to remote work from a different country. This depends on the company and the role, and which country you want to remote from, but it's doable.

To me, the main issue with leetcode is that it's not transferable kills. It may be very frustrating to spend 100s of hours doing these problems and not being able to land a job in the end.


Thank you very much for sharing your experience!

I definitely know a lot of Googlers and Xooglers who didn't graduate from top schools. Or at all.

Leetcode is the kind of thing I enjoy.


I agree Leetcode can be fun and I liked it too but it's extremely different from the day-to-day job. It's something to keep in mind.


> What if you aren't willing or able to relocate, though?

Many jobs are fully remotable now (tho it varies from almost all of them like Meta, to almost none of them like Apple). Sometimes slightly less money.


What would be a good source for non-faang fully remote jobs in Europe? I keep looking at various sites, but most companies seem to abuse remote postings by posting partially remote, on-site or only-remote-within-the-same-country jobs on sites for fully remote jobs.


It definitely doesn't take 500 leetcode problems. If you have a solid grasp of algorithms, you can probably get by by grinding ~30 medium problems. If you're needing to do that many leetcode then you're basically solving on pattern recognition rather than understanding.


> It definitely doesn't take 500 leetcode problems.

I'd say it depends on many things. What level are you applying to. And also, how well you perform in situation of stress. And of course, in the end, it's a competition. If the other applicant can solve problems faster than you, they'll get the job and you won't.

For me the hard part wasn't solving the problem, but solving them in 15 minutes. At Google, 2/3 problems I got were hard and not medium. There would be no chance that I solved any of them if I hadn't seen them before.


Interesting, was that in the EU? I recently had a friend go through the process in the bay area, he didn't get anything harder than easy/medium. I thought that Google, at least, was trending to making their algo portion easier as they introduced design questions instead. 2/3 hard questions is pretty crazy and anyone would struggle with that unless they grind a lot like you suggest. Might be you just got really unlucky with the interviewer or there is a culture in that office of asking hard algo questions.


I kinda wonder what kind of salaries FAANGs can pay while working remotely right now, outside of US. While in US salaries can be veryy good, for example Google in Poland is known for paying pretty bad


They all adjust based on your location. Like Meta aims for top 5% pay in the market. Other places will be lower/higher accordingly.


What's "the market"? You mean, top 5% pay in the country where you live? That would probably be about US$15k/year for me, not really what I'm looking for. So they'll hire you for full remote but pay you 80% less than someone who'll move to Palo Alto?


Yep, as far as I know.


If you go on blind and ask about interview processes the vast majority of high paying companies where TC is over $200k are going to ask LC questions. So I'd say yes, being able to solve LC gives you good odds for landing high-paying jobs.

You can go on LC (I think it requires premium) and see people post similar things (may be biased there). There's an entire category in the problems where you can see what companies have asked certain Qs and their frequency (6 months, 1 year, 3 years, etc).

I myself am starting the LC grind, the only thing I've honestly regretted in my career is not getting a CS degree (mine is in Maths). Never having a solid foundation in DSA makes LC prep painful, also the first time I'm prepping LC in general.

I'm a frontend developer for the last 7ish years and it kinda sucks that I have to do LC to get these jobs. I know some companies are starting to give different tracts for frontend roles but the vast majority still seem to be LC problems.


I work remotely from Zürich, Switzerland myself and went through the process last year.

When I went through it all, it was only Google and Facebook that did leetcode questions. The Facebook recruiter even suggested grinding before the interview. The rest of the companies did various coding and architecture sessions, with the coding sessions being much closer to real world problems.

In the end I ended up at Mutiny (https://www.mutinyhq.com/). We do real-world domain-related coding problems in our technical screens and we won't ding you for having to google things - that is after all what most of us do day-today.

If you're interested in learning more about what we do, I am happy to chat. Just shoot me an e-mail at bo@mutinyhq.com


Europe may well be different, but anecdata: I live and work in the northeast US, I suck at leetcode / FAANG-style whiteboard interviews, and I make about $300k/yr (albeit via long-term contract gigs as a consultant w/ my own tiny S-Corp).


Practicing programming is never useless. Especially problems that are often parts of interviews. Reviewing basic data structures and algorithms and refreshing your memory with whatever languages you expect to have to deal with would be good practice even if you didn't do interviews. You say you are looking for a high paying job which means being flexible and capable with programming over a broad range of ideas and topics is something you need to be able to do.

However it does not mean it is necessary, there are other ways to prove yourself and not every high paying job is going to do a coding interview.


Meta discussion about abstaining from the poll:

I just loaded this submission because I am very interested in the results. I have not interviewed in ages, and I want to know what the trend is, but I do not have a meaningful opinion. I have to make a vote one way or another in order to see the results though.

This means I will most likely vote “depends” and not explain it in order to see the results as they develop. I do not want to do this.

Adding an option to abstain would help a lot here, and I suspect this applies to many if not most polls on HN. The number of abstentions should of course appear in the results.


The points for each option are visible to me in multiple browsers on my phone.

Do you not see them?


No, I am on iOS and all I see are the options. I didn’t vote in order to refrain from polluting the poll. Maybe when it’s closed I can see the results.


Hmmm. Can see on both my iPhone 7 in both Safari and Firefox, and my Ulefone Power Amor 13 in Edge abs Firefox.


I just looked again now and the totals show up! They did not when I made the post. It’s not closed; I could still vote if I wanted to (I won’t, see upthread).

I don’t know who to thank other than ‘dang, so thanks ‘dang.


I've gotten jobs at three international remote companies, all paying above $150k, with no whiteboard and definitively no leet code. Although domain expertise helps, and working in the open (a track record of open source code, blog posts, interactions, communication style).

At current company, we're open to hiring in Europe, and we do a ~4 hr take home assignment, which is then discussed in the meeting. Evaluation is just as much around documentation and showing your thinking, as it is around the code quality - very important qualities for a remote team.


I've interviewed at a lot of companies this summer, and landed a similar remote job, x2 your salary target. I was even choosing between a few different offers. I did not train on leetcode, and I've explicitly said it to interviewers — I like to present my skills as they are when I work, not some temporarily buffed up version. I also don't remember what different letters in SOLID mean.

I still got some live coding questions, which weren't that hard. For example, one of the problems was classic n queens. I remembered the problem, but didn't remember the solution, and had to come up with it in 45 minutes. Interviewer even pointed out that my solution ended up being not one of the more common ones — it was a bit quirky and awkward, but it worked.

But most of the interviews were centred around more practical problems: take-homes with realistic tasks, or questions about architecture that didn't have one "correct" solutions but served more as conversation starters. May be it's because I didn't interview at FAANGS (I really dislike working at companies that have more than 100 employees), but overwhelming majority of the companies that I talked to had excellent interview process and I did not feel as if they were testing irrelevant skills like leetcode grinding or API memoization.


Personally I think skill at interviewing counts a lot. I've yet to see a data science interview problem that can't be answered with either "look it up in the hashtable" or "look it up in the literature". If you are good at connecting with people, don't say stupid things that offend people (boast about drinking or drugs, make anti-semitic jokes, etc.) and not "lose your shit" it counts for a lot. Bluff and bluster helps with leetcode-style tests as well as all the other tests.

This guy's course changed my life

https://job-interview-answers.com/job-interview-tips/about-b...

even though I am an extreme introvert who has to spend a lot of downtime to emerge from my lair I can manage great feats of empathy, charm and seduction. I went from being afraid of job interviews to finding them fun.

To be fair I got a PhD in a quantitative field so I find the "leetcode grind" to be easy and intrinsitcally gratifying. Today, even if I am less good at it, I find it more challenging and interesting to grind at art, photography, printing, unusual imaging technology, 3-d graphics and ensorcelling people,.


9 months ago, applied for a FAANG role, did the full day of interviews etc. Rejected, I feel the reason was not enough experience doing these on the spot coding challenges. I was given 2 on the day, 25 mins to answer each. I answered but on retrospect not a 'text book' answer. I know how I'd answer it now.

It is what it is, in practice, on the job your value comes from knowing a system, which takes time, but interviews don't check for that. I don't respond well to artificial pressure like that, but interviews have time pressure, the only way for me to break through that is to practice these puzzles.

I had been making my way through these:

https://www.teamblind.com/post/New-Year-Gift---Curated-List-...

Paused currently though, as I got a job elsewhere, that didn't have the leet code barrier to entry. Respectfully, they told me up front what they wanted to talk about it, so the questions were not a surprise.


I became quite proficient in those types of interviews just by doing really small amount of exercises. No need to grind for countless hours.

If you get an async automatic test you can always google your solution easily. You need to be proficient in understanding the problem and implementing the solution from description or rewriting in it different programming language. I had few live coding sessions with "leetcode like" task. Most of they time you'll ask you to do some basic thing, where the default complexity is around O(N²) and the idea is to come up with faster solution.

Once in a while I like to experiment with different programming language and leetcode is one of the best way to do that. People advice on building real world apps when learning new stack, but I find that really dull, as you need to understand a lot more machinery in the stack before you can actually have something running. Leetcodes are easy to run and create. At the same time they force you to lookup basic constructs, learn how to work with strings, arrays, etc.


I'm not sure why you assume it has to be hundreds of hours. Take a look at something like https://github.com/jwasham/coding-interview-university, which has a lot of different topics.

In interview loops I've done recently, I realized I was most nervous around Systems/Scaling and Graph (e.g. Dijkstra's) questions, so took some time to work on those.

You don't have to do like the author of that piece and work for hundreds of hours. If trees are proving a problem or are an area you know you aren't so up on, then use studying to fill in the gap. Anything is better than nothing, and studying for, let's say, 10 hours might make you just more comfortable with the topic to turn the interview in a more positive direction.

(Disclaimer: I have a academic background from years ago, just haven't used most of these things in years, since like everyone here has admitted, it isn't regularly a part of day-to-day life)


I'm seeing a huge discrepancy between the poll responses and the comments.

Most everyone seems to agree that leetcode has poor corollation with the ability to perform at most companies, while also agreeing that leetcode is very common practice in interviewing.

You may be able to find a company where you can pass through the interview stages with poor leetcode ability, but many companies that YOU WOULD ACTUALLY WANT TO WORK AT currently include a leetcode evaluation as part of their interview process, despite the fact that that very company does not require those skills for every day work.

And ignore the, "well you wouldn't want to work for a company that tests this way" comments. There is NOT some magical super-strong correlation between the interview experience and the actually-working-there experience that applies to all companies. Some have this correlation, and some don't. This is why you ask the hiring manager for 1:1 interviews with front line engineers and then you grill THEM about aspects of work that matter to you.


Interviewing I've done for high competence positions that aren't necessarily super high volume had such creative and difficult coding assessments that bitching about leetcode just seems soooooo bizarre to me by comparison.

Companies that did leetcode stuff are just like a joke. Can you reuse this array to store the information you're using while you're going through this list of items? Great! Wow, smart candidate!

Okay, try interviewing for something like Insomniac Games where they want you to write an effective memory manager in C as a screening question! Or interview for Sony where you got 3 algorithms problems, 3 game logic vector math type problems, and 3 obscure memory uses of C problems in 2 hours and you gotta do it all on paper. These are out of date too. It's probably even more involved now for game companies.

Leetcode is totally fine and you should get comfortable using the techniques you learned in your core competency classes in school to solve novel problems.


I think it depends on the role, I think SDE1 level jobs are more likely going to have leetcode style questions, but if you're going for senior roles it's going to be more systems design style interviews. They wanna know that you can handle their whole stack for them and scale it to their dreamed AWS perfection.


Depends.

You need some luck, and learn to be good at marketing yourself. More than that though, you need to work your arse off. Work-life balance is something you always should be mindful of, but you'll have to work harder and smarter without the leetcode,etc. and a degree, than someone with those things did, to get to the same spot.

I think the biggest benefit of leetcode and things like it is that they help you prepare for coding interviews.

I've been working as a software engineer for twenty+ years, am making low six figures, and do not have a bachelors degree (I am in the slow process of going back for it). I also don't have a leetcode account. Someone with half my experience, but with a degree from a prodigious school, could be making $300-$400k. I also am more risk averse due to family situation (so no moving to SV/Austin/NYC to take my shot with a startup, yet).


I agree with the complaints that esoteric competitive-programming stuff (suffix arrays, segment trees, Dinic's algorithm, etc.) should not tested in a coding interview.

But most of the Leetcode problems cover basic algorithms like BFS/DFS, binary search, dynamic programming, and other Algorithms-class material, no? As long as you're given adequate time to think about and solve the problems, I don't really understand the negativity in the comments towards companies requiring coders to... actually code.

(By the way, if all of the monetization/engagement/social-media aspects of Leetcode turn you off as much as they do me, I recommend practicing on https://cses.fi/ instead---the problems are higher-quality and better-taxonomized too).


Leetcode is ok. My issue with it is some of the prompts are kind of confusing. Some of the solutions are often crowd sourced. Someone will probably post a solution in your language of choice, but there's not always a good explanation.

I much prefer the book Elements of Programming Interviews. It has an accompanying git repo with tests that you can debug in if you really need to. The solutions usually discuss a couple possible approaches. Following their study guide, I learned about Java data structures that I don't normally use and saw a good variety of problems. Ended up getting a job I was shooting for.

Ultimately though, it's not so different from leet code, although I think it is a more effective use of time. I think it is a good idea to do some practice just so you are ready for this type of question.


No.

I'm a software consultant with a consultancy that would qualify as both high paying and remote in the UK and involved with interviewing, personally I value having a "homework" assignment so that candidates can complete a simple assignment and then build on that in a pairing session.

I don't think much of leetcode assignments as they tend to focus on the algorithm and getting solution through rather than writing good quality code that keeps it simple and is maintainable. That is much much more important than repeating an algorithm.

Though I also would say that in the current climate, the pressure on finding good candidates is so that a lot of places are considering dropping take-home tests in fear of putting off quality candidates, so I think you may well be in a good position at the moment to avoid leetcode and hackerrank...


No matter whether it is required, it is a malpractice. The real coding skills needed for a job are the ability to read code, not only write. So, if I were to present an automated test, it would be to invent some input to a preexisting badly-written function which exposes that it is wrong.


“No, but yes”.

If you want high paying job, you need some way to demonstrate that you are smart enough and distinguish yourself from others. Leetcode is one way to do it.

Other way is to demonstrate your work contribution. But what if you don’t have any experience?

Show that your are from top tech institute and got good marks.

But what if you are not from top institute? And you don’t have any great projects to distinguish yourself from others?

The answer is leetcode. Regardless of your college/background/ company background, with leetcode, you can demonstrate that you have aptitude for learning, self motivation, grit and perseverance.

That is why leetcode is so much used. If you are senior engineer (>10yrs), then you can turn down leetcode and show case your experience instead. For all else, leetcode is most reliable way to do it


I said yes, but only with the assumption that this is specifically for software engineering roles. You can land a high paying job in other roles without the leetcode grind. You may pay in other ways, in terms of the nature of the work or other requirements. Yes, FANGS definitely do hire MBAs from a top programs, PhD scientists to work in non-SE analytical roles, and so forth, and they may get to skip the technical interview. But I have been astonished by the credentials of people currently working at google, we're talking people with PhDs in computer science who were hired as analysts or scientists, who still had to run the leetcode gauntlet to switch over to an SE role - and some of them failed the interviews.


I also live in western Europe (UK) and refuse to interview with any company who hires this way. I work 100% from home and I earn ~$80,000.

FAANGs aren't the only things out there. I'm not sure why you specified that kind of company specifically, but you may want to consider that there are literally hundreds if not thousands of local or country-wide companies that can give you what you want.

My company probably isn't even the biggest company on the street and employes less than 50 people, and yet I get good pay, work 100% from home, and get 28 days paid leave. I work from 08:00 to 16:00 with 1 hour lunch and I haven't worked a minute of overtime in 5 years. FAANG isn't the be-all-and-end-all.


TIL you can create polls on HN via https://news.ycombinator.com/newpoll

I haven't seen one here in a long time. Maybe the algorithm doesn't particularly like poll posts?


If you want to work as a computer scientist, then you have to understand algorithms. Leetcode is just algorithms. Most SW devs do not need to understand this.

So long as SW devs realize simple things such as maps are faster for lookups (rather than looping over a list) and use them when needed, that's about all they need to know to get the job done.

I would also say that everyone ought to be able to come up with the brute force (slow) solution to the algorithm problems (at the very least) and then offer another solution that's still correct and somewhat faster. If you can do that, then most places will hire you (even if you can't think of the ideal solution in 20 minutes).


Edited: deleted. Somehow my post appeared twice.


I think the truth is the exact opposite: the biggest proponents of white board interviews are FAANG who have extensive data on the hiring process and realized that these interviews are the least discriminatory. 'Traditional' chatting or behavioral interviews are biased because the interviewers will often preder candidates they find likeable.


>I’ve been a software engineer and now architect for 15 years.

Can you do your work remote?


What’s leetcode? In my interviews they usually ask me to write pseudocode solutions to some fun, clever little problems. Like, one asked me to write a function to get the permutations of a list of arrays of strings. That one took me a few minutes to solve- should have been obvious but I did stare into space for a minute or two before giving the answer. I think I was just nervous. That was the hardest one though, all the others were easy. But you know, aside from just knowing what you’re doing I don’t know how you would grind to prepare for that.


I told myself: I spent years studying (mostly) irrelevant material in university, what is a few months' worth of evenings studying (mostly) irrelevant leetcode problems if it doubles my TC. Still, it does suck.


It is possible, you have to ask for it though.

I just did a round of interviews with offers over 100kEUR in GameDev working remotely. All British or EU companies. No leetcode questions, some did take home tests, some online questionnaires and most of them a normal technical interview talking about code.

I had a few companies reject me for the asking price, but that's fine, at least I knew I was pushing their limits. If we don't do that we won't get rid of the hand waiving excuse of salaries are lower in the EU (or in gamedev for that matter)


Judging by the sad state of Android, I am confident that the main cause is Google hiring people who grind Leetcode and "crack their interviews". So yeah It's necessary I would say.


From what I've seen, if the interview doesn't include leetcode like questions, the hiring company usually gives you a take-home assignment or a timed project through a web app. Companies will sometimes pay you to do the take-home assignment (rare from my experience) and give a deadline (but not always). For a particular company, both, the take-home assignment or timed online project, are usually related to the job. Try looking for a company that doesn't do "whiteboarding"?


I am a point where I context switch all the time, and find I look up the details for specific environments all the time. Because I don't have them all memorized. I have more important things to devote my abilities to, whatever they are.

If this is ever cause for filtering, that's fine. I'm not interested in the kind of environment that privileges memorization over thinking.

The details matter; but the details that matter are almost never (it not literally never) about the syntax of e.g. for loops in bash.


The business of leetcode depends on people thinking that they _have_ to use it.

I have a feeling that some content marketeers have been posting questions like this here and also on https://www.reddit.com/r/cscareerquestions/ just to give the impression that leetcode is some sort of industry standard, when in reality it is almost never used.


I landed my $bigtech work last year via a leetcode process but it was pretty lightweight and tasks were simple (I do frontend, maybe other positions have more difficult tasks). YMMV depending on company but don't assume leetcode = solving NP-hard problems.

Also pro tip: absolutely do a fake interview before with a friend before each step. You'll fail miserably and stress af, but it will give you point to reflect on and prepare for real one not to panic.


Saying "it's a crying shame that it's necessary" and saying "it's not at all necessary" are two different things. In this moment, you have to at least brush up on coding concepts you don't use at your current day-job (and might not end up using at this prospective new day-job) to be able to talk through some pretty arcane problems. Right now, it's necessary.


Hard to give a yes/no answer.

At one point in my career, I did the grind and it helped me land at FAANG.

Now I can land good jobs without doing the grind, but that's because I'm at a level where I could easily solve most problems without prep. (The key is to make sure you're being challenged and growing in your current role)

Further I can see myself doing it again in the future to hone my skills again as interviews continue to evolve.


I make more 100k per year contracting for a bank and I've never done a leetcode interview. I'm not in Europe though but I think I could actually make more there because my specialty is more in demand.

I suspect leetcode and whiteboard interviews are a way for Asians in the US to select for other Asians. Also more powerful HR departments leads to more "objective" and metrics-based hiring practices.


I live in Western Europe and got my current 6 figure 100% remote job or a US company with no leetcode, but the take-home assignment was quite long.


I think you would do better to apply for fully remote companies based in the US and avoid faang+ companies. Lot's of start ups and mid sized companies who are growing their eng team will pay you 100K+ regardless of where you are located if you can code well.

Look for anyone who had 50 million plus in funding. Look at every YCombinator graduate. Look at crunchbase. There are lots of remote job boards.


In Europe I have never encountered a leet code style interview; and I have interviewed with 30+ companies for a full remote role in the past 2 years. So far they have all been project based (these are the specs, produce a deliverable within one week and demo it). The only issue being that +$100K remote salaries are quite the unicorns in Europe. I've seen them go as high as $85k though.


Interesting, is there a website which offers a set of real dev problems to solve? Like, here is the IP of a prod environment, we are getting 500 with some combination of POST request parameters to this endpoint, the logs say there is something wrong with deserialization, integration tests are green, customers are screaming. This kind of things, not "find a sum of polynomials"?


A sequence of checks to arrive at the root cause of the problem can be represented as a path in (preferably balanced) binary search tree. Binary search tree is not a goal by itself, but a tool to build a mental model for a practical problem solution.

So at least to me "this kind of things" would be a superset of "find a sum of polynomials" and checking knowledge of a subset is a little bit easier.


> A sequence of checks to arrive at the root cause of the problem can be represented as a path in (preferably balanced) binary search tree.

Yes, probably everything in this world can be represented as a balanced binary search tree, who knows.


I know it doesn't directly answer your question, but there is a nice repository of companies[1] that lists their technical interview processes (take-home project, live coding exercise, etc).

[1] https://github.com/poteto/hiring-without-whiteboards


These conversations always seem to conflate different types of jobs into one. Are algorithms and data structures important if you’re creating backend services at Facebook? Probably. Are they important if you’re creating backend services for an internal app at your regional bank? Probably not. Most software jobs are more like the latter than the former.


I worked at 2 FAANGs for 8 years. I did not do a single leetcode problem on purpose. I read Algorithms by Sedgewick and How to Crack the Coding Interview. At least on 2 occasions the interviewer gave me a problem that was straight from the latter book and not an exercise, i.e. it was walked through step by step at the beginning of the chapter, and the rest were very similar to the exercises in the book, so I'd say it's not a requirement to go through leetcode, with the caveat below, but you should at least expose yourself to them.

In my experience interviewing, doing leetcode problems gives you a distinct advantage over people who haven't, like me. I did much better on problems that I have encountered in the books (even if I didn't recall the solution exactly) than on completely new types of problems, so, by induction, if you work through as many problems as possible you'll perform better at the coding interview (the leetcode-style ones).

That's the trick to performing well in these interviews. It's unlikely you'll come up with a double-pointer list traversal method in 30 minutes on your own (maybe with a lot of help from the interviewer), because that's a clever way of solving a problem and clever solutions are non-obvious by definition. It takes time to invent an entirely new solution in your mind, but if you know about it and other clever solutions like it, you have a bigger bag of solutions to match to the problem at hand, which is a distinct advantage when interviewing.

You could argue that you should be able to come up with a solution to these problems in less than 30 minutes all on your own, but when the interviewers are calibrated on the other people who have interviewed before you, the majority of which trained on leetcode problems, were exposed to that problem category and it took them much less time to solve it, then you look like an outlier, even if there's nothing wrong with your problem solving abilities. This translates to the interviewer expecting to work through 2 problems in the 30-40 minutes, because that's what the majority of his other leetcode-trained candidates were able to do, so you performed worse than your peers, even if you found the solution in ~30 minutes.

In my opinion, there's value in knowing about these algorithms, in general, to be able to recognize situations when they might apply, but there's little value in being able to know them all so well that we should be able to code the algorithms on a whiteboard under time pressure.


No, not at all. At least in Europe leetcode is what companies do when they hail from SV or, more commonly, are just cargo culting its culture.

In any case if you want to land such a job then there's one thing which helps tremendously, namely: immediate availability at the start of the quarter.

Q3 is an exception, because that's when everyone is on vacation.


> mostly because I know that I would panic and perform poorly in this kind of interview, so I don't really see the point of practicing for that

That disappears with practice. Just start slow, do a couple of easy leetcode questions a day until you are comfortable then move onto medium. You'll get there don't sweat it.


It's a quick and easy way to separate people who know what they're doing from those that don't.

If you know your field, then 'leetcode' is a non-issue, it's like asking a barista to make you a coffee.

The only people struggling and complaining are the ones that won't make the cut, and that tells you all you need to know.


Haha no.

It's a quick and easy way to separate companies who know what they're doing from those that don't.


No leetcode necessary. I landed a fintech job with a starting salary of 80k$ with a short get-to-know-you interview based on my resume and about 6 years of work experience. Other offers were in the ballpark of 40-65k$.

Edit: I live in a country with average wage of ~25k$. All numbers are pre-tax.


Couldn't companies just adopt strategies that have been used for "traditional" engineers for decades? Verify credentials and then for technical interviews discuss a potential proplem that could easily arise in detail and how you'd solve it.


I don't think remote has anything to do with it If a company does leetcode for remote jobs in 2022 it probably did it for "local" jobs pre pandemic.

It really depends on the company and country. Leetcode style is more prevalent in some countries then in other


Reading this made me picture a future in a few years where programmers grind leetcode for low-paying FAANG jobs competing against millions of new remote entrants into the job market for whom the salaries are worth it.


I have never went through leet code or any of those types and I’m self taught. I just tried (and failed) to build a handful of companies and the experience was enough to land me a senior engineering gig.


Startup Idea: Duolingo meets LeetCode: Interview prep that solves real world coding needs (for non-profit causes maybe?). Actually, I vaguely remember something about TopCoder doing similar.


The real answer is no, but after interviewing earlier this year the actual answer in practice is an astounding YES.

There are two options of leet code: some compound algorithm that you would never use in production coded live or homework conducted over 4-6 hours on your own time. Given the extreme subjectivity of software hiring I am not inclined to do either. The homework approach is far more practical and realistic but is a complete waste of time. Never do hiring homework without grading criteria supplied in advance.

There are far more effective ways of assessing competence with simple cognitive exercises unless you are in an area of software that doesn’t primarily favor competence, such as preferences towards tools.


Absolutely not! I got my current role by going in to an interview and critiquing my previous employer's architecture, data pipeline and (complete) lack of data oversight.


If you only want to make 80k, you definitely don't need to grind leet code. I've never done a single jot of leetcode, I make that much doing SQL and stats.


If FAANG world, yes. In most other areas of the economy, no.


I've asked potential employers not to do these because I think they are bullshit (in much nicer words) and they have been ok with that.


If I may ask, what country are you living in? Getting a salaried $100k without FAANG should be possible for every country in western Europe.


May be true for UK, France, Germany, Luxembourg, Switzerland, Scandinavia but everywhere else I'd say it will be very difficult.

I'm in Portugal. 100k is a mirage.


I know a FB dev, who did two months of such practice assignments before interviewing at FB.

He said, the actual interview questions were easy after that.


This might be an unpopular opinion, but maybe grinding leetcode for 2 months just made your friend a better programmer in general.

I’ve seen people on here say curious things like “I’ve been a software engineer for N years, but I wasn’t able to get past advent of code day 3”.

At a certain point you have to wonder if, no matter what they tell you, these people are just bad at programming.

That’s not to say they can’t improve, of course, nor is it saying leetcode is the best way to improve. I’ve never done leetcode myself, I can’t speak for it.


leetcode is about conformity

if you screw leetcode up, most likely the interviewer will dismiss you as not being serious

do you need to grind leetcode? or without grinding is it possible to land a job?

both depends heavily on the lineup of the interviewers on that day. everyone has a different interview style and strategy.

if you expect to get good/better pay, then grinding leetcode is actually ok, the roi is worth it


if you know you are going to get nervous facing those questions, it makes more sense that you spend time training and overcome it. Just for the sick of getting rid of anxiety, it would worth it, wouldn't it?


I interview quite a few engineers and have never heard of leetcode.


unpopular opinion:

the reason you should LC is precisely most dislike it.

that is why it is worthwhile


Absolutely not.

Search more, you will find 10-50 people companies paying way above the usual faang-style sweatshops.

Last couple of years crypto-hft was the place to be, but that's changing. Anyway, they are there. Do not conform or you become useless.


What's leetcode? /developer the past 23 years.


As an engineering manager this is a difficult one.

A developer who's excellent at leetcode really shines; it's a strong positive signal that correlates more often than not with someone who writes clean, easy-to-read and fast code. Furthermore, huge bonus points if they find learning algorithms fun because learning and enjoying code is, obviously, a big part of our work.

It also saddens me that so many developers (especially late in their careers) are stubborn about not learning these techniques ("I didn't get to be where I am now mastering recursion therefore it's stupid") which too often comes from an established position of privilege... This is very apparent when you compare to developers fresh out of university with little commercial experience; for them being good at algorithms is one of the few things - other than enthusiasm and side-projects - at their disposal. For that reason, leetcode is also fair you could argue; everyone gets the same treatment regardless of level.

However... a great many outstanding developers get flustered and tie themselves up in knots under interview pressure. If I went purely by "can this applicant perfectly solve this problem in 50 minutes" then I would be ruling out lots of really talented people. It also saddens me that early-career developers are being trained to just leetcode grind when what makes for a good hire (at any level) is someone who's endlessly curious and humble as opposed to being an algorithm beast.

It's tempting to think the solution should be a practical "make this app" test, but most highly-experienced developers can kick out excellent apps from muscle memory which tells me little about their ability to think on their feet, collaborate or learn new things. Furthermore if it's a take-home exercise, it significantly privileges those who have the freedoms to spend lots of time on it: e.g this could be a struggle for single parent families.

I recommend you watch Dan Abramov's fake interview on YouTube along with the two Ben Awad did to get some perspective on all this.

What we're currently experimenting with at Tipalti is pairing on a mix of some practical challenges and some algorithm challenges. The expectation is set that we don't care about completing, but more about how to solve the problem together. Everyone - including the hiring panel - are allowed to get confused and stuck and in a good interview session we'd all solve it together. The two sessions act as complementary bookend that gives a good feel for the candidate's range and approach.

Of course, it's not perfect by any stretch but like most things with engineering we keep an open mind try something new, get feedback then iterate. Always learning.


leetcode = i waste my time while other people land high paying jobs


I remember well an interview with a company where I was asked a lot of questions that pertained to scaling characteristics of algorithmic solutions. For example, I was asked to describe ways to implement a solution for determining all of the words that can be composed from a given combination of numbers. (similar to how early texting was done on flip phones with numbers but no keyboard) We talked about how a conventional lookup would entail 3 possible letters per key and that the order of growth for checking words in this fashion would be 3^n. I was asked if it could be optimized, and I proposed a sorted list of number combinations in which you could do a binary search on the number sequence and get all of the possible words. I explained that this would facilitate a single lookup in logarithmic time. They asked if I had other ideas, which I didn't, and they brought up the use of a hash. I hadn't thought of it, but that also made sense, as it would result in a fixed time lookup. (Not a major improvement over logarithmic time, especially at scale, but an improvement nonetheless.) We discussed a few other things, and all in all, it felt like a very good interview in which I thought I had demonstrated good working knowledge of the concepts they were asking about - and was comfortable doing so.

Then came the second interview. They asked me to, in real time, using a shared coding system, construct a javascript program that would, given any input string, print out a list of all the possible letter permutations. (eg. "abc" would show "abc", "acb", "bac", "bca", "cab", and "cba") The challenge didn't scare me, and I had an idea of what I wanted to do algorithmically. I certainly knew it would be a recursive sequence of calls moving along the string until it was done. Using the "abc" example, you'd rotate "a", "b", "c" into the first spot, then, with each of those rotations, you'd do the same on the next digit, and repeat until getting to the last character. When you get to the last character, on each rotation, you'd have a result, which you'd store. You'd then unwind back up the chain storing the results as you went along. So it involved a recursive sequence that was rotating letters in each spot and then on the unwind aggregating the results.

I sat there, with the interviewer watching my every keystroke as I put together a first pass that didn't work. I added some diagnostic output and worked through a few things. For some reason, the interviewer, apparently thinking I was "close", jumped in with a couple of things to change, which I did, but there were still problems. After about 45 minutes, he called the interview over. Shortly afterward, I got an email from the company thanking me for taking the time, but declining any further interest.

That evening, I sat down to write the exact program they had asked for. It took me the better part of two hours, but I got it working, and working well. Having no prior experience with this problem, I wouldn't have solved it in the time they were expecting. I was going to email my solution to the company, but I figured they'd just dismiss it and assume I had cheated, or, perhaps not be interested anyway since it took me so long.

To this day, I think the company misjudged me. I'm not one to produce rapid-fire, bug-free, algorithmically magical solutions in a first pass on the spot. But I do pride myself on the quality of what I write and how well I'm able to address and understand the very problems I was being asked about in a variety of contexts.

In this scenario, I felt that "leetcode" skills and speed were given too much weight over other factors including the thought process and eventual solution. I don't disagree with the use of some "leetcode" competency tests, but I think a company should be careful not to eliminate a candidate who doesn't sling code fast enough in an interview, particularly if, through probing questions, you can establish that they have a sincere and thorough understanding of the problems at play and how to solve them with code.

My two cents.


> Is the leetcode grind necessary to land a high paying remote job?

> Do you think grinding leetcode is an absolute necessity to land a good job at a company hiring worldwide remotely?

> ... western europe ... salaries around 80-100k$ ...

You've very clearly defined the problem, and I'd think the answer should be obviously "no". Are there any software engineers making that salary in that location who haven't ground leetcode (grinded?). I guess that term isn't very well defined, but let's be super generous and say it's spending more than 8 total hours practicing algorithms for the purpose of passing interviews.

So an equivalent question is "are there zero software engineers with a $100k salary in western europe who spent 0-8 hours practicing algorithms for their interviews?". I'm guessing if you asked that question you'd have a lot less "yes" on the poll.

Not exactly the best question though. It sounds like you're not categorically blocked from grinding leetcode. You have performance anxiety. Not diagnosing you, just rephrasing:

> it's not really about whether or not I can solve a hard leetcode problem, it's about if I want to do it live in front of a recruiter, it make me anxious just to think about that and I don't want to inflict that on myself

So is dealing with performance anxiety + the hours spent on leetcode worth the job? Is there another path to the job that's less work and/or higher probability? These are optimization questions. You won't get at their answers with asking about necessities.

My perspective is there are roughly three levels of algorithm skill that come up in interviews. First is the kind of stuff you really actually do on the job. A decent professional with a few years of experience should be fine with zero prep. FizzBuzz level, really. Level 2 is beyond what most people do in their jobs. Count the number of components in a graph. Really good engineers or people who practice will be able to do this. Level 3 is the stuff that just rarely comes up at all. Leetcode hard. Can't think of an example. Almost everyone needs dedicated work to get to this level.

I think level 2 and level 3 come up in similar proportion in interviews, and jobs that ask level 3 questions might pay a little better on average but not a ton and there's high variance. And, critically, getting to level 3 requires 10x the effort of getting to level 2.

With that framing, I think there is outsized benefit to getting to level 2. If anything, make sure your coverage of all possible problems at level 2 is great rather than go into level 3. Go for level 3 if you know you need to for a certain job, or algorithms is a strength you want to lean into. You should probably go for level 2.

Second piece of advice is you should split dealing with the anxiety and learning the algorithms. Think of them as separate problems, practice them separately. They can cloud each other. I've seen it so many times. The pain of performance anxiety will convince you algorithms are dumb and pointless and you shouldn't study since it has zero benefit. But it is benefitting you, it's getting you a job.

Anyway, you should probably just think of it as "practicing coding in front of people" instead of "anxiety". Not saying you need to see a therapist. You would probably do very well to try answering questions that are very easy for you, questions you already know the answer to, in front of someone. Maybe a record a video, maybe live stream it. Now you've separated the algo skill from the performance. Practice talking and coding alone. Separately improve the algo skill and combine them at the end.

Hope this helps.


You can get a remote job in your pay range for example in the UK, but I'll focus on the US market in my answer. (I'm a European developer, lived in the Silicon Valley for a while, and now I'm back in Europe, working remotely for an early-stage US startup, making a lot more than the upper limit of the pay range you mentioned).

First of all, $80-100k isn't considered a high pay in the Silicon Valley, but rather an intern salary. So $100k for a remote job is a reasonable ask, even at an early stage startup. In my experience, most of the small startups don't conduct interviews with an algorithm gauntlet like FAANG (or is it MANGA?) companies do; there could be some of that stuff, but not exclusively, and you're of course allowed to communicate that it's not your strong suite. The market to hire good developers is so tough right now, that smart companies are willing to cut you some slack on the "formal" knowledge part if you're able to prove you can be an asset in the "real world" for them.

In my experience, the biggest pain points in hiring Europeans are the time difference, bad English skills, and cultural differences. This varies a lot by company, so take it with a grain of salt, but here's a breakdown of these three things:

1. The time difference is what it is, so you might be required to work in the evenings with some companies. If you live in the Western Europe and work for an East Coast company, the time difference shouldn't be that big of a deal, as you can have a comfortable overlap in your afternoon and their morning. Eastern Europe to West Coast, on the other hand, is a 10h difference, so you might expect to work the late shift.

2. Language skills can be practiced. In your case, I'd say your written English is perfectly sufficient, but in case you're shaky on the spoken level, it might be wise to sharpen your skills there. You don't have to be on a native level, not even close (and Americans in general are used to immigrants and different accents and whatnot), but you don't want it to be a clear weakness either. As long as you're able to understand others and communicate your thoughts in a clear manner, you're good.

3. What I mean by cultural differences is that many European cultures lack the sort of self-promotional and positive aura that comes naturally to most Americans. If you ever visited the US, you know what I'm talking about. US employers aren't necessarily accustomed to reading people who aren't good at this, so it might throw them off. Being able to relax and smile and get past the usual small talk takes you a long way.

It might be easier to get into a company where there are other European remote employees already, as "offshoring" for the first time can be a scary thing for a small startup, especially if the candidate doesn't tick off all boxes.


Man, scrolling through this thread-- 100k a year is not gonna cut it for me.

I need 200k minimum these days and I would like to end up closer to 400k. Why? Houses in the area I want to live cost money, and these salaries may not be around forever. So extra money is needed for a cushion and for investments.

The dollar is weakening, and real assets/income-producing assets are only becoming more expensive. 100k is the new blue collar, sadly.


Reeks of privilege and lack of perspective.


I concede this, but it is true. It is a fact of nature that if I've purchased a house with a $5,000 mortgage, I must pay for it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: