I joined medium to write about transportation but my post about the Data Science Interview Process was my most read post by far.
This is a similar post about how you might be evaluated as a Data Scientist at a tech company. As before, I’ll add in personal anecdotes, focus on what I wish I had known previously, and offer my somewhat cynical take on things.
It’s (Hopefully) Not That Important
The stakes are both higher and lower than you might think.
A great performance review can lead to a promotion. A terrible performance review can lead to being put on a PIP and/or being laid off. Furloughs and layoffs are common in tech, especially now. Being evaluated poorly, officially or unofficially, can lead to uncomfortable meetings with your Engineering Manager and your team, and just a poor work experience. So it’s worth working to make sure you are thought of as a high performer.
One thing to keep in mind is that, thankfully, the Data Science job market is hot. There is career security if not always job security. I lost what I thought was my dream job and relatively rapidly got 3 new offers and a job one level higher. Yay! And I’m terrible at interviewing. If you’re aiming for a promotion and don’t get it, apply elsewhere. You may get that level up. If you do, chances are you’ll make more money switching anyways.
There are two exceptions here. If you’re just starting your Data Science journey, then it will be harder to bounce back and find that next job. If you’re on a work visa, then the stakes are higher. People know these things. Good people will want to help.
Another thing to keep in mind is the stochastic nature of all of this. It’s much easier to get that promotion or avoid the sack if your project, manager, and startup are … impactful. You can and should carefully select your work. But there will be a lot you can’t control, especially as a junior Data Scientist. When layoffs or furloughs happen, they are often planned at high levels within the organization based on data you will never see. It’s not all about you. It’s also important to recognize that different people will shine in different environments. Get in where you fit in!
Also know that your career will be long and there aren’t that many levels in Data Science. If things don’t turn out right this year, maybe it’ll happen next year. No worries!
Move the Jira Tickets Across the Board
Imagine a super organized, agile company. You join as a junior Data Scientist and are assigned to a project. That project is led by a Project Manager. You have a Jira board full of tickets describing work that needs to be done, organized around 2 week sprints. You have daily stand up meetings where everyone talks a bit about the tickets assigned to them. You may even have backlog grooming, sprint planning, and sprint retrospective meetings. Wow, such organization!
Many Data Scientists and Engineers hate Jira. Jira is awkward for data science. People will tell you the Jira board doesn’t matter. It does. Particularly for junior employees. Important people can track it. Learn how Jira works. Make sure you always have tickets and are moving your tickets across the board at a good pace relative to your peers.
Your world may not look like the one I described. At 2 of the 3 jobs I’ve had, there were long stretches when a coworker used a janky Google Sheet to track project status. I don’t mean to criticize; I didn’t really mind the janky Google Sheets. My current work is split between responding to urgent incidents, attending entirely too many meetings, and blue sky research, none of which can be tracked well in Jira. I guess here I do mean to criticize. We have all of the hassles of Project Management and none of the benefits. I’m eight months in and yet to see an PRD or an ERD. Whatever. I’m moving tickets across the board, and making sure boxes get ticked off in that Google Sheet. Jira isn’t perfect, but if you aren’t moving the tickets across the board it’s often a sign that something is off.
Commit Code, Merge PRs
You should pay attention to Jira because it can be used to quantify your output as a worker. Welcome to your dystopian present. Another way to quantify output is to look at activity on the corporate code repository. How many commits have you made? Pull requests merged? reviewed? Etc.
You may be saying that as a Data Scientist your job is not to sling code. I’m inclined to agree. Even for Software Engineers, it would be foolish to evaluate someone based on how many lines of code they write. That’s true too. But I am just letting you know that there are high ranking employees at tech companies who do evaluate people by looking at their github activity. I’ve seen it happen. Particularly for high ranking employees who used to be Software Engineers and Machine Learning Engineers. Sometimes they just want to see if someone has the ability to contribute to the production code base. The hardest commit to merge is the first one. Just do it! Ask for help if you need it (see below).
You may be saying that Data Scientists on your team don’t really touch production code, or that there has never been a task assigned to you where you needed to change production code. That’s how I initially felt at my first Data Science job at Uber. I worked hard for those first few months, putting together analyses in Jupyter notebooks, queries, docs, and presentations. I’d like to think I shaped the development of some key services and the team’s verbiage (ha! see below). No one ever indicated I should even think about the code. But, if I had it to do over again, I’d have worked more in the code from the start. I would find a way. Put your name on the product and, at a tech company, the code is the product.
Ask for Guidance and Help (in the right way)
There are two super common failure modes for new Data Scientists. One involves the new hire not learning how to contribute followed by them getting frustrated, demotivated, and disengaged. Maybe he or she doesn’t know what they should be working on or how to use git or doesn’t have the right permissions set up to access the data and doesn’t know who to ask. He or she asks the wrong person or waits too long to ask. Everyone is surprised when, four months in, Anthony on Pricing doesn’t know how to query for revenue.
Another super common failure mode involves the junior Data Scientist working hard for entirely too long all by themselves on some complex analysis or feature that their team is not all that interested in. This one is especially painful because of the disconnect between how well Evelyn thinks she’s doing and how well the rest of the team thinks she’s doing.
Both of these super common failure modes are easily avoided with proper communication. Ask for help when you get stuck, especially when you’re just starting out. Ask for feedback when you complete a task, and pay attention to that feedback. Make sure you are regularly completing tasks. Ask lots of people.
One important point: you don’t have to go exclusively to your Tech Lead. Pay attention to how your Tech Lead likes to communicate. There are Zoom people and there are Slack people. It’s 2021; there are no other acceptable methods of communication. Constantly bugging your Tech Lead via the form of communication they don’t like isn’t a great idea. How would you like it if you kept getting phone calls from some strange number?
Your relationship with your Tech Lead is very important, even if they aren’t technically your boss. Your Engineering Manager will ask your Tech Lead about your contribution to the team.
Also, your peers will often know how to help and probably aren’t as busy as your Tech Lead. Here’s a secret I’ve learned after 3 years as a Data Scientist: we’re all making it up as we go along, building upon what we have seen. It’s helpful to learn from as many people as possible.
Etc.
It is important to have good relationships with your Engineering Manager and your Tech Lead. You already know that and are probably over emphasizing how important it is to make the right impression on them. Don’t overthink it. Don’t be obsequious. But hopefully you genuinely get along. It’s easier in tech. We’re all working together. It’ll be easier to get along if you’re moving the jira tickets across the board.
It is beneficial to shape the direction and even the verbiage of your project and team. Coming from 6 years in consulting / public policy, I know I over emphasized this. I was proud when my Uber Bus team started talking about headways and passengers alighting and looking at time-space diagrams. That was my influence! But there were minimal tangible outputs. I should’ve been making Pull Requests on the existing Route Generation microservice.
It’s important to document your work. Make and distribute a brief but well written Google Doc explaining your analysis. Your Jupyter notebook that’s almost entirely code isn’t enough. Have one clean and consistent point of view. Make a Confluence page for the big task or little project that you’re working on. Solicit feedback, especially if English isn’t your first language. Missing or exceptionally poor documentation is very common and will make a bad impression on Engineering Managers — the very people who have to justify your performance review. Again coming from 6 years in consulting / public policy, I know I over emphasized documentation. But I also got it slightly wrong. Don’t explain both sides and don’t write too much. I need to follow that advice right now.
Leave a Reply