Chapter 9. The first months on the job

This chapter covers

• What to expect in your first few weeks as a data scientist
• How to become productive by building relationships and asking questions
• What to do if you’re in a bad work environment

In this chapter, we’re going to walk you through what to expect in your first few months and how to use them to set yourself up for success. These months will have an outsize impact on how the job goes; this is your chance to set up a system and support network that will allow you to be successful. Although each data science job is different, some broad patterns and principles apply to any job.

When you start working, you’ll instinctively want to get as much done as possible. Fight that instinct. You need to be sure that you’re not just accomplishing tasks, but doing them in the right way. When you’re starting a job is the easiest time to ask questions about how something should be done, because you aren’t expected to know the processes at your new company. Managers occasionally forget that you don’t have the institutional knowledge that your predecessor may have had, so you might get tasked with something that doesn’t make sense to you. You might be able to fake your way through the first few tasks, but you’ll be much better served by asking questions early and finding out how to approach your work process.

9.1. The first month

Your first month at one company will look really different from your first month at another type of organization. Large and small companies will approach your onboarding from almost opposite perspectives. Figure 9.1 compares what you might expect at two companies: a massive one with tons of data scientists and one with no or barely any data science team. (In chapter 2, these examples would be MTC and Seg-Metra, respectively.) These two examples highlight the ends of a spectrum, but the company you’re working for will likely fall in between.

Figure 9.1. Onboarding at a large organization is like going through a factory line, while a small company is more ad hoc. (Twitter Emojis from the Twemoji project)

9.1.1. Onboarding at a large organization: A well-oiled machine

You’re one of dozens of people starting this week. You got an email the week before telling you where to go, when to arrive, and what you need to bring. Now you begin a formal, multiday onboarding process with people from different departments. You’re issued your laptop and go through the process of setting it up. You listen to presentations about the company culture, human resources policies, and how the company is organized. Everything runs like clockwork; the company has onboarded thousands of employees before.

On the data science side, you’ll get help setting up your coding environment. There’s likely to be a checklist or extensive documentation on everything you need to do to get access to the data. There’s also a central repository of old reports and documentation of the data for you to read and absorb. No one is expecting you to deliver much right away; although your co-workers are excited to have you join the team, they know that you’ll need time to adjust. You’ll be expected to take a few weeks to go through all the training and get your access approved for the systems. You may be frustrated that it’s taking so long to feel productive, but a slow start is natural in this environment.

If you’re given a list of to-dos or an assignment, you should take it seriously, but worry more about the process than the result. Established data science teams often have their own idiosyncrasies that you’ll need to adopt. It’s not just good to ask questions at this stage; it’s essential to your ability to perform your job later. The first few months are your chance to see what’s been done before you and learn about the rhythm of your peers.

9.1.2. Onboarding at a small company: What onboarding?

“Oh, you’re starting today?” If you’re joining a small startup, don’t be surprised if not everything is ready, including your laptop. You may be left on your own to figure out how to access the data. When you do get in, it may turn out that the data isn’t well optimized for your job and that a SQL query on a small table of 100,000 rows takes six minutes to run. Onboarding sessions for learning about the company may not happen for weeks, if there even are any, because not enough people may be starting in a given week for it to make sense to run those sessions frequently.

There are no data science standards to speak of. No one will tell you what programming language to use or how to approach and structure an analysis. You will, however, be asked to start getting results quickly. Unlike at a large organization, you don’t have to worry about not being productive; you’ll be asked to do that right away. You do have to worry a lot more that you’re accidentally doing something wrong and no one will tell you, finding out a few months later that your (incorrect) work is already being relied upon. That’s why it’s still imperative to ask questions and work to get a foothold before you no longer have the fallback position of being new. Going from crisis to crisis will cause you to burn out quickly, so work to build your own processes that will allow you to be successful in the long run.

9.1.3. Understanding and setting expectations

