Hiring High Quality Developers on a Bootstrapper’s Budget

Most of the info you’ll find on hiring is meant for large companies or startups with funding.

What if you’re bootstrapping?

While you’re not going to be competing with Google or Facebook for the same people, you still want developers that can do high quality work to help build your product.

The post that follows covers what I’ve learned about hiring high quality developers while bootstrapping Bidsketch over the last three years.

Before you Post the Job Application

Make sure you know what you’re building before you hire a developer.

I know, this sounds obvious, but a lot of people aren’t specific enough before they try to find someone to help build their product.

Building Version 1

The first version of your product should be very simple. A lot has been written about building a minimal viable product, so I won’t go into the details. I’ll just show this v1 Bidsketch screenshot of the proposal overview page:

(Click below for larger view)

 

Things that I wanted to launch with but are missing on that page:

1. Copying proposals
2. Client activity details (time spent viewing the proposal, etc.)
3. Integration with at least one invoicing app
4. Ability to comment on a proposal
5. A decent design
6. Etc.

Why did people pay for Bidsketch at that point?

Because it saved them lots of time when writing proposals (which addresses the core problem).

Have Something to Show People

The other thing you’ll want to have before hiring a developer: Documentation of your product’s first version features and interface.

It sounds like a lot of work but you can get this done quickly with the right system.

With Bidsketch I did the following:

• Created a high level document describing what Bidsketch was supposed to do
• Used Balsamiq Mockups and created every single page of the application
• Hired a designer who took those mockups to design the app
• Created screencasts where I walked through each of the pages and explained how they were supposed to work

Hiring a designer is optional if you’re on really tight budget. Use some of these templates or libraries to help on the interface side:

• Admin templates from ThemeForest: http://themeforest.net/category/site-templates/admin-templates
• Twitter Bootstrap: http://twitter.github.io/bootstrap
• Zurb Foundation: http://foundation.zurb.com

Initially I described everything — in as much detail as possible — on a wiki. I soon learned that it was too much information and no one was actually reading it. So I changed to using screencasts and got much better results.

(Note: Use Jing for screencasts; the 5 minute limit on the free version keeps you focused on the stuff that matters. Inspired by Rob Walling’s use of screencasts to give instructions to VA’s and covered in his awesome book.)

Posting Your Project

I’ve hired developers on job sites like oDesk and from other sites like Craigslist. I prefer using oDesk since you can view feedback from their previous projects and it’s much easier to sort through applications.

Regardless of what you use, you’ll want to start by posting a new job with the following things:

1. Clear and specific title that stands out – I like to mention the type of application, what problem it’s solving, and the programming language in the title. Example: Rails Developer for a Web App That Helps Freelancers Get Clients
2. High level goals – It’s necessary to mention your high level goals if you want the developer to make great suggestions.
3. End result – What the product is supposed to produce. For Bidsketch this meant including several sample proposals.
4. Confidence – This is important because developers will judge you based on what you write. They’re trying to figure out what type of client you’ll be. The good ones will not apply for your job if they think you’ll be flaky, argumentative, or won’t pay on time.
5. Action item – Give people an action item. Sometimes I ask them to reply with: I AM REAL at the top of their message, other times I ask them to send me a link to their Github profile (or something similar). People that completely ignore this either didn’t read the job description or can’t follow simple instructions.

Example job description on oDesk (click for larger view):

After I’ve posted the project description I filter developers in four stages.

Stage 1

First stage consists of declining applications from developers that don’t fit my profile.

What do I look for?

• Previous experience building web apps — if that’s what I’m looking for (as opposed to a desktop or iPhone app)
• Previous work history in oDesk (or public project history in Github if job is on Craigslist)
• Average feedback of 4 stars or better (disregard for Craigslist)
• Individual developers instead of agencies

I used to heavily filter at this stage but nowadays I’m a bit more flexible here. There really hasn’t been much of an interaction to decline a ton of applications just yet.

That said, even from the small amount of information here it’s easy to see that (usually) more than half aren’t going to work out. I promptly decline those applications.

Stage 2

I send a message to the remaining people. The message has a few questions and it’s very short/simple.

Example email:

Hi X, thanks for applying for the job.

I have a few questions for you:

1. How many hours a week are you available to work on this project?
2. Do you have a Github project or code samples I can take a look at?
3. Tell me about your development environment and the tools that you use please.
4. Why do you think you’re a better fit for this project than the other people that applied?

-Ruben

