As you may have recently seen, I've recently gone through the interviewing process and joined Deliveroo as a Senior Software Engineer.

This was different to my last move to the Cabinet Office, as I only applied for that role, whereas this time I wasn't really sure what I wanted, and so wanted to interview at a few great places and see what felt like a good fit for me.

I naturally wanted to blog about the processes, talk about how I felt the interview processes have improved/not been as good, and give folks a chance to learn from my experience, as well as be a chance for me to look back on this in the future.

As I was part way through the process, I attended Carol's talk at Women in Tech Nottingham about "Looking for a job, while looking after yourself", which was really great, and I recommend a read of the blog post writeup.

One thing Carol mentioned was to stretch out the process to let it fit within your life, which I actively did the opposite of - for reasons I won't go into so much - which in hindsight worked out well, but I know that I would've regretted if the results weren't positive.

If you're not pushed for time and don't want to "just push through it" like I did, please follow her advice 😅

Results

Before I go into the actual lessons I learned, and how the overall process was, it may be helpful to see the rundown of where I applied, how far I got through the process, etc:

Very different to the stereotypical interviews

Firstly, I'm really glad to say that the interviews I did were not the stereotypical tech interviews. As an industry, it's great to see we're getting better, and moving away from whiteboard coding, dealing with super abstract problems like inverting a binary tree, or doing things that we'd generally just use a Search Engine for in our real jobs.

Unfortunately one company - who outsourced the first part of their interview process - had something similar to this, which I wasn't impressed with. There were some arbitrary questions around several topics, and then in the coding exercises you were asked what the O(n) complexity of time/space were. I was very close to dropping out of the process there and then, because I had such a bad experience with the interview, and thought I'd bombed it.

While I was still in the process of interviewing, I made a point of challenging it and asking whether it was representative of the role, to which they said no, and I was a bit like, well why do it then? 🤷 It's also one of those things that I'd argue is less important, because you may be pre-optimising a solution that may be used for a proof of concept and then be rewritten, or you can learn through production metrics or performance testing that the area of the codebase isn't ideal.

Take home tests

Something really positive was that all the companies I had practical exercises with had the option - if not the requirement - that the technical test would be a take home test, instead of an in-person coding challenge.

My interview for the Cabinet Office, which involved building a very basic restaurant till was a live coding challenge, and I found it worked really well. I got into the groove quickly, was able to show off TDD, software design, and thinking out loud. I was really happy with the interview and felt it was a good pair programming session rather than an interview.

But it's not always like that, and it's really nice to get the chance to take it away and do it when you have more time. I realise there's a balance between someone being able to take i.e. 3 hours to do an interview during working hours to do a coding interview and 3 hours in their spare time (where it conflicts with being a caregiver, hobbies, etc), and for me it worked out, but especially if you're doing a few of these interviews, it may not be as easy.

While doing the interviewing, I was reading a lot of posts from Jacon Kaplan-Moss on work sample tests, which I agree are a much nicer indicator for interviewing.

These take homes were a good amount of time, had a good, short, brief, and for each of them there was a chance to chat through things further, as well as one company asking me to make changes on top of it.

I definitely spent a bit more time on Starling's take home test, as I used it as a chance to play around with some concepts and types of testing that I'd recently been looking at for my job at the time, and I used it more as a side project than an interview, which wasn't ideal!

Seeing my gaps

It was really good to see that I was able to pick up on a few of my gaps as an Engineer, and although it was a little bit humbling, it was good to know.

In one role, there was a strong focus on concurrency of distributed systems. The technical interview involved delving into how a concurrent set could work, and I couldn't really answer. I know it's probably good to have the understandings of some of the core pieces of concurrency for a job that's working on highly distributed and concurrent systems, but isn't that also the point of having a good set of concurrency primitives in libraries?

Across several roles, the need to build and operate scalable, distributed systems was key, and was one of a big draw of the role. I realised that all of the systems I've built in the past have been low and consistent traffic patterns, not very scalable, and going into roles where you needed that experience, it was very clear to myself the gap.

Systems design / architecture interview

I've not done a lot of systems designs, and it was really highlighted during the process as a gap. I spent a bit of time reading through the content in this resource, and it turned out to be the only real area that I prepared for.

I discovered that the way I go through these designs is to think about the MVP and iterate over it, talking through my thought process and how we could tackle challenges as they came up. This is important, because not everyone liked this.

The first of these I did was really great, I had an interviewer who was really nice and made me feel at ease, and quickly understood that I was stepping through the solution incrementally, and played off that. It was an interesting problem, and one that was mentioned on Glassdoor, so I'd had a bit of chance to think about it, albeit not too much, given I knew it may not still be in use.

This other company, however, gave me feedback that "if this was how you worked on a team, it'd be perfect, and we love it. But in an interview, that's not what we want" 😕🤔

