How we do technical interviews at Wolt

Imagine you are founding a new tech company. Initially, you can afford a single engineer to work alongside yourself, someone to handle everything from devops to design. You will face obstacles together, have conflicts, and deal with failures and success – it is a significant relationship. You want someone who will do their damnedest and share some laughs and hugs along the way. So it is a big commitment and a meaningful investment. Now zoom forward ten years. You chose right! Your baby has grown into something big. The engineering team is a hundred times bigger. Growth requires more hires – now bunches of engineers at a time – who again will determine the technical progress and the social fiber of your company. You, the CEO, cannot possibly hand pick every engineer anymore: how would you ensure you get engineers you can trust? Here is Wolt’s answer.

Each candidate hand-picked by future teammates

A large percentage of engineers at Wolt are involved in hiring. At the time of this writing we have around 130 engineers actively involved in assessing candidates. This includes, for example, nearly 30 frontend engineers involved in frontend candidate interviews. Moreover, Wolt has Competence Leads, engineers tasked with maintaining this pool of interviewers and inculcating new participants into the process and ethos of interviewing at Wolt. This is in addition to our talent acquisition team who are responsible for building candidate pipelines and ensuring a delightful and effective hiring process.

Having hundreds of your employees spending time on hiring is a big investment. Why not automate technical assessment and invest this “lost” engineering time in your product? The first part of the answer is that it is very hard to resist the “default effect”. The easy path beckons; in other words, we are cognitively averse to avoiding the default path – in this case, the sufficiently good engineer on paper. This works both ways, for job seekers as well as job offerers. Many of us are so grateful for that first job offer, we are scared to not accept that first offer, even if we know in our heart of hearts it is not the best one for us. It does take some hubris, discipline and endurance to wait for the best chance for self-actualization. That inclination to hurry along is, by the way, one reason to make it a community task––to galvanize each other against the enemy of complacency. The second part of the why-not-outsource answer is that it is very hard to measure the outcomes of hiring. While you may be able to identify abject failures, it is impossible to measure the lost contributions of a talented engineer or the more subtle damage of social dis-function. There is really no one with stronger incentives and an intuitive understanding of social fit than the engineering teams themselves. They are the ones prepared to say “not yet” when faced with a long-term relationship with a new colleague. From the job seeker side, it also helps to approach every job interview as a two-way evaluation; you are also interviewing to find out if you will fit in and be able to flourish.

We believe in a take-home task

For candidates who eventually join, there will be several interviews. Here I want to focus on the technical assessment, typically comprising a take home task and a technical interview, even though every part of the process is about deciding on a relationship which is more than just great technical skills. We believe in a take-home task. I know some of you are groaning; I empathize. It can suck to spend much of a Sunday doing something not unlike what you do at work. On the other hand, we believe this is both the fairest and most mistake-proof way. A little sweat up front helps us all see what sort of game and hustle you have. If you are not motivated enough to do this; that is ok.

Here are the practical reasons we value a home task:

• Relevance: we can craft a task that genuinely reflects the work you would do at Wolt rather than a toy problem. In fact, I think we can even offer an interesting task because it is genuine and not just an exercise.

• Eliminating bias: when initially reviewing the assignment, we direct interviewers to not look at the CV or even the person’s photo. The correlation between impressive work history and impressive code is not always there. Nor is gender, age or ethnicity relevant to your skills as an engineer. Furthermore, while some of us are extraverts who thrive in high pressure social situations, others of us are introverted. We might miss someone’s talent because of the initial social friction of performing in public. A take-home task potentially mitigates both interviewer bias and the noise of personality differences.

• Time and environment: the candidate is given the time and space to demonstrate their skills in the place and time of their choosing with their own tools. So crank up the focus music, load up the snippets and prepare Stack Overflow in a tab. Do it how you really do it. Importantly we, the evaluators, also have time to spend with the resulting code, giving your work our full consideration. With a discussion it can be very hard to analyze in real time someone’s strengths and weaknesses.

• Autonomy: There are some gaps in the assignment specifications. That is not accidental. We want to see you fill in those gaps. Be wisely ostentatious.

For those of you who may be doing this task in the near future, a few tips. First, do not expand the scope of the assignment. This is an easy mistake to make if you are motivated – “oh, if I add this extra backend service, they will be so impressed”. But think of this like real work and a real specification; stay on task. Second, this is not about demonstrating you know a bunch of popular libraries or techniques. Focus on robustness. We like things that work even when nothing else around it does. So assume that your assignment lives in an imperfect world. Finally, take this as a learning opportunity. Be vulnerable and open in assessing your work. Bring out the tradeoffs that led your solutions – you might even document these in code comments. Being transparent about the process and honest about weaknesses are super powers.

The pain-free technical interview

The second part of the technical recruitment process is an interview with two Wolt engineers. This interview is conversational and reciprocal. It would be naive to think that the situation is not high stress – for both you and us. But open conversation can go a long way to changing the dynamic into something more collegial and even fun. We are opposed to gotcha questions and ritual humiliation. You have already proved something; we liked your code. Still you are not your code. What are your processes, principles, and passions? Even more importantly, do your values and the values of Wolt converge? Personal characteristics like humbleness, vulnerability, ability to listen, interest in others always matter in every interview.

There is a loose structure we follow: introductions, a discussion about the take-home task solution – an opportunity for more feedback and also to hear how it was for the candidate – and then some time for more wide-ranging and open-ended questions. Then, we spend a small amount of time discussing some very small code snippets or artifacts of some kind, for example for frontend engineers we might look at small screenshots of UIs and ask you to evaluate them visually. Again, these are invitations to a discussion and a chance to feel out what happens when we both put our hands in the clay at the same time. Would it be a kick to work together? We don’t expect the candidate to write code in the interview, and white-boarding exercises, if used at all, are used as a practical aid, such as visualizing a database schema. The candidate is invited to ask questions at the end. Another tip to candidates: have good questions prepared. Not having anything to ask is a meta-message in itself.

Exploring new ways forward

While we do have strong opinions on technical assessment, we are still questioning them and exploring other approaches. For example, we are also trying out conversations about code or even live coding with candidates who feel confident based on their long experience or for some reason cannot do the home task. This fast-track has the potential to be more high-pressure and intense, for both interviewer and interviewee. But for experienced candidates with strong “muscle memory” the flow will kick in and it can be surprisingly easy. We will keep tuning and evolving these processes. So by the time you stumble upon this post, we may have already refactored it. Nevertheless, we will stick to our guns in terms of avoiding the default path and suggest you do as well. Having a pipeline of job application opportunities as a candidate will make you better at the process and better at understanding where you really belong. We love working in teams where every engineer is that kind of colleague you wonder how you ever lived without – a match worth waiting for.

And, of course, we are hiring 🙂