I've hired several engineers who get productive within the first week. Most manage to get in a PR and deploy to production by the end of the first day.
If it's taking a few months before the candidate can get productive, something has gone horrifically wrong.
There's a big difference between "deployed their first PR" and "getting productive." The latter implies the engineer knows or has figured out how to use your source control, CI, and deployment processes. That probably is something most people can manage in a day, with proper instruction, provided the code change itself is simple enough. The latter means they're familiar with large parts of the codebase and are able to make changes, and have an idea how the major parts interact. This is what takes a few months.
It's also a good sniff test if you're interviewing. Slow and steady might be up your alley too. There's definitely a hierarchy of security and compliance needs depending on the org, but many orgs loose the forest for the trees.
Agree 100%. And in most cases it probably isn't a problem with the candidate. It's a problem with the existing software and development process. It shouldn't take someone months to become useful on a new project.