Strava’s Longest Internship Ever
This is the third post in Strava’s Intern Blog Series, where we give interns the opportunity to talk about the projects that they’ve been working on.
Tell us about yourself
I began cycling in the summer of 2014 as cross-training for running. I am from Massachusetts, which isn’t particularly hilly, so I always thought that cycling was super easy. When I returned to the West Coast for my second year at Stanford, the mountainous terrain in the Bay Area Peninsula and the speed at which some other students climbed the hills made me reassess that notion; nonetheless, I joined Stanford’s cycling team. It took me a while to begin using Strava, but once I did I was hooked, and it was my first choice for a summer internship.
I started at Strava in 2016 as a summer intern on the iOS team following my junior year at Stanford. During that year I suffered badly from post concussion syndrome caused by a bike crash in July 2015. I didn’t feel unmotivated or depressed, but I did feel that I needed a break from some of the unhealthy habits necessary to do well in school, like staring at a computer screen for 20 hours straight or staying up way later than our bodies are designed for in order to meet assignment deadlines. Because of this, I had planned to take a gap year from Stanford for the 2016/17 academic year. Given how much I enjoyed my summer internship, I approached Strava about staying on during my gap year. Strava was very receptive to the idea, and when I again expressed interest in extending my internship to spend time on the infrastructure team, Strava agreed.
What are you working on?
I’ve been able to work on a variety of projects during Strava’s Longest Internship Ever, so I’ll just highlight a few.
Club posts on mobile was my first project. Within two weeks of joining the company, it had been shipped to users. Granted, all I did was add a delete button, but still, it was cool to see my work so quickly visible in the product. Other iOS projects I worked on include posts in the feed, iOS 8 deprecation, and improvements to the new user onboarding flow.
Since moving to the infrastructure team, I have been working in Scala to write Thrift services. My first task was to create a basic service that determines whether a user has access to our internal support tools. I then integrated this service with existing admin-only Finatra HTTP services, using HTTP filters to apply the access check to all incoming requests. A couple of interesting issues emerged. First, our health checks started failing because they didn’t have the access credentials, so I created a designated health endpoint. Second, credentials weren’t set when running locally, so I added a parameter to the configuration file that allows the server to be run without requiring credentials.
I am currently working on migrating segment search to a new platform, using an internal service that we call Surtch, which is backed by Elasticsearch. Currently clubs search uses Surtch in production. We are moving more entities to it because we’ve seen great improvements in reliability, cost, and user experience.
In Surtch, each type of entity that has an index is called a ‘document’. The document outlines the properties of each instance that might be relevant during search. For example, the segment document includes name and location. Each document has a ‘schema’, which defines how the values should be converted to JSON for ingestion into Elasticsearch, and what type should be used when those JSON values are indexed by Elasticsearch.
Each document also has an ‘indexer’, which compiles the properties of an instance of the document from various sources. For the most part the indexer reads relevant properties from a single database table, but in some cases information can be spread across multiple tables. For example, starred segments are not stored in the main segments table.
The ‘notifier’ listens for Kafka events generated from the main Strava web app that require indexing, such as when segments are created, updated, or deleted. The notifier adds the ID of the document to an SQS queue, from which the indexer consumes. Finally, the web and mobile apps make requests through a Thrift interface, and the Surtch service performs queries on the index and returns results to the user.
As I mentioned, items are indexed when they are created, updated, or deleted. When we create a new index (such as segments), or when we modify the properties of a document, we need to perform a ‘backfill’. Our current backfill gathers all existing IDs and adds them to the SQS queue. This works well for clubs because it is a relatively small dataset. However, for a larger dataset like segments this approach is too slow as it is not sufficiently parallelized. So, I am rewriting our backfill to use Apache Spark. The faster our backfill runs, the more flexibility we have to add indices or update the properties of a Document and experiment with improvements to Surtch.
What else makes up the Strava Experience?
Jams
Our quarterly hackathon, Jams(check out the blog series!), is one of my favorite activities.
During my second Jams, I sought to improve athletes’ privacy in regards to what data is visible to people they might not know. Prior to the start of Jams, I met with members of Support, our Privacy Improvement Group, and user experience designers to discuss what might be the best solution. I wanted to escalate the process of building the ideal privacy features that we would create in the future. I then rallied together a large team of designers and engineers to implement Group Activity Enhanced Privacy and the ability to hide activities from segment leaderboards. We also brought these settings to mobile.
Our team won Jams, and even though the work wasn’t entirely finished in those 3 days, it was prioritized and is now in the product. Personally, I haven’t opted in to either of these features because I like it when people discover my activities, but I’m glad that they exist.
More recently, I’ve been fired-up on routes, and have, for each of the last two Jams respectively, worked on a mobile route builder and turn-by-turn navigation.
Mobile Route Builder
Turn-by-turn Navigation
Culture
Not everyone who works at Strava is an intense athlete; that’s a common misconception. I wouldn’t necessarily call myself a super-serious athlete — I think I’ve only managed Sarah Does Intervals™ four times this year. But I do think it’s fun to do things like getting up before 5am to ride bikes up Mount Tam for a ‘bachelor party’, and it’s awesome that so many of my coworkers do too.
What other aspects are there to being a Strava intern that you’d like to share?
Strava cares deeply about each individual at the company and wants to invest in their career growth. Not only was Strava happy to let me work on the infrastructure team, but my mentor, Jacob, met with me weekly leading up to my transition to ensure that it was as smooth as possible. I’ve been at Strava for 14 months now, longer than many full-time employees, and in that time I have worked on a multitude of production features, attended dozens of happy hours, and biked (literally) thousands of miles with my coworkers. I am the subject of many ‘the intern’ jokes, but I believe this is a testament to the trust, responsibility, and integration that Strava has given me.
I would like to thank my managers and mentors, Evelyn Cordner, Steve Lloyd, Quang Nguyen, and Jacob Stultz, for the incredible amount of time and energy they have put in to enabling my growth and success. I would also like to thank the myriad people who have gone out of their way to discuss issues over lunch, teach me new concepts, or help me debug problems during my time at Strava.
