Our take on the “final interview” for developers
How do you at one point in the tech interview process determine if a candidate is the right fit for your team? He or she has passed initial screenings and interviews, and seems to possess the right skills to fill the needed role. If we consider this a stage-gate-process, what should be the final gate?
At Unacast, we are experimenting with an interesting take. The question that we asked ourselves is basically - how do know that the candidate will fit into our everyday life at Unacastle and how we work? This lead to a rough analysis of what we actually do during a typical workday.
Being a startup in a highly exploratory space, working on the tech, we spend a lot of time on researching, testing and discussing different approaches to solve problems at hand before implementing production code. This means that we often need to learn new languages, frameworks and paradigms.
A common approach in development is to do pair-programming, which is basically what it sounds like, developers working on the same problem on one computer. One could also call it pair-problem-solving - and research have shown that being two often yields better solutions faster. This is especially true when learning new things or attacking unknown problems.
We therefore decided to invite candidates that had passed all stages to a “night at the Unacastle”, where the candidate would be paired up with one of our developers to work for a couple of hours on a given problem.
An important twist is that the problem to work in is unknown both to our developer and the candidate. That means that both start pretty much on scratch and have to approach the problem together and stitch together a solution by googling, reading documentation and discussing. And usually a pretty solid dose of Stack Overflow.
In our experience, after a little while, everybody seems to forgot that this is actually an interview, and people let their guard down - let’s get some shit done! It has been interesting to see how people react when they are being questioned or how they argue that one approach is better than the other. In our opinion, the real goal of an interview is to let the candidates show their true selves, and their skills. We have found that this interview structure make that happen because it creates a relaxed environment. Considering the fact that some developers can have an analytical and introvert personality (and by the way, being introvert or extrovert are neither positive or negative traits - they are just different) , in addition to the natural nervousness connected to applying for a new job, an approach that creates a playing field that feels natural is a huge win.
Some guidelines and ethical perspectives
We value the candidate’s time and effort, so it would be unethical to work on internal products or features, which basically would mean that candidates did free work for us. Our solution to this issue has been to just do something for fun, that could be open sourced at some point. Obviously it can be stuff that is useful for us, but it should also have potential to be useful to other people and not tightly integrated or related to our systems or codebase. Usually, we build something in a new, exciting language or framework that we may have looked at in our spare time at but haven’t found the time to dig into. It’s a win-win!
One could fear that the candidate may find that we do not have the level they expect, but that is ok. An interview process goes both ways, it is just as much about that the candidate should get a real impression of our company, our people and how we do our things.
Takeaways and learnings
On the practical side, you need at least one developer internally that is available. Ideally, a few more are good because then the team can just hang around and listen casually into the conversation and drop in if they feel like. Looking at recruiting in general for non-tech positions, case assignments are a widely used method to assess a candidate’s real-life abilities, however in a somewhat artificial setting. Coding like we do in “A night at the Unacastle” is in many ways easier to assess, since it is much closer to the actual thing. We are a young company that is in continuous development in all aspects, such as recruiting. But we feel that we have found something precious here, and we will definitely continue with this practice, and continue to refine it based on feedback from candidates and our own learnings.
Lastly, although not entirely related to the “Night at Unacastle”, one of the most important learnings is that sourcing candidates is really, really hard work! Considering that the type of candidates (i.e. the A players) we are looking for usually are happy where they are, it’s all about using networks, seminars, social media and whatever means possible to get hold of the right people. We have also found that working with recruiters is a great help in the actual interview process, but there is no excuse for not making sourcing a team responsibility that everybody should feel committed to.
A last little secret that we want to share is that most developers get at least a couple of recruiter calls or emails per month that are easily dismissed. It has a lot more punch to start the conversation with “Hey, I work as a Platform Engineer at Unacast. I think you have done some really interesting stuff, wanna grab a coffee?”
If you feel that you are in the target group and that the last question speaks to you, don’t hesitate to reach out! We would love to spend a night at Unacastle with you.