One of the most important things you can do in your first weeks is have a meeting with your manager to discuss priorities. This meeting is important because it gives you knowledge about what you’re supposed to be working toward in your job. In some data science jobs, the priority is to provide analyses to a specific set of stakeholders to help grow a particular part of the business. In other data science jobs, the goal is to make high-performing models for the website. And in some jobs, both or neither of these goals may apply.

You may feel that you should already know the job expectations from the job posting and interview process. Although this is sometimes true, a lot can change between the interview process and the start of the job. The interviewers may not be on the same time frame as you, or the organization may have changed before you joined. By talking to your manager as early as possible, you’ll get the most up-to-date information and have time to spend discussing it.

Ideally, your manager has a vision of what you’ll be doing but is open to your priorities and strengths. Together, you want to define what success means in your job. Generally, your success is tied to making your team and/or manager successful; if the members of the data science team aren’t all working broadly toward the same objective, it can be difficult to support one another. To define your own success, you need to understand what problems the team is trying to solve and how performance is evaluated. Will you be helping to generate more revenue by working on experiments to increase conversion, or will you be making a machine learning model to help customer service agents predict a customer’s concerns, with the goal of decreasing average time spent per request?

Performance goals usually do not mean “Make a machine learning model with 99% accuracy” or “Use the newest statistical model in your analysis.” These tools help you solve a problem; they’re not the goal itself. If your models and analyses deal with problems that people don’t care about, they’re pretty much useless. Thinking that developing the highest-performing models is the goal is a common misconception among people entering their first data science jobs. It makes sense that this misconception is common, because many academic research and educational courses cover the many methods of making accurate models. Ultimately, however, for most data science jobs, having highly accurate models isn’t enough to be successful. Things such as the model’s usefulness, level of insight, and maintainability are often more important. (Chapters 10 and 11 discuss these ideas in more detail.)

You can’t know when you start a new job what the expectations are in terms of job responsibilities. Some companies value teamwork; you may be expected to work on several projects at the same time but drop your work on a moment’s notice to help a colleague. Other companies ask that you have deliverables on a regular basis, and it’s OK to ignore emails or Slack messages to finish your project. The way to find out whether you’re meeting expectations is to have regular meetings with your direct supervisor. In most companies, you’ll have a weekly one-on-one so that you can discuss what you’re working on or any issues you have. These meetings exist so that you can find out whether you’re spending your time on the tasks that matter to your boss. Why should you guess what is wanted when you can get explicit feedback? Thinking in shorter-term blocks will help you be sure that you’re on the right track when the larger performance reviews come along.

9.1.4. Knowing your data

You do need to learn about the data science part as well, of course. If your company has been doing data science for a while, a great place to start is reading reports that employees have written. Reports will tell you not only what types of data your company keeps (and give you key insights), but also the tone and style of how you should communicate your results. Much of a data scientist’s job is conveying information to nontechnical peers, and by reading reports, you’ll have a sense of just how nontechnical those peers are. See how simplified or complex the writers make certain concepts, and you’ll be less likely to over- or underexplain when it comes time to write your own reports.

Then you’ll need to learn where the data lives and get access to it. Getting this access includes knowing what table contains the data you want and maybe also what data system has it. Perhaps the most frequently accessed data lives in a SQL database, but the event data from two years ago lives in HDFS (Hadoop Distributed File System), which you need to use another language to access.

Take a broad look at the data you’re going to be working with on a regular basis, but go in with an open mind. Some tables have documentation (either packaged with the data or in a report about the data) that explains potential quality issues or quirkiness. Read those documents first, as they’ll keep you from investigating “mysteries” that later turn out to have been solved. Then take a look at a few rows and summary statistics. This information can help you avoid “gotchas,” in which you find out that some subscriptions start in the future or that a column often has missing values. When you find surprises that aren’t documented, the best way to figure them out is usually to talk to the expert on that table. That person may be a data scientist, if your company is large enough, or someone who collected the data. You might find out that the surprise is a true issue that needs fixing, or it might turn out to be what’s expected. Subscriptions that start in the future, for example, could be those that have been paused and set to restart on that date. Or the coupons for last year’s New Year promo that you find used in May of this year may have been used in May because the support team issued them.

