Self-learning is overrated (in programming) (October 10, 2010)

Few weeks ago I had series of interviews in two top-tier investment banks. I was applying for development position in similar departments, but the technology stacks those two banks were using varied wildly: from hardcore low-level multithreaded Java in one to Haskell/F# in another. The outcome of those interviews provoked some thoughts abouth whether self-education means that much when a well-paid position in a respectable company is at stake.

First of all, banks are always a good indicator of the position’s value in business terms. Startups may hire people to explore the previously unknown areas, to experiment with products that might have very little or no monetary value at the moment. To the contrary, banks are dealing with the established business models and are rarely tolerating even short-term decreases in the added value that every person brings to the company. They hire people to earn money for the bank, not to experiment, and they pay those people accordingly. This usually sets the interview direction from the very beginning.

I have around 10 years of industrial experience with Java, interruped by few years of enterprise C# development. So despite being exhaustive (two people on the other end of the phone line asking one question after another in the course of hours), interviews for the Java position went pretty smooth. How to implement a fair lock? What’s a GC generation and what are they used for? What would you do if you need soft-realtime Java system? How to avoid resource contention? Deadlock? Livelock? Can you implement locking without using synchronized keyword? Synchronized container that will use locking less often than a standard one? And so on and so forth.

Fortunately, most of those question constitute part of my day job, so it was nice to have this brain excercise. Not so with Haskell/F# interviews. I didn’t had a chance to gain any industrial experience with functional programming — I bet lots of people practically interested in FP didn’t. I was asked about type inference results for some specific function combinations, possibility of Haskell program to be as fast as C program, type covariance and contravariance in .NET, the way to control state and side effects with monads, existential types, a bit about the way Haskell supports multithreading, short “what is STM?”, and so on.

Shortly after the interview I found a polite “no” in my mailbox. I myself wasn’t satisfied with my performance, so this wasn’t a surprise. At this point I was happy that my experience with resolving all sorts of problems in the real industrial environment gave me a chance to learn what I know about Java. I felt what it is like to be in shoes of self-learner. One bright guy who fleed from the enterprise development to the AI-related work wrote this:

Learning AI (or any deep comp.sci for that matter) is not like learning J2EE or Ruby DSLs or whatever the fad du jour in the enterprise software world is — read a few chapters of the latest bestselling “pragmatic” book, write some crappy web site and hey presto you are the expert.

“Real” comp.sci doesn’t quite work like that

Real industry does not work like that too. I can’t imagine a self-learner to know the nuts and bolts of Java GC, just as I didn’t felt too confident about existential types. I simply never had an external pressure that would throw me into the necessity to know ins and outs of Haskell by heart, and pragmatic books (Haskell, as all you know, have one) no matter how good, do not help with that. Self-learner is like a fresh college graduate: he simply has to start his way from the lowest positions again.

No amount of self-learning can come near years of work in a mission-critical environment when company’s revenue is at stake.