Conversations about life & privacy in the digital age

Stop Judging Resumes: Virtuously Virtual Hiring Practices

In my own experience there’s been very little relationship between the
quality of a resume and the eventual usefulness of a developer. I’ve seen guys
with great work history, references, advanced degrees, numerous publications,
and so on, and yet their presence proved less valuable than their absence.
Meanwhile some of the most rewarding engineers I’ve worked with introduced
themselves with nothing more than a simple letter.

At a previous company I worked with in the dot-com era, we created an epic
test for long distance interviews for a Perl programmer/ Linux sysadmin role.
It consisted of questions that a veteran hacker would maybe know 80 or 90% off
the top of his head, and exactly which man pages to lookup for another 10%.
Cute stuff like “How can you rm a file named -rf?” and “Name
3 things you can accomplish at a GRUB prompt.” We would arrange a designated
time and email the applicant the test. They had one hour (which we would pay
them for) to return it. The test was so long and specific there was no hope of
completion if you needed Google’s help for a large portion of the answers. The
feedback from many applicants was elaborately negative.

These days our process is more to the point. If we’re considering brining
someone on staff, we start by giving them some work to do. We find detachable
development tasks that will further the SpiderOak cause, send them a minimal
set of instructions, and let them run with it. It’s usually something
smallish, 1 – 3 days at most. As an all telecommute team, we’re already
accustomed to giving code feedback. When they’re done, they send us a bill and
we send them a review.

Sometimes we give several people the same task. The results often show an
obvious contrast of strengths and weaknesses across several applicants, and it
conserves the (sometimes scarce) resource of development tasks that don’t
require detailed knowledge of core SpiderOak source code. Sometimes we’re not
sure after the first task so we give more.

I’m sure there are big corporate HR departments who would be astonished to
learn that the best predictor of a developer’s usefulness might be an ability
to complete development tasks.

The Virtues of Virtual…

Given that we have just completed the first official physical gathering of
the SpiderOak Team (see picture below), I thought this might be a good
opportunity to discuss our experiences with creating, building, maintaining,
and continually developing our virtual work environment.

When SpiderOak began, our hiring philosophy focused on finding the best
possible engineers. As you can imagine, that search took us much greater
distances than the cities in which we live. In the end, after our team had
formed, the developers that build the SpiderOak application represent 3
different countries (Bulgaria, Germany, and the US) and 5 different states
(Virginia, Indiana, Illinois, Missouri, and Washington). All my ideas of
creating the fun loft work environment with beer breaks and ping-pong where
quickly dashed. However, what arrived in its stead has been a pleasant and
efficient means of conducting a development and business process on a daily

Daily Communication – We all talk everyday. And due to the nature of our
placement, there is usually someone online at all times which makes for some
interesting early morning/late evening conversations. Our medium for
communication is IRC (Internet Relay Chat) which, despite having to overcome
my own technical ineptitude, has proven to be a great tool. Further, through a
monitoring bot (aptly named SpiderBot) we are able to capture every
conversation and place it on our Wiki – allowing everyone to review what was
said throughout the day.

General Communication – As mentioned before, most if not all of the
information pertaining to what we are doing (both descriptive and actual code)
is stored on our Wiki. I have found this to a be wonderful tool for
organizing, distributing, and developing a communal work environment where
comments, thoughts, ideas, and directions can be laid out and communicated in
an organized and structured format.

Voice Communication – Although this does not occur with great frequency, it
is nice to hear everyone’s voice from time to time – if nothing else to
re-establish that everyone is actually human – on both ends. We are currently
trying to set-up a weekly conference call to both keep aware of each other and
further discourage the developers from turning into or creating artificially
intelligent droids to handle the load.

I will look forward to posting more about our experiences as we continue
and will always be curious to hear additional thoughts, experiences, ideas on
other virtual networks – what worked, what didn’t, and what still might…