Google needs More Rigid Hiring Practices (cause their developers suck)

Apparently all of Google’s developers suck:

Despite attempts at education, our developers regularly write loops that retry indefinitely when a file is not present, or poll a file by opening it and closing it repeatedly when one might expect they would open the file just once.

Developers rarely consider availability. We find that our developers rarely think about failure probabilities.

Developers also fail to appreciate the difference between a service being up, and that service being available to their applications.

Unfortunately, many developers chose to crash their applications on receiving [a failover] event, thus decreasing the availability of their systems substantially.

A word of advice… Just make your hiring practices more rigid. Google is apparently at 10 interviews now. Just make it 20 and you’re future developers will be twice as smart!

I’m feeling a bit of schadenfreude on this one.

Update:

In case it wasn’t obvious I was joking about Google developers sucking :-). I just think its amazingly funny that the authors of this paper had to spend nearly an entire page explaining how bad their developers were.

Update:

There’s a serious lesson to be learned here…

In Transparent Batch and Stream Operations in Distributed Systems I talked about the problems I’ve run into in the past with high performance APIs. The problem is that you have developers who are only loading Javadoc and assuming that all method calls are instantaneous and that the system will be online and available 100% of the time.

This is seldom the case. Calling a method might result in a network fetch which might take from 1-20ms to call. If you exec that 1000 times you have one slow web service.

The problem is that the guys who wrote that Google paper were experts and you can’t build an army with all Generals (which is a quote taken from the Art of War).

While I was at Rojo I failed to impress upon our Engineers the difficulty in building scalable/distributed systems. It wasn’t their fault – they were smart guys. The problem was that they were working at a very high level and the underlying system was failing them.

Google has done a great job in building systems that scale with very little work. I’m amazingly jealous of Bigtable and Map/Reduce and I seriously think they help developers within Google build fast and scaleable systems. The problem is that apparently even with these advanced tools developer education is still a major problem.



%d bloggers like this: