Skip to content

Instantly share code, notes, and snippets.

@seanwolter
Last active August 29, 2015 14:22
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save seanwolter/d5b17fb5f6019b04b763 to your computer and use it in GitHub Desktop.
Save seanwolter/d5b17fb5f6019b04b763 to your computer and use it in GitHub Desktop.
how Vokal's iOS team evaluates candidates
At Vokal our engineering interview process is pretty simple. Before we get emotionally attached
to any candidate we meet with them for two coding challenges. Candidates solve these contrived
coding conundrums with members of our team. During the challenge candidates are encouraged to
check documentation, google for help, and talk to their proctor. The exercise is not about
brain teasers, but how candidates work with people to solve a novel problem. Most of our
challenges require manipulating basic data structures. The work is completed in a collaborative
text editor. Often the most difficult part for candidates is working without autocomplete.
We've often asked ourselves what we want from candidates in these programming exercises. In short,
we're trying our best to notice the idiosyncrasies of a good engineer. There are small things like,
Does the candidate know their way around their own computer? Are they effective at googling and
reading documentation? Then there are bigger things like, Can they repurpose code from sites
like Stack Overflow? Are they capable of asking for help or admitting ignorance? Are they curious?
Whether the candidate solves the problem or not is secondary to the way they attempt to solve the
problem and how they work with their proctors. We all understand that a code challenges is a blunt
instrument, but at the moment it's the best qualifier we've got. If a candidate is just short of
competency we've always got our apprenticeship program.
After the code challenge, candidates will come back to spend an afternoon with the team. This gives
everyone a chance to get acquainted. I try to be as upfront as possible about the ups and downs
of Vokal. "Straight shooting" is one of our core values, after all. On the iOS team we've agreed
that we're looking for a few key traits: enthusiasm about the platform, ability to learn,
varied experience, ability to teach, curiosity, ability to ship, and flexibility.
After the hiring team has had a chance to meet the candidate managers ask for a HIRE/NO-HIRE decision
from everyone involved. Based on that I make a decision and go forward.
What do you think? Do you have any better ideas? At Vokal we're always iterating on our processes.
This process may not be the same in the future, but I'm hopeful that by sharing we might help
others and help ourselves.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment