Thursday 7 July 2016

Katie is also a Software Engineer...

The question came about how people who are, on paper, experienced software engineers at large companies end up not being able to write simple code in job interviews.

Everyone who recruits for software companies knows this happens -- stellar looking candidate; turns out not to be able to write trivial bits of code.

This had always slightly confused me until I worked at a succession of large companies...

The software teams work on a matrix management system with daily assignments. You arrived, found out which project you were on, picked up the work packet. In my case, I'd look at the trivial task, the gibberish that had been written for it, delete all the existing code, write the small section required, tag the work packet as completed and retire to the on-site cafe for an afternoon of "meetings"[1].

People who didn't finish the code simply let go of the work packet -- tomorrow they get a different one, possibly on a different project entirely.

The result? As a whole, the team (slowly) writes software -- eventually all the work packets will arrive on the desk of one of the competent developers and get done. So everyone on the team is a successful software engineer... Of course, writing software is very slow when the majority of the people aren't great[2]. So you need a lot of engineers. Since you need a lot, you can't pay very well... which means you don't get very many good ones[3].

Tada! An environment in which a lot of people work successfully as poorly-paid software engineers for many years but when asked to personally write simple code in the filtering for a better paid job screw it up.

And then (as was famously pointed out by Spolsky) they apply for ALL the better paid jobs; figuring that they're just "unlucky" when rejected so everyone interviews a ton of them plus a couple of good ones and hires "only the top 1%" which is how everyone claims to be hiring top-tier[4].

[1] No, you may not have a second work packet. No, you may not go home early. No, you may not fix other code. No, you cannot work on another project...

[2] Overheard conversations in the office included discussions over whether, when getting pointer related errors from the compiler, it was better to try adding more * characters or more & characters to make the errors go away...

[3] So... Why was I there? Well, mostly they were conveniently located and I was usually hired to try and improve productivity. That part I never succeeded at, because my 'suggestions' of firing, say, 19 out of 20 in each team of the -- successful, remember -- engineering staff and replacing them with two or three people on maybe 3x the pay were always turned down by HR people. Whose job positions are dictated by how many staff the company has, not how productive the staff are.

[4] You're not hiring the top 1% of the industry, you're hiring the top of the applicant pool -- which includes all the people everyone else didn't hire as well..


  1. If it's any consolation the most useless idiots getting hired/promoted is fairly universal. I work in the public sector; I'm sure we could cull many individuals without a significant deterioration in productivity, especially as most have jobs that have no real purpose.
    I also see lots of businesses; a lot of these run on the same principal of about 10% useful employees with 90% dross (the only appreciable skill being to write and talk bulls**t that makes them sound wonderful).