Guy Kawasaki nailed it when he said “Good people hire people better than themselves. So A players hire A+ players. But others hire below their skills to make themselves look good. So B players hire C players. C players hire D players, etc.”
Mark Zuckerberg recently added a wonderful corollary, when he was asked how he decides whether to hire someone. He replied “I will only hire someone to work directly for me if I would work for that person… It’s a pretty good test and I think this rule has served me well.” I dub thee the Zuckerberg Test.
As someone who has hired many Data Scientists (and, sadly, fired a few), when I heard Zuckerberg’s statement, it strongly resonated with me. Which got me thinking about why exactly it resonated, and what specific advice I’d offer you if you are in the process of hiring a Data Scientist. Of course, you could simply apply the Zuckerberg Test by gut feeling during the interview process. But we all know how often impulse buying is followed by regret. So I’ll share some interviewing practices that I’ve found can provide the kinds of insights you need to rigorously apply the Zuckerberg Test.
Let’s suppose you are leading a Data Science team, and you are interviewing people for a role on your team. Take a moment, and actually do the thought experiment: What kind of person would you want to work for? Make a list of the characteristics that would make them appealing. We’ll all have different lists, but I’d wager that technical skills won’t dominate any list. And that’s the beauty of the Zuckerberg Test. Put bluntly, who cares if your co-worker is an A player technically, if they are also an A-hole personally. Life is way too short.
Here’s how I would answer the question:
- They know the techniques of Data Science. In particular, they know the theory behind the techniques. So when I need to bounce an idea off them, we can have a deep and meaningful discussion. They have some serious intellectual horsepower.
- They know the tools of Data Science. They are self-sufficient in accessing, manipulating, and analyzing data. So they are not going to be leaning on me to pull data for them, etc. And they are not religious about the use of SAS any specific tool.
- They can think at different altitudes. That is, they are equally comfortable dealing with both the big picture and the fine details.
- They are superb communicators. They explain their ideas clearly and succinctly. They ask others for input. They listen carefully. They build on the ideas of others. Their presentations are not death by powerpoint.
- They can give and take criticism well. They don’t get defensive when you challenge their ideas. In fact, they welcome input, and see how they can weave it into their ideas. Conversely, they are not afraid to challenge your ideas, but they do so gently.
- They are confident but not arrogant. They ask for help when they need it. When they don’t know something they just say so. They don’t fall in love with their own ideas. They are not territorial. They value and celebrate the contributions of others.
- They get things done. They collaboratively create thoughtful plans, communicate them to others, hustle to get resources, and then execute. They are organized. They strongly favor simple and elegant solutions over complex ones. They don’t need to display their technical prowess just for the hell of it.
- They make the people around them better. They love to learn and teach. They are patient when explaining things to others.
- They are fun to be around. They don’t take themselves too seriously. They smile and joke easily. They have a rich life beyond the office. They have an infectious enthusiasm for the work. They are relentlessly positive. Remember, you might be spending more time with this person than with your significant other. Make sure that time will be enjoyable.
- They don’t freak out when things go wrong. Who wants to work for someone who is constantly in a panic?
As I said, your list of characteristics will be different from mine. But how can you best screen candidates for the characteristics that are important to you?
Most Data Science interviews feature whiteboard sessions on the technical aspects of the role. That’s fine as far as it goes, but I’ve found that two additional interviewing practices are hugely helpful for gathering the kind of input you need to rigorously apply the Zuckerberg test.
First, there is the full-day case study as the final step before the candidate is offered the position. The candidate arrives at your office in the morning with their own laptop, or one that you provide them for the day. You also provide the candidate with a dataset, an open-ended business challenge, and an Internet connection, and then leave them to their own devices, with the only requirement being that they present their final product at the end of the day.
The case study materials will ideally be a sanitized version of a real dataset and a real business challenge from your organization, but in a pinch there are many resources on the Internet that you can use to construct a suitable case study e.g. www.data.gov, www.kaggle.com, etc.
Part of what you’re testing with the case study is the candidate’s adaptability and ingenuity. Will they ask clarifying questions during the day? Maybe you purposefully withhold important information. Will they creatively use all the resources available to them? For example, will they download open source analysis tools from the Internet? Or, will they ask online forums for help if they are stuck on some technical point? Heck, I personally wouldn’t care if they payed someone on eLance/oDesk to do work for them! I’m looking for creativity and persistence as much as anything else.
The culmination of the case study is the presentation at the end of the day. The final product, the presentation, and the Q&A, all provide incredibly useful insights into the candidate. But you also get insights from the process the candidate used during the day to arrive at the final product.
Preparing and facilitating the full-day case study certainly takes much more effort on your behalf than the stereotypical just-turn-up whiteboard session. But hiring is the most important job of a leader, and hiring the wrong person can be worse than hiring nobody at all and maybe losing that headcount.
The second interviewing technique is the much-misused behavioral interview. Admittedly, this can degenerate into farce if the interviewer asks idiotic questions e.g. “If you were a can of soup, what kind of soup would you be?” But I’m talking here about posing questions of the form “Tell me about a time when…” which force the candidate to dig deep into their experience. But this too can become Kabuki theater if the interviewer simply regurgitates the standard twenty behavioral interviewing questions, while the candidate responds by regurgitating their twenty prepared answers. Instead, your questions should probe for the characteristics on your list. For example, “Tell me about a time when things completely fell apart around you, how you responded, and what you learned” may help you see if the candidate is prone to freaking out, but more importantly to gauge if they are self-aware enough to admit such a frailty. Self-awareness is golden.
I hope this article has given you a couple of ideas that you can try in your own organization, perhaps starting with small-scale, low-risk experiments. Feel free to reach out to me if you have any questions. And, as always, I’d love to hear about your thoughts and experiences!
Thank you Mr Zuckerberg for your most excellent Test!