Why would companies prefer a single experienced engineer over several entry level trainees?

Question

Possible Duplicate:
How can I overcome “years of experience” requirements when applying to positions?

Over the last decade or so of browsing online 'engineering' job postings, I've noticed that the vast majority seek applicants with 5+ years of experience. But with both youth employment as high as it is - and so many people seeking career-transition into engineering - it would seem that companies could hire 2~3 entry-level trainees to do a job for (possibly) less than the cost of recruiting and paying that one purple squirrel with 5+ years experience.

For jobs that absolutely require top-level performance, I can see that market forces might shape those labor markets into a small set of elite members (i.e. professional athletes, CEOs, brain surgeons); but is this also true for engineering?

Obviously companies want the best employees they can find, but the engineering labor market still seems really imbalanced: why would a 'process engineer' or 'quality engineer' with 5+ years experience (for example) be that much more attractive to a hiring manager than an entry-level trainee?

Answer 1

The answer here is fairly obvious when you think about.

Consider the benefits of hiring an experienced software engineer.

• They require very little additional training and can be brought up to speed in a matter of days or weeks at the most. Basically, they will be a net contributor as early as the first month (i.e. the work that they do more than offsets the work required by existing staff to to get them up to speed).
• They bring in new knowledge and new insights. And it is practical knowledge, they've learned it by using it in the real world.
• You know what you are getting, at least to some extent. Between recommendations and projects they can show off, experienced developers have a track record.

None of this applies to fresh-out-of-college recruits:

• It can take months before they no longer require assistance from other staff for day-to-day work. During the first month or two they may in fact be a net deficit as the amount of work they produce may be less than the effort put in by existing staff to train them.
• While they may bring in some academic concepts, they rarely have a good grasp on how to translate them into workable solutions.
• Academic performance is not a good indicator for workplace performance (it isn't useless, but it says a lot less than actual experience).

** A caveat here, there are of course prodigies, these will usually be discovered during their academic career and be recruited long before they graduate. My comments are on the "average" graduate. **

By this I am not arguing that hiring inexperienced people is bad. But it requires that you have the capacity (in terms of existing staff, time in schedules etc.) to train them. As they are cheaper and easier to find, if you can manage the process you can potentially make hiring a lot easier. But it requires a long term effort and there is always the danger that once they have acquired enough experience that they'll move on to other companies.

So, given all the uncertainties and expense of hiring someone with little or no experience, is it any wonder that companies go for the more experienced developers?

Answer 2

I think there are some good points here for entry-level workers who are finding it hard:

it would seem that companies could hire 2~3 entry-level trainees to do a job for (possibly) less than the cost of recruiting and paying that one purple squirrel with 5+ years experience.

Well no, not really. Bringing on new staff is rarely just about the bottom line of salary, there are usually a number of benefits, and those per employee costs are often similar for an entry-level or more experiences employee. Also there are kit costs, training costs etc, which are usually the same no matter what the level.

Obviously companies want the best employees they can find, but the engineering labor market still seems really imbalanced: why would a 'process engineer' or 'quality engineer' with 5+ years experience (for example) be that much more attractive to a hiring manager than an entry-level trainee?

I'm hiring because I need someone now, I only have time to show him how WE work, not how to do the job or use the technologies. Entry-level hires usually have significant ramping up until you get to a productive point.

Also the situation is being made worse by the major universities (at least in the UK) who are becoming more and more out-of-touch with what businesses actually want.

Sure you may be a coding deity who can do the really hard stuff, but the fact of the matter is I need someone who won't take 6 months to do an over-perfect job, can talk to, and negotiate with the business on stories, can be trusted to make reasonable decisions based on experience, and keep me in the loop so we don't get issues biting us.

Most universities are driven around some purest thing, and have little time for teaching survival in the workplace, so most entry-level folks I see want to sit on their own (or telework at different hours to the business), and make career choices based on dress code rather than the team they'll be part of. Meanwhile my schedule is floating off into the sunset as no-one is actually burning down stories.

Now this isn't intended as a rant. I have mentored a number of new engineers over the years and quite enjoy it.

When I started (a long time ago now), you would come into the workplace as a new recruit, the job would be to get a spec for some task (software dev), which you would write, unit test and check-in, and Uni courses were fine for that. These days devs are expected to be agile, use TDD etc, but the unis are still teaching as before.

This is something that could easily be done in a course setting, the course I was on still (in the early nineties) managed to have assignments where the lecturers played roles, and we (as self created teams) needed talk/interview them to gain requirements and work out what was actually a priority to the assignment.

I think the problem stems from the fact that given all the money spent on higher education, the system needs to promote a competitive atmosphere. Modern teams work in a collaborative way, and that can be a huge shock when you've been doing it all yourself.

Answer 3

A few points:

1. Overall productivity can vary greatly among software developers. The number that's get often tossed around is 10x, i.e. a star programmer can be ten times more productive than a "so so" guy. See for example http://blogs.construx.com/blogs/stevemcc/archive/2008/03/27/productivity-variations-among-software-developers-and-teams-the-origin-of-quot-10x-quot.aspx. This doesn't even account for programmers with negative productivity, i.e. people that generate more bug fixing work than usable code.
2. The total out-of-pocket expense for the company is actually not that different. In terms of base salary the difference between a rooky and a senior/principal level guy is maybe a factor of two. However, there is a lot of overhead that's not dependent on salary: health and other insurances, IT infrastructure, licenses, space & facilities (rent, food, toilets etc.), benefits, etc. which are charged per head regardless of salary. This makes the actual difference only about 50% or so.

So the best choice for most companies is to hire the best person they can get their hands on for that particular job, pretty much regardless of cost.

Interestingly enough seniority doesn't correlate particularly well with performance. I've worked in organizations where the worst Engineer Vs were considerably worse than the best Engineer IIs. However, some level of experience makes the interview process easier and you can look at actual results that the candidate has produced in a comparable environment.

Since good people are hard to find, larger companies have a certain incentive to build their own talent internally. Many of these companies have "college recruitment" departments that will specifically handle college interns and recent grads. Often these are "subsidized" by some general fund in the company, so that the business unit isn't initially burdened with a low productivity contributor during the training phase. Granted, with the economic crisis of 2008, a lot of these programs have landed on the chipping block. There is no point in creating the starts of tomorrow when today's survival is in question.