It’s not the time to be writing about this sort of thing. But here we are. Hopefully this post helps someone who would otherwise struggle to break into Data Science.
I finished graduate school in 2006 and started as a Senior Data Scientist at Uber in 2018. I applied to tens of Data Science and Data Science-adjacent jobs in the intervening dozen years. I was not prepared. This post includes details that I wish I had known. Some of it is geared towards who I was, someone a bit shy with research experience but who didn’t really understand tech. A lot of this might be obvious. Sorry. Let me know if any of it doesn’t ring true. I’m old but I’m still learning.
Protip: Stop saying sorry.
The Resume Screen
The interview process will start when you see a job posting that piques your interest. You send in your resume or a link to your LinkedIn profile. We don’t really do cover letters in tech. A recruiter and maybe the hiring manager will briefly scan your resume and decide whether to reach out. (Once you have a Data Science job, recruiters will find you on LinkedIn and reach out. It all gets easier after you land that first job.)
If you have a few years of post-PhD experience, you should probably aim for a Senior Data Scientist or a Research Scientist position. It varies by company. When you see a job ad that interests you, look up some people with that job title at that company and compare your resume to theirs. Keep in mind that tech values non-tech experience very little. Sigh.
Landing a Machine Learning Engineer position requires better Software Engineering skills. Landing a Data Analyst position requires experience querying databases and creating dashboards. Senior level positions at the most famous tech companies in San Francisco and Seattle pay salaries that may shock you if you’re coming from academia, if you’re into that sort of thing. Hopefully you know all this.
Protips: Contact a friend who works at the company and send them your resume. Get them to make sure you are a good match for the position, to let you know if the hiring manager and/or team are toxic, and to put your resume into the system as a referral. Tech hiring runs on referrals. You have much better odds this way. Culture varies a surprising amount by company and by team. I’ll leave it at that.
Keep your resume at 1 page, maybe 2. Hint at the things that matter to tech companies, like the fact that you can code. Limit the space devoted to things that don’t, like all of your (unrelated) scientific publications.
The Recruiter Call
A recruiter will reach out if your resume interests them. He or she will ask to set up a 30 minute chat. The recruiter is trying to make sure you fit the requirements of the advertised position, are a real human being capable of arranging and showing up to a meeting, and aren’t a jerk.
Typical questions: Why are you looking to leave your current position? Tell me about your current position. Have you done <technical thing listed on the job description> before? How many people did you manage? Are you willing to move to <insert job location>?
Protips: Read the job description before this call. Don’t be self deprecating. Say yes! The recruiter is looking for a reason not to pass your resume along. The recruiter will be more guarded (and you less prepared) if you haven’t worked in tech.
Embarrassing stories: I got rejected from Facebook (in 2018?) at this stage for not knowing Machine Learning. I had just finished a 3 year, NASA-funded Machine Learning research project. I got rejected from Next Trucking in 2019 for not having a PhD.. I do, in fact, have a PhD. (It’s in, of all things, Transportation Engineering.) I can be very self deprecating. This is my super power.
The Hiring Manager Call
There are a few things that can happen after the recruiter call. You may be asked to speak with the hiring manager or someone senior in the organization, on the phone or over coffee. At small startups, this can take the place of technical phone screens (see below). For senior roles, you will probably have to chat with the hiring manager and then complete phone screens and/or a take-home exercise.
The hiring manager will probably spend a good chunk of time trying to sell you on the job, describing the organization and the position while painting both in the best possible light. He or she will probably ask some similar questions to the ones the recruiter asked. But he or she will probably also ask more technical questions. The level of detail will depend upon how technical the hiring manager views themselves.
If you’re coming from an academic or research post, you will probably be able to succinctly describe yourself and a prior project that is sufficiently complex. You might automatically hint at technical details that you’re able to expound upon. Great! You’re probably used to speaking with relatively senior, intellectual people. This might be the part of the interview process that you’re best prepared for. That’s the good news.
Some managers might be particularly interested in impact and/or how your work was operationalized / productionalized. They sometimes do this to determine what levelis right for you. Beware! Your work might not have had that much impact, or you might not have been too motivated to quantify that impact. If you worked in a Jupyter notebook or coded up some Python scripts, you didn’t productionalize your work in the way that the interviewer means.
Typical questions: Tell me about yourself. Tell me about your ideal job. Tell me about a recent project. How did you evaluate your Machine Learning model? What language did you program in? How was your work productionalized? What was the impact of your work?
Protips: Frame your work in the best light possible. Fight the urge to be self deprecating. (I’m just talking to myself now, ha!)
Keep in mind that this is usually a short interview and the hiring manager has a lot to cover. Sometimes the interviewer just wants you to demonstrate that you understand what they’re asking about. Use the right keywords. Talk about “production-level code,” setting up data pipelines, and/or system design. Re: system design, check out the canonical text and course. See also this insightful and recent medium post.
This interview is one of your best chances to get intel on the job, manager, and company. Ask about the team. Ask about the work. Pay attention to your interviewer. Do they talk over you? Are they distracted? Can they explain themselves reasonably well when talking about a technical topic? Are they capable of deviating from their script?
Embarrassing story: I was twice told, after a hiring manager call, that the company would like to consider me for a different position. Although the recruiters tried to obfuscate, these were serious demotions. This could be a nefarious strategy on the part of the manager or company but probably I just did worse than anticipated on the call — but not poorly enough to fail completely. Politely decline to continue the application process if this happens to you. There is no way this ends well.
The Technical Phone Screen: Problem Solving
You will have to pass one and potentially two technical phone screen interviews before being hired as a Data Scientist at most large tech companies. For some reason, these interviews almost always involve two distinct components.
The most common component is a problem solving exercise, where your interviewer sketches out a problem quite similar to one they are facing or have faced at the company. You and your interviewer brainstorm about possible solutions. It pretty quickly becomes apparent that the solution involves running a statistical test, developing a Machine Learning model, or optimizing a math program. You need to demonstrate that you understand the situation and then dive into technical details.
There’s a variant of this type of problem where the interviewer asks you about a well known game instead of a problem at the company. How would you define an algorithm capable of playing tic-tac-toe? Snake? Soduku? To be honest, I hate this variant.
Typical questions (problem solving): What is the statistical power of your test? What about nonparametric tests? What about network effects? switchback experiments?
What if the classes for your Machine Learning are unbalanced? What is Precision? Recall?
What if the size of the problem grew to the point where you couldn’t solve your math program to optimality?
Protips: A very common failure mode for people coming from academia is to overthink the problem. I vividly recall shadowing one interviewer who just wanted the candidate to say that if her merchandise was selling out, she should raise prices. The candidate went on and on about “inverse optimization.”
Related to this, the interviewer usually begins with a trivial question. The difficulty level increases over time and according to your abilities. You should never feel like you got “the answer” and totally solved a question. Arrogance is another common failure mode. Be sure to ask questions and listen carefully to the responses. Interviewers will often give huge hints if you let them.
The Technical Phone Screen: Coding
The second most common component of technical phone screens is a coding exercise. Your interviewer will ask you to work through some fairly basic leetcode style exercises. They often give you a choice of language, but Python is standard, and your safest bet. You will be asked about computational complexity. At least skim the canonical text for this type of interview.
There is a variant of this where they ask you to write SQL queries. If you see this, it’s a good indication that the job will involve … SQL querying. By the way, one common misconception among aspiring Data Scientists is that they will be inverting matrices and applying Deep Learning every day.
A lot of people in academia or at research institutions I talk to are particularly scared of this interview. It’s not as bad as you might think. You (usually) won’t be asked questions as difficult as those given to a Software Engineer. I was a pretty terrible programmer when I got the job at Uber. Having said this, it’s remarkable how many people bomb the coding interviews and are almost totally incapable of writing code.
Protip: Practice.
Embarrassing story: I got through what felt like 57 rounds of interviewing including 2 onsite interview days at Netflix only to be turned down. The one thing I know I failed was the very last interview where I had to write SQL queries on a whiteboard. I had almost no experience with SQL and assumed it wasn’t relevant. I could’ve answered at least the questions that I saw and bombed if I had studied SQL for 10 minutes. I had spent hours before the interview reading about matrix factorization and recommender systems. Nobody asked me about those.
The Take-Home Exercise
Some companies will ask you to complete a take-home exercise, typically in addition to one technical phone screen. The exercise will be similar to the problem solving exercise described above, based on a stylized version of a problem the company faces. You will have to provide documentation of your findings and your computer code. You will typically have about a week to work on the assignment.
As a researcher, you might be optimistic about your chances on take-home exercises. Being able to access google and your notes while you work is helpful. You might be particularly good at documentation and at solving more meaty problems rather than quick gotcha leetcode style problems (which, in my humble opinion, primarily reward exposure to this type of problem). But bear a few things in mind. You’ll probably have to provide more complex (and just more) code than you would on a coding phone screen. You won’t be able to communicate with your interviewer, making it difficult to know when you are or are not on the right track. Take-home interviews take up a lot more of your time as a candidate than phone screens.
I still like take-home exercises. To me, they seem the most fair form of interview in this whole process. I think most of the Data Scientists who I have worked with don’t particularly like take-home exercises. Maybe because of the time required.
Protips: Don’t write pages and pages of documentation (or code). This is a common failure mode for people coming from academia. The referee won’t have time to review it. Do demonstrate some understanding of the domain.
Don’t expect feedback. Any. At all. If you frequently fail at this hurdle, consider getting a Software Engineer to look over your code. Maybe also ask someone in tech to look over your documentation. AirBnB was (is?) famous for asking quite difficult Machine Learning take-home exercises.
The On-Site Interview
If you have passed the technical phone screen(s) and/or a take-home assignment, you will be invited to spend a full day interviewing on-site at the company. You will probably have 5 or 6 interviews on the day. They will be a mixture of the interview types described above.
You’ll typically have an in-person interview with the hiring manager, a coding interview, 2 or 3 technical problem solving interviews, and 1 or 2 meetings with Project Managers or other external but respected interviewers. The coding and technical problem solving interviews will be similar to the phone screens described above. The hiring manager and other interviews will be similar to the hiring manager call described above but, at least in my experience, a little more conversational and easier.
Protip: Keep your expectations low. You may think you have it in the bag if you got this far, but roughly 75% of the people I have seen show up for on-site interviews fail. I‘m not totally sure why. On-site interviews are exhausting. Trust me, by the end of 6 back-to-back technical grilling sessions I am not making any sense.
This is your best and final chance to learn about the company and the position. Find out which of your interviewers you would actually work with and in what capacity. Pay attention to your rapport with them, and their rapport with one another if multiple people interview you.
At smaller companies, you’ll get good signal on if you passed the on-site interview or not by how the day ends. At Scoop, one of the co-founders came in with his dog for a casual conversation. Yay!
Leave a Reply