Some companies are better than others about having data that was created for testing separate from real data, although others merge the data without a second thought. In the latter case, you want to ask around whether you should exclude certain orders or activity generated by test accounts or special business partnerships. Similarly, some datasets include users with radically different behavior. American Airlines, for example, once offered a lifetime pass that included a companion fare. One of the people with the pass used the companion fare for strangers, pets, or his violin and might fly multiple times a day. Although you may not have anyone so extreme, it’s not uncommon for newer businesses to offer deals that later look silly (such as 10 years of access for $100) and may need to be accounted for in your analysis.

Throughout this process of investigating the data, you’re figuring out what kind of overall shape your data is in. If you’re at a smaller company, you may find that you need to work with engineers to collect more data before the overall data can be useful. If you’re at a larger company, you’ll be deciphering dozens of tables to see whether what you want exists. Maybe you’re looking for tables with a column called Order across 12 databases. Ideally, there should be well-documented, well-maintained tables for the core business metric, such as transactions or subscriptions. But that’s likely not to be the case for other, less-important datasets, and you should try to learn more if you’re going to focus on one of the less-documented areas.

Make sure that you learn how the data got to you. If you’re working with something such as website data, it’ll likely flow through multiple systems to get from the website to the database you can use. Each of these systems likely changes the data in some way. When data collection suddenly stops, you want to know where to try to find the problem (rather than panic about it). But some places have data that people input manually, such as doctors in a hospital or survey results. In these situations, you have to worry less about pipelines and much more about understanding the many attributes of the data and potential places where a human entered it incorrectly. Pretty much anywhere you go, you’ll have to deal with some data dirtiness.

As you go along, try writing down any “gotchas” in the data and making a map of where everything lives. It’s difficult to remember these sorts of facts over the course of a job, and many companies don’t have a great system for documentation or data discovery. Just as commenting code helps your future self and others understand its purpose, documenting data provides enormous dividends. Although keeping this documentation locally on your laptop is OK, the best thing to do is store it somewhere that everyone in the company can access. You’ll be helping future new hires and even current data scientists at the company who aren’t familiar with that specific area.

9.2. Becoming productive

Eventually, you should be making your manager look good and lightening their workload, but in the beginning, you will make it harder, and that’s expected. It takes longer than you think to get fully productive. It’s normal to feel frustrated during this time, but remember that you’re dealing with a lot of cognitive load from being in a new environment. You’re trying to pick up on the (likely unspoken) norms about how long people take for lunch, what the working hours are, what forms of communication to use, whether everyone closes their laptop when they walk away from the desk, and more. On top of that, you have a whole data system to get to know.

It’s important to stress that it’s an easy mistake to make to assume that you have to prove yourself quickly and early, such as “I need to do everything faster, or else they’ll wonder why they hired me.” This is a case of impostor syndrome (chapter 8). Unless you’re in a truly dysfunctional company, it’ll expect some ramp-up time. Instead of proving yourself quickly, focus on positioning yourself to deliver value over the longer term (within months, not weeks). Early on, you’re going to be asking more of the company (“Can I get access to this? Why is this query so slow?”) than you’re giving back (in the form of reports, analyses, and models).

That being said, you can still deliver some value early. Focus on simple and entirely descriptive questions, such as “What is the distribution of our client sizes?” or “What percentage of our users are active each week?” In the process, you’ll familiarize yourself with the company’s data and also find some of the snags and traps that are waiting. During your check-ins with your manager, show off some of your in-progress work so that you can see whether you’re headed in the right direction. It’s frustrating to put in a lot of time and find yourself answering the wrong question, using a methodology that your boss hates, or that you’re using the wrong data source.

Focusing on simpler questions also keeps you from embarrassing yourself by giving an incorrect conclusion because you’re trying to answer a complicated question without learning all the details of the data first. This situation can be challenging, because if your stakeholders are new to data science, their first question might be something like “Can you predict which sales deals will close?” or “How can we maximize user retention?” But as we’ll talk about in chapter 12, one of your jobs as a data scientist is to dig into the business question to find the data question behind it. If people don’t know or have misconceptions about basic facts (such as what percentage of users make a second purchase or how many people click ads), they won’t be asking the right questions.

