"Why are manhole covers round?"
Three sets of eyes stare at you from tilted heads, hands resting on laptop keyboards, waiting for an answer. You pause for a few seconds, trying to remember if the role you applied for was indeed titled "Software Engineer" and not "Sewage Systems Architect".
"To make them easier to fit I guess?"
The eyes look down at laptop screens as the hands type.
"Great. Next, how would you weigh an airplane?"
Update - As of February 2022, our interview process now uses ByteBoard instead of our own custom exercise that this article refers to - however the tips are still useful for any exercise you take on!
Team Tines
Looking for what's actually important
There are lots of different approaches that companies use to evaluate whether a candidate is the right person for a role. At Tines, we want to make sure our process shows us how candidates would perform when doing the actual work that the role entails. This work doesn't involve answering riddles, it doesn't involve quoting minute details of the Ruby standard library from memory, and it (mostly) doesn't involve standing at a whiteboard trying to solve deep computer science problems. Working as an engineer on our team involves collaborating with teammates to improve our product in the simplest and most effective way. Our approach to evaluating a candidate's ability to do this is a coding exercise.
The first part of this exercise is building a small, extremely simplified version of Tines that runs on the command line. Candidates complete this first phase alone, in their own time, with the tools they feel comfortable using.
If they complete this successfully and the solution meets our requirements, they progress to an interview during which they pair with some of our engineers to add new functionality to their solution. This takes about 90 minutes and aims to be as similar as possible to the actual day-to-day work we do - candidates can do any research they want and collaborate with the team to build their solution.
There's another aspect to the team's work that we can recreate in this exercise - transparency. When we're building features or fixing issues, we make the goals of the work clear. With that in mind, we've written this post to share insights into our hiring process and help candidates understand what we're looking for and how they can succeed.
What we look for
Because this exercise is intended to be as similar as possible to actual day-to-day work at Tines, we're looking for solutions that have some qualities that we think make any piece of code better: