Google's hiring process is supposed to be a utopian system for identifying superhuman staff. Yet it needs a surprising amount of correcting. And we're trying to figure out if this "stage 2" interview test also needs fixing.

Sent in by the friend of an ultimately unsuccessful Google applicant, the test was supposed to be completed by the applicant within three days. It asks for a response to an imaginary request from an imaginary Google manager, for an analysis of whether the company — "Poogle," not Google, mind you — can hire 750 engineers in six months to launch a new product within 12 months (click to enlarge):

This is a terrible question. The only issue is whether it is an intentional one, designed to test the applicant.

It's terrible because doubling the number of engineers on the sort of product Google makes — software — emphatically does not make it ship faster, certainly not within the first six months of their work, and certainly not at the scale of 750 engineers.

This has been widely understood among software managers since the publication of Frederick Brooks' Mythical Man Month in 1975. As blogger and former Microsoftie Joel Spolsky summarized the thesis 25 years later:

When you add more programmers to a late project, it gets even later. That's because when you have n programmers on a team, the number of communication paths is n(n-1)/2, which grows at O(n2).

From Mythical Man Month:

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true for... picking cotton; it is not even approximately true of systems programming.

When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many woman are assigned...

Since software construction is inherently a systems effort — an exercise in complex interrelationships — communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men then lengthens, not shortens, the schedule.

Even when a software team can benefit from some organic growth (as opposed to Poogle's doubling), it's going to take on the order of six months just to get the new people up to speed on the existing code base and trained in corporate peculiarities, which at Google are significant due to the scale at which it operates (Ken Thompson, legendary co-creator of the Unix operating system and inventor of Google's new Go programming language, still isn't allowed to check in code there, having failed to jump through the requisite hoops, he recently said in the book Coders at Work ).

So "Poogle" shouldn't be asking whether it needs to hire more recruiters to add 750 new programmers to "Product X" in six months; it should be asking whether the feature list for Product X should be trimmed, the deadline lengthened or a subset of it easily split off into Product Y.

But maybe Google is asking candidates to come up with that answer on their own. Whoops.

Supporting documents supplied as tabs to the test:

This one goes on; we've cut it off:

(Top pic: Google co-founders Larry Page and Sergey Brin. Getty.)