[balabaster]

Nobody can be 100% efficient from day one, because even with all other things being equal, the new guy still has to learn all the idiosyncracies of your existing codebase (which is quite likely full of technical debt and poor decisions), your team, your process, your management style, your politics.

Realistically, even the basic "we want someone that's 100% efficient from day one" is the most unreasonable expectation you can have as a hiring manager, and is usually the one spurring the "high quality candidate shortage" complaints.

[avgDev]

IMO, if someone thinks you are going to get much work done the first week they are out of their minds, or their software is a trivial console app contained in handful of classes.

I could probably jump into a new position and start cranking out code fast, but it would be different than any code in the existing code base, and could apply techniques not used by anyone on the team. This would result in an awful piece of code to maintain for the team.

There are just so many different ways of writing code that a dev would probably need a few weeks to get comfortable with the code base. I speak openly about this during interviews. One interviewer from a fortune 1k company said I would be given about 6 months to get comfortable with the code base and start with smaller tasks. Another company said I would be building trivial things for a few weeks before touching the codebase.

Unless it is a fresh project there is no such a thing as jumping in and cranking out code day 1.

[saagarjha]

I've written code on day one at some positions. Usually it's something simple like a bugfix or refactor, but it is certainly working code. Of course, most of the time I spend doing this is figuring out how to work with the codebase and how to submit my changes.

[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.