State of Engineering @ Beam
Thinking about applying for an engineering role at Beam? This might help you get a glimpse of how we work!
Product and Platform
We have two main types of teams at Beam. Product teams which focus on specific business areas like acquisitions, renewals, claims etc. and platform teams which work in tooling for our product teams, and non-functional requirements like uptime, performance, and security.
Product teams have stakeholders both internal and external to Beam. For example, our claims product team works tightly with our claims processing team, but our acquisition team might be more focused on how brokers use our applications.
Platform teams’ stakeholders are the product teams themselves. They continuously seek feedback for new tools, and try to reduce the amount of toil our product teams go through while working on their features.
Beam Agile Methodology
Beam follows a hybrid dual track Agile methodology somewhere between Scrum, and Shape Up (we wrote about our Shape Up transition previously here). At its core, we have two parallel tracks: discovery and delivery.
- Discovery — Our product managers, engineering managers, and tech leads actively poll stakeholders to understand what problems we should be solving and which opportunities we can invest in in upcoming cycles.
- Delivery — Our engineers break down pitches by quickly iterating on solutions. Our approach is largely to solve the problem simply first, then see how else we can delight our users within each six week cycle.
Most of our applications are written using Ruby on Rails, and ReactJS. All engineers at Beam are welcome to write both backend and frontend code. Engineers own code quality across the whole stack, and we try to automate our tests as much as possible.
Backend
Our tool of choice for backend work is Ruby on Rails, although we have some services written using Python and leverage AWS Lambda to interact with them.
The Monolith and Microservices
Early in our company journey we were mostly concerned with validating our business rules and moving fast so we followed the Monolith First approach. Since then we’ve created discrete microservices for our high traffic areas, but we still leverage our monolith for some of our applications.
Our monolith has a comprehensive CI pipeline including: Danger, Rubocop, Strong Migrations, and requires 80% code coverage to mention a few. Even brand new engineers can work with large parts of our code with the assurance it will not break production. We’ve also recently begun our journey into Packwerk which has provided even more structure to an already elegant monolith.
Our microservices that also leverage Rails have very similar CI checks thanks to a homegrown linter which uses the Ruby abstract syntax tree to ensure we are configured correctly. The linter outputs a score for each microservice, and if it dips below a certain threshold our platform team will hear about it.
Frontend
Our frontend applications mainly use ReactJS but we’ve also started to move towards Next.js and Typescript in some key parts of our applications. We have a component library that is entirely typed, and we use Docusaurus to generate its documentation.
Our frontend applications also have a comprehensive CI pipeline including: Coveralls, Danger, and Commit Lint. Our dependencies are kept up to date using Renovate. And our bot PRs are automatically assigned to corresponding teams using a Github labeler.
Mobile
Our mobile application leverages Typescript and React Native. Its code coverage threshold is higher than our other projects because the release and hot-fix process is slightly slower. It’s currently sitting at around 95%*. We additionally run automated end to end tests when preparing for a release.
Beam CLI and Ephemeral Environments
A key part of the engineering experience is using our homegrown command line interface beam-cli to spin up staging environments we’ve affectionately called ephemerals .
Early on in our growth, when we only had around 15 engineers, we had two staging environments. If you wanted to use one of them, you had to poll the other engineers and see if any were available. Now through this CLI, engineers can spin up staging environments from their pull requests to quickly gather feedback from stakeholders or to test out features in a production-like environment.
Currently it takes about ~5 minutes to spin up each environment, which is completely free of Protected Health Information but still contains all the data you might need. Ephemeral environments are deployed in a Kubernetes cluster, so any updates to your branches are automatically reflected as soon as it is packaged up. If you only need certain services you can specify that as command line arguments and each environment’s time to live is customizable.
Ephemeral environments make user acceptance testing a breeze, and if we ever need to conditionally enable certain features while testing we can do that through our feature flag service called Flipper.
Working Groups
We have several working groups that are modeled on the Spotify squad model concept of tribes. Our working groups continuously discuss best practices, tech debt ideas, and exploratory experiments using new technologies and processes. They are groups of Beamers across our organization that share a common passion like: frontend, backend, data, or mobile.
Additionally, some of our working groups focus on non-technical subject areas like our interview and onboarding practices, or focusing on improving our remote first culture.
Overall, we’ve come a long way are excited to continue experimenting with new tools and processes that make our work more efficient and fun! If any of this excites you or you would like to know more, leave us a comment or check out our job openings at https://jobs.lever.co/beam
Disclosures
*Based on Beam internal data, 7/11/2022.
Any product names, logos, brands, and other trademarks or images featured or referred to are the property of their respective trademark holders. These trademark holders are not affiliated with Beam or it’s website. These trademark holders do not sponsor or endorse Beam or any of its products or comments. Beam declares no affiliation, sponsorship, nor any partnerships with any registered trademarks unless otherwise stated.
For informational purposes only and not intended to be relied on as complete information, or to be construed as tax, legal, investment or medical advice. This is not a sale of or an offer to purchase a benefits plan from Beam.
