[ctvo]

I feel the same way about whiteboarding as I do about capitalism: It's not perfect, but what's a viable alternative? And like capitalism, it's a spectrum. Most companies could cut back on pure leetcode style questions, but ask something more practical that can still be whiteboarded in ~40 minutes.

Take home assignments, deep dive chats, pair programming, temporary contracts all have their own drawbacks. I've tried everything but temporary contracts.

We're measuring along a few dimensions:

- Can someone fake this expertise?

- What's it like working with this person?

- What's their general intelligence?

- What's the depth of their prior knowledge in computer science?

- What's the scope of the problems they've solved previously?

For both the candidate and the company:

- How long does it take to conduct the interview?

- How much money does it cost?

- How much legal resources?

You can assign points to each interview type, and at scale, I'd take whiteboarding over the alternatives.

[mountainriver]

Here’s a better one, show us your open source work. Don’t have any? No problem you can create some in the same time you would study for Leetcode but it would actually matter

[ctvo]

> - How long does it take to conduct the interview?

(for the candidate)

You're excluding a slew of people who either don't have the time or inclination to start and possibly maintain an open source project. The assumption here is leetcode requires an equal time commitment, but that differs greatly from person to person. This is very similar to take home assignments, but even more of a time / commitment sink.

They'd also need to pick an appropriate project that demonstrated the technical depth and scope an interviewer would be interested in. You're also hoping the interviewer will do an appropriate deep dive into the code base to understand it and judge it correctly. Finally, you can't be sure the person actually wrote the code. I know it sounds ludicrous, but I've seen outrageous things people have attempted to know it's a legitimate concern.

[mountainriver]

> You're excluding a slew of people who either don't have the time or inclination to start and possibly maintain an open source project.

And leetcode isn't excluding a bunch of people who don't have time or inclination to memorize puzzles?

> They'd also need to pick an appropriate project that demonstrated the technical depth and scope an interviewer would be interested in.

Then build useful things, this is how the world actually works

> You're also hoping the interviewer will do an appropriate deep dive into the code base to understand it and judge it correctly

Thats always the case with every interview style

> Finally, you can't be sure the person actually wrote the code

You should be able to tell this easily by talking to them about it. If you're at all unsure, dig deeper on why they did things, someone who didn't write it wouldn't be able to answer hard questions.

[isbvhodnvemrwvn]

It's also impossible to compare candidates if you are hiring for dozens of openings at the same time.

[mountainriver]

Interviews are always biased, chances are dozens of candidates wouldn't get the same puzzle, and dozens would get different interviewers that help them in different ways, and the candidates may or may not have the puzzle memorized which has literally nothing to do with their actual skill.

Everywhere else in the world, when you hire someone, you ask to see their previous work. It is universally the best signal, you don't have a carpenter build a chair on site, you look at what they've built and talk to them about it. And you certainly don't ask them to build a chair in a style they have never done before, you just see if you like their style.

[ctvo]

> Everywhere else in the world, when you hire someone, you ask to see their previous work. It is universally the best signal, you don't have a carpenter build a chair on site, you look at what they've built and talk to them about it. And you certainly don't ask them to build a chair in a style they have never done before, you just see if you like their style.

This analogy is flawed. Software engineers work in teams on any project of worthwhile complexity, even open source ones. It's not simple to parse out what your contributions are.

To validate expertise, universally, everywhere else in the world, many professions have licenses, certifications, and governing bodies. They rarely take your word for it. See lawyers, doctors, civil engineers, dentists, architects, etc. etc.. Software engineering has none of these things, and until the field matures, we use adhoc methods. From prior experience, I disagree that the best method in finding competent engineers is to simply talk to them about projects. This is easy to fake, and you may even have colleagues you've suspected of doing so.

[mountainriver]

Having someone walk through their open source work is not easy to fake, reading someones PRs and comments is not easy to fake. And its real life work not some memorized puzzle nonsense

[warrenm]

sorry, but creating some open source work doesn't "matter"

If anything, I'd rather know that your side projects/hobbies aren't work-related :: it signifies breadth of character and intellectual curiosity

[mountainriver]

what? creating a useful project absolutely matters to the world a lot more than memorizing some leetcode problems

[warrenm]

Who said anything about a "useful project"?

Just because you spend 100s or 1000s of hours building something and releasing it on GitHub doesn't inherently make it "useful"

You might spend 30 minutes and it be "useful"

Or 10 years, and it be not "useful"