[kevinstubbs]

The best hires I've ever made have started submitting code reviews within 24-48 hrs of being onboarded. Sure it's not for something like Microsoft Windows, but still this has been a hallmark positive indicator of a good hire for me, and applicable to many (but not all of course) frontend, backend, and app development projects.

Now maybe there is some discussion to have about what "100% efficient" means. Of course they will not hit their peak of productivity on day 1, and anyways if 100% efficient means the most productive day they've ever had, then they will more days than not be < maximally productive.

[balabaster]

I would wager your codebase, tests and development environment reflects this. Any product of any significance requires a day of setup at least before you even get as far as cloning the repo and opening your first user story.

[kevinstubbs]

Well, first of all, ouch. Sure, of course you're right about "product of any significance" and I mentioned one myself in my post - Windows. The more complex the project/team is, the fewer people will be productive in 24-48 hours. So yes you can arbitrarily set the bar as high as you like for what "significant" means for you to be correct.

[makeitdouble]

I think it's not a bad metric if you have hired someone fitting right into your current stack.

Now I am sure you had cases where you hired someone that didn't quite fit, but seemed interesting, and you were confident they'd get up to speed and pull their weight in a reasonable time frame (3 weeks ~ a month ?).

I'd argue focusing on the second category of hires as a target, and consider it a lucky event when someone exactly matches what you're doing, can lead to a more stable/less homogeneous team.

[kevinstubbs]

That's a fair point. In the life of my startup so far, we haven't been blessed with the room to allow us to hire people that we don't think will be productive for a month. For an established company though, I agree it's a totally reasonable measuring stick for good hires.