Two strategies can help you become productive more quickly: asking questions and building relationships. Asking questions helps you understand the details of your job more quickly. Building relationships allows you to understand the context of your role in the organization.

9.2.1. Asking questions

One of the biggest things that can hold you back in your career is being afraid to ask questions or say “I don’t know.” As we’ve said before, data science is such a big field that no one knows everything or even 20% of it! And there’s no way you could know all the intricacies of your company’s data. Your manager would much rather you ask questions and take up a few minutes of someone’s time than be stuck spinning your wheels for days. A helpful question can be anything from a technical question (such as “What statistical test do we use for detecting a change in revenue in an A/B test?”) to a business question (such as “Which team is responsible for this product?”).

That being said, all questions are not created equal. Here are some suggestions for asking better questions:

• Try to learn from observation about the question culture at the company. Do people ask questions in person, on a Slack channel, in forums, or by email? Getting the channel right means that you’re less likely to bother someone. You also can ask your manager the meta-question of how to ask questions.
• It’s good to show that you’ve been proactive. You might say “I researched this and found these three things” or “This sounds like X. Is it?” By having done some research yourself, you may be able to answer the question on your own, and you’ll be able to ask questions with a better understanding of the concept.
• Don’t ask questions when you can find the answers quickly on your own. Unless the topic comes up while you’re working with someone or discussing an issue, you want to avoid asking questions that are answered in the first Stack Overflow result on Google (such as “What’s the difference between a vector and a list in R?”).
• Find the experts and be thoughtful about their time. Although some of your questions will be general, you might also have deeply technical questions. Finding out who are the experts on various statistical or programming methods is important, as those people are generally the ones you need to get answers from. You don’t want to be a burden on this type of person (or anyone), so if you realize that you have many questions for a particular person, try to schedule a meeting with them. People are much less likely to feel put-upon if they have a few time-boxed meetings rather than face questions every few minutes. It can also help to ask that person’s style. Some people within the company have the role of supporting others, but if that person is also required to have deliverables, see whether they have a calendar that blocks out certain times where they aren’t reachable, and respect those times.
• Avoid voicing criticisms veiled as questions, such as “Why do you code this request this way instead of the clearly better way I learned in undergrad?” Try to genuinely understand why things are done the way they are. If the company has been around for a while, there’s a lot of technical debt. If a large company has physical servers, for example, moving that data to the cloud is more than a half-year of work for dozens of engineers. When people ask “Why don’t we just do X? It’s so easy and would save us a lot of time,” they often assume that other people don’t understand the problem or feel that it’s urgent. But the reason they’re not doing X may be because of things you have no idea about, such as legal constraints.
• Team up with someone else. A great way to learn is to pair with people. Instead of just asking questions and getting answers, you can see how people found those answers. For a technical question, pairing with someone is also a way to see their coding environment and learn new techniques. Even if your question is about how to get data, you can learn what table that data is in, how they knew which table, and maybe some coding tricks. Your eventual goal is to be able to answer as many questions yourself as possible by knowing where to look.
• Make a list. Finally, if you have questions that don’t need an immediate response, try to keep a list of things that might be useful to know, such as how often the data refreshes, the size limit for queries, and how far back certain data goes on the local server. Then go over these items in a block with your mentor or manager. This approach prevents you from interrupting someone over and over, which can become a bother if you’re not careful.

9.2.2. Building relationships

An important part of feeling comfortable in your new work environment is building a support network. Some people do this more easily than others, but you want to make sure that you engage in some nontechnical talk with people. In most cases, this means setting up meetings with people you’ve never talked to before to get to know them and their work. This time isn’t wasted; it allows both you and your co-workers to feel more comfortable relying on one another if you know more than names and job titles.

