Look for strong math backgrounds. Data science requires a background in mathematics – this is really not negotiable. We made some mistakes in the past finding candidates that had strong software backgrounds, but didn’t really have the necessary math fundamentals. What happened? The software team didn’t have a strong appreciation for the data-crunching algorithms being developed, so there was a divide within our team; it became harder for the scientists and the software engineers to work together to achieve common goals. Knowledge of statistics, linear algebra, calculus, geometry, and trigonometry are baseline requirements. I’ve even heard stories of a company (not ours, thank goodness…) that had a programmer implement algorithms incorrectly, and didn’t really appreciate what was being done. An algorithm that used the sum of squared values was implemented by squaring the sum of the values, because it ran faster (by the way, these two algorithms are not the same!) This is a simple example, but if your implementation team doesn’t have a strong math background, they might not know the difference, causing you real problems down the road.
Seek the willingness to program, not necessarily specific languages. Here’s the heretical statement – don’t pay as much mind to the actual programming languages someone has on their resume. They need to have experience programming and show that they can get their hands dirty with coding. However, data science is about learning and discovering; you need to be flexible. So, look beyond the recitation of R, Python, Pig/Hive, C/C++, Perl, MATLAB, IDL, SQL, SAS, Java, Unix shell, Ruby, Scala… Any good scientist who is willing and able to program can pick up a new language. It’s much harder to get someone who knows the ins-and-outs of a particular language to be a good scientist. Keyword searches of résumés targeting specific languages may exclude some strong candidates, while also including others that are weak yet know what to put on their résumé. Manual review can lead to the same result, since if you’re looking for Hadoop experience, you may hire that and onboard a less-than-stellar data scientist in the process.
Make sure candidates have a probabilistic/statistical view of the world. In data science, nothing is black and white. Data has two driving elements – the behavioral (characterized by what we know – our model for how the data is observed) and the statistical (everything else that we currently don’t understand). The job of the quality data science team is to characterize the behavioral and deal with the statistical. As your team gets to know the data better, they will find even more subtle drivers and nuggets of information, turning what used to be statistical into a more accurate behavioral model (this is the cool part of data science – amazing predictive ability!). Candidates must have an appreciation for a probabilistic view of the world, meaning that when a certain condition occurs, you expect the data to appear a given way with some probability (or only some of the time). A background in statistics is an absolute must in data science, so look for that on the résumé and test for it in your interviewing. With that said…
Look for people who are detail-oriented and want to get to the root cause. Statistics come from the lack of information about what drives the data we observe, which you can get at when you have more data. Sometimes there is a real root cause to what we see, and good data scientists try to figure out why. Technical staff members that aren’t detail-oriented tend to make more mistakes than others who are, leading to inaccurate results and incorrect conclusions. I’ve seen really smart people find some very confusing results in their data analysis and be stumped as to what it was. When we looked into it further, it was merely a bug in their algorithm (not necessarily in their implementation) which led to some subtle errors. A probabilistic view of the world is important, but having a taste for getting to the bottom of things is equally as valuable.
Find people who can communicate effectively. An often overlooked quality for data science candidates is top communication skills. Even if someone is working alone on their data analysis, they have to communicate with someone, whether that is his boss or her colleague; no one works alone. I’ve written several articles about the importance of communicating (such as What We Can Learn From Stephen Hawking, Why Scientists Are Lousy Communicators, and tips on Job Interview Presentations), and it becomes especially important for those in the sciences. Math and science geeks think presenting is merely for marketers and sales people… Not so! If you want others to believe the results of your data science teams, your team has an obligation to communicate effectively.
Include your current scientific staff in interviews. We know that hiring is the job for managers. However, including your current staff in the interview process can yield real benefits. It can ensure that new candidates will be good fits for the organization and can even improve the company. In his 1998 letter to shareholders, Jeff Bezos, CEO of Amazon, detailed three questions that were asked of his hiring teams when evaluating candidates. Here’s what Bezos wrote about these questions:
- Will you admire this person? If you think about the people you’ve admired in your life, they are probably people you’ve been able to learn from or take an example from. For myself, I’ve always tried hard to work only with people I admire, and I encourage folks here to be just as demanding. Life is definitely too short to do otherwise.
- Will this person raise the average level of effectiveness of the group they’re entering? We want to fight entropy. The bar has to continuously go up. I ask people to visualize the company 5 years from now. At that point, each of us should look around and say, “The standards are so high now — boy, I’m glad I got in when I did!”
- Along what dimension might this person be a superstar? Many people have unique skills, interests, and perspectives that enrich the work environment for all of us. It’s often something that’s not even related to their jobs. One person here is a National Spelling Bee champion (1978, I believe). I suspect it doesn’t help her in her everyday work, but it does make working here more fun if you can occasionally snag her in the hall with a quick challenge: “onomatopeoeia!”
Bring members of your current team in with the understanding that you’re looking for people who will make their team better, and the help from your current staff will be valuable in assessing talent.
Don’t get so hung up on brainteasers – whether they can or can’t answer them. I know that some companies like to put candidates on the spot and get them to solve brainteasers during their interview. Personally, I find this to be a waste of time and an inaccurate way to tell whether someone will work well as a data scientist on your team. Some people need a little time to work through a problem, but if they have that time, they nail it. Others get to the right answer by trying out many things, learn from their mistakes, and hone in on what works. Brainteasers would make these candidates look like they can’t do the job, so they’d get weeded out. Plus, if someone happened to solve a brainteaser quickly, it may mean that they’ve been exposed to that particular before, which is why they know it so easily (for example, here’s one: For any prime number p > 5, show me why p2-1 is divisible by 24…). You aren’t hiring someone who can solve the problem – you are hiring someone who can find the solution to the problem. They may solve it themselves (which can be especially important when the problem has never been solved before), but if it has been solved, why would you want someone who is predisposed to solving it over again? Instead…
Ask open-ended questions that provoke how people approach problems. There is a great book, Are You Smart Enough To Work at Google?, which details how Google evaluates candidates for their teams. There is even an insightful question they have asked: You are shrunk to the height of a nickel and thrown into a blender. Your mass is reduced so that your density is the same as usual. The blades start moving in 60 seconds. What do you do? (How would you answer this?…) For their interview process, Google posts on their website how they approach it and what they look for. They generally look at four elements:
- Leadership. We’ll want to know how you’ve flexed different muscles in different situations in order to mobilize a team. This might be by asserting a leadership role at work or with an organization, or by helping a team succeed when you weren’t officially appointed as the leader.
- Role-Related Knowledge. We’re looking for people who have a variety of strengths and passions, not just isolated skill sets. We also want to make sure that you have the experience and the background that will set you up for success in your role. For engineering candidates in particular, we’ll be looking to check out your coding skills and technical areas of expertise.
- How You Think. We’re less concerned about grades and transcripts and more interested in how you think. We’re likely to ask you some role-related questions that provide insight into how you solve problems. Show us how you would tackle the problem presented–don’t get hung up on nailing the “right” answer.
- Googlyness. We want to get a feel for what makes you, well, you. We also want to make sure this is a place you’ll thrive, so we’ll be looking for signs around your comfort with ambiguity, your bias to action and your collaborative nature.
Use a group interview process when possible. Having an interview process that is back-to-back-to-back-to-back one-on-one interviews leads to repeat questions, making it tiring for the candidate. Additionally, when the interviewing team gets together to discuss the candidate (if they do at all), each member has a different perspective on the candidate because different questions may have been asked and different answers might have been given for the same repeat question. When you have multiple people (four to six) hearing the same thing as part of a group interview, you can get a better feel for the person coming on board. The information is the same, but different people pick up on different things, so it gives the team a more well-rounded perspective on the candidate. Something to keep in mind: These types of interviews can be intimidating for someone being interviewed, so it’s important to establish an environment of trust from the start. Make them comfortable so that you can get the best out of them.
Look for people that can tell you what they’ve learned, not just telling you what they did. Machine learning algorithms are great at exploiting separations in data. But, why are we looking for separations in data? To make better decisions with that data. The tools of data science are important to know, but if we don’t look for the “why” in the data science we are performing, then we are just using tools for the sake of using tools. Just because someone is an expert in hammers and nails doesn’t make him a carpenter. Extracting information out of data is all about context – what question are you asking of the data, and what drives what you see? This is about understanding, forming hypotheses, drawing conclusions. If a data scientist starts down the path of “we used this algorithm and the metrics came out like this…” without giving you some context or understanding of what it means, then you and your team could run into problems down the road (overfitting, building models that aren’t robust, etc.). It’s the difference between hearing about what you did on your summer vacation and what you learned on your summer vacation. In looking for what makes a good data scientist, DJ Patil talks about storytelling – the ability to use data to tell a story and to be able to communicate it effectively. Data scientists need to understand what they are trying to communicate and let their data science help them tell that story. No one really wants to hear what you did on your summer vacation, but they may want to know what you’ve learned and how you learned it.