How we improved our tech interviews at Depop

Photo by Charles Deluvio on Unsplash

Depop’s engineering department has grown significantly over the past few years, with more than 50 engineers joining us this year alone. Like most tech companies, our interview process for engineers includes a practical coding component. Technical interviews can be hugely stressful for candidates, and the “right” way to conduct them is a source of much debate within the industry. At Depop we’ve recently improved this stage of our interview process for hiring backend software engineers and wanted to share our reasoning behind it.

What our tech interview looks like

We want to find out if someone has the necessary practical skills to make them a great member of our team. More specifically, we need all of our engineers to write clear, maintainable, well-tested code, so this is the primary focus of our assessment. Writing software that is easy for others to read and modify is just as important as solving the problem at hand. Additionally we want to see how a candidate works with the interviewers (their potential future teammates) and how they respond to questions or feedback.

Most engineers at Depop will work closely with product managers to build features, so being able to translate a user focused problem statement into technical requirements is a valuable skill to us; more so than being able to solve a classical computer science problem on a whiteboard.

Other parts of the process give candidates a chance to demonstrate system design knowledge and discuss their personal values and prior experience. Every stage includes a chance for candidates to ask questions so that they can hear from as many people as possible.

Tech hiring can be hard on everyone

From a company perspective, hiring is important to get right. Sourcing the right candidates, interviewing them, and then onboarding and training them represents a significant investment. A poor hiring decision can mean a painful loss on that investment.

On the flip side, it’s not fair for us to ask candidates to spend hours of their free time working on tasks or sitting through endless rounds of interviews. If the process drags on for too long candidates may lose interest or perhaps accept an offer from another company with a more streamlined interview process. Long unfilled positions can leave teams frustrated and struggling to reach their goals.

For multiple reasons, it’s important that we reach a “hire” or “no hire” decision with a good level of confidence as quickly and efficiently as possible.

We value diversity and inclusion and we want to make sure our hiring process reflects that by being as fair as possible to everyone. Not everyone has had the same route into the tech industry and we need to have a process where applicants from all backgrounds are given the best chance at demonstrating the value they can bring to the company.

Whether they end up working at Depop or not, we want every candidate to be left with a positive impression of their experience.

Why are we changing ours?

We love using Scala at Depop, so it follows that our previous interview task was Scala-specific. Here are some example questions we were asking:

• “What is a sealed trait?” — many candidates work with dynamic languages, that may not have traits/interfaces at all, and even in statically types languages sealed traits are not very common.
• “What does the +A notation mean?” — this notation means that the generic type A is covariant, but even if you worked in a language that has generics before, they use different syntax for covariant types.

This was problematic because it presumed prior Scala experience in our candidates, significantly biasing outcomes against those without. We believe that [some] skills are transferable, that new technologies and languages can be learned [relatively] quickly, and most importantly, that there is so much more to a good software engineer than their expertise or syntactic familiarity with one particular programming language.

Before starting on the new task we set ourselves some requirements:

• Language agnostic: We want to meet as many candidates as possible so we designed an exercise that can be completed in any programming language.
• Remote first: We started running remote interviews out of necessity but we see the value in the shorter time commitment required without travelling to our offices and benefit of not putting candidates in an unknown environment. In the future we hope to be able to offer a choice between remote and in-person.
• Inclusive: Not all great engineers have a degree in Computer Science or have studied classical CS algorithms in depth. Tasks such as inverting a binary tree or implementing radix sort are not particularly representative of what we tend to do on a daily basis at Depop, so no obscure logic puzzles and no coding on a whiteboard!
• Not stressful: Emphasis on pairing, the goal is to help the candidate complete the solution as best they can, not sit back and silently judge them especially if they are nervous or having trouble.
• Make it Depop: We want the task to be fun and give an idea of some of the actual features that we create for our buyers and sellers.
• One size fits all: We want to give candidates at all levels the same task, and only take up an hour of their time at this stage, so we need it to be achievable for those with less experience, and have some extra challenges ready for those who breeze through it quickly.
• Not time consuming: We don’t want to disadvantage candidates with busy lives.

What qualities are we looking for?

• An iterative, logical approach to problem solving
• Writing clear, readable, maintainable code which doesn’t over complicate the problem
• Well written tests
• Communication — asking questions, explaining your thought process and how your code works
• Admitting when you need help or if you don’t know something, taking feedback

What did we do?

We set up a working group of engineers and talked about our good and bad interview experiences; the group had mixed feelings on the merits of take-home tasks because some people find them less stressful. Ultimately we felt that they would be too time consuming and provide less insight than discussing and solving the problem together with the candidate.

We then came up with tasks and iterated on testing them internally; this was the really tricky part! No wonder some companies revert to standard problems because it was difficult to come up with a simple problem that was just challenging enough. Once we started thinking about actual problems we’ve solved at Depop and our users’ needs we were able to formulate a good idea for a task.

Once we were happy with the task in our working group we ran some mock interviews with other Depop engineers who hadn’t seen it before. We were then able to use the feedback from interviewers and candidates to tweak the difficulty and make the instructions clearer. We then introduced the task into our interviewing process, gathering feedback all along. At this point we are happy with the results. The new interview process provides us with valuable information on candidates from all levels, and from their feedback, the process is much less stressful than in some other interviews they attended.

Join us!

To find out more about careers at Depop and see the roles we currently have open, visit our jobs board.