Engineering Interview Questions of Onefootball — Hiring Blog

As part of an ongoing series of blog posts (last time we covered Jobbatical), we’re taking a closer look at different approaches to hiring the best talent. This time, we’re digging deeper into the recruiting secrets that have helped make Onefootball the world’s leading mobile football platform.

It goes without saying that behind any great product is a talented and skilled team of engineers, painstakingly chosen from a pool of candidates. What’s the trick to identifying the engineers that really know their stuff? We asked Marc Bobzien, Release Manager and Process Facilitator at Onefootball, to share their take on a hiring process that yields the best results.

Here’s how to put them to the test

Marc has found that it doesn’t have to take much more than half an hour to find out if a person will be a good fit for your team. To start with, ask your candidates to review a piece of code with quite a few flaws in it. At Onefootball, those flaws include:

1. Code that wouldn’t compile at all
2. Dangerous pieces of code that might cause problems/bugs
3. Major code style issues that are no-goes
4. Less severe code style issues

The candidates then go through the code and explain what they think the code does and point out any issues they see.

What this tells you

Based on which flaws your candidates uncover, you can make some fairly safe assumptions about different elements of their engineering skills:

1. If they don’t find the no-go code style flaws — that’s a no-go.
2. If they don’t find the parts that don’t compile, they might be very nervous or just don’t have a good eye for code and probably lack experience — that’s a K.O.
3. If they find the parts that are dangerous, that indicates experience and an ability to see the bigger picture in software. They’ve probably run into similar issues in the past and learned from those mistakes — that’s a good sign.
4. If they find the parts that are questionable style-wise, it’s clear that they care about what code looks like and that it stays maintainable. People who do this often have a good theoretical background — another good sign.

The most crucial part

Now that they’ve had a chance to find the flaws, pay extra attention to how your candidates express their concerns about the code. This is the part that tells you how they communicate and approach problem-solving.

• Even if the candidates identify the style problems, they might say something along the lines of, “It doesn’t look nice, but I guess it works…” This shows that they may have the right theoretical knowledge, but won’t necessarily enforce good style if put under pressure.
• You’ve found a winner if they have strong opinions about the style problems and can clearly express what should be changed and why.
• Firstly, this shows that the candidate isn’t afraid of honest discussion and is able to communicate clearly.
• Secondly, it tells you that they care about code style and want others to care as well. As such, they’re likely to be a good influence on the rest of the team. Depending on how well they argue their point, it’s safe to assume they will speak up if they see something going wrong. That’s precisely what you want — someone who will identify problems and offer solutions.

Why is this the best way to do it?

Squeezing this roughly 30-minute session into the recruiting process as early as possible can reveal a lot. Of course, this is not a 100% foolproof approach — is there such a thing anywhere? “But there are some good indicators that will give you a pretty good idea about the kind of developer that’s sitting in front of you,” says Mark.

Would you like to share your company’s interview questions? Please email us at hello@jobbatical.com.