How we hire at SuperAPI

This document outlines how hire at SuperAPI. Chances are if you're reading this then you're thinking about joining us, awesome! One of our values at SuperAPI is to be open and transparent in the way we operate and hiring is no exception. We wrote document to give you an idea of what to expect if you go through the hiring process with SuperAPI.

We don’t always get the hiring process right, so if you have feedback, thoughts or anything else, then please reach out to us. You can contact us directly at [email protected]

INFO

We're always open to meeting Elixir developers based in Melbourne. Drop us a line at [email protected] and come say "hi" in person. We're located in Melbourne's CBD close to the Southern Cross station.

How we work

At the end of the day, we're a SASS company providing software to our partners. That means we don't usually solve extremely difficult software engineering problems, the kind of problems we do solve tend toward:

• Data modelling
• Performance
• Software architecture
• Compliance
• Data visualisation

This means that when we interview, we're looking for people with a broad experience base across multiple software engineering disciplines who have a deep specialties in areas that interest them (commonly known as "t-shaped" people).

We've tried to make SuperAPI the kind of place that we've always wanted to work at but couldn't. This means that we don't take ourselves too seriously, foster a blameless culture and have a strong philosophy in "giving back" (wrote a cool piece of code? Let's open source it!). We're the kind of company that is more likely to have an informal beer after work together on Friday than to have formal team building exercises.

The two sets of criteria we look at

First, it’s important to understand that when we hire we don’t just look at your skills. If you’re a developer and have a deep understanding of Elixir, that’s great, but that's only half of the puzzle. Along with Elixir skills that match the kind of work we do, we also look for what could be described as a "culture" fit (we kind of despise the word culture as it doesn't quite capture what we're looking for but it will do as a stand in until we can think of a better word)

The "culture" interview

When we do the culture interview we’re looking for people that have a certain set of characteristics. These characteristics are built up from those we've noticed in each other and with people that we've loved working with in the past. They are:

• Optimism - kindness, thoughtfulness and a sense that the glass is always at least half full.
• Curious intelligence - learning for the sake of learning, a curiosity towards new things.
• A work ethic - pride in the work done, a willingness to master one's craft. Not to be confused with willingness to work all hours!
• Empathy - An awareness of how one's actions affect others, caring for others.
• Integrity - Do the right thing, even when no one is watching.

Our culture interview is always the first interview that we do, in fact it might not even feel like the usual cultural interview at another workplace. After we’ve had a chat, we will get together and discuss the meeting and try to frame it in light of the 5 criteria listed above. Depending on how that goes, we’ll then progress to the skills based interview.

The skills interview

Our skills interview follows a more traditional interview process. E.g. for a skills interview in our engineering team, we’re looking to see how your development skills will fit with the kind of work that we do. In this interview we strive to make it as close as possible to the actual kinds of work that you will be doing, what this also means is that as we don't typically solve leetcode style problems here, we don't use leetcode style tests for potential employees.

Some of the things you can expect from the skills interview are:

• Review a pull request - Let’s pair on a real pull request in the system and have you work through understanding what it does. Here we’re looking for the kinds of questions that you might ask and how you apply your experience and knowledge from previous roles.

• Pair on a feature - We’ll pick an easy feature from the codebase and work together to implement it. Similar to the pull request review, we’re looking to see how you approach a problem.

• Bring in some code - Rather than working on our code, let’s work on yours instead. Bring in something you’re proud of building (and can show us!) and let’s work through how you might add a feature to your own code base.

• Tell us about our code - Let's bring up some of our code and you tell us what it's doing and ask some questions about why we did it.

In all cases, these aren’t pass or fail tests in the sense that you must add the feature in the hour we have allotted. Instead, we’re looking for how you approach a problem and communicate with the engineer that’s running the test.