Approaching someone you don’t know can be daunting, but you can use your questions as a way to start a conversation with someone. People like being helpful and feeling knowledgeable, so don’t be afraid to use questions as an in as long as you’re polite and friendly in your queries. When you know a few people, even the largest offices feel less intimidating. It’s also normal to message people you’ll be working closely with to ask whether you can set up a 30-minute meeting to get to know each other. If you work in a large office, ask your manager to make a list of people you should get to know.

In an office of any size, it’s good to find out who to go to for specific questions. One person might be the company’s best at SQL, and someone else might be in charge of the experimentation system. It’s very helpful to know who to turn to when you face a technical hurdle, and that person usually isn’t your manager. You also want to at least introduce yourself to your skip-level boss—not so you can tattle on your boss, but because making yourself known to the person will make it easier when they have to discuss you with your boss.

Similarly, you should try to meet all the stakeholders you’ll be working with. If the data science team is fewer than ten people, try to meet with all of them individually. If you’ll be working with data engineers or other data people, talk with them. These meetings can be informal, but it’s important for you not to exist solely as an email signature. Even if you mostly work remotely, try to use a video conferencing system so that people can see your face.

Do a lot of listening, both in official meetings and during social opportunities such as lunch. Meet people who work in data-adjacent areas (which could be everything from engineering to finance to sales operations to marketing analytics), and hear how they currently do their jobs. Don’t rush in with a statement like “I could do that better” or make commitments early, such as “We’ll build you a machine learning platform to do that.” Simply focus on collecting information and thoughts. And don’t forget that everything doesn’t always need to be about work. It’s nice to get to know people on a personal level, whether by asking about their weekend plans, favorite TV shows, or hobbies.

One last word to the wise: befriend the office manager. Office managers control a lot of the things that can make your day better: snacks, the lunch order, what type of hand lotion is in the bathroom, and so on. They also have one of the hardest and most thankless jobs around, so make sure that they feel appreciated.

9.3. If you’re the first data scientist

Everything up to this point of the chapter applies to the first few months of any data scientist position, but being the first data scientist in an organization provides its own unique set of challenges. Given how new the field is and how many small companies lack data scientists, being the first one isn’t uncommon. For those reasons, as the first data scientist in a company, you should be especially prepared when you begin.

When you start your new position, there’ll be absolutely no precedents. No one has decided yet whether to use Python, R, or some other programming language. No one has figured out how to manage the work. Should software development practices such as agile be used to decide what to work on, or should you do whatever you feel like that day? How should the code be managed? Should a GitHub professional license be bought or a Microsoft TFS server used, or can you keep all the files in your My Documents folder on your laptop without backups?

Because there are no precedents, everything you do will implicitly become a precedent. If you happen to enjoy doing your work in the obscure programming language F#, for example, you’re forcing the next data scientist to learn F#. It’s in your best interest to make decisions that will benefit whatever the team looks like down the line, which may mean using a more common programming language than the one that’s your favorite. This approach has to be balanced with the fact that focusing too much on the future can cause serious harm to the present. If you spent three months setting up a beautiful pipeline for sharing reports with other data scientists automatically, but the second data scientist isn’t hired for five years, that work was a waste. Every day, either directly or indirectly, you’ll be making decisions that have large consequences.

Besides having to figure out the role on your own, you have to sell data science to the rest of the organization. Because the company hasn’t had data scientists before, most people won’t understand why you’re around. The faster people get your role, the more likely they are to want to work with you and keep a data scientist around. These conversations are also about managing expectations. As we’ve discussed before, some people think that data science is basically magic and that their first data scientist can immediately solve some of the company’s biggest problems. You’ll need to set realistic expectations about (a) what data science is capable of and (b) how quickly those goals can be reached. Therefore, your job will require you to continually explain data science in general to people, as well as what in particular you can do to help the business. Sitting quietly in a corner working on models for months is possibly OK if you’re the 20th data scientist on a team, but you certainly can’t do that as the first.

