Sweet pitch and of course a genuine problem. But companies have very limited resources and they use them at elite schools which have already stringent requirements to get in. Alternatively, I now see most companies are giving a hackerrank test as a start irrespective of your school. I guess this is a starting point to avoid the bias towards top schools.

First, I know this isn't a black or white issue but the problem I have with this is that I'm wondering if they are hiring people with the skills they want or are they hiring people with the skill to succeed in their test.

In theory, they should be the same. In practice... I don't know.

Where is that?

> We are not a software company so we do not use deep algorithm testing as part of our evaluation process [...] My experience has been that of that candidate pool, we will have 3-6 candidates with well documented programming projects or job experience. These tend to be the candidates we interview - we use a simple rubric with yes/no for 5-10 categories we evaluate

You should try it. Right now it seems you are skewing toward hiring folks who already have experience vs fresh grads for entry level positions.

Whiteboard, if done right, gives a chance to college hires to prove themselves. Especially if there are other tech companies in the area. The pool of candidates that have one year of experience and are already looking to jump ship is very different than fresh grads (where everyone is looking for a job).

Genuine question here: what's the better way?

I'm not a fan of whiteboard coding challenges, even though they got me my first "real" Bay Area tech job.

On the other hand, take home challenges eat up a lot of time and credentialist filters like going to a name brand school (or even having the right major) filter me out.

My go-to for when I'm in a hiring position again would be recommendations from my personal network, but that has its own flaws and doesn't scale very well.

I think at the core of the problem is that most companies are extremely risk adverse in their hiring and would gladly miss a Jeff Dean type of super-performer in order to reduce their number of bad hires.

Can you speak to that a little? I'm reading it as either programming challenges in a real environment, or analysis of previous code snippets submitted. In either case, I'm happy to see more companies doing this.

I'm always looking for ways to improve my interview skills, but I want to do it honestly. Studying to the test isn't fun for me, I would rather hack on something.

That's true, but it is meant as a different filter when applied to a large number of candidates.

I went through a bunch of leetcode style interviews last year with some very odd interviewers - the oddest was a Sr Principal engineer asking me to manipulate linked lists with recursion.

And the comment he made after I wrote the code was that "We don't care if you write code at work, but we want to know you like writing code enough to not see it as beneath you to do. To make sure you're not some whiteboard architect, because everyone you are supposed to lead will be writing code."

I had been looking at the interview as a sort of idiot catcher before that point, but suddenly it seemed like a good filter for respecting the effort at the lowest level of the profession.

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.

The problem is 99% (or more) of the rand-o startups/companies that do this are not Stripe. They are not companies that people are fighting to become employed at.

> this works out for me > their ability > how they communicate > how they approach > how they seek help

What's ends up happening is you miss out on a lot of truly talented folks by putting the burden of proof 100% on them.

> is the easiest way to filter out a lot of unqualified candidates

It may be the easiest way for YOU. It's an important distinction as you (and this is not a personal attack, sorry if it sounds like it is) may not have the hiring skillset. It is a skill. Just like managing people, supporting software, being a CEO, etc...

That's what recruiters do when they use leetcode-type problems as their first interview to filter out the bulk of their applicantions.

thanks, it means a lot you trust my ability so much :)

>All have PhDs and yet they’re all facing delays when landing a job. There is something definitely broken.

Everyone agrees it's the leetcode interview format. I agree to some extent, but I wouldn't throw it out completely. For me, I give four problems, and the candidate must solve two of the four with full internet access in an hour. It seriously reduces interview day variation for good candidates. If they can't do graphs but can do text formatting, they get a pass. I'm sure there's still some better way of doing this.

Inreviewing is expensive. I think coding tests are a strategy to make it more expensive for a candidate.

Even if you are one of the best, getting a single offer can be full 2 days work - if you count the time spent searching, applying, etc.

I'd love to have a standard test for software engineering jobs that was accepted in the place of building yet another 8-hour sample React app.

I think that would be misusing this approach.

We build recruitment software.

The recruitment process is a funnel. At each stage, the employer tries to weed out the bad candidates. Simple maths says they try and use cheaper tests early on in the process when there are more candidates.

For example, first stage is often eyeballing the resume and a quick search on GitHub/SO. 5 minutes, costs say $10, weeds out say 65% of candidates.

At the next stage, we use a more expensive test, since we have fewer candidates to filter.

This particular test sounds like it would sit after an initial phone screen and before a team interview in terms of cost.

Personally I would only use it after a first interview, or tell the candidate that you will decide immediately after completion of the first interview whether it was successful, and if so send them away to do this project afterwards,i.e. reduce double handling