(Note: A while back I used this process to hire a support person and instead created a Google web form with these questions. If you have a lot of people at stage 2, this works great as you can rank each answer and sort by totals. I stole this from the Noah Kagan’s Hiring Course on AppSumo.)

Things I look for in responses:

• Ridiculously short responses. They either don’t care or their English sucks.
• Too many clients or active projects. Reliability and availability is a major problem with most contract developers.
• Attitude. People that seem like they have a bad attitude or are annoyed at the number of questions they have to answer aren’t the right people.
• Fast response time.
• Developers working in Linux or OS X. I don’t hire developers that work in Windows (since I’m usually hiring Rails developers).
• Experience building similar things. That’s the real purpose behind question #4; I want them to show me they’ve built things that are similar.

Stage 3

Based on answers to stage 2, it’s typically very easy to get the list of applications down to about 5 developers. I send those developers another message asking if they’d be open to doing an exercise (coding test) in Ruby on Rails.

This is the email:

Hi X, would you be able to do a small programming exercise? It would be paid of course (through PayPal). If you’re interested, carefully review the README file inside the attached Rails project and let me know if you can do this. Also, please send over an estimate on how long you think this will take. Thanks.

-Ruben

So what’s the test exactly?

My test is just a simple template engine in Rails. Similar to what’s shown in this tutorial:
http://www.broculos.net/2008/03/how-to-make-simple-html-template-engine.html#.UXgmtpVVicY

I give them a zip file with a Rails app, the HTML file and even the controllers. They just have to code the business logic.

You’d be shocked how many people can’t do a decent job here. You’ll learn a ton about how they work by seeing them actually writing code and reviewing their work.

If you’re not technical, find someone technical to review the work for you — it takes less than 5 minutes. I’d be happy to send you the test and/or review the work if you send me an email 🙂

After they finish with their test, I typically ask them to make some sort of change. The specific change doesn’t matter as long as it takes about 30 mins to an hour. This step is important because you’ll get to see how they react to these types of request and how quickly they get back to you.

At this stage I’m looking for the following:

• Fast response time
• Fast implementation time (short amount of time finishing up the exercise)
• Accurate estimate
• Clean code
• Intelligent questions regarding the coding exercise

Some people won’t finish the code or will make an excuse why they can’t start for a couple of days. The ones that can’t finish, you obviously don’t want to hire. People who can’t start on the exercise for a few days might be too busy, so be careful with them.

Stage 4

You might be left with about 2 or 3 developers by this point. The next step is to set up a Skype call/chat and talk about the specifics of the project and how you plan on working with them.

The last stage was about code quality. This stage is about finding the developer you feel will be the best regarding communication, availability, and responsiveness. Pick the one you feel most comfortable with.

Another big part of this stage is about setting expectations expectations. What do you expect from them? What can they expect from you?

You might create a list of things that they expect from you like this:

1. Daily 5 minute Skype chat sessions to discuss progress and new work
2. All work should be accompanied by unit tests
3. Please thoroughly test everything in your browser before sending it over to me; I shouldn’t be the first person testing things in the browser.
4. Some sort of notice if you’re not going to be available for more than a day.
5. Etc.

Some of this you’ll have covered in your original job posting but it’s important to be 100% clear on what the expectations are on both sides of the relationship.

Once you’ve decided to hire a developer, you should continue to test them out by having them work on small tasks for your project that take anywhere from 2 to 4 hours.

I prefer to hire them for a two week trial period and will send a message like this:

I’d like to hire you for a two week trial period. This way we can pause after the two week period and evaluate whether it’s working on both sides, and whether it makes sense to continue working together. How’s that sound?

This way you’re more likely to move on quickly to the next developer if it’s not working for you, and they’re more likely to stop the contract if they’re not excited about the work they’ll be doing.

Final Thoughts

Hiring people takes practice and you’ll likely make some mistakes at first. If after the first couple of tasks you’re not getting the type of results you want, end the contract as soon as possible.

For some reason people focus almost all of their energy in trying to find the developer with the best code quality. This isn’t always what you want.

The biggest problem you’ll run into is with communication, availability and reliability. So focus on those attributes as much as the quality of the code (even more, I’d argue).

Finding the right developer can take some work, but it’s totally worth it.

Even if you have a technical background, seeing your product being built while you work (or sleep) is awesome.

I outsourced about 50% of the code on the first version of Bidsketch and launched in half the time.

Give it a try, you’ll be glad you did 🙂