This is the short version of how to find a job. You can read my entire series here for a longer one.
Point 1: Set an amount of new people you can reach to a day
I recommend 4-5 people a day; 2-3 if you already have a full-time work.
->) This refers to starting a conversation, including people like recruiters who reach out to you, but not a follow-up with someone who you have been talking to for a while. ->) When someone recommends you talk to someone else, I usually count that, but it’s up to you (like later rounds of a job interview may not count; a judgement call). ->) Finding a job is a marathon, not a sprint. Snowball (aka increasingly exponentially): Talking to people leads to talking to more people, who recommend talk to more people. It may take a few weeks to build.
Point 2: Set an amount of jobs to apply in one day
I recommend applying to 10 jobs online a day.
->) For online job applications, quantity over quality works better, because of the way that the internet gamifies applications. Now, many applications won’t get back to you, so you have to apply a lot. It used to be the case that you might hear back from 10% of online applications, but the percentage may be even lower now. ->) Easy apply on LinkedIn is your friend. ->) Many job application platforms like LinkedIn notice that you are applying to jobs and are more likely to put on top of the list for recruiters looking for roles. Thus, sometimes quickly applying to many jobs on them in itself is a good thing even if you aren’t interested in those specific roles. ->) This is more important than applying online. Usually I find about two thirds to three quarters of my interviews are from networking connections rather than applying to jobs online.
Point 3: Reach out to people to talk to them
->) These are the best people to reach out to in order, those most likely to get back to you: 1) People you know and the people they know (friends, family, acquaintances, former classmates, etc.): Ask people you know if they know anyone in the fields you are interested in. Studies show that those most likely to coordinate a job are technically not friends or family but the acquaintance your friend and family members knows from “the whatever” two years. Ask for your people if they know people doing something similar to what you do. 2) Alum from any of your schools: It does not matter the year, even if they graduated decades before you. The perceived commonality of having attended the same schools means they are more likely to respond to you. 3) Internet searches on platforms like LinkedIn: For example, you can search for people in your area who work one of the jobs you would like, or anywhere. You can look up companies like those you are interest in and try to connect with people who work at that company (easier to lead to jobs with smaller companies).
->) What to say when reaching out to people: Basic ask: Request to meet with them to learn about their experiences (the technical word for these are “informational interviews”, but I never actually use the phrase when talking to a regular person) a) Prepare an introductory message template to use. Two important rules I follow: Rule 1) Be succinct: Rarely more than 3-4 sentences. All your experiences, refine to a sentence or two. Rule 2) Cut to the chase. State your request in the first sentence (after any greeting you have).
->) This is a basic template for an introductory message:
Hello,
I am passionate about _ [your desired field], and I would love to learn more about your experiences at _ [where they currently work] as _ [their title or describe their role]. Is it okay if we schedule a time to talk in the next two weeks to learn about your experiences?
More context about me: [Write 1-2 sentence bio that explains why you are interested in that field.]
Sincerely, Stephen
Second example specifically for when you are transitioning from one field to another field:
Hello,
I have been working as a _ [your current field], but I have been trying to learn more about [the field they work in]. It seems like you do rather interesting work as a _ [their role] at _ [their company], and I would love to learn more about your experiences. Would you it be okay to schedule a time to talk in the next few weeks?
More context about me: [Write 1-2 sentence bio that explains why you are interested in transitioning into this field.]
Sincerely, Stephen
You will refine these templates over time based on what seems to work for you and for that specific industry.
->) LinkedIn templates: You can include a message when connecting with people, but it has a very small character limitation, so I synthesize my “email template” above into something smaller that can fit their character limits. Then, for those who connect, I will write use the email template above as my basis for writing them a follow-up LinkedIn message.
->) People can choose whether to respond. It’s fine if they don’t have time. Don’t hound people. I don’t follow-up at all if people don’t respond to me. They may have better things to do with their life than talk to me, and that is fine. I focus my energy on those who apply and continue reaching out to more people if I need to talk to more people.
->) One important rule: Don’t formally ask people for a job. That puts people on the spot. They will know from such a message that you are looking for a role and will bring up a good role they have. There are a few subtle questions that draw the conversation towards jobs without asking explicitly. These work much better. Examples: “What does an entry position typically look in [the field they work in] or at [their company]?” or “How did you first enter this field? What kind of role did you have first, and how did you find it?” If they click with you, they may say their organization has a role, or that they may say they know someone who has an open position and offer to introduce you to them. They may also not say anything, often because they don’t know any roles. That’s fine.
->) Always ask: “Is there someone else who does this kind of work that you would recommend I talk to?” They may offer to introduce you to their friends. This keeps you meeting new people. Eventually one of whom will have a job for you.
With this, good luck. It’s a marathon not a sprint, so make you pace yourself, take stock, and prepare yourself for the adventure and inevitable frustration of rejection. If you feel discouraged, remember pretty much everyone has at least once when applying for a new job (for me, at least seventeen times).
Interviewing for a data science role can be a daunting task, especially for those new to the field. I have lost count of the number of data science interviews I have had over the years, but here are the four most common questions I have encountered and strategies for preparing for each. Prepping for these questions is a great opportunity to develop your story thesis, the most important part of any data science interview.
Most Common Data Science Questions:
1) Tell me about yourself.
2) Describe a data science job you have worked on.
3) What kind of experience do you have with messy data?
4) What programming languages and software have you used?
Question 1: Tell me about yourself.
This is probably hands down the most common interview question across all industries and fields, not just data science, so the fact that it is the most commonly asked questions in data science interviews may not seem that surprising. A good answer is crucial to establish a favorable first impression and to lay your main story or thesis of who you are that you will come back to throughout the interview.
In data science interviews, I emphasize my passion for using data science tools to help organizations solve complex problems that were previously vexing. If you are unsure what your thesis is, I designed this activity to help people decipher it. Here is an example of how I would describe myself:
“I fell in love with data science because I enjoy helping organizations solve complex problems. In my past roles, I have used my combined data science and social science skills to explore and build solutions for complicated problems for which the typical ways of doing things within the organization have not worked. I am energized by the intellectual stimulation of breaking down complex problems and using data science to develop potential innovative yet useful solutions. What kind of problems do you guys have that has led you to need to find a data scientist like me?”
Your self-description should tell the story of who you are in a way that demonstrates how you would be a natural fit for the role and helpful to the organization. As your interview thesis, if you laid it out well, then every other question you answer will simply involve fleshing out one (or a combination) of those three basic parts of your self-story: 1) Who you are, 2) How your identity makes you a natural fit for the role, and 3) How this would benefit the organization.
Here are four other important observations to note about how I told my story:
I emphasized who I was – an innovator developing unique solutions to complex problems – while showing my innovator identity naturally connects with data science and could be helpful for the organization. You might not consider yourself an “innovator” per se, but the trick is to figure out who you are based on what energizes and impassions you and then show how performing the data science role you are applying for is a natural fit for who you are.
I told the story with normal words, not technical jargon. I have found that many, if not most, of my interviews, especially the first-round interviews, are with employees without technical expertise, and since you often do not know the level of technical expertise of the interviewer, it is better to err on the non-technical side.
I kept my story positive, only mentioning what I like to do. Sometimes people instinctively try to illustrate what they want by describing things they do not like to do: e.g. “At previous last job, I learned I do not like doing Y, so I am seeking to do X instead” or “I am doing Y, and I hate it. I want out.” I would describe these aspects of my story later if the interviewer asks, but I would stick with the positive at first: only mentioning what I want to do.
I used strong, subjective, even emotional phrases like “fell in love with,” “passionate about,” and “energized by.” At first glance, these phrases might seem overly informal, but I have found they help interviewers remember me. Do not overdo it, but being more vivid and personable is generally helps rather than hurts your interview chances for data science positions.
Question 2: Describe a data science project you have worked on.
This is the second most common question I encountered, so make sure you come prepared with an exemplar project to showcase. They may ask you a lot of questions about your project, so I would recommend choosing a project where you did an amazing job on, really knocked it out of the park and that you are proud of. Unless there are disclosure issues, post your work on GitHub, a blog, LinkedIn, or somewhere else online, and include a link to it in your job application.
How to explain the project will vary considerably depending on your interviewer’s degree of expertise. I generally start with a non-technical, high level explanation and provide the technical details if the interviewer(s) prompts me to with follow-up questions. This gives the interviewers the freedom to choose the level of technical expertise they would like in their follow-up. A data scientist interviewer worth his or her salt will quickly steer the conversation into more technical aspects of your project that he or she wants to learn more about, but even then, starting non-technical demonstrates that you know how to effectively communicate your work to non-technical audiences as well.
When describing your project, you are effectively telling the story of the project, and most project stories have the following core components:
Who: You are probably the story’s protagonist (it is your interview after all, so naturally pick a project or part of a project where you were the primary driver), but there are likely multiple important side characters that you will need to setup, like who commissioned the project, who it was for, who the data was about, and so on.
What: The problem, need, or question your project sought to address generally forms the “conflict” of the project story, so be sure to explain what led to the problem, need, or question (in stories, called the inciting incident).
When and Where: The timeframe setting/context in which the project took place (e.g., the organization you were working with or a class you took for which the project was for). How long you had to complete the project can also be important to establish.
How: What did you to solve the problem. If you tried a lot of approaches before discovering what works, the how includes both your methodological story and your final solution (that is part of the rising and falling action for how you overcame the project). This is the meat of your story. You will want technical and non-technical descriptions of the how:
Technical How: Generally, the core two parts of a technical description are the model you used (and any you tried if applicable) and how you determined the features/variables you selected. Another important part might be how you cleaned and/or gleaned the data.
Non-technical How: I have found that non-technical audiences usually do not glean much from either the model I ended using or my feature selection procedure. Instead, I explain what type of functionality I ensured the model had to solve the problem I had just setup: for example, “I built a model that calculated the probability of X phenomena based on data sources A, B, and C, testing various types of models to determine which would do this best, and then discerned which variables among those datasets were the best to use.” For a non-technical audience, that is generally enough. The core component for them is what goes into the model (the data), what result the model produced from it, and how that informed the problem, need, or question driving the project.
Finally, in your how explanation, make sure you slip in whatever programming languages and software you used: Python, R, SQL, Azure, etc.
Why: This is your explanation of why you chose the approach(es) you did for your how. Now, just like with the how, you will need a technical and non-technical explanations of the why.
Make sure your non-technical explanation of why aligns with your non-technical how. I commonly see data scientists make the mistake of going over a non-technical individual’s head by trying to provide a technical why explanation for their non-technical how. In particular, I would not explain the metric or criteria you used to compare models or decide the feature selection procedure in my non-technical explanation, since these will likely lose a non-technical person. If my non-technical how description focused what data the model used and what it did with it, then my non-technical why focuses on why building a model to do that mattered and how it helped others and/or myself in the real world.
What happened: This is the result of the project. Did you succeed or fail (or somewhere in between)? Was it useful for whoever you built it for? Were you able to conduct any follow-up analysis after deployment? Maybe most importantly, what did you learn from the experience? In narrative terminology, this is the resolution. The more you can quantitatively measure any outcomes the better.
These are the basic components of a project story. Here is the most common project I use, and when reading through it, feel free to analyze how I present each component of the story. I wrote this blog for a general audience, so I provided my non-technical how and why.
Question 3: What kind of experience do you have with messy data?
Interviewers ask me this question surprisingly frequently. They usually preface the question by explaining that they at the organization have a lot of messy data that would require cleaning/processing for their future data scientist. This is a great opportunity to showcase your comfort with data science and data science issues.
I typically answering something like this:
“Yes, I have had to organize and clean messy data all the time. That’s par for the course in data science: the running joke among data scientists is that 90% of any data science project is data cleaning, and 10% actually doing anything with it. At least you guys are honest about the fact that your data is messy. When I worked as a consultant, for example, I talked with many organizations about potential data science projects, and if they said their data was clean and ready to go, chances are they were lying either to themselves or to me about how messy and haphazard their data really was. The fact that you are upfront about the messiness of your data tells me that you guys as an organization are realistically assessing where you are and what you need.”
This answer not only establishes that I have handled messy data before but also normalizes the problem in the field as resolvable by an expert (like myself) and compliments them for being up front. Answering this question confidently and positively has uniquely put me at the top of the list as the front runner candidate in some interviews. Giving a good answer to is is a perfect opportunity to endear yourself with your interviewer.
Question 4: What programming languages and/or software have you used?
Even though a technical interviewer might ask this as well, I have encountered this question most frequently among non-technical interviewers. In my experience, fellow data scientist interviewers have more insider ways of deciphering whether you do in fact know data science, but for non-technical interviewers, this question is their initial way to probe that. Sometimes, they will cling to a laundry list of software and/or languages to determine whether you are qualified.
Now, I believe that having experience using the exact combination of softwares that the data science team you would be joining uses is generally not that important a criterion for job success. For a good data scientist, learning another software system or programming language once you know dozens is not that difficult of a task. But their question is completely natural and reasonable coming from their side, so you will have to answer it.
If they open-endedly ask what softwares and languages you have use, list through the ones you have used, maybe starting with the ones you use the most often. I generally start by mentioning Python, since not only is it my favorite language for data science (see this article) but also conveys that I am familiar with programming in general.
More often, though, they might ask whether you have used X software before, often asking whether you have used each software on a list they have in front of them. I would never recommend lying by claiming that you have experience with a software you have never used, but I would recommend recasting a “No” by providing an equivalent software to it that you have worked with. Here is an example:
“No, I have not used Julia, but that is because I prefer using Python for what others might use Julia for. Python is an equivalent high-functioning programming language in complexity, and the data science teams I worked on happened to prefer it over Julia.”
This not only conveys the “No” in a bit more of a positive light, but it shows that you are familiar with the software he or she just mentioned and confident about using it to match your would-be team.
Question 5: What are you looking for in a job?
Most often, this is the last major question interviewers ask me, but I have gotten it at the beginning as well. They probably save it until the end, because the question transitions very easily to the next part of the interview: either them describing the role or you providing any questions you have.
If you did a good job laying out your thesis story in the first question, then here you simply restate it from a different angle. You already laid the groundwork, and you are just bringing it home at this point. If they ask me this at the beginning of the interview before the “Tell me about yourself” question, then I use this question to retell my thesis story from this new angle.
Here is my typical answer:
“Like I said, I am energized by figuring out how to help organizations solve complex data science problems. Over the years, I have found two concrete things in an organization help me with this. First, I thrive in stimulating work environments where I am given the space and resources to think creatively through problems. Second, I also need to be able to work with people from a variety of backgrounds and disciplines from whom I can learn from and develop innovative approaches to the problem at hand. You guys seem to provide both. [I then conclude by explaining why they seem to provide both based on what you learned about the organization during the interview, or if we have not had a chance to talk about them yet, ask about these within the organization.]”
Notice that the first sentence references my self-explanation answer to the “Tell me about myself” question. If they ask this question before I have given that spiel, I spend about 30 seconds or a minute providing a condensed self-introduction and then continue with the rest of the answer.
Conclusion
These are the five most common data science interview questions I have encountered and how to prepare for them. I have found that when data scientists give advice on how to prepare for job interviews, they often focus on preparing for highly technical, factual questions (e.g., here and here). Even though having a solid data science foundation can be important, refining your overall story thesis – who you are, what you are passionate about doing, and how that relates to this job – is far more important to advance through the interview process.
I have found that humans, even supposedly “nerdy” data scientists, tend to connect with people and stories, so if you can hook them there, they generally remember you better and are more likely to hire you. When you have a compelling story, every other question will naturally fall into place as an intuitive further clarification of that overall story.
