I've never worked for a company that trained programmers. You ether knew what you said you knew, or you didn't. Management would weed out the imposters in the end.
What about things people they say they don't know. You can't expect everyone to know everything. You definitely want people to work on things after company's has taken them on onboard.
They varied. The one I currently work for is fairly large (~300 people in software and product, which constitutes maybe 1-2% of the total number of employees). I've worked for larger and smaller companies, though.
The company I work for now actually has fairly long tenure times, 4 years or more. There really isn't an expected ramp-up time. Each project handles onboarding their own way. "Hit the ground running, learn as you go." is pretty popular.
Maybe so, but I've never worked for a company that trained programmers. It was always assumed that the wonderful open office plan will facilitate the transmission of tribal knowledge like that.
I have only seen software training twice in my career.
At Travelocity I became a developer because I was involuntarily reclassify into development. If I wanted to keep my job I had to learn it. Any time tough challenges came up I was expected to train myself and figure out how to do it the right way. Copy/pasting from an external source or hoping some framework/tool would do my job for me were unacceptable. This line of thinking evaporated the moment I separated for a military deployment.
At Bank of America they will pay for you to attend some boot camp class about using some framework.
In absolutely every other case you were expected know what you needed the moment you walked through the door and there is never training or any other kind of professional growth once you get there. If you want to get better or learn some new school you are writing code on your own outside office hours.
That sets false expectations and bias in hiring and candidate selection. If you look at almost any posted developer open rec the listed qualifications are usually a list of tools, frameworks, and languages. Rarely is the list of qualifications specific to skills or performance.
The expectation is to hire a tool money that can turn a figurative wrench instead of an engineer who can create a more powerful/efficient system. The bias kicks in during candidate selection. The company knows it needs a capable candidate to be selected for the given set of requirements but there is no formal industry guidance to define any kind of baseline.
It's not unheard of for small startups to have no training beyond "here's your email account and here's our repo". Sometimes you don't even get a company laptop.
It's not ideal but when everyone is swamped and pulling founders hours it's not exactly abnormal.
"Hit the ground running" is fairly common in startups as they don't have the resources to train.
I shortlisted a candidate once who clearly was an experienced developer, but because he didn't have any JavaScript experience, the CTO discarded his application. Very shortsighted but his argument was "We don't have time train people and JavaScript is a very popular language"
