Experience Doesn’t Matter (…As Much)

People gasp when they hear me say it. Or at the very least, they roll their eyes. “When hiring,” I say, “prioritize experience below most other things.” Or, more bluntly, “Experience doesn’t matter nearly as much as you think it does.”

I’m not talking about personal experience, the ability to learn and improve from our own lived successes and failures. In fact, as I’ve written about before, personal experience (particularly of the negative kind) is one of the most valuable teachers we have.

Instead, I’m talking about placing former work experience on a pedestal when choosing who to hire.

Flashback to 2015: My early startup days, attempting to build the world’s greatest and fastest team. At Anchor, we were building products in the audio space and so were naturally inclined to look at resumes that included words like “audio”, “radio”, and the like. My cofounder and I had not formally come from that world. We needed team members who would bring that DNA into the company.

Hindsight is illuminating though, and I now see a pronounced pattern that emerged over years of hiring, managing, and promoting: Those people who were most successful, who made the biggest impact, and who most directly influenced our journey were (nearly, for there are always exceptions) people who had virtually no relevant experience working on things like what we were building.

The Fundamentals

So, if it wasn’t experience, what was the common thread among those who flourished? To answer that, I want to go back a bit further in time.

In 2011, I had a first (and only) round interview for a software engineering role at Google. I’d spent weeks preparing for the sixty minute call. And when it came, I hopped on the phone, spent a few moments talking about my background, and then was asked to solve a single question:

“Write a program that, given an array of N numbers, prints the product of every combination of N-1 numbers in that array.”

For the non-technical, here’s what this means: Say you’re given a list of numbers. For instance, a list of three numbers might be 1, 2, and 3. Now write some code that spits out what happens when you multiply each combination of two numbers (three minus one). So, in our example, it would have to calculate: 1×2, 2×3, and 1×3. Simple enough.

What’s hard about this question is that, because you don’t know how long the list of numbers will be, it’s surprisingly hard to write an algorithm to solve it.

Young Nir spent virtually the whole hour struggling to answer the question to no avail. And in the last three minutes, the interviewer showed me the “trick” that, once apparent, turned this from a very difficult question into a shockingly trivial one. I won’t spoil the trick here.

I got off the call as did many people who interviewed with Google during that time: confused and frustrated. What possible relevance could that question have had to my job there? Wasn’t I applying to be a web engineer? Why not spend the hour asking me questions about HTTP and Javascript functions? (The more famous example of one of Google’s “puzzle interview questions” is hilariously captured in this scene from the movie The Internship, starring Vince Vaughn and Owen Wilson.)

It wasn’t until I started hiring engineers myself that I realized what this was all about. The goal of the Google question was not to assess my experience. It was to uncover my process of thinking and problem solving. There are millions of people with “relevant experience” to particular problems. But there are not many people with the fundamental skills needed to solve any problem.

And so when I began conducting my own interviews, I developed a similar mentality. The people I wanted to hire were not those who had done similar work. I wanted to hire those who could jump into the unknown with curiosity and excitement, who could navigate tricky problems not because they’d seen them before but because they hadn’t. (There’s one interview question—not the Google one—I’ve asked every single engineer at Anchor. It has little relevance to the specifics of the job but tells me a lot about how the candidate problem-solves. I won’t reveal the question here, because I still love it and use it to this day.)

Most of the people I’ve hired because of their experience on paper didn’t work out. Not just engineers, but all roles. And most of people I’ve hired because of their fundamental problem solving skills did work out. The distinction is simple. Startups have very little time and resources to focus on the wrong thing. But it’s impossible to predict what they will need to focus on (I’ve written before about this fascinating phenomenon, the Startup Uncertainty Principle). So don’t waste energy and precious hires on what a person has done in the past. It’s 97% irrelevant to what they will be doing in the future.

My philosophy on hiring is this: Great employees understand fundamentals. The rest, they can learn on the job. Don’t hire engineers who know Python. Hire engineers with great foundations, because they can learn any programming language. Don’t hire designers who have experience creating products like yours. Hire designers with great innate design skills, because they can apply those concepts to any type of product. Don’t hire marketers who have marketed similar brands before. Your brand is different. Hire marketers who understand how and why marketing works at its core. Then task them with a problem they’ve never seen before.

The Drawbacks of Prioritizing Experience

That’s all great and good, but to say experience doesn’t matter is a bit extreme, isn’t it? I don’t believe it is. For in those hiring processes that allow former work experience to play much of a role at all, some shrouded but damaging consequences begin to take form.

• Focusing on experience reduces the candidate pool - Hiring is a numbers game. Why reduce the eligible candidates to those who have worked in particular industries or have specific buzzwords on their resumes? Most of the successful business leaders I know did not start their careers in the same places they ended up.

• Focusing on experience assumes the past repeats itself - As I mention above, when it comes to startups in particular, most problems are new. Most situations are unique. Yet the more applicable someone’s past job is, the more likely they are to fall back to what they know. There’s comfort in familiarity. In my experience, employees who frame every challenge through experiences they’ve had before are unlikely to appreciate and navigate the nuances new challenges contain.

• Focusing on experience masks other weaknesses - I’ve been in the room with panels of people choosing whether to hire individuals after interviews. And when a yellow or red flag is brought up, someone often attempts to explain it away by focusing on an impressive resume. “Sure, they didn’t get that question right. But look what they did at their last job!” The problem: the question they got wrong in your interview is much more relevant to the open role than whatever they’ve accomplished before.

That last bullet reminds me of the interview skills of the great Michael Scott from The Office. I figured that would be a good place to wrap up:

P.S.

If you enjoyed this article and are not yet a subscriber of this free weekly newsletter, consider subscribing to Z-Axis by clicking here!