The best cultures are formed organically by having like-minded people come together with a common purpose. A healthy engineering culture can't be forced but it can be shaped with time and commitment.
- We want to enable our engineers to do their best work.
- We want to keep a high standard for our product and code quality.
We've found that the best way to do this is through a culture of trust and autonomy. Our engineers have the freedom to choose how something is built and the ability to take on responsibilities beyond just programming. It's a great place to learn, collaborate, take on new challenges, and have fun.
Maintaining this culture requires us to:
- Hire great people and trust them to do their jobs.
- Favor tools over process and keep process lightweight.
- Make sure we are always improving.
It starts with hiring and from the get-go, we want to show that Hipmunk is different. Our interview process is geared towards practicality and focuses on answering the question of whether or not the candidate will be able to do the job. We don't ask brain teasers or obscure CS questions (like how to rotate a binary tree) because you don't need to know stuff like that off the top of your head to be successful at Hipmunk. We ask questions based on actual problems that we've encountered and look for people who are smart, easy to work with, and can get things done.
We describe our workflow as agile-ish. We use Jira to manage tasks but don't take it too seriously. We are wary of scrum masters and don't believe in story point estimation. We organize ourselves around key projects with cross-functional teams made up of engineers, designers, and product managers. Each team starts their week with a quick sync on Mondays to coordinate and go over the tasks for that week. Every other day we have standups after lunch. On Fridays we end a little early and give people the opportunity to show off their work.
And we like to have fun. We take lunch breaks seriously: people play pool, board games, video games, or just hang out. We have regular events like happy hours and game nights, as well as the occasional company trip (last one was to Mexico). We make sure to celebrate the big wins!
Tools Over Process
Whenever possible, we prefer to build tools over implementing process to keep things organized and safe. Tools are more reliable and actually boost productivity whereas process often hinders it. For example, it used to be that only a handful of engineers could deploy to production. These gatekeepers existed because deploying was complicated and error-prone and only a few people knew the system well enough to use it. But the process was a growing bottleneck so we decided to overhaul the deploy tool and make it so safe and easy to use that anyone could deploy.
The fact that anyone can deploy to production means that everyone is also responsible for quality. We set a high bar for ourselves when it comes to quality and at the end of the day, it's up to each engineer to make sure their patch does what it's supposed to and doesn't break anything. Of course we have tools and processes to assist with this.
One process that we have found to be invaluable is code reviews. Every patch that ships to production must be code reviewed and signed off by at least one other person. Code reviews are great for getting feedback and catching bugs early but an often overlooked benefit of them is that they provide an opportunity for education in both directions. You'll learn a lot from people reviewing your code but you'll also learn a lot from reviewing other people's code.
We're big fans of automated tests. Automated tests are an investment that take time up front but always pay themselves off in the long run. Any code that touches our backend must have tests to pass our code coverage health check. If something is too difficult to write an automated test for and/or a patch is particularly risky or complex, we encourage manual testing. Engineers are responsible for understanding and cross-checking specs and general checklists to ensure this. When a pull request is created, we automatically create a staging environment for it where the author and reviewers can go to test it.
We like to move quickly and iterate. We try our best to make sure things go smoothly but when mistakes happen, we don't shy away from them. Instead, we learn from them. One way we do this is through post-mortems. Post-mortems are a way for us to objectively walk through a problem and identify what went wrong and how we can do better. It's not about who made a mistake but instead about learning what circumstances led to a mistake being made so we can address them.
We believe it's important to encourage continuous education and do so through Nerd Trainings. Nerd Trainings are tech talks that occur every other Wednesday. They could be an info session about a new technology, a workshop on how to use a tool, or a Q&A about an important part of the Hipmunk stack. It's all in the spirit of teaching something to your peers.
We also believe in constantly improving the product, usually incrementally but sometimes radically. We encourage innovation through Foo Weeks, which are a weeklong hackathon that occur once a quarter. It's time for engineers to work on whatever they want, whether it's experimenting with different ideas or just learning something new.
Want to be a part of the team? Check out our jobs page!