Sometimes it takes 15 years to put it all together and figure out what the lessons are. This is one of those cases.
I was ready to quit my first job in January of 2001, having been working for Scient, the “eBusiness systems innovator,” for a year and a half, and foreseeing the decline in the quantity of business. I started hunting for a job and found a very interesting company called Kenamea, which had been founded by the team behind Weblogic and was building a cool technology to do real-time messaging for webapps – something like what we know today as AJAX and websockets. My first interview was a phone screen with a guy who went to the same high school as me and graduated a few years after me.1 I figured I had it in the bag.
Then he asked me one fateful question:
How does a classloader work?
I had no clue. I had not written a classloader, so I had no practical point of reference, and I hadn’t learned this type of thing in college, so I had no academic framework to fall back on. I’d really have to bullshit my way through this one. So, I gave it my best shot. I cannot remember at all what I said, but I know I didn’t do well, because I ended up making a passionate plea afterwards to give me another shot.
Lesson #1 (in two parts)
In many ways that question is biased and unfair. My interviewer, Michael, had worked on the internals of Weblogic with the inventor of it. He probably wrote several versions of classloaders for it. I had 1.5 years of application development experience, none of which had needed to get down into the bowels of the application server itself.
It is important to find the extent of a candidate’s knowledge and experience, but Michael either misread or ignored the context of my experience at the time and blasted me with a pretty deep question right off the bat. I have done the exact same thing in interviews that I have conducted, so this isn’t an indictment of him. Unfortunately, it is easy and rational to use a question you intimately know the answer to in order to form an opinion of the interviewee, but it can also make the interview into a battle of ego. Now when I interview, I try to take the interviewee’s experience and context into consideration and ease my way up to the “hardest” questions, building a foundation of trust so the candidate is more comfortable as we progress through the interview.
From the other side of the table, I totally botched the answer. I could have done a much better job if I had just said, “I do not know. I’ve never written a classloader, and I haven’t yet run into a case when I needed to know how they work. I’m pretty good at reading documentation and understanding code, so I have faith that when I decide to dig that deep into the environment, I will be able to understand how it works.” That would have been a totally honest answer. It would have given Michael a perspective on my experience as an app developer, not as a framework or server developer. It would have given him an opportunity to follow up with a question about one of the times I did need to understand something more deeply and to have me explain that experience to him.
Lesson #2
With a little bit of revisionist history, I can say that it was at that moment that I decided to become the best software engineer I could and to deeply learn the environment I was working in, the tools I had at my disposal, and the theory behind how it all worked. In truth, that was maybe the case subconsciously, especially given that I still remember the experience 15 years later. But the conscious experience was me grovelling for a job, getting an offer to be a test engineer, deciding that was beneath me, and taking an offer at a spin-off from Autodesk that then laid me off six months later.2
Fortunately, that gave me an opportunity. While working at Buzzsaw, there was a book lying on someone’s desk titled “Java Performance and Scalability: Volume 1 – Server-Side Programming Techniques”. I decided to read it cover to cover. By the time I finished chapter 11, which is a step-by-step case study of building and optimizing a web server, I had learned so much about the JVM, threading, and performance tuning, I was astonished by how little I had known beforehand. I’ve kept up that practice of reading technical books like this cover to cover, even without having an immediate need for the knowledge held within. Many of these books have helped me level up my engineering game throughout my career.
Failing that interview set me on a path of continual improvement. I may have found that path some other way at another time in my career, but it was the right opportunity at the right time, and I am thankful to Michael, even if it took me 15 years to figure it out.