New Hires: A Welcome Letter to Hipmunk Engineers ✈︎

True to their website claims, Hipmunk delivered delight from Day One for me when I was hired to be the newest engineer on the Platform team. My arrival time was arranged well before my start date and instructions for whom to meet where were precisely planned. I received a boisterous hello from our office manager, who took me to my desk that was covered in welcome signs and gifts and, most notably, a printed schedule for my first day. It started out with coffee and a tour of the building, then moved on to me picking up my laptop from IT, after which was catered lunch with the team and other Hipmunkers, followed by daily standup, and ended with me setting up my development environment according to well-documented instructions and deploying a patch to Production my first afternoon on the job — all the while being introduced to many friendly new coworkers throughout the day. (I might have written a run-on sentence or two that day as well.) It couldn't have been a cooler, more comfortable way to start my new job. I felt at ease and at home immediately.

I had heard and read so many horror stories about the total absence of engineering onboarding at other tech companies that it was a huge relief that my experience was what it was. But I had confidence coming in because Steve Huffman, one of Hipmunk's cofounders who eventually returned to his Reddit roots, had visited my dev bootcamp (Hackbright Academy, where he's been a mentor for years) and couldn't stop raving about the culture and how hard it was for him to leave.

I should also note that even before my start date, Christopher Beacham (AKA Lady Red, who is a senior member of the Platform team) sent me several in-depth emails demystifying the asynchronous Tornado framework that I was unfamiliar and would be working with. She was so generous with her time and then volunteered to be my mentor before I had even set foot in the office! And better still, it quickly became clear that every member of my team was excited and willing to be my mentor. I couldn't have felt more well-cared-for in my new role. It was also suggested that I join Hipmunk's #onboarding Slack channel where dozens of co-workers eagerly answer your questions like "what is the code review process here?" or "what method should I use to update foo?" or even "where's the best place to get coffee outside of the office?" I learned pretty quickly that the #onboarding channel is actually used by new hires and veterans alike.

Two other devs joined shortly after I did, so various senior engineers set up a Hip School for us. Over the course of a week, we spent a couple hours per day being introduced to Hipmunk's tech stack, products, processes, and people. It was enough to help us be able to navigate this new world of industry and internal acronyms and terminology, without feeling overwhelming. We immediately started attending weekly nerd lunches, which are brown bag tech talks on topics like "debugging with Charles and pudb" or "Hipmunk's ORM" voluntarily presented by team members on Wednesdays.

When I was assigned my first JIRA tickets, they were explained to me in-person, which was both a valuable and efficient way to introduce me to my initial tasks. We talked through the requests, requirements, changes, related files, and testing approach. Whenever I hit a roadblock, several engineers were available to help talk me through next steps or point me to a file or method that would help me get unblocked. I felt well-supported from all sides.

What new engineers can expect at Hipmunk

At Hipmunk, every engineer has the permission and power to deploy to Production from Day One. This was a notable shift in practice for me, having come from a background of working on more traditional sites like that took several release managers, release engineers, and a senior technical project manager a couple of hours to deploy with a considerable amount of coordination and effort.

From the start at Hipmunk, we are set up for success and able to immediately have an impact and not just feel like, but actually be, a productive and contributing member of the team. What I love most is that because one of our core engineering values is to be kind — which as a female engineer is as important as having empathy — new engineers can expect to feel safe asking questions or making mistakes.

To kick off every quarter, we have a Foo Week when everyone can work on any project idea that interests them either individually or with a team that we don't typically work with on a daily basis, as long as we are learning and growing — upholding another one of our core engineering values. During my first Foo Week, I wrote a proof-of-concept Slack chatbot that allows users to query our wiki for questions typically asked in the #onboarding or #engineering channels, so my chatbot was answering the "what is the code review process here?"-type of questions instead of a human. Dream job status officially achieved.

With our managers, we come up with measurable goals for each quarter. For example, one of my goals is to get better at writing tests, so one way I can do that is to be responsible for getting a certain part of the codebase up to 100 percent coverage; this is what is meant by measurable. Our managers do their best to keep us out of meetings so we can focus on actual work. They also try to minimize context-switching, the ultimate productivity killer, as best they can. We have 1:1 meetings every two weeks to check in and make sure everyone is happy and getting the support they need and feeling in a position to do their jobs well. And of course we can always chat with our managers informally outside of that schedule if any issue ever comes up.

