A while back, we talked about the coding exercise that forms part of our hiring process and what we're looking for when reviewing submissions. If a candidate's submission is successful, the next stages of our process involve them talking to our engineering team about their experiences, and pairing with them to add features to their submission.
Just like with the coding exercise, we want these stages to tell us as much as possible about how well the candidate can do the work that we do every day on our team. Here, we share insights into what qualities we think make people effective at this type of work and how we look for them in candidates.
Talking about your experience
During this stage, we'll ask you questions to explore some different situations that you've come across and challenges you've faced in your professional experience. There are a couple of things that are good to know about how we talk about this:
We want to hear concrete examples of what you did in situations you've experienced - not what you think you would do if one happened.
The more specifics and context you can give, the better - think of the difference between "I was on a team that made login better" and "I was responsible for reducing the response time for the login endpoint and was able to bring it down by 45%".
To prepare for this section, it's helpful to refresh your memory around some of your proudest achievements and most impactful projects from the last couple of years.
After that, we move on to pairing.
What we look for when pairing
Communication & collaboration
You need to be able to express your technical ideas in a clear, thoughtful way. We're constantly working with colleagues inside and outside the engineering team, so this is a crucial skill.
You need to collaborate well with the engineers who are pairing with you. When you get feedback, you should be professional when receiving it and discussing it. It's also important to effectively apply the feedback, if you agree with it.
You should ask questions about anything you're unsure of. We don't penalise people for not knowing something - instead, we value people being open about what they do and don't know.
Problem-solving
Solving problems is at the core of what we do. You'll need to be able to analyse the problems given to you, come up with an approach to solve them, and then build out that approach, testing and iterating on it as you go.
You also need to demonstrate you can focus on what's important. There are lots of things you can choose to spend time on during these coding sessions, be aware of what the most impactful options would be if you were doing this for real.
Technical fluency
You need to be quite fluent with your programming language of choice - you don't need to know every quirk of it, but we expect you not to be significantly slowed down by not knowing the fundamentals of it.
Likewise, you need to show comfort in adding tests for the new features you're developing.
In the later stages, you'll likely need to debug some of your code to evaluate if it's correct. You'll need to show that you can do this effectively.
What we're not looking for
A perfect solution - we deliberately choose problems that offer some challenges during the pairing stage. Showing you can make progress on the critical parts is more important than getting a perfect answer by the end of the session.
A solution from someone else - we do allow research during the session (as we do when doing the real work), but Googling for the entire answer doesn't tell us how you usually solve problems. We can't simply Google "How to make Tines" to do our job (unfortunately).
Like we said in the previous post - we want our whole application experience to feel cooperative. Hopefully, these later stages of the interview can feel more like a collaboration and less like a stressful exam with these insights.
Also, we're hiring - so visit our careers site if you want to know more.