When I was in college it was raining heavily outside, and I had to walk from the lab to my dorm at some point in the next hour. I started thinking about the secretary problem and derived the continuous case for it (surprise! It's 1/e) to figure out how long I should observe how heavily it was raining before I trying to head out.
I mention all this because modern hiring is nothing like the actual Secretary Problem, which is about when to stop given unknown information on future samples and a known retry limit. No one hires that way anymore, so I don't feel like the author side-stepped anything about it. I guess that doesn't matter, but it irks me as someone who's spent time on optimal stopping.
I interpreted hiring as optimal stopping problem because:
(a) we as hiring managers have no idea who's out there that we can hire and train for our requirement, and
(b) traditional hiring pipelines have a retry limit of zero; once rejected, rejected forever, and the open-door retry policy makes it infinite retries (after a cooling off period).
So the idea is to process applications as fast as possible to reject negatives and false positives, at the possible expense of some false negatives. And then try to defeat the downsides with the open-door / infinite retry trick.
That is certainly not exact science. Besides, I'm not a stats / maths / operations research person though, so I do accept I could be wrong. For now, I am okay being wrong because I hope to never have to hire anybody as an indie software builder :D
Yeah, your interpretation of the constraints of the problem are wrong, so the strategy of the secretary problem does not apply even for sidestepping it.
The very specific rules of the problem are that you are evaluating one person on a single metric, and you must choose to hire/reject them before viewing the next. You must know in advance how many people you will be evaluating. This is why it's the "secretary problem." You're interviewing 10 candidates and only evaluating them on typing speed. Once you see their typing speed you must hire or reject on the spot. The optimal strategy is to always reject the first 37% of your sample candidates, then hire the next candidate to beat their score (or hire the last person you interview if none beat them).
In college, we joked that this is optimal dating strategy, because dating still kind of works this way. You decide how high you're willing to go on your body count, and then use this strategy to decide who to settle down with.
As you describe it, (A) does not apply because it isn't about "the best person in the world" it's about the candidate sample you have. (B) doesn't apply because this is a post-hire rejection. You can keep your candidates "warm" and interview the entire batch, then decide among the batch who you want to hire, or not hire and continue.
It's a nice idea, but there's probably a better optimal stopping model than secretary problem for what you're doing.
madrox · · focus · HN ↗
I mention all this because modern hiring is nothing like the actual Secretary Problem, which is about when to stop given unknown information on future samples and a known retry limit. No one hires that way anymore, so I don't feel like the author side-stepped anything about it. I guess that doesn't matter, but it irks me as someone who's spent time on optimal stopping.
adityaathalye · · focus · HN ↗
I interpreted hiring as optimal stopping problem because:
(a) we as hiring managers have no idea who's out there that we can hire and train for our requirement, and
(b) traditional hiring pipelines have a retry limit of zero; once rejected, rejected forever, and the open-door retry policy makes it infinite retries (after a cooling off period).
So the idea is to process applications as fast as possible to reject negatives and false positives, at the possible expense of some false negatives. And then try to defeat the downsides with the open-door / infinite retry trick.
That is certainly not exact science. Besides, I'm not a stats / maths / operations research person though, so I do accept I could be wrong. For now, I am okay being wrong because I hope to never have to hire anybody as an indie software builder :D
madrox · · focus · HN ↗
The very specific rules of the problem are that you are evaluating one person on a single metric, and you must choose to hire/reject them before viewing the next. You must know in advance how many people you will be evaluating. This is why it's the "secretary problem." You're interviewing 10 candidates and only evaluating them on typing speed. Once you see their typing speed you must hire or reject on the spot. The optimal strategy is to always reject the first 37% of your sample candidates, then hire the next candidate to beat their score (or hire the last person you interview if none beat them).
In college, we joked that this is optimal dating strategy, because dating still kind of works this way. You decide how high you're willing to go on your body count, and then use this strategy to decide who to settle down with.
As you describe it, (A) does not apply because it isn't about "the best person in the world" it's about the candidate sample you have. (B) doesn't apply because this is a post-hire rejection. You can keep your candidates "warm" and interview the entire batch, then decide among the batch who you want to hire, or not hire and continue.
It's a nice idea, but there's probably a better optimal stopping model than secretary problem for what you're doing.