Notes on Recruitment for Candidates

The Trōv team is building the world's first on-demand insurance platform and on a mission to make protecting your things simple and flexible. And we're hiring!

As we approach the half-way mark in our current recruitment effort, I want to share some thoughts on the process that may be useful for future candidates.

There is a vast spectrum of what candidates experience as part of an interview process: from seven to eight structured interviews in a day to casual pairing on the current project with a few team members. I believe what Trōv has strikes the right balance given our current size.

Current process

  1. We receive a candidate's info and ask them to fill out a short questionnaire. This helps both sides quickly determine if there are any obvious mismatches (e.g. unable to work remotely, dislike iterative development, resistant to unit testing).

  2. We arrange a thirty-minute call with the candidate where we answer questions about Trōv (day-to-day life, tools, etc.) and find out more about the candidate. At the end, we email our take-home assignment and ask for an estimated return date.

    (We used to give candidates two days, but people have varying commitments and we feel it's better to let the candidate decide when they can set aside time. The exercise usually takes 4-5 hours.)

  3. After receiving the assignment, the team evaluates it within 48 hours. If it passes, they arrange up to 3 one hour-long technical phone/Skype/Hangout interviews. These interviews are a mixture of coding and diving into technical details based on the candidate's resume.

The struggle

This is the first time we:

  • are open to hiring developers with any number of years of experience
  • don't need them to start yesterday
  • are hiring for all three teams (iOS, Android, server) at once

In theory this should make our lives easier, but it has presented some interesting questions.

  • What exactly do we expect from a "junior" developer vs. a "senior" one when it comes to the coding exercise? (Still not sure)
  • Should we expect an intermediate server developer to understand recursion? (We think so)
  • If an iOS candidate submits their coding exercise using iOS6 techniques or pre-ARC Objective-C, does that mean they don't care about learning, or does their job force them to remain in that era? (Unsure)
  • Is it reasonable to expect a mobile developer to be able to write unit tests? (We've decided no, for now)

Given that by mid-year we will have grown our department by 50% to approximately thirty, we are committed to getting our process right. In the past, we only had to integrate one or two people at a given time. Now we have less room for error.

I've encouraged the team to re-read Joel's Guerilla Guide to Interviewing* and to err on the "no hire" side if they are at all wavering. But are we concerned about the right things? Only time will tell and I look forward to writing a follow-up article in six to nine months. In the meantime, here are things we look for.

What we like

Developers who:

  • structure their code well
  • write unit tests and enjoy it / couldn't imagine living without them
  • are comfortable with flexible schedules (we do one-week iterations)
  • appreciate learning with and from others
  • can clearly articulate why they chose a specific solution and discuss alternatives without involving ego
  • enjoy the challenge of digging into a problem
  • value writing things down
  • pay attention to detail
  • have successfully worked remotely in the past (even on personal or open-source projects)

That last point is something I really encourage candidates to consider. Working from home (or a coffee shop, shared space, etc.) is quite a bit different from an office and requires a certain mindset.


Whenever possible, we try to stay up-to-date with changes in the environment and prefer developers who do the same. Although we realize it's not always possible to use the latest-and-greatest stuff at work, the coding exercise is green-field development — take advantage of something interesting you saw in WWDC or I/O videos!

As much as I would like to require tests as part of our exercise, I realize the vast majority of mobile teams out there do not write unit tests (and many actively discourage it). Still, we do look for clear separation of concerns and an understanding of how someone could test their code, given the chance.


The server team works in a variety of areas: HTTP endpoints, middle-tier services, databases, data warehouses, and a couple front-end portals. Although we use C#, our goal is to find candidates who are great at designing and implementing back-end servers.

Given how mature the environment is, we expect candidates to have a solid understanding of unit testing, asynchronicity and scalability. Familiarity with large data (i.e. basic algorithmic tradeoffs and processing), redundancy, and ETLs is also useful.

Next steps

We are still hiring for all three teams (iOS, Android, server) and would welcome candidates who could discuss what's been presented here. If you're interested, check out our job descriptions and then send your resume to!

(We are also considering candidates for internship positions)

* Yes, I've read Steve Yegge's response. I think for where we are right now as a company, the most relevant advice from that article is recognizing candidates who are smarter than you and finding people who leave the code better than they found it.