well, welcome to software engineering. The interviews are for the reason, they let you peek into your future job. If you can't manage that environment for 4 hours of the interviews, how you're expecting to manage it for many years if/when you get into software engineering?

I'm not trying to be mean, i'm just warning that something like having a fresh out-of-college arrogant Millenial reviewing your code means - well suffice it to say that at my previous job it drove 6 out of 8 person team in 1 year, all from mid to senior engineers, me being 7th, to either change the team (3) or leave the company (4). The guy is a pest, smart, driven, high GPA from top University...

OP said "just about every other skill that is needed to be a good software engineer", for which leetcode is useless.

Communication skills, organizational skills, hell, even general knowledge isn't covered by leetcode-like interviews.

Personally, speaking as someone who doesn't like but has to interview potential hires, I have found that there is zero overlap between people doing well in leetcode interviews, and hires doing well in their first year.

> If one could do better hiring at the same cost or less, the whole industry would be interested

I think this is a naive perspective. If there is any takeaway from the recent wave of layoffs, it would be that company wide decisions may be driven by factors that have no relation with actual financial performance. Google could have kept all these engineers and still make an absurd profit.

The notion here is that some company, at some point in time, started putting their applicants through these kind of puzzles, and it became trendy.

Hey, I had a similar experience with Google! It was my first technical interview for my first job out of college. The interviewer laughed at my code, and then after going through the logic said "Wow I can't believe this actually works."

Personal grievances aside, I've come to think that the Leetcode interview style has morphed from a "let's see how you handle problems at scale" test into an ego-driven hazing ritual. My biggest gripe is that Leetcode is systematically favoring candidates who have months of free time to memorize arbitrary logic puzzles. It makes me sad for the less privileged candidates who might be working a job while also trying to break into the IT field.

Yes, but what it is not is economical. There's a huge dropoff in the interview funnel at this step because it's largely not worth the effort for the interviewee. The choice is between spending 5-10 hours per take home test per company or spending 5-10 hours a week studying silly whiteboard exercises that apply to dozens of companies.

It's also just as uneconomical for the interviewer. I've completed about a dozen of these tests over the last year and only one company bothered to look at the test after I sent it in. Which makes sense; it takes time to look at a lot of code, figure out which of it is boilerplate and which of it was written fresh for the test. And even then, there's no guarantee somebody else didn't write it. And while you may not be interviewing with hundreds of companies, most companies easily get hundreds of applicants per position these days.

For whatever reason, it doesn't seem to be worth anybody's time to do these tests. This bums me out because I'm terrible at live coding tests. But, this is the reality of the situation, so I have to adapt.

I've grown to learn that it's important to understand that interviewing in particular and job-seeking in general is not an objective and impartial process, and the output is not deterministic or reproducible. You can be hired even when there are objectively better people in the race, and you can be sidelined right on the phone screening even though you are the ideal candidate. It's a crapshoot, and the only people claiming otherwise are motivated by a mix of survivorship bias with a need to avoid recognizing that the process is flawed by nature.

> I’ve also interviewed and rejected experienced candidates who talked a great game but couldn’t demonstrate the ability to code FizzBuzz-level problems in any language.

I'm afraid that this take is also a reflection of the cargo cult mentality that plagues recruiting. I personally know FANG engineers with half a dozen years of high-profile work who had to spend weeks training coding golf and algo&data structures trivia before passing the first round of interviews, all because these trivia games bear no resemblance with real world software engineering. In fact, I will go as far as to claim that they serve more as ladder-pulling than actual technical assessments. For example, once I was automatically rejected from a C++ position to work on a desktop app because I wasn't familiar with placement new. This also extends to framework tests. I know a guy who applied for a backend position who was rejected because even though he rolled out a Spring service from scratch that passed all integration tests, the interviewer complained about how the service did not commented the controllers. These are things that takes a single comment in a PR to address. I mean, is adding a comment w challenging technical feat? But somehow some interviewers reject candidates based on this nitpicking.

This is irrelevant. No interview can accurately reflect actual job behaviors.

Job interviews are a proxy. Either they produce false positives/negatives or they don’t. It doesn’t matter that the proxy isn’t 1:1 with day-to-day.

I sympathize with job seekers dealing with leet code interviews. But I’m somewhat over the million blog posts that say the same thing. I’d be much more interested in hearing from the other side. Hiring is a nigh impossible task. People rarely share reproducible alternatives. Only hand wavey gut checks. It’s unfortunate this is the best we’ve come up with. Hiring is hard!