Although being the first data scientist is a lot more work and a lot riskier than other positions, it also has great payoffs. By making the technical decisions, you get to choose things that are more in line with what you want. By selling data science to the organization, you get to be better known and more influential. And as the data science team grows, you’re in line to be the head of it, which can be great for career growth.

9.4. When the job isn’t what was promised

Entering a data science job and finding that it’s nowhere near what you expected can be crushing. After months of work, you’ve finally broken into the field, and now you might have to go out and start all over again. Worse, you may worry that leaving quickly will look terrible on your résumé. Does that mean you have to put in a year? Managing a bad environment and deciding whether to leave is challenging. In the following sections, we cover two main categories of problems: the work is terrible, and the work environment is toxic. Although there’s no silver bullet to solve these problems, we’ll walk through some potential mitigation strategies.

9.4.1. The work is terrible

First, take a hard look at your expectations. Is the problem something along the lines of “All my data isn’t cleaned! I spent two days just on data prep! The data engineers don’t fix everything immediately!” Those problems are going to be part of every data science role. Even data scientists at the biggest companies with hundreds of engineers have these problems; there’s so much data that it’s impossible for it all to be perfectly vetted. Although the core tables should be clean and well-documented, you’ll likely encounter data in your subareas that you need to improve or work with others to collect.

One way to check how realistic your expectations are is to check them with other data scientists. If you graduated with a related degree or a bootcamp, ask your peers or people in the alumni network what they think of the data environment you’re working in. If you don’t know many data scientists yet, try to go to meetups or join online communities if you’re in a small town or rural area. (We covered this topic in depth in chapter 5.) If other data scientists at your company had previous data science jobs, see whether they can give you an idea of how this one compares.

Another situation may be that the work is tedious and boring. The job you got hired to do might have been forecasting, for example, but in practice, all you do is press the rerun button on someone else’s existing forecasting model once a month. In that case, see whether you can carve out some side projects in the organization or automate some processes. If the work is boring but not time-consuming, take the opportunity to do things that are related to data science. Continue to build your data science portfolio with side projects, write blog posts, or take online courses. These tactics will help position you for your next role.

Finally, you can learn even from bad jobs. Is there any way you can tailor your job so that you’ll do more things from which you can learn? What areas can you improve upon? Maybe your peers won’t help you learn how to write better code, but can you learn about what mistakes are easy to make in building a data science team? It’s very likely that there are some smart and well-meaning people in your company, so what happened to make the work bad? By learning what you don’t like, you’ll know what to watch out for in your next job search and be better prepared to avoid mistakes if you ever start your own data science team.

9.4.2. The work environment is toxic

Section 9.4.1 discusses a bad but manageable situation. But what if your work is really toxic? What if your manager and stakeholders have completely unrealistic expectations and threaten to fire you because you’re not making progress in predicting lifetime value when they have no data for it? Or you get penalized when your answers don’t meet the company’s expectations? Companies that are new to data science may expect you to sprinkle your data science fairy dust to solve the company’s core problems. They may tell you “Build a model to tell whether text is written well”—a problem that no one in the field has even come close to solving. In this case, you need to adjust the company’s expectations or risk feeling like a constant underperformer. Speaking up for yourself in this circumstance is difficult, but there are usually reasonable and smart people working at any company. If they say, “If you were a better data scientist, you would be able to do this,” that’s a huge red flag. Even if a much more experienced data scientist could tackle the problem, the company should have recognized that fact when it was designing and hiring for the role.

Maybe the problem is that people and teams aren’t collaborating. Instead of seeing where they can help, teams may be trying to sabotage one another. They focus only on how they can get ahead, and they may even see having success at the company as a zero-sum game: if you or your team is doing well, theirs is losing. Besides creating an unhealthy environment, this situation often leads to a lot of wasted work, as you may end up duplicating someone else’s project because they wouldn’t share their data or learning with you.

The problem may have nothing to do with the data science part at all; the environment may be sexist, racist, homophobic, or otherwise hostile. There’s no reason why you should feel uncomfortable going to work every day. Even if you’re not getting openly hostile harassment, being talked over in meetings, being addressed by incorrect pronouns, or being asked “But where are you really from?” all add up.

