Jobs
Search Expedia Group Jobs
How a role outside my comfort zone set me up for further success
Joe had a more intriguing introduction to life at Expedia Group than most but couldn’t be happier with what is only the start of his journey here. Discover how Joe overcame challenges and has embraced the ‘safe-to-fail’ approach and managed to find the right fit for him.
I joined Expedia Group in Brisbane back in February 2018. I am a back-end developer, mainly in Java and Spring, but with a broad range of experience across languages and roles. I originally applied for a Software Development Engineer (SDE) role in a team responsible for the “post-purchase” customer experience on the Expedia website. I did a technical test, an online screening and attended two interviews. But I didn’t get the position. However, my details were passed on to the managers of the Cloud Acceleration Team (CAT), a devops team that managed AWS infrastructure and deployment automation.
On paper, I was not a good fit for the role. If I’d seen it advertised, I wouldn’t have applied for it. The team was made up of system admins and AWS engineers, and a handful of developers. A team of operational guns who lived and breathed bash, CIDR ranges and NAT routing tables. The team were also the global experts on AWS ECS cluster management and deployment. Previously, I had used automation to spin up EC2 instances, but I had no idea about ECS, let alone the raft of other AWS services in use across Expedia Group. And I’d played with Docker at home and understood the concept of containers, but the thought of troubleshooting containerization issues made my head spin.
I met with the hiring manager to discuss the role. He had a vision of “beefing” up the “dev” side of the devops team. He came from a developer background himself and was trying to apply some of the dev best practices (design patterns, SOLID principles, clean code, unit testing, etc) across the team. He had plenty of experts in the team from an ops perspective – he was looking for experienced developers to help balance the team. I came in for another two interviews, one with the hiring manager and his manager, and another with two members of the team. I liked what I saw, but honestly, I was still scared that I wouldn’t fit in, that I wouldn’t be able to add value, or that this might be a step in the wrong direction career wise.
I took the role.
When I started, the learning curve was huge. I was frequently a helpless bystander when incidents occurred or during technical discussions. I had so many questions, but I didn’t want to railroad every conversation with constant interruptions for clarification. This was a massive shock to the system: I went from being an expert to a noob overnight. I couldn’t possibly learn everything at once, so I forced myself to make choices: I’m going to focus on learning about x at the expense of y and z. I had to keep reminding myself that I was part of a team, I didn’t need to know everything, I could depend on others to pick up the slack. Still, sometimes it was overwhelming. Fortunately, my team were super supportive, patient and helpful.
There were plenty of things I could do without help from day one if I played to my strengths. I knew my way around git, Jenkins, Nexus, etc. I could check out code, install and set up the prerequisite tools, get things building locally, run the tests, and start exploring. If there were problems that I was capable of debugging with minimal support from the team, I jumped on those. I started to add value.
And I threw myself into the “ops” deep end. I read a lot. I read Confluence (web-based corporate wiki) pages and watched brownbag recordings. I did courses online. I attended study groups. I got myself on the support roster. I started picking up support tickets, which meant communicating with the users of my team’s automation. Trying to understand their issue or problem really helped me to learn.
I made mistakes. I pushed PRs that broke things in production and had to clean up. But the “safe-to-fail” culture and continuous deployment practices at Expedia Group made this relatively pain-free: if you break something, you can rollback or fix forward in minutes.
There were times where I struggled with self-doubt, but I had people around me who could help perk me up with a quick pep talk. I had to keep reminding myself why I was there: to share my dev experience with the team, to help improve processes and to make our codebases cleaner. Little by little, I learned to “walk” again. About three months in, I was given a fairly isolated piece of “dev heavy” work to lead, one which allowed me to play to my strengths, but still with plenty of learning opportunities. This was a real confidence boost for me. From there, I worked with a global team on a deployment automation implementation feature and took ownership of the overall code design – there was plenty of implementation detail I didn’t fully understand, but that was ok. I started to find my “place” in the team.
I also started to build relationships with Expedians outside my immediate team. I volunteered to co-facilitate a Code Retreat in the Brisbane office. And in my second year, one of my colleagues and I spoke at the internal tech conference about our experiences applying OO patterns to one of our Ruby codebases. I started running refactoring workshops and got to travel to our offices in London, Seattle and Gurgaon to deliver them face-to-face.
After two years, I did a rotation to another team, a move that has since become permanent. My new team aligns much more closely with the dev teams I’m used to working in. But I’m now one of the go-to people for help with AWS, infrastructure and automation related questions and issues. I have a much better understanding of firewalls, SSL certs and networking. I am comfortable teaching others about ECS and the other AWS products. I can knock out a CloudFormation template with my eyes closed (almost). I am called upon to make recommendations or decisions about how to design and implement my team’s runtime environment. And I’m currently leading a project which is largely related to AWS infrastructure. There is no way I would have been able to ramp up as quickly as I did across such a broad range of subject matter had I not taken my initial role at Expedia Group.
Expedia Group is a great place to work, with a great culture, and some of the best technical people in the business. I love working here, but most of all, I am grateful to Expedia Group, my managers and my team, who put their faith in me and gave me their support as I embarked on a journey well outside my comfort zone.
Join our Talent Community
We’re looking for outstanding talent to join us on our purpose to bring the world within reach. By joining our talent community, you’ll have exclusive access to our latest opportunities, events, interview advice, and global insights from our Expedia Group leaders. Sign up now!
-
Previous Post
Virtual Intern Life at Expedia Group
-
Next Post
Traveling Solo while Latinx