Demystifying the interview process: How we recruit at Polystream

Polystream is a rapidly growing company, and we are constantly looking for good people who can help us tackle the many challenges we have to solve. It could be tempting, perhaps, to be less careful about the hiring process in order to get in people in order to fill seats. It happens, and it’s not always a bad thing depending on your type of business, but for us quality trumps quantity any day. As people we have been through a number of different interview processes in our careers, both as interviewers, and as interviewees, and we have seen both the good, the bad, and the outright ugly. We want to learn from those experiences, and we want our interview process to be great. We know we’ll have to do a lot of rinsing to get there, but what has always been clear is that it must be focused around a simple set of objectives;

  • We want people who know what they’re doing
  • We want people we can work- and get on -with
  • We want people who can teach us things

The interview process, and this can not be overstated, is a reflection of your company; If you screw it up then that will hurt you, if you make it too hard, then that will hurt you, and if you make it too easy then that will hurt you too…

We will speak of our technical interview process here, i.e. the one we use to hire into our development organisation.

So first; A few words about whiteboard coding…

It’s one of those topics that gets people passionate; some people hate it with a vengeance, others love it and swear it’s The Only True Path.

We fall somewhere in the middle; we really like whiteboard coding, it helps us think, and we love it when someone else does the same. But (!) it doesn’t work for everybody, and whether we like it or not; in today’s world a lot of coding depends on intellisense/resharper/visualassist and other tools that help us remember and correct syntax.

Also; the coding process is a very personal one, and some people are just not comfortable with having to code “in full view”, on a whiteboard, in a live doc, or with somebody else looking over their shoulder. That reservation is not a reflection of their coding skills, it’s a reflection of their personality and we need to be able to gauge one orthogonally to the other.

At Polystream, therefore, we don’t push whiteboard coding, but we also don’t discourage it.

When it comes to communication we want the candidate to be able to express their skills, but they don’t have to be great speakers, writers of wonderful prose, or stand up comedians either. What is important is that you are able to interact with us.

So, if you apply, or are approached, for a job @Polystream the process you will currently be taken through (rinsing and repeats pending), is;

  1. A phone call; this is the first screening. We like to ask about your CV, your current work, what you like to do, and get you to explain something interesting you have worked on. It’s also a great way for us to get a sense of who “you” are. We can also tell you more about who we are and what we do, to let you decide if you still think we’re interesting to you
  2. If 1 goes well we send you some questions. These are important, and they are a collection of technical and code questions (depending on the role of course) that we ask you to provide some answers to, taking whatever time and resources you need. In some sense they’re the “whiteboard” exercise, without the whiteboard. Obviously we’d like you to come back sooner rather than later, but we know that people have day jobs and lives so we don’t set a time limit and you can use any resource available to you when you respond to these; we are looking for relevance, understanding beyond just copy-and-paste, and we use your answers to identify areas that we want to drill deeper into for the next round
  3. If, subsequently, we invite you on-site we really want you to meet with as many people as possible; we’re still relatively small so it’s possible to virtually meet with the entire company; our CEO, our marketing lead, our CTO etc, but we’ve tried to pick the most relevant ones for the bulk of the interview, based on the role and what we think your core competencies are. This is where we look for indicators (and red flags!) around our core values; the team fit, the competence, the ability to innovate. You’ll be meeting a lot of people, being asked a lot of questions, over a couple of intense hours, but we strive to keep a relaxed, and mild, tone. We’ve been up against enough boasting wannabe-alphas in interviews to last a lifetime, and it’s not a style we want to adopt
  4. Debrief; when we hire into engineering we like to do a debrief with you, asking about how you think things went, if you have any questions about us, what you thought about the interview process itself (yes, we really want to know!) and hopefully have pleasant ramp off from the last few hours.

During the interview, or very shortly after, the hiring manager will quickly ask the people who you’ve met with if there are any red flags, and if it’s a go/no-go. As simple as that; the gut feel they got from you, quickly sampled while it’s fresh.

Once we’re all done we bring everyone together and discuss the interview in more detail; allowing the interviewers to discuss between themselves, and correct or improve their assessment.

At this point we make our decision, weighted by the hiring manager’s ultimate right to veto; gauging a person’s skills and abilities is not an exact science, it will always be a subjective decision, and therefore there has to be someone who can decide, and who is accountable for that decision, regardless of consensus.

If all goes well, and you think we seem like an ok bunch to work with, we make you an offer, decide on a start date, and eagerly await your arrival @Polystream!

Visit our jobs page here.

Follow Jarl on Twitter @psjarlo