[hnfong]

I don't see how your method works better than a sieve with noise.

Instead of a "noisy" sieve, you're just using the time of application as your sieve. Which, unless your job opening values the skill of submitting lightning fast job applications, is pretty much 100% random noise.

You say a sieve approach drops the best candidates. Your approach also drops the best candidates.

And if the bar is actually so high that only the best candidate(s) qualify for the job, then your approach would imply you interview an expected half of the applicants before you fill the positions.

It's pretty obvious a "noisy" sieve (with some signal) is better than sieving by application time or sorting by arbitrary order and taking the top N applications. You don't have a magical solution. The people handling those 100000 applications are not that stupid.

[lordnacho]

The difference is that you don't need to wait for 100k people to show up.

If you're already reasonably confident from the first batch of people what the potential in the pool is, why would you wait? People have work to do and they want those people in as early as possible.

I'm not saying you will do much better sieving by time, in terms of quality. But you will save all the effort of looking at the people at the back of the queue, for little loss.

Sure, half the best people will be at the back, but what is your loss on taking the second best people earlier? Chances are you won't even be able to tell.

[dahart]

If the problem is having to wait for applicants, then you’re right; stopping early will help. In my experience, companies already do what you’re suggesting simply by having a deadline or time window for filling a job. Even if a lot of companies would love it, most job posts don’t get over three thousand applicants per seat available.

In this particular case, MS didn’t have to wait for people to show up, they got 100k candidates before they could have even made a decision on a small subset. And in general, the problem being discussed in this thread isn’t having to wait, it’s how to deal the flood of applications coming in too fast.

* huge edit to this comment after this rattled around my head a little more: actually, duh, sieve and early stopping are completely orthogonal, this is not an either-or situation, and you are probably assuming a sieve in your proposed approach. You can sieve 1 candidate at a time, since it’s a series of criteria ranked in order of how much time each one takes to evaluate. If someone doesn’t meet minimum requirements, they’re rejected quickly and not invited to interview. If you’re going to stop early but you have a lot of candidates to evaluate, then you still have to sieve. Like, I’m pretty sure you’re not proposing to conduct 37,000 interviews for 100k candidates, right? Even if we stop before looking at all candidates, each candidate will have some early criteria used to cull them, and only the ones that pass all the early criteria are invited for an interview. That’s true whether or not we stop early. The sieve is a given and unavoidable. The only question is whether to stop early, which we would only do if it solves a problem. We can, if we want, interview the same number of candidates either way. The sieve allows you to look at all candidates efficiently, but does not require it. If you do look at all candidates, then the more people in the top of the sieve, the statistically better the final interview pool will be. Stopping early is valuable only if the applications process is slow (which is not the case here) or if the early criteria take significant time to evaluate.