My name is Divyansh Agarwal and I am a data scientist at Uber in San Francisco. I’m working on optimizing the efficiency of Uber’s ride sharing marketplace by improving graph optimization algorithms for rider-driver matching, and evaluating their performance via experimentation and simulations.
I recently graduated from UC Berkeley with a double major in Computer Science and Stats.
So, I had an interest in machine learning and predictive analytics before going into university. I wrote about it in my college essays as well.
But I was also interested in software engineering and fields like security. What really made me truly interested in data science was taking Data 8 at UC Berkeley. I really liked the fact that you could use statistics to extract insights from data and provide value - and although I had always been aware of this, I only realized then how powerful statistics could be and how computing facilitates all of this.
After that, I started doing a bunch of projects, some internships, and got involved in research.
Not really - I was always set on data science once I got into it. I used software engineering more as a backup, because given my CS background it would have been easy to get a software job if I just prepped hard for their interviews.
It’s actually harder to get a data science job out of undergrad. This is because there’s a general bias towards people with graduate degrees and people with a lot of experience. So you need to have either of both - either you need to have a lot of work experience, or you need to have a PHD.
So that’s why I built experience through doing projects, research, internships, as well as reaching out to people in the industry.
For Data Science, there’s no real standardized process when it comes to interviewing - it varies a lot from company to company (this is in contrast to software engineering where using websites like LeetCode can get you ready for almost all jobs).
So I had to spend a lot of time prepping for each specific company I interviewed with - at every stage of the process - and this ended up taking a lot of time.
After my sophomore year of college, I was invited for this intern open house at Uber. That’s when I met some of the team across rides, security, and eats. I spoke to this guy on the marketplace team and another guy on the maps team, I was really interested in those teams.
What’s really cool about the marketplace team specifically is that it’s at the intersection of computer science, economics, optimization, statistics, and there’s a lot of hard & interesting problems that can be solved from an algorithmic perspective.
So after this event I attended, I knew that I wanted to be on the marketplace team at Uber. So during my senior year recruiting, I reached out to someone on the marketplace team, and they were interested in me, so that’s how I started interviewing at Uber.
I’m on the Shared Rides team (which is a part of Marketplace). The core of building new shared rides products and features come from matching improvements or UI improvements. So either tweaking these algorithms, designing & analyzing experiments, understanding how users are responding & behaving - these are all very important and central to Uber’s business.
What are some challenges (both technical and non-technical) your team faces?
The biggest challenge for our team (and I think this is true for any consumer internet product) is building something that people actually like that meets your business objectives. Because everytime you change something with the product, one metric might become worse and the other might become better.
It’s also really hard to figure out what users really want and what they really like. This involves a lot of UX research, as well as experimentation. This stuff is really challenging. Here’s another example:
So, there’s an optimization & efficiency side of Shared Rides - there’s always a tension between the two. If I make something more optimal, it might hurt the experience. If I make the experience better, we have to give some leeway on the optimization side of things. So that’s this underlying technical tension that’s always there.
On the product side, as I had already mentioned, it just comes down to building something users really want. So we have designers and UX researchers who are embedded within shared rides, as well as marketing folks, and I have to work cross functionally with these guys to problem solve on a daily basis.
So Quora was a very small company - there were only 230 people or so when I was working there (two years ago). There were fewer layers of management, it was easier to know people across the company - for example I even got the chance to speak with the CEO on a couple of occasions. There was also less bureaucracy I guess.
At Uber, since it’s a bigger company, sometimes if you want to build something you might need to get buy-in from another team, there’s more bureaucracy, there’s more layers between you and executive management.
Like at Quora, I knew the Head of Data Science very well, but at Uber I can’t imagine doing that currently (given I’ve just begun my career).
At a bigger company like Uber though, you’re working on projects that have bigger scope, bigger impact on the world, and you work with a lot more people. I’m also more specialized within my role here at Uber - at Quora I could have had more flexibility in terms of what I wanted to work on. At Uber, I’m on a very specific team, in a very specific role, working on a very specific part of the product.
Finally, in a smaller company it’s also a lot easier to hang out with your teammates - Quora for instance had organized clubs (poker, badminton etc) across the board that made it really easy to meet people in different teams. At Uber, that’s much harder to do.
Onboarding at a company level was for a day - it more of an engineering orientation, where they introduced me to security concerns, etc. My experience onboarding with my specific team was really good - they had a bunch of documentation that I had to go through, they gave me some small starter tasks to go through, and everyone was very helpful in answering questions.
We also had another bigger orientation where I was introduced to different teams.
We mostly just use Google Spreadsheets for tracking stuff, use Coda for documentation, and to make notes we use Google Docs.
In terms of tech stack, I mainly use SQL, Python, and also occasionally code in Java.
Data science roles are defined very differently based on the team, company, size, role you’re working on. For instance, even Uber Data Science can vary greatly across teams - for example, I work on the Shared Rides / Matching team, which is mostly optimization. And I didn’t even study that in college. The important thing to understand is that different teams have different scopes. For instance, the pricing team does a lot of machine learning. Some other teams are trying to understand user experience. So having a strong base is really important, because at companies like Uber, there’s many directions you could go in.
In the Data Science industry overall, there’s broadly three tracks:
Most of the Data Science jobs involve Analytics or Inference. There are also Data Analyst roles that might be labelled as Data Science, but those are different.
At Quora, they were mostly on the inference side of things. They were trying to understand product opportunities, trends in user behavior, and see if new product features were impactful.
On Uber, on my team at least, I’m more focused on building algorithms.
So in terms of advice: you need to focus on what you’re actually interested in (within the domains listed above). Of course, there’s going to be work that’s a mix of both, but knowing which topics interest you will help you map out and identify which companies you want to work for.
Everything is going to be very team and company specific, so don’t look at titles, but actually look at what the role is, talk to people on the team, and do your research.
Stats theory is also important, but on the job you’re not really going to be actively using theory too much. What really matters is understanding and gaining intuition. For example, I didn’t study a lot of Operations Research in college, but I took some Machine Learning classes in college which helped me build intuition for how Operations Research works.
The purpose of theory is to build intuition and understand things.
Some people call it a newsletter - I call it a good time. I write about tech careers and how you can get ahead in yours. It’s my best content (like this case study) delivered to you once a week.