Unfortunately, solving these types of problems usually requires the involvement of top leadership and active engagement from everyone else. But the fact that the workplace is toxic often indicates that leadership is nonexistent or even actively contributing to the problem. If the problem is rooted in one bad person, ideally, others will recognize that fact, and the person will be removed. But if the problem is widespread, it may be close to impossible to change, and trying to change it as a junior employee is a quick recipe for burnout. In these situations, you want to think carefully about whether you need to leave.

9.4.3. Deciding to leave

Deciding whether it’s right to leave your job is an extremely personal decision. Although no one can give you a simple flow chart that will make the decision painless and easy, we can offer some questions to think about to guide your decision:

• Do you have enough savings, a partner with a second income who can support you, or family members whom you can ask for a loan if you leave without having another job?
• Is your job affecting your health or life outside work?
• If the issue is the work, have you talked with your manager about the issues and tried to resolve them?
• Is it possible to switch teams or roles—if not now, within a few months?

If the answers to these questions make you feel that you need to leave, one option is to start looking for other jobs immediately. But you may worry about how having a short job stint on your résumé will look or how you’d explain it to interviewers. If you’ve been on the job for only a few weeks, and you came to it directly from your last job, consider getting in touch with your previous manager. It’s likely that your position hasn’t been filled yet, and if you left on a good note, you may be able to go back.

If you’re looking for a new job, here are a few tips on talking about your short stint during your interview:

• Wait for the interviewer to bring up the subject. Don’t feel that you need to talk about it proactively; it may not be a concern, especially because the company is clearly interested. (You’ve reached the interview stage!)
• Find some positive experience and learning from the job you can talk about. Those experiences and lessons may be a project you worked on, exposure to the industry, or guidance from a senior leader.
• When asked why you left so soon, keep it short and neutral. You’re in a difficult situation because you want to be honest about why you left and about how it wasn’t through any fault of your own, but if you’re too open and honest, the interviewer may unfairly perceive you as difficult to work with. Thus, your best bet is to give a vague “The requirements of my job weren’t what I expected, and I wasn’t able to use my skills and expertise to benefit the company” and leave it at that. If you’ve learned something about the type of work environment you want, share it. Maybe you were the first data scientist at a company, and you realized that you want to be a part of a larger team.

If you’ve decided to leave, check out chapter 15 for information on how to do so gracefully, including searching for a new job while you’re working full-time and leaving on a good note.

But maybe you can’t leave because your visa is tied to your workplace or the company is the only one doing data science in your small town. If that’s your situation, here are some tips:

• Remember that you are not your job. You don’t have to take responsibility for poor decisions that the company makes. Unless you’re in a leadership position, you likely have little control over what the company does.
• Try to keep yourself healthy. Don’t sacrifice sleep, exercise, and time with friends and family members.
• Talk to someone. Maybe that person is a partner, a friend, or a therapist. They may have advice to give, but just listening to you will help.
• Think about reporting personal harassment. If you’re being harassed by a specific person, consider reporting them to your human resources department. Make sure that you document your reporting. Don’t drop by human resources in person; send emails and get emails back so that you have a record of the process. Eventually, you may want to point out certain things that were said to you, and having a written record will be helpful. If the company does nothing, you can file a claim with the Equal Employment Opportunity Commission if you’re in the United States. Unfortunately, reporting harassment is not without risk: although it’s illegal to do so, companies have retaliated against employees for reporting by stalling their career growth or even firing them. Even if you don’t want to report harassment, consider keeping documentation of any harassment you experience in case you decide to report it later.
• See whether you can think outside the box about leaving the company. Maybe you feel that you can’t leave because the only options available to you are going to a less-prestigious company, getting a lower title, or temporarily depleting your savings. But don’t underestimate the negative effects of staying in a toxic environment: if you can make a short-term sacrifice to leave, leaving will likely be worthwhile in the long term.

