Table of Contents
On December 3rd 2018 I boarded a one-way flight from Perth, Western Australia to the United Kingdom. A week later I started a new position as a Senior Software Engineer within the Cloud Platform team at Condé Nast International. My partner had relocated to Cambridge, UK at the beginning of March 2018 after accepting a PhD position at Cancer Research UK Cambridge Institute. I stayed in Perth to organise our affairs and prepare for what would be at least a 4 year adventure on the other side of the world.
I’m sure it won’t surprise most people to hear that in addition to shipping all of our belongings, organising the relocation of our dog, selling cars and furniture we weren’t taking with us, and a host of other things, that an important item on the relocation checklist was ensuring I had a job lined up when I arrived (rather than risk the possibility that I would struggle to find one after moving). The purpose of this blog post is to describe the methodology used to find a job, and how my priorities changed over time. It should go without saying that a lot of the decisions I made, and what I considered important when selecting a job and company is personal preference, but hopefully you manage to take away something valuable anyway.
An Opportunity Arises
I think one of the first questions I get when I tell people about my UK job hunt is “Why so many interviews?”. The short answer is “Why not?”, but the longer, much more accurate answer is that I realised my relocation was an opportunity that most people rarely get. I was in a situation where I:
- Had flexibility in my relocation timeline.
- Lived alone and had free time in the evening.
- Was 8 hours ahead of the UK, which meant interviews didn’t interfere with my current employment.
- Had a skillset that was in high demand.
What this all meant was that I was incredibily lucky to have an opportunity to take a broad and methodical approach to the interview process. I was able to cast a “wide net” so to speak, and get a good understanding of the technical and professional landscape within Cambridge and later London. I was also able to move past just the technical aspects of the roles - I was able to question not just the culture, but the company’s attitude towards equality and social responsibility. In the end it was these questions that played the largest role in my decision making process.
Let’s Start With The Numbers
Over the 5 weeks I spent interviewing I spoke with a total of 39 companies, or should I say - I remembered to keep records of interviewing with 39 companies. It’s worth noting that I may have missed a few companies, and I didn’t keep a record of every time I spoke with a new recruiter.
Of those 39, I declined to continue with 20. This was for a range of reasons - including salary, culture, thoughts and focus on diversity, or location (more on this later). 8 companies declined to progress with my application; 6 “ghosted” me, which in this context means that I never heard from them again after an interview (and in most cases even after I attempted to follow-up); and finally - I received 5 official offers.
In total I participated in at least 79 interviews (again, add a couple I might have missed). There’s not much more to say on top of the numbers below. Most companies seemed to have jumped on the take-home assessment bandwagon - most of which were, at least in my experience, fairly relevant to the job I was being interviewed for; however, a few still insisted on rather pointless algorithm and computer science heavy puzzlers.
For the most part, I applied and interviewed for Senior DevOps Engineer (NB: I’ve lumped ‘Principal Engineer’ in with Senior Engineer) and SRE roles.
Almost a quarter were “lead” level roles which would have involved having direct reports. Those that know me will also know that I’m not a huge fan of the management pathway, hence I placed extra importance on the amount of engineering work these roles would involve. In the end I only chose to progress with one lead level role to the final round, which I eventually declined an offer for.
I’ve never been a huge fan of the DevOps as a title trend that is currently happening, but I also understand that it’s a direction the industry has chosen to take - as such I have a basic principle when evaluating a role:
No matter the title of the role advertised my choice to progress with a role was always primarily influenced by the responsiblities of the role as told by the company. Me
It doesn’t take long to filter out companies that aren’t taking DevOps culture seriously, as long as you’re asking the right questions (more on this later).
The Nitty Gritty: Logistics
The timezone difference between Western Australia (GMT+8) and the UK (GMT/GMT+1) was a huge advantage in scheduling interviews without having to worry about clashing with my existing full-time job, enabling me to interview between 6pm and 1am during my time. Of course, applying for so many positions, and interviewing from across the world introduced a whole other set of complications.
Let’s start with some of the most obvious things - I used a standard 3-page CV and a standard cover letter, neither of which I bothered to customise for the roles or companies I was applying for. While I’m not opposed to taking the time to tweak and customise for specific applications, in this case I decided for the sake of time it wasn’t worth the hassle. It’s important to note that there is a level of priviledge that comes with this - the tech market in the UK very much favours the candidate, and thus under different circumstances I might have acted differently.
One of my biggest concerns was interview methods. I was asked on a number of occasions if I had plans, or means, to come to the UK for the purpose of a face-to-face interview. Most of the time the expectation was that it would be on my own dime. This was an instant non-starter for me because, to me, it displayed a cultural issue within the company. If phone and video conferencing wasn’t sufficient then it raised serious questions around workplace flexibility and management culture. NB: The vast majority of companies were able to accommodate this requirement. Any company that couldn’t/wouldn’t is not included in the 39
I mostly applied for jobs that came under the banner of “DevOps Engineer”, “Platform Engineer”, or “Site Reliability Engineer”, and nothing that appeared lower than a senior level. I had a few basic technological criteria:
- Firstly - Scale. I wanted to work with systems that reached millions of people. This can mean different things within different contexts, but the basic premise is that the role should involve large scale systems (for whatever the definiton of “large scale” is for the industry).
- Kubernetes. This one should be obvious for the space I work in. Kubernetes is becoming increasingly popular, so gaining experience while it’s still (relatively) early days is a huge plus for my career.
- Cloud. I wanted to stay away from on-prem or data-center based compute. Again, continuing to work with cloud technologies would be beneficial for my future employability.
- Go. This wasn’t a “must have”, but I enjoy the Go programming language, so this would be a plus for me.
I kept the technical criteria pretty small because, outside of a few basic things, I wasn’t overly fussed with the tech stack. My primary focus beyond the list above was the culture and values of the company.
Down The Learning Brick Road
There were some interesting lessons over the course of those 5 weeks, so I’m going to go over a few of those lessons learnt, which will also cover how my thought process evolved and my priorities changed over time.
Something I learnt very early in the process is that scheduling is a nightmare, especially from across timezones. It became obvious fairly quickly that mutliple back and forth emails or phone calls in order to schedule an interview wasn’t going to work. The solution to this was to start using a calendar service. In my case I picked calendly, which allowed me to pick a timespan (6pm to 1am) and synced with my Google Calendar. This meant I could simply send my calendly link to a recruiter or interviewer and they could instantly book the required amount of time for an interview.
Which brings me to the second lesson I learnt early on: scheduling breaks. It turns out if you just send people your availability, that gets used up pretty quickly. On the plus side, the calendly link was working! However, I quickly found myself with a full calendar, and no time for dinner, take-home assessments, or even just half an hour of downtime to recharge. The solution is a pretty obvious one - I simply blocked out time in my Google Calendar, which synced back into calendly. Nice and easy!
One thing to also keep in mind when scheduling interviews - if the interview was organised via a recruiter, make sure you account for the time before and/or after the interview to speak with said recruiter. Recruiters LOVE to not only pretend they’re experts at interviews, but also that you have no idea what you’re doing. So make sure to allocate time for the pre-interview conversation about how the interview will be structured, and what you should focus on with your answers; and the post-interview debrief, where they’ll want the minute-by-minute replay of the entire conversation. (Recruiters: This might come across as if I hate you, but I don’t. A lot of what you do is very important, but sometimes it feels like you might have an inflated sense of self-worth when it comes to this process.)
When I started this process I thought I had a pretty clear idea of what I was looking for (beyond the technical). Initially I limited my search to opportunities that were in Cambridge or fully-remote, while prioritising tech stack and salary once I got into the interview. It didn’t take long for that to change. I realised a few things quite quickly:
- Beyond my basic requirements (that are becoming quite common now), I wasn’t too fussed about tech stacks.
- Salary was a primary factor in extending my search to include London (£20-30k difference on average), but the differences in salary between roles within London wasn’t as important to me as I thought it would be.
- I was limiting myself severely by not including London jobs in my search.
I decided to extend my search to include London companies, and in the process found myself with a new set of priorities. Flexible working, such as working from home days and flexible hours, and company culture, such as opportunities for personal growth and how well I got along with the team, replaced my previous priorities.
Most importantly though - I started asking companies how they approached diversity and inclusion. Did they consider diversity and inclusion an important part of building a great company? How well were different backgrounds represented within their tech teams? What, if anything, were they doing to improve diversity and become a more inclusive company? The answers to these questions will tell you a lot about what the company prioritises, which (in my experience) translates quite well to how they treat their employees in general. In the end it turns out the only company to ask me these questions first was the company that I accepted an offer from.
DevOps Culture? or Just a Title?
As I mentioned before - I’m not a huge fan of the DevOps-as-a-Title or Team trend that has become quite prevalent in the industry. However, it’s a fixture that’s probably around for the long haul. I also don’t place a huge amount of importance on job titles as these titles generally don’t have much meaning outside of the context of that company. As such, I realised the importance of being able to gather a strong understanding of the core responsibilities of the role, along with how I would be expected to interact with other people and teams.
One key question for me was in regards to the on-call policy and the expectation of after hours support for the applications running in production. It became obvious that many companies (especially start-ups) had an expectation that “the DevOps guy” would be on-call for all applications running in production, while product development teams were only considered second-line support (if at all).
Another key question was in regards to the ownership of the delivery process. It’s one thing to have ownership over the Continuous Integration (CI) and Continuous Delivery (CD) system, and another thing to own the delivery process of the applications utilising that system. I discovered that many companies expect “DevOps Engineers” to own CI/CD of applications running in production, rather than giving product developers responsibility over understanding and improving the delivery of their apps. This is a huge red flag regarding the DevOps culture of a company.
What Makes My Blood Boil
I’m going to keep this section short, because most of these things that really annoy me are fairly self-explainatory:
- “Bro culture” - The prevalance of obnoxious and arrogant dudes that consider their “fast-paced, take no prisoners” workplace so awesome.
- Take-home assessements that have no relevance to the role. Most of these consist of obscure computer science puzzles that you would find on LeetCode or Hacker Rank.
- Take-home assessments that require more than a few hours. These aren’t as rare as you would want to think. At least 2 of the assessments I completed expected more than 10 hours of committment. This kind of expectation is a form of bias and arbitrary gate-keeping. Employers, please stop this.
- Companies that won’t discuss salary upfront.
- Long, fluffy questionnaires in application forms. E.g. “In 150 words or more explain why you want to work for
dime-a-dozen tech company?”
- No/low investment in the process by engineers. Don’t make me wait 2 weeks for a tech interview because your engineers “don’t have time”. Either make them find time or stop wasting mine.
- Companies that require on-site interviews. As before… ⬆️
So - this has gotten pretty long. I hope someone finds value in my experience! To conclude this post I want to say this: almost 6 months ago I started a position with one of almost 40 companies I spoke to - Condé Nast International (CNI). I’m pleased to say that almost 6 months later I don’t regret my decision for a single second. I love working at CNI. I work with awesome people, solving interesting problems, at a company that cares about creating an amazing, diverse, and inclusive place to work. I’m thankful that I had the priviledge to speak with so many companies and eventually make a definitive decision.