Opinion: Why universities are training industry-ready graduates

Otago University head of Computer Science Brendan McCane argues that employers need to think long-term when hiring

I sometimes hear that universities should be producing “industry-ready graduates”. I’d argue that we already do, but first I am going to apply a standard academic trick: redefine what “industry-ready” means.

Intuitively, industry-ready means able to work productively from day one, or in other words, creating more value for the company than the cost of salary. This is clearly an impossible goal to achieve since even experienced professionals need time to learn the foibles of any new workplace.

Once we relax the requirement of “productive from day one”, we are left with the goal of “productive in a short time frame”, and then we are left with the problem of defining what “short” means (week? month?).

However, in my view even this is the wrong yardstick for permanent positions. So what is the right yardstick? I think the same yardstick should be applied to all new hires regardless of whether they are graduates: “productive over their entire career at the company”.

Joel Spolsky has a great article about programmer productivity on his blog and he uses data from Professor Stanley Eisenstat’s third year class at Yale University.

The programming assignments are not easy (e.g. coding the LZW compression algorithm). If we only look at students with the top 25 percent of the marks, there is a 1.7 to 5.8 times productivity difference between the fastest and the slowest student.

If we look at all students, there is a 5 -17 times productivity difference. Keep in mind that this is Yale and we’re already talking about some of the smartest kids in the USA. But don’t think this applies just to students, numerous studies have found similar results for professional programmers and it is widely accepted as the 10X rule.

What does this have to do with industry-ready or graduate recruitment or recruitment in general?

Again, we come back to the notion of “productive from day one”. What I think people mean, in the context of programming, is that the candidate is an expert in “language x in environment y in application area z”.

This is what I see in the overwhelming majority of recruitment adverts (e.g. 3+ years experience programming C# on the .NET platform for banking applications). This is bone-headed recruitment exactly because of the 10X rule.

A good programmer is able to learn the basics of a new language in a couple of hours, become competent in a few days, and expert in a few weeks. Remember that a good programmer is 10 times more productive than a poor programmer, and five times more productive than an average programmer.

Even if it takes a month (20 working days) for the good programmer to learn the new environment (an overestimate), after two months (40 working days) they have already done as much work as a poor programmer who knows the exact environment working for 200 days, and as much work as an average programmer working for 100 days. Again, assuming 20 working days for the good programmer to get up to speed, the break even point compared to a poor programmer is 22.2 days and compared to an average programmer is 25 days.

Given these statistics, employers would be far better off trying to attract good programmers rather than just programmers with knowledge of the right language and environment. Of course, if you can get both, even better, but any advertisement needs to be carefully crafted so the good people are not put off.

What makes a good programmer? First, they have to love programming and probably program for fun as well as work. But they also: enjoy problem solving; enjoy learning new languages and concepts; and are independent and critical thinkers.

This is what I think “industry-ready” means. Coincidentally, these are exactly the sort of skills we teach at university.

How do you tell if someone is a good programmer? That’s a topic for another time.

Join the newsletter!

Error: Please check your email address.

Tags careers

Show Comments
[]