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 us at email@example.com. We’d love to hear from you.
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 for car insurance because most carriers base rates primarily on demographics, not driving. We’re fixing that.
Root is reinventing the broken insurance industry by using technology in smartphones to measure driving behavior. The Root app measures things like smooth braking and turning to determine who is a safe driver and who isn’t. By only insuring good drivers, we can offer more affordable rates. And the software the engineering team built from scratch powers it all.
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.
Our teams regularly gather for retrospectives 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 pursue. Reflecting on how to become more effective as a team is a critical component of our process.
Our product team sets road maps 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.
We release weekly for our mobile apps. 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 back-end, we release twice a day.
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 back-end 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 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 back-end builds are successful, we push a container to Amazon’s Container Registry. Our client builds can then pull down the latest back-end container to run the integration test suite.
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.
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.