We're very happy to announce that we've had a great developer accept our offer to join our team. We'll have more details on our newest team member soon.
This was our first attempt at hiring and we certainly learned a lot. While our process has improved since we started, it's still a work in progress.
The first lesson we learned is that hiring can take a long, long time - in fact, much longer than we expected. I looked back through my emails and we officially started looking for someone more than four months ago. One thing we have heard time and time again was the importance of hiring only the best people - and, just as importantly, people that fit well within your company culture.
As a result, we were extremely picky when it came to candidates. As the process goes on and on, it's easy to get frustrated and want to lower your bar. Avoid this temptation! If at all possible, go the other route: raise your compensation, improve your pitch, and raise your profile so you can attract candidates that meet or exceed your bar.
When we started, we severely underestimated how long it would take and we overestimated how many applications we'd get. Because of these bad assumptions, we made our first mistake - we chose to slowly "roll out" the announcement that we were hiring. First, we just told friends and mentors. A week or so later, we tweeted and put up a blog post. Later on, we posted on some news sites and newsgroups. And after that, we finally created a job posting at Startuply. Waiting between each step was a waste of time - we should have just broadcast as loudly as we could the first day.
We ended up getting a good number of applications, the vast majority of which were from great programmers. We assumed that going through them would waste a bunch of time. We were wrong. In reality, it was really easy to turn down many applications just from their resume (usually the applicant was good, but didn't have the skill set we were looking for). Phone calls were a bit more time-consuming, but were never a waste of time. We always enjoyed talking to candidates, always found a way to improve our process, and usually learned something new about the Ruby ecosystem.
One thing that we improved on was learning to say "no" quickly. Even with the manageable number of candidates we talked to, it was important say "no" as soon as we discovered something that wouldn't fit. Early on, we were a bit hesitant to do so and ended up continuing our process for too long. That wasn't fair to either ourselves or the candidates. It became easier to shut things down quickly once we had interviewed a few people and started to gain confidence that new applications would show up, even if the queue was currently empty.
We also learned that it's important to have a fairly short process. Of course, the biggest priority is to have a process that lets you learn enough about a candidate to be confident in your decision. That said, as you improve, you'll find that you can shorten your process while maintaining your confidence. Shortening the process is better for you (less time spent) and better for your candidates.
The initial version of our process went something like this:
- Check resume, blog, Github account
- Introductory phone call to learn about candidate and convince them Devver is cool
- Second phone call to ask some high-level technical questions
- Ask for and call references
- Remotely pair on a project for a few hours with the candidate
- Fly candidate out to Boulder to meet and discuss technical and business issues
The final version was a bit more compressed:
- Check resume, blog, Github account
- Phone call to learn about them, introduce ourselves, and cover high-level technical questions
- Ask for and call references
- (In parallel with #3) Ask candidate to write small Ruby application and review their code
- Fly candidate out to do some pair programming and discuss technical and business issues
All in all, it was a good (if sometimes painful) learning experience. We deeply appreciate the time and effort spent by every single applicant (and their patience with us as we learned by trial and error).
If you've got your own lessons you've learned while hiring, please let us know. We know we've still got a lot to learn...
subscribe to our feed