How to pass our coding exercise

"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:

Meeting the requirements 

This seems like an obvious one, but you might be surprised how often people get it wrong.

• If the exercise mentions a clear requirement, like The result must be printed in alphabetical order, then it's critical that your solution meets that requirement.

• A clear requirement is also a strong indicator that you should include a test which asserts that the requirement is met (more on tests later).

• Another mistake people make in this area is by adding their own requirements that they think the program should have and making the code meet them. Doing this will just cost time and energy, and often makes the code unnecessarily complicated. Stick with a simpler solution that does what we want it to.

Clarity & readability 

We value code that can be understood quickly over code that can be written quickly. Here are some ways you can make your code clearer:

• Make your names clear and specific - naming a variable parsed_story is clearer than s or data. Conveying meaning is more important than having short lines.

• Format your code consistently - we find that applying consistent formatting is more important than which formatting rules you apply. There are lots of tools like Prettier and Black out there that make this very easy for you; we're not looking for you to do this formatting manually.

• Take a break after completing the exercise, then try to imagine you're one of us, reviewing your solution. From this perspective, re-read your code and improve areas that seem unclear. We do this for our own PRs on our team, and it saves code reviewers a lot of time and effort.

Tests 

Testing is a core part of our development workflow, and we look for candidates who are familiar with the fundamentals of it.

• We expect solutions to contain automated tests, preferably both unit and integration tests.

• If you haven't worked with these types of tests before, you can learn the fundamentals relatively easily. They usually involve a library like RSpec, Jest, or JUnit.

Documentation 

Remember that the person evaluating your solution will be seeing your code for the first time. They may not even have any experience in the language you wrote it in! Empathetic documentation is the best way to introduce your solution to the viewer and give them context.

• Add clear instructions on how to run your program and how to run the tests for it.

• Add comments in areas of the code that benefit from more context or insight, like places where the purpose of some logic is not obvious.

• Don't add comments that restate the obvious - these just add noise. A method named parse_json doesn't need a comment above it saying "this method parses JSON".

Simplicity 

The systems that power Tines are already complex enough without making it more complex through unnecessarily complicated code.

• We've deliberately designed the exercise not to require advanced Computer Science knowledge. Stick to simple logic where you can - it's what we do every day.

• When reviewing your code after writing it, think about whether there are simpler alternatives to the complex sections.

• Remember that the solution still has to be correct, so don't choose incorrect logic for the sake of simplicity.

What we're not looking for 

• A specific language - at Tines, we mostly use Ruby and TypeScript, but those can be learned while working on the team. You can write your solution in any language, but try to avoid languages that are not commonly used for web application development. Those languages (e.g., C, C++) are less relevant to the kind of work we do and harder to write solutions in.

• An answer from someone else - if you pass off someone else's work as your own, then it will be very clear in the next part of the exercise when you work with Tines engineers to extend the solution.

We want our whole application experience to feel cooperative. After all, both us and the candidates want the same thing - a successful interview! All we need to do is see enough evidence that you're right for us, and we're right for you. With this post, we hope it will now be easier for you to show us that.

We're hiring right now, so visit our careers site and try it yourself.