With our team members, we collectively do code reviews of each others' pull requests on a daily/weekly basis. This inherently promotes knowledge-sharing across the engineering organization and can often be an opportunity for new engineers to offer fresh eyes on code that could use some attention and upkeep. Without a QA team, writing tests and doing code reviews are a couple avenues through which we can achieve another of one our core engineering values to "own your work."

Ways that I was able to contribute while still learning the ropes

We all come from different backgrounds, so even though I was new, I was still able to contribute in ways that were particular to my personality and past experience. Having fresh insight on joining Hipmunk as a new employee, I wrote a widely-used welcome email template for future new hires with useful links that would help them get through their first days or weeks. I also compiled an extensive glossary of Hipmunk- and travel industry-specific terminology that is basically a foreign language until you get accustomed to it. Even our founder and CEO, Adam Goldstein, said there were some things on there that he hadn't known the definition of!

Coming from an engineering project management background, I suggested using a consistent concept of doneness on a request when communicating to our Product team. It ended up being "deployed to Production," when it previously could have meant "code-complete but not tested," "code-complete with tests written," "in code review," "being revised after code review," or "deployed to Production." I've also emphasized the importance of having designs finalized before making any development timeline commitments, so we can be more realistic with our estimates and planning. I also requested setting up a separate Slack channel for deployment status updates, which are pretty much constant throughout the day, to reduce noise in our #engineering channel that can now more easily be used for actual engineering discussions.

I've set up team outings for Hipmunk engineers to more cohesively bond beyond just working together. I've been able to help new hires with general questions and coding, taking some of the weight off of senior engineers doing all the ramp-up and explanations. I've given feedback and new perspectives on existing processes. These have been pride- and confidence-building experiences for me here considering they were all accomplished when I was new to Hipmunk. The best part was that my ideas were always heard and welcomed.

Platform team

Platform team-bonding outing to the Houdini Escape Room at the Palace of Fine Arts. We couldn’t stop talking about it for days after, it was so fun.

Which traits could help new engineers be successful

Remembering the fact that we all come from different backgrounds, I wanted to share some of the parts of my personality that have helped me be successful as a new engineer at Hipmunk — and they will obviously be different for everyone. First and foremost, embodying the shoshin mindset, which is all about openness, eagerness, and fearlessness to "be the beginner," inherently keeps me in sync with Hipmunk's core engineering value to constantly learn and grow. It also helps to be humble enough to be transparent about what I know and what I don't know.

My main obsessions throughout my life have been skateboarding, fishing, and muay thai kickboxing; from those, the necessity of having determination, grit, and the ability to accept failure as a part of everyday life were ingrained from a young age. As a new engineer, these traits have been essential in keeping me positive and motivated. For instance, instead of feeling frustrated or defeated by bugs in my code, I find absolute delight in debugging and can almost view it like a game, eliminating them one by one. Then each time one is corrected, it feels like a little reward and I get to experience that feeling many times throughout every workday.

Early on in my engineering project management experience, I became aware of the need for engineers to ask clear, well-crafted questions in order to be respectful of people's time and to demonstrate that you value it so they want to help you. Instead of walking up to someone's desk and saying, "x is broken," give them the time and space to respond asynchronously (via Slack or whichever app your company uses) and express the request for help in written form with this general structure: "I'm working on Jira ticket x. The request is to add a new form page at /xyz url but I am not seeing it in my dev environment. I have tried [thing1], [thing2], and [thing3], have confirmed that I am running x script, and expect to see foo/bar/baz but I'm actually only seeing foo on the page. Here is the link to my pull request. What do you recommend I try next?" In a similar way, writing pull requests with the same amount of context by predicting questions that might be asked is a skill that all of your engineering teammates will appreciate.

Basically, thinking about the future you in the way you code, comment, write and review pull requests, and ask questions will help you be a better engineer.

The coolest thing about coding to me is that there is no finish line to reach where you can ultimately know everything there is to know. You can always write better code — make it more efficient, more scalable, more secure, etc. That aspect of coding syncs up perfectly with Hipmunk's core engineering value to constantly learn and grow. If Hipmunk's culture of trust, learning, and growth sounds like one you'd like to be a part of, please check out our jobs page. My contact info is ahm at hipmunk dot com if you want to chat about becoming an engineer.