posted: March 17, 2018
tl;dr: It matters more how fast one learns than the knowledge that one has...
Having been part of several high-growth companies, I can truthfully say that I have interviewed over one thousand candidates and have hired hundreds. Hiring great people is one of my strengths. One of my proudest career accomplishments is to have hired at least six people (perhaps more, I don’t keep tabs on everyone I’ve ever hired) who have themselves gone on to become Vice Presidents of Engineering or similar VP-level technical roles. I was able to recognize their potential early in their careers, and others eventually also recognized their talents.
I have already given away some of my hiring secrets. See:
It is now time to give away my #1 hiring secret: hire the candidate with the highest first derivative on the graph of knowledge over time, even though that candidate at this point in time may have less knowledge relevant to the job at hand than other candidates. In simple terms, in the graph below, my preferred candidate would be Candidate B:
There are several reasons for this. First and foremost, hiring is (ideally) a multi-year decision: you want the candidate to be successful over a multi-year period, not just in the first six months of the job. In technology, the world moves very fast: new languages, frameworks, tools, infrastructure, etc. are constantly being developed by others and introduced to the world at large. Although there are long-standing design principles that will remain universally true over time, a large fraction of the specific technical knowledge that anyone in the tech world has is going to become obsolete or less important over time. To keep your company’s technology from becoming obsolete, it is best to have people who are able to learn and become productive in new technology quickly.
Even at the very beginning of the candidate’s work period there is going to be a gap between the candidate’s skillset and the specific technology stack in use at the company. Everyone is going to have to acquire some amount of new knowledge in order to become productive. You want people who can quickly master the company’s version control system, deployment pipeline, coding standards, and internally developed tools and processes. You actually don’t want people who only know one way of doing something and are hesitant to change.
If you can find the fast learners, and give them a little more time up front to close the relevant knowledge gap, you’ll be much better off in the medium and long term, and probably even the short term. The question then becomes: how can you measure learning ability? Another term I sometimes use for this is “raw intellectual capacity”. A careful reading of the candidate’s resume, combined with some probing during an interview, can provide a good assessment. Has the candidate shown a history of learning new technologies and concepts quickly and doing different types of projects, or has the candidate been using pretty much the exact same small set of technologies and been doing the same types of projects for years? Don’t be fooled by candidates who sprinkle their resumes with as many technical acronyms and buzzwords as possible: probe on a few and see if they’ve really developed a mastery of those topics.
Companies often ignore learning ability during hiring, especially when they list requirements such as “ten years of SQL database experience”. I’m not knocking experience (I have plenty of it myself), but it doesn’t take ten years to master SQL; a candidate who attained an equal mastery after two years is almost certainly a faster learner. In fact if a candidate has been doing primarily SQL and little else for a decade, it may demonstrate an inability or lack of desire to learn new technologies. Of course, that may be what some companies are seeking: someone who has been happy doing SQL for a decade and who wants to do SQL for another decade. That company and candidate, however, run the risk of becoming technically obsolete.
Please don’t interpret this guidance as meaning that companies should only try to hire young hot shots early in their careers. There are plenty of experienced candidates whose track records show a long-term ability to learn and master new technologies. I like to think that I myself fall into this category. These can be some of the best people to hire, because then you get a wealth of experience about good design practices coupled with a proven ability to learn new technologies quickly.
Although the following analogy isn’t perfect, because the world of technology changes faster than the baseball world, there is a good parallel with MLB teams’ prospect rankings. It is almost always the case that a team’s top-ranked prospects are not currently playing at the highest level of minor league baseball. At initial glance this may not seem to make any sense: shouldn’t the best prospects be the players currently playing on the AAA team, one level below the major leagues, as those players have the highest current level of skill? But what the scouts and others who determine those rankings are doing is not measuring each player’s current skill level; they are projecting forward in time and determining which players are on the steepest growth curve, and may therefore be most likely to develop into stars over time. In other words, they are looking for those candidates with the greatest first derivative on the curve.