I graduated from Cornell University in 2015, and my major was a bit of a mouthful: Industrial and Labor Relations. It was half typical management-type stuff, economics, and traditional business courses, and the other half was labor law, labor economics, wages, and unemployment.
I came from an international background and grew up in three different countries. The major resonated well with my interests at the time.
But as you can imagine, it wasn’t the most analytical or quantitatively rigorous major you could have, and preparations for a data science interview were challenging.
There were two jobs before Facebook. The first one was at an enterprise software company, called CA Technologies. And that was really my first foray into Big Data and how to make sense of it. It was very much a trial-by-fire role: Business analytics aligned to on-premise software.
The entire role was pretty straightforward. My role was to understand what the function of analytics was, provide dashboarding, and a lot of ad hoc requests.
Next was strategy and analytics at Capital One. Again, it was data aligned to the product function there. That was a great learning experience. I was able to touch on a whole lot of different functions: Part analytical, like working with SQL and Python, and also project management and strategic road mapping, e.g. working with all the business leaders across different functions to plot out the future.
About a year ago, a recruiter from Facebook reached out about the data science role and product analytics. I wasn’t a machine learning expert, and I’m not a coding whiz. But I was interested, and that’s what led me to Interview Query.
I explored data science product analytics and that’s when I realized that data science was much more of an umbrella term than I had thought. And there were a lot of different roles that fit under it, like a product analyst or technology strategist, which aligned much more closely with my skills than I had thought.
That’s when the path became clear to me: I needed to learn a few additional skills, brush up on SQL and Python, introduce some experimental methods, and ultimately, package that into a nice little gift for my data science interview preparation.
There were four main steps in the approach that I used:
For the first step, I took the time to identify the overlapping tangible skills (e.g., SQL, A/B testing, etc.) and the intangible skills (e.g., strong product leadership, proven ability to influence cross-functional partners, etc.) across different job listings. Breaking those down and finding what skills were similar across roles helped me structure a plan of attack.
Second, I looked at specific interview questions online and mapped that to the job role. Technically, are they asking for SQL or Python? Asking statistics? Are they looking for leadership or general communication? I was figuring out which skills I needed to study compared to my current ability and levels.
The third step really overlapped with the second one. This is where coaching and Interview Query’s interview prep questions helped me elevate quickly. I interspersed all my studies across these confined subject matters with help from coaches and mentors.
I asked them to give me practice interviews and benchmark where I was at, and over time, I started to get a picture of where I was improving and what I needed to focus on. I also created rubrics in these different areas, which helped me to continually reevaluate my study plan and refocus on what needed work.
Step four was really just applying to companies and using my learnings from steps 1-3 in interviews. Around steps three and four I started to feel like I was hitting my stride. For example, my interviews with DoorDash, Uber, and Facebook all fell within two weeks of each other, so I was interviewing for 4-6 hours per day for a while. I got offers from all of them.
I started about a year ago, and really ramped up in late 2020. The first step took maybe two weeks. Steps 2 and 3 took the majority of time, about 4 to 5 months. I wanted to be as prepared as possible before I began even practicing interviews for those firms. Finally, the last step took about 2 to 3 months, from the initial interviews to negotiations.
I continually forced myself to add context to any of the interview questions I was asked. It’s easy when you’re asked a SQL interview question, you just want to jump in and answer.
But the ability to step back and think about it in the context of why the company is asking that question and why they would care about that, helps you to structure your answers and let the interviewer know you have a firm grasp of the role. And this approach allows you to guide them along on your answer. That’s just great practice, especially now on the job.
There are a few different ways that I tackled it. First, before I got to Capital One, I did a bunch of case study interviews. So I was familiar with case interviewing. I brushed up on it with some classic consulting books like Case Interview Secrets and Case In Point.
But practicing with a product manager was really helpful. Because when you practice with data scientists or people from more technical backgrounds, they tend to focus on what they know. With PMs, when I didn’t do a good job of scoping it out, they’d stop me and say,
“OK, but I, as the one who’s making the executive decision cross-functionally, am curious why you’re starting at this point and thinking about this analytically.”
Working with a variety of different interview partners in a variety of roles was really what helped with that.
You definitely have to be technically solid to pass these interviews. There’s no doubt about it. But a fair number of applicants have the technical chops. Nowadays, it’s the ability to frame it from the business perspective and drive that business value that helps get candidates over the edge.