"Senior" is a title with a different meaning everywhere

Something I knew before going in, from folks who recently interviewed there, was that Monzo has a very high bar for their Senior engineer roles. A friend who recently moved to AWS and was trying to get me to join, and through looking at job roles, I saw that their Senior role required ~8 years of industry experience.

It reminded me that although I think of myself as a Senior, and that I've been a team's Tech Lead, that's been for a smaller scale of things and my experience in one place does not equate to another, and to be a little humble rather than expecting the same title everywhere.

I really would like some level of standardisation between roles across the industry, but I'm uncertain if it'll ever happen.

Prepare to wait a bit

My situation was a little bit more difficult because I was constantly watching the clock, as I wanted to hand my notice in before my probation period ended, at which point my notice period would jump from 1 to 3 months.

This meant that each additional day of waiting for a reply made things slower, and as I've found I'm not a fan of not being in control, this made it a little frustrating. Fortunately it all turned out OK, but the longer things went on, the more conversations with my then-manager I felt I had to lie, or at least conceal my true feelings in.

Negotiate!

When I went into the job market, I knew what I was being paid, and it's likely others did because my salary is public. I knew that some may see this as a negative, because it'll make it harder to negotiate right?

WRONG!

Although it was all public, and my current salary was £69k, I was asked by companies what I was expecting, of which the minimum I specified was £80. I knew from chatting to others around the community that was a reasonable request of the companies I was going to, and I noted that the salary I was leaving was a public sector one, which are generally lower than private sector anyway, as well as the fact that I was leaving a very nice pension behind.

So when I received whopping £90k offers, what did I do? I thought back to something a friend of mine says, "channel your inner middle-aged white man who'd feel entitled to ask for more". (Note that this is a statement said in jest, based on research that men are more likely to ask for raises, and doesn't have any racist undertones)

Knowing that I had two offers, and that I had gone through a very long process with them and having received an offer, I knew that I was a candidate they'd like to hire. This is the perfect time to get that extra worth, as you hold a lot of the chips, especially with two offers.

I ended up implying that the offers I received were lower than others, and managed to negotiate up, receiving a starting bonus.

The worst thing they'll do is say "no, sorry we don't have budget". The best thing you'll do is get 💸. Your mediocre white male colleagues wouldn't think twice about it, so go for it!

Unconscious bias in interviews

I found it a little uncomfortable going back to private sector interviews, which involved a single interviewer, after seeing the way that the government does it.

What I liked about the government's way of interviewing was that it made sure there were multiple interviewers in the room, who aimed to be a diverse group of folks from different job roles, backgrounds, ethnicity, gender, etc. I found this to be a great approach to make sure that candidates aren't subject to (un)conscious biases.

That being said, across different interviews, I did have different people, so there was at least a mix of diverse interviewers across the process, just not in each and every part of the interview.

A cursory search online couldn't find a handy reference for the government's way of interviewing, but if I find one I'll update it here.

Read the engineering blogs, listen to their podcasts, and chat to others working there

I was fortunate to be in the middle of stripping the wallpaper in my living room, which meant I had many hours of time spare to listen to podcasts/articles. I was able to get a feel for the various companies I was interviewing by reading their blog posts, listening to their podcasts, and learning about their tech.

A few companies are also blogging about their interview process, which demystifies the process a lot, and gives you some great insights.

It was also really nice to be able to thank the authors of the posts on day 1 at Deliveroo to say thanks for doing it!

If you're able to get some time for it, it can be helpful to understand more about the (technical) culture that makes up the company.

If your network includes people working there, or people who you can introduce you to people who do work there, that can also be a great way to learn a bit more about the role. For instance at Deliveroo, I had a few folks to speak to which gave me a bit more of a balanced view of the role, which was great.

Time consuming

Overall, they were a lot of work. I think the three I got through to final stages were each 6-7 sessions. In a single week, I had 8 interviews, alongside a lot of stuff going on in my personal life, as well as a job I was doing. That's a good deal of time investment, and to think that I may have been going through more than three processes at once, it's a lot of time to invest.

Compensation

The only company that gave me any compensation for the interview process was GitPod and I thought this was a really mature way of looking at the process, as it requires a lot of investment for all parties. I'd love to see more of this, especially as it's a lot of time spent going through the process.

Preparing for the interviews

Another thing to note is that I ended up not really preparing for the interviews. I feel like this is a bit of an arrogant move by me, and I probably should've worked a bit harder for them, but it's also a good sign to myself of what I can do at the level I'm at!

Conclusion

I found it handy to collate a list of companies that may be interesting to work for. Although I didn't get around to applying to their roles, I've now considered they're a good company, and if something interesting pops up, who knows?

I hope this has been a helpful read, but if not, you know where to find me!