In most firms entry level employees don't bring much to the table except their ambition and raw ability. The actual skills they develop are usual acquired on the job and specific to that firm and/or industry. For example, if you were hired as a logistics trainee, most of the skills and protocols you use would be acquired at work and usually could not be developed beforehand.<p>However, in most technology firms relating to developer/engineering positions it is expected that the candidate would already have a firm grasp on the technology he would be using and the only on the job skill development that would occur would pertain to that specific firm's projects. For example, if a firm had a job opening for a Ruby on Rails programmer the candidate would be expected to already know quite a good deal about RoR and he would not expect the firm to give them basic training on RoR.
<i>Smart</i> tech firms are willing to hire experienced developers who can learn new stuff in a reasonable amount of time. There tend to be or should be limits, e.g. back in the '90s it really didn't tend to work to hire a non-OO programmer to work on an OO language project, because they had to learn a new paradigm as well as the more minor details of a new language (which if we're talking C to C++ isn't that big to begin with), unless you were willing to wait something more than a month for them to be productive.<p>It would be interesting to look at the hiring of companies that do functional programming. A new employee how didn't at least take SICP or one of its functional derivatives would take a while to learn the new paradigm.<p>And there are many tech companies that simply can't do anything other than train new employees because they're just not going to find anyone who's up on their technology. Before the mainframe alternatives to IBM all but died and UNIX took over the midrange companies doing anything other than IBM mainframe work generally would have to train their new employees, e.g. Honeywell didn't expect new Multicians to be productive until at least a month had passed.<p>Today's greater standardization allows what you're talking about ... which many people think is also commonly a sign of poor management, specifically the manager who doesn't believe he has the ability to mentor those under him or even be able to judge their progress in coming up to speed. Heck, how many companies even ask prospects to <i>prove</i> they can program (e.g. FizzBuzz), let alone program in the language/framework in question?<p>In general the state of the art in US IT industry management is <i>dreadful</i> and you can't particularly afford that in a field that's so difficult and unforgiving ("Can't fool Mother Nature" sort of unforgiving).