Hello! We’re the engineering team at Root. We’ve put tremendous care into defining who we are and how we work, and we want to share it openly. Job postings often contain only a fraction of the information that thoughtful and deliberate people want to know when choosing a place to work. So we provide more detail here to see if Root is the kind of place you want to spend your time. If so, please get in touch with Chris Evans at email@example.com. We’d love to hear from you.
What is Root?
Root is a car insurance company founded on the belief that good drivers should pay less for insurance since they’re less likely to get into accidents. Some drivers are paying significantly more than they should on car insurance, because most carriers assign rates based primarily on demographics. We’re fixing that.
Root is reinventing the broken insurance industry by using technology in smartphones to measure driving behavior. The Root app determines who is a safe driver and who isn't. By only insuring safe drivers, we can offer more affordable rates. And the entire business runs on the software that the engineering team built. From scratch. After a Series E funding round of $350 million, Root is now valued at $3.65 billion.
We’re proving that with teams of smart, talented people, we can reshape an entire industry.
Even with our significant growth, we operate in small teams that are given ownership over projects and results. Root is where it is today due to the hard work, ingenuity, and exceptional performance of the people here.
Insurance companies have known for a long time that people’s driving behavior is more predictive of their likelihood of getting into an accident than their demographics. However, actually executing on this idea is challenging. We’ve been fortunate to build an incredibly talented team that has brought this idea to life.
We build software using an agile methodology, working in cross-functional teams comprised of people from across the company including: software engineers, product managers, data scientists, designers, actuaries, legal, pricing, customer service, claims, and marketing. Working directly with stakeholders, we contribute to strategy and decision-making to put out the best product and drive business results.
We work in one-week iterations. We kick off iterations by gathering together as a team to review story cards for the week. We have a daily standup to share progress from the previous day, plans for the current day, and any issues or blockers. At the end of each iteration, we share our results and celebrate our progress. Sharing our work creates accountability and ensures we’re consistently delivering working software.
Working software is the primary measure of progress. The constant feedback loop and proximity to the business means that engineers can know the impact of their work within days of shipping a new feature.
Periodically, teams gather for a retrospective to identify opportunities for improvement. We discuss what’s going well and what’s not going well, and we identify action items we want to take. Reflecting on how to become more effective as a team is a critical component of our process. The entire engineering organization at Root does a retrospective each quarter.
Our product team sets roadmaps and objectives on a quarterly basis. As we wrap up one quarter and plan to start work on the next, we set aside three days for Hack Days. It’s an opportunity for the engineering team to hone skills, explore new technologies, and work on problems entirely of our choosing.
For our mobile apps, we release weekly. We cut release branches every Tuesday morning at the end of the iteration. If a feature isn’t quite ready, we wait to ship it until the next release. We value the consistency and predictability of the weekly “train schedule” release strategy. For our backend, we release daily.
We primarily work individually, but we also periodically do pair programming. We have pairing stations set up to be comfortable and conducive to collaboration: two monitors (mirrored), two keyboards, and two mice hooked up to a single computer. While our pull request process can help engineers learn and grow, there are many aspects of software development that can’t be taught via pull requests. PRs only contain the end-result of writing code; they don’t capture the process of getting there. Tools, techniques, and thought processes can all be improved via pairing.
As engineers, we pay attention to trends and love exploring new tools. When we make decisions for how we want to build software, we do so judiciously and deliberately. We currently leverage many new tools across our projects, such as React Native, Buildkite, and Amazon’s Elastic Container Service. We also rely on the tried and true solutions: Rails, Postgres, and Redis.
We’ve listed the technologies that we work with last, because we believe that people care more about what they’ll be building and who they’ll be building it with than the exact tools they’ll be using. Our goal is to deliver software at the optimal intersection of quality and speed.
We’ve built our backend in Rails. It’s mostly an API for our mobile clients, but we have some web views for our internal admin dashboard. Ever since DHH published that video of building a blog in 15 minutes back in 2005, it’s been apparent that Rails is a framework designed to make developers happy and productive.
Our mobile apps are written in React Native, along with some functionality built in native code on each platform. The cross-platform reuse of React Native is beneficial, but even within a single mobile platform, we’ve found our development velocity to be higher than it is with native code. With features like hot reloading and better testability, the feedback loop in the development process is significantly faster. We released an open source library that we built to enable better unit testing of React Native components.
We deploy to Amazon ECS. While we enjoy DevOps work, we keep our production infrastructure as simple as possible. Many engineering teams seem to spend a disproportionate amount of time on infrastructure wizardry: orchestrating containers, configuring service discovery, distributed request tracing, and the like. We’ve positioned ourselves to spend the majority of our time on creating direct value for our customers in building our products. So far, we haven’t received a single email from our customers asking about our tech stack or deployment strategies.
We run Continuous Integration through Buildkite. When our backend builds are successful, we push a container to Amazon’s Container Registry. Our client builds can then pull down the latest backend container to run the integration test suite.
Our Interview Process
Our interview process is designed to make hiring decisions confidently, while also being efficient with candidates’ time.
We ask everybody interviewing with us to write a little bit of code as a work-sample test. Of course, it’s difficult to determine true engineering ability from a small bit of code, but we’ve found this exercise to be a representative indicator of ability.
Following the coding exercise, we’ll schedule a one-hour phone interview with two engineers at Root. We cover a variety of questions to assess breadth and depth of expertise, as well as engineering philosophy. We’ve shaped our topics to reflect the actual work that we do at Root and the skills we’d require for the position.
Next, we bring people in for an on-site interview where they meet with more members of the team, further share their capabilities, and get a firsthand look at what it’s like to be at Root.
Learning More & Getting Involved
You can learn more about the engineering team at Root through our Engineering at Root Podcast. In each episode, colleagues discuss topics in the industry and day-to-day work life at Root. We invite you into the conversation—check it out.
We value being a part of the larger communities around engineering, startups, and insurance. And we participate whenever we can. If you’re planning an event or would like to collaborate, please reach out to us—we’d love to chat.