Christine Mathiesen | Software Development Intern in London

Week Zero

Nervous is an understatement when I think back on my frazzled emotions during my first few weeks at Expedia Group. I was going into a year-long placement at one of the largest travel companies in the world with zero professional experience and a lot to learn, so it was safe to say I was shaking in my boots. 

The first week passed by in a blurry haze of friendly introductions, laptop setup and induction talks and tutorials. I spent 80% of my energy trying to remember the names of people around me, in the hopes of avoiding future awkwardness. There’s really no way to practice the skill of remembering names, so my best tip is to write down everything you can and try to remind yourself each time you greet someone in the morning. 

I’d extend this advice to remind you to write down all the little pieces of information you learn in your first few weeks, from how to log into company systems, to how your team’s core projects work. Listening and understanding all these new concepts is super important, but the reality is you’ll forget most of it if you don’t write stuff down when you’re first introduced to it. 

My fabulous team 

I am working for the Big Data Platform (BDP) team under the Hotels.com brand, which is a team that works mostly with Java backend applications focused around big data. The big data field was very new to me, so I immediately felt anxious about my lack of domain-specific knowledge. Random, indecipherable words, phrases and concepts were thrown about by my teammates, sending my head spinning during most meetings in the first month of work. 

Fortunately for me, the BDP team is very patient and eager to give detailed explanations about the projects they’ve been working on. I spent many hours listening to concept summaries, drawing diagrams and watching videos on a wide range of projects. It should also be noted that a large amount of my time was spent researching the tools the team uses for development, such as Maven and Jenkins, before I could start any of my own work. I even read some Git tutorials and contribution guidelines so I knew how to collaborate seamlessly within the team. The learning curve is steep when you’re new, and chances are you’ll be exhausted all the time, but it gets easier the longer you keep at it.

The first 2 months

Within a few weeks, I had been assigned my first ticket, which only involved altering version numbers of a few dependencies in projects. I was literally just changing a single number in each project (yep that’s it!) and I was still abnormally sweaty each time I had to commit something and open a pull request for the change. However, as I was assigned more projects, the scared feeling slowly ebbed away because I was continuously reminded that I’m part of a team. Each pull request opened by a team member gets reviewed by at least two others, where constructive feedback and suggestions are offered. This creates a great educational environment, where everyone is encouraged to evaluate different viewpoints and solutions. Each day, I learn more about good code practice (which is probably the most valuable lesson you can learn as a budding developer).

The next step in my journey was a ticket requiring research into a replacement for a tool we use within all of our other projects. The original scope was to determine if we could use the new tool as a ‘drop-in’ replacement for the old one without major changes, and initially this seemed like a ‘piece-of-cake’ ticket. However, this seemingly simple task ended up exploding into an exciting first contribution to an open-source project. It turned out that to use this replacement in Jenkins (our continuous integration tool), we needed an extra configuration parameter. I was tasked with experimenting on the open-source code base to attempt this change, and with the support of my manager/tech lead, I managed to implement what we needed and became an open-source contributor just a month in!

This submission came with a huge confidence boost and, gradually, I found myself attempting to contribute to discussions within the team more and more. It’s easy to convince yourself that you don’t have much to add because you’re still soaking up so much information, but speaking up is the only way to accelerate your learning. Speak up if you’re stuck with something because chances are, your teammates have seen it before and can fix it and explain it to you faster than you can rifle through StackOverflow. Ask questions if something doesn’t make sense to you, or even just to confirm your own thoughts so you’re not always doubting yourself.

Over the next two months, I started working on projects where I got to write more code or make changes and alterations to existing code. As part of my daily routine, I usually do a lot of research, experimentation and testing of concepts. This is combined with regular progress discussions with teammates, resulting in consistent iterations of work towards completing a ticket. Throw in occasional team coffee breaks, book club discussions and table tennis games and you have a good summary of a general day in my life. And on top of all that, mix in a huge list of intern workshops and socials, resulting in one of the best starts to an internship I could have asked for. 

Six month check-in

As I approach the six-month anniversary of starting this job, it seems appropriate to reflect on how much has changed since I wrote the earlier parts of this post. In particular I notice that, actually, nothing has changed in terms of the amount I need to learn. Each new ticket I get assigned brings new challenges and new technology I haven’t used before which is, in my opinion, the best thing that I could be offered during an internship. 

What has changed, however, is how fast I can pick up these new technologies. My background knowledge has increased enough to be able to get on with things myself by just trying out an idea, and iterating versions based off this. I can follow most technical discussions between the team, and occasionally voice answers or opinions too (but sometimes the acronyms still leave me stumped). I still ask the same amount of questions, but they tend to be more technical these days to help further my knowledge about language and library pros and cons. A key point I’ve learnt is you should always be able to justify the choices you make within your code. This pushes you to write better code, and to up your low-level language understanding which is fundamental to any programmer. 

Probably the most useful skill I’ve picked up is how to deal with failures and bugs. It’s important to understand why you’re facing issues, and to do what you need to be able to skim and understand code you haven’t written very quickly, and how to trace code to find the underlying culprit. You can debug and move on faster (and avoid the issue again in the future) if you understand why your code failed. An old habit that’s been hard to shake is to StackOverflow the error message and copy-paste the solution in, without really knowing whats going on. 

Recently, I’ve been working on a research-based spike that involves testing the capabilities of a new technology that we may or may not adopt in the future. This has involved a lot of trial-and-error code, documentation scouring and deep-dives into source code to get a better understanding of how mechanisms work. I’ve had to improve how I present technical findings, how to write more user-friendly documentation and how to write emails to scary mailing lists to ask for guidance from project owners. And this has all culminated in another open-source contribution back to the project I’d initially been researching. 

In summary

On this team, there isn’t a set agenda for work I’ll be completing throughout my year here. This means a more dynamic work day, where new issues pop up randomly and change expectations of the immediate future. I’m excited to see what will get thrown my way, and find each day to be rewarding no matter what I’ve worked on. Some days are more productive than others, but that’s bound to happen to all of us. Even if I’m particularly stuck, the support I receive from my team always helps me climb over that troublesome blocking issue. 

The point I am trying to make with this post is that this has been a great challenge, and for this, I am very thankful. The opportunity to learn and grow amongst such wonderful professionals will be priceless in my own journey, and I would greatly encourage anyone considering a placement to apply, no matter what field or company you’re looking into!

—

Join our Early Careers 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!