[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