Paul Stovell Paul Stovell March 2, 2015

Growing Octopus Part IV: Interview process

This is part four in a series of posts about how we're growing as a company. In this post I'll talk about how we recruit, interview and onboard new team members.

  1. Developer career paths
  2. How we work
  3. Compensation and career progression
  4. Interview process
  5. Laptop program
  6. Anti-harassment policy
  7. Local or remote?

Interview process

At the start of this series, I wrote:

Octopus grew by about 40% every quarter for the last 8 quarters, or 400% in the last 12 months. We hired 6 people over that time, so that leads to a conclusion: assuming we grow at the same rate this year, we're going to be hiring at least another 12 people.

Knowing that we'll be hiring heavily this year, one of our first challenges was to actually have a structured recruitment process. Our old process looked something like: we're hiring people we already know through our networks, so we'd have coffee with them, then make an offer. Clearly, that doesn't scale.

Damian spent some time designing a recruitment process which looks like this:

  1. CV's/resumes come in. We only use these to filter out people who definitely aren't worth talking to (wrong city, clearly not experienced, etc.), but otherwise they don't factor in very heavily.
  2. Phone interview: this usually lasts 20 minutes, and progresses through a handful of questions to give us a sense of whether it's worth progressing to the next stage (we err on the side of 'yes'). Think FizzBuzz-level of difficulty.
  3. In person interview

First up, don't worry: our process isn't a days-long process involving dozens of people. The in-person interview takes approximately two hours, and just involves just you, Damian and myself.

Part I: Pair programming exercise

First, there's a pair programming exercise. This takes between 45 mins to an hour. The goal is to help us determine:

  1. Can you actually write code: a little string manipulation, some very basic data structures, and some critical thinking. We don't expect you to be able to write the whole thing without a problem, and we'll help if you get stuck.
  2. Can you pick up new concepts. The problem domain we use in our exercise is something you've probably never heard of, but can be taught in 5 minutes. We'll spend some time at the start of the exercise making you a domain expert in the problem domain.
  3. Are you someone we'd actually want to pair with to work on real Octopus code each day. Are you personable, do you communicate when you get stuck, or do you get easily distracted or spend most of the session complaining about keybindings or your current employer.

We start with a stub solution in C#, but we're happy if you prefer to use a different language too. Someone will sit next to you as you do it, and they might ask questions about your approach or help you avoid coding into a corner. Once the basic version is working, we'll let you clean it up (we don't expect beautiful code at first, but we'd like you to refactor to something nice after), we'll add a few requirements, and get a sense of how you approach refactoring and object oriented structure.

Part II: Q&A

After the pairing exercise is a more traditional interview. We'll ask about your past experiences, and get a sense for what excites you - what are you passionate about? If you're applying for a senior developer/architect role, we also want to find something you can go really deep on - something that proves that you care about what goes on under the hood. We'll give you a choice of topics to choose your strength, such as:

  • Concurrency
  • Memory management/garbage collector
  • Production debugging/performance analysis
  • Architecting high-performance systems
  • HTTP/TCP fundamentals

For example, if you choose concurrency, we'll discuss processes vs. threads, thread synchronisation, pooling, what async/await actually does (your answer should probably describe IOCP, for example), and so on. As discussed in a previous post in this series, this is stuff we expect senior developers to know.

This is also a chance for you to ask us questions, since interviews are just as much about us interviewing you, as you interviewing us.

Part III: Presentation

Finally, for senior developer roles and above, we'll ask you to give a presentation for about 20 minutes. Typically this involves pitching a new feature for Octopus to us, or teaching us about something you're passionate about (development related, of course). The point of this is to get a sense of whether you can communicate ideas to the team, and structure your thought process to bring people along with you.

Decisions and feedback

We try to give feedback as much as we can throughout the process - e.g., if the pairing code is messy, we'll point out why we think so and give you a chance to tidy it. If you're struggling on a deep dive question, we'll fill in a gap or even move to a different topic.

At the end, if we're pretty sure the answer is no, we'll give you the answer on the spot - there's no sense letting you go home wondering, if our minds are made up. Either way, we'll let you know the answer within a couple of days, and we are happy to answer any questions about what went wrong/what you might have done differently - in fact we think giving honest answers to these questions is just as important as the initial interview. Brisbane is a small town, and we hope you'll come back in 6 months and try again.

The whole process takes about two hours, and we keep it casual and friendly. We've put half a dozen people through this process now, and I think it's working quite well - certainly better than our previous recruitment approach. I especially like the pair programming exercise as a way of getting to know what people are really like to work with. We all have implicit biases and reach conclusions in a matter of seconds when the interview starts, but seeing the person actual put down code can really undo those assumptions (for good or bad).

If you think you'd ace the interview (and live in Brisbane), we're hiring!