We hope that you’ll never be in this type of situation, but it’s handy to have a little “Break glass in case of emergency” information somewhere. Keep in mind that switching jobs in the data science field is common (as we discuss further in chapter 15), so there’s no career reason to stay in a workplace that makes you uncomfortable.

9.5. Interview with Jarvis Miller, data scientist at Spotify

Jarvis Miller works as a data scientist in the Personalization Mission at Spotify, focusing on improving the listening experience for each user. When this interview was conducted, he was working as a data scientist at BuzzFeed. He graduated in 2018 with a master’s degree in statistics.

What were some things that surprised you in your first data science job?

Two things that surprised me were how much I could improve as a writer and how I needed to explain my data science contribution to the business without using jargon. I had this idea that because stakeholders had been working with data scientists, they have learned to understand the language, and thus, I didn’t really have to change the way I explained things. I realized that that’s absolutely not the case, and I can’t simply say, “I ran a logistic regression on this data to classify . . .” On the being-a-better-writer side, I’ve begun to flesh out the story when I write a report; improve my data storytelling abilities; and explain things in a way to where product managers, designers, and stakeholders who aren’t in tech at all can understand what I’m saying.

I came from academia, where I felt it was all about whether you found the result at the end of the day; it didn’t matter whether you started working right before the deadline or if you planned way ahead. In industry, you have a big overall goal, but you figure out how to break it down into versions. You get the first version working, ship it, learn about whether it’s doing well or not, and maybe improve it in a future quarter. I was used to going until it is done. But here, I had to learn how to prioritize parts of a project and then wrap it up. I learned to document what I had done and what there is to do in the next version; and then make it shareable, whether that’s by putting a report into a shared folder or making an app so people can use my work and see what it’s supposed to do.

What are some issues you faced?

Speaking out was something I really struggled with. When I started, I was doing an isolated project, and the person I reported to was in New York, and I was in LA. If I was confused, I didn’t know whether I should message them immediately or save it for our meeting. I knew I didn’t want to be derailed by something that was blocking my work, but I wasn’t even sure when something was a blocker. I think this is a common problem for data scientists, especially for those in marginalized groups or who switched from a different field. They may feel like because they’re new or not experts, they can’t express displeasure or voice an opinion. If I could go back, I would have a conversation sooner about how I’m feeling isolated and how I’m not sure how communication works at this company.

Can you tell us about one of your first projects?

One of them was to revamp our A/B testing platform, which was a very broad problem. I started by getting a list of people to talk with about what they did at BuzzFeed, how they worked, and how A/B testing fit into that workflow. We then discussed the specific tool: what did they dislike and why, and what was their workflow when using it? Unfortunately, this led to the issue of taking on too much. A lot of people had multiple suggestions, and I gave them all equal weight, which ended up with 50 big things that I needed to do. But my manager asked me to break those suggestions up into the must-haves and the nice-to-haves, including the reasons why these were prioritized the way they were. He suggested listing the overall goal of the project and giving ideas weights based on their contribution towards the goal and how long they would take.

What would be your biggest piece of advice for the first few months?

Remember that you’ve been hired for a reason: they respect your point of view, and they think they can help you learn and that they can learn from you. If you have an opinion, try and let someone know. If you hate speaking in a big group, maybe message one person, run it through with them, and bounce ideas back and forth before you express it in front of the larger group.

This doesn’t just apply for the technical side of the job. For me, in the first few minutes of my one-on-one with my manager, I don’t want to immediately jump into what I’ve done. I want to have a few minutes to have a casual conversion to destress and clear my mind. I know that this helps my productivity, and my company wants me to be productive, so I should let them know. Your opinion is valued, and it’s worth sharing, especially if it’s about how you like to be treated or how you can be most productive and flourish in this role, because they don’t know you like you know yourself, and your being productive will benefit everyone.

Summary

• Don’t worry about becoming fully productive right away. Instead, focus on building relationships, tools, and your understanding of the data, which will make you productive in the long term.
• If you’re in a bad work situation, try to work to get control to mitigate the impact on your health and career.