How do you interview engineers?
Engineering interviews: there’s hardly a more divisive topic. The right approach and what’s fair to ask are endlessly debated on forums and among hiring teams.
Hacker News, Reddit and Twitter are littered with stories of strong engineers thwarted by seemingly pointless brainteasers in their interview.
The reality is the interview is also your best opportunity to really understand an engineer’s performance and ability.
Unlike most roles, it’s actually harder to assess an engineer’s fit in the first few months on the job than in 4 hours of focused interview time.
Even in a team with code reviews, design reviews, and other best practices it can take a long time to understand how somebody is performing. And the software they write can live on in the product for a long, long time.
With all that importance baked into the interview, it’s not surprising that many hiring managers default to archetypal CS problems to ensure candidates “meet the bar”.
Now, CS problems are generally pretty good at measuring raw intellect.
But it’s not how we interview.
So what’s wrong with CS problems?
Two things.
The first: you might just be measuring canned knowledge of a given algorithm. If the candidate has never seen the algorithm before, it can be infinitely harder to solve than if they have.
The second issue is more subtle.
Although it might be very interesting, the ability to balance a binary search tree is not a good indicator of on-the-job success.
Computer Science questions may be a good test of raw intelligence but they don’t really measure the most important requirements for a strong candidate — the ability to write software!
Raw intellect is vital for a strong engineer, but it’s far from the only factor — particularly when you’re building products. Design thinking, making mental leaps and the ability to slot into the team are equally significant.
It’s not just about hiring good engineers, it’s about hiring the right engineers for your company.
When we default to CS questions, we create an unconscious hierarchy where we assume solving algorithms is the ultimate measure of an engineer.
So how do we do it?
Beyond the initial phone call, our hiring process is made up of three parts:
- Code comprehension & simple coding question over a Google Hangout
- A mini project & system design session during an onsite loop
- A behavioural interview with the leadership team
Every part of the process is intended to get a real sense of how an engineer would operate day-to-day, month-to-month in our team, working on our products.
The code comprehension is to understand how candidates communicate. We review code from a project they’ve worked on and code they’re unfamiliar with. The coding question is included to ensure a base familiarity with writing code (E.g. something that might take you 10 minutes to write, like finding elements in an array).
We’re still playing with the level of complexity but the aim is to ensure a positive candidate experience if they move to the next stage.
The mini project is the big part that differentiates us from other companies with a high hiring bar (Google, Amazon, Facebook, Snap et al). For this exercise we ask the candidate to bring their own laptop and a REPL /test runner setup in their preferred language. We then ask the candidate to build a system. What we’re looking for here is strong design principles (be that solid OOD or readable functional patterns).
We believe this is the best signal for candidate success at Freetrade.
Being able to convert a design into code is critical, which some candidates struggle to do. The mini project can also highlight other anti-patterns such as poor planning and analysis-paralysis. We see it as a win for us and the candidate. The candidate doesn’t have to revise esoteric algorithms and we get a better insight into how they work.
If they excel at the mini project, we move onto a final set of interviews with the leadership team across the company.
This stage is also very important. We want to know that every team member can collaborate and interact with the wider team. We look for a culture fit and a sense of ownership for the products they build. You spend more time with your colleagues than anyone else — it’s worth making sure that time will be spent happily!
Does it work?
So far the indicators are positive. Strong candidates have excelled and we’ve had few unexpected failures. In either instance, we’ll continue to iterate our hiring process, using strong levelling guidelines and candidate feedback to improve as we go.
We don’t think it’s the only way to interview. This is what works for us. But the reason it works is because we’ve specifically designed our process for the kind of engineering team we need. And that’s something everyone should do.
If you want to become part of one of the fastest growing fintech startups in London — head over to http://freetrade.io/careers and apply.
We’re on a mission to bring fee-free investing to Europe and beyond. 🔥
Freetrade does not provide investment advice and individual investors should make their own decisions or seek independent advice. The value of investments can go up as well as down and you may receive back less than your original investment. Tax laws are subject to change and may vary in how they apply depending on the circumstances.
Freetrade is a trading name of Freetrade Limited, which is a member firm of the London Stock Exchange and is authorised and regulated by the Financial Conduct Authority. Registered in England and Wales (no. 09797821).
