Scared of choosing the wrong developer to build your SaaS or start-up project? Well, I can understand that. After all, I’m not only a developer myself but I’m also a startup owner that needs to hire a crew. I understand the concerns we all have when it comes to building a product or requiring a service. This is probably one of the most intimidating things, especially if you do not have any technical skills that can help you understand what you are hiring for!
There are few things we did to help us to find those rare gems: developers you can trust when it comes to bringing your idea into life. And there are also few other tips which we use over and over when hiring people via Upwork. I would like to share those with you and try and break it down as much as possible here in this article.
Separating the Wheat From the Chaff
Let’s start with what to expect. I’m sure, you have questions now, for example…
How long should all this take?
How long does it take to hire a developer?
Can I just post an offer out there and find a guy the next day?
Unfortunately the answer to this question is no.
The process of hiring a developer is probably going to take a fair amount of your time. It can be anywhere from 3 days up to several weeks when trying to find the right person to work on a specific job. So it’s a very broad range.
But if you are doing this for a first time, consider it taking at least 1 or 2 weeks.
The reason for that is you really want to weed out all the bad developers (and there’s a lot of them out there).
You want to find somebody that you’re going to be able to work with long-term, somebody that’s got some passion for the project you’re working on.
Of course they’re looking for a paycheck at the end of the day but you also want somebody who’s interested in what you are doing. You don’t want just somebody to write a code but somebody who may also guide or advise you when needed, somebody who may bring his own ideas into the project.
The more time you spend upfront finding the right match the happier you will be down the road working with this person.
Next thing that’s super important is that you’ve got to understand what you’re building. The developer cannot and won’t figure that out for you. If you do not have clear specifications for what you want to create, you’re not in a place where you should be hiring a developer. Just keep that in mind, that you as well should do your homework.
Okay, so you’ve got your specs and now are ready to craft your job offer.
No worries you are not going to put all the specs into the job offer, that step was just for your own sake.
Crafting Your Post
One of the things you want to include in your job offer is a good catchy headline. I will leave this one on you but here you probably want to make sure that the developer understands that there may be a long-term opportunity there.
The next thing is the actual job posting where you describe what you want to build, who you are looking for and what the outcome should look like.
No worries, you are not going to post you full specifications. The key thing here you want the developers to realize after reading your posting is: “Okay, this person has actually thought about this project a little more.”
There are lot of posts which are exact opposite. Posts and concepts which take 2 seconds to come up with. Try to open Upwork to see how many you can find. Don’t be like that!
Look at it from your perspective. When checking the answers to your offer, you will immediately recognize the generic answers (or pasted from somewhere else) from the ones where somebody put the effort into it. Developers are not different. If you post something generic, the ones you probably want to hire will skip your offer leaving you with the ones you probably want to avoid. You should keep in mind that:
The quality of developers applying is directly proportional to the quality of your job posting.
Keywords and Categories
To help you with compiling your job posting you can check Upwork or other sites for similar jobs using the keywords relevant to your project. You want to see what others are posting.
In your post use bullet points, be specific in what the outcome should be, what technologies they should be familiar with. Let the developers know that you are ready to hire. That you have all the specifications in place, that your mockups are ready. You can also ask them for time-frame but in order to do that you must be very clear about what you want to be done.
Also make sure you get your job category right as well. You don’t want to be posting SaaS application under Web Design for example. So just make sure you get the category right.
The Secret Phrase
The next thing and our favorite one is a secret phrase somewhere in the post. We use this to make sure that the developers or whoever applying actually read the whole job posting.
What I’m talking about?
Try to include some phrase (I like BLUE HIPPO) in your job posting and ask the applicants to include this phrase at the top of their reply. If it’s not there, you can go ahead and reject their reply immediately.
Because if they didn’t take time to read and understand your posting now, how you can make sure that they will read your specifications later. This is very efficient way to quickly reject responses and not to be buried or overwhelmed by the amount of responses you will get (because you will get tons of them ). And you may be surprised how many people you’ll actually weed out when you’re doing this kind of the review.
Choosing the Right Fit
Last time we posted on Upwork, we got 72 replies. By excluding those who did not reply with our secret phrase, we were left with only 18 candidates. I bet you see the difference now. This is also the number you are most likely to see when posting your own job offer. In most cases you will be able to reject ¾ of applicants simply just by not including your secret phrase in their reply. You may lose some good developers as well but trust me, this is the most effective way to filter developers and go through all responses.
Feedback and Ratings
Next thing you want to do is to look at their feedback. You can check the reviews people have left. You probably want to keep developers with rating above 4 stars but I would advise not to be biased only by this. Take time to read the reviews and look at the context and scope of the projects, they have been working on in the past as well as how much the project was. You are looking for similarities with your project. Have they done this type of work before? How long they have been around as developers?
Very important is also to check their current workload. If they are already out there working on 4 other full-time projects right now, you want to stay away from them.
After filtering out you will probably end up with up to 5 developers you really would like to work with. You’ve looked at ratings, feedback, review, similar projects, their rates are within your budget, but now is time to start communicate with them.
Send an email to all selected developers. It doesn’t have to be long. Just thank them for applying and tell them that they were selected. Just don’t make the message sound too generic. It’s all about building a relationship so you can mention their past projects. Or let them know that you did look at their background or why you think they are a good fit.
The next thing you want to do is to send them a more detailed specifications, either for the project or for the test project. You want to get their thoughts and feedback on the specifications you’ve send them. It’s important that the instructions you give them are very clear, and you aren’t jumping any steps. Communication has to be very clear from your side in order to get a developer to respond.
What you’re looking to see is how their communication skills are. You want them to get back to you with good questions or feedback related to your specifications. You can use Skype to chat with them, but note that - if they are not native - most of them will write good English but will also have an accent. In any case, rather than pronunciation, you’re looking for things such as complete and prompt responses. If somebody is stalling, it’s usually a bad sign and you probably would not want to work with this person. You also want to make sure that they’ve really actually read everything and they understand everything. Understanding comes from questions so they usually should have some. Ask them also what in their opinion can be done differently or better. Their feedback is also very important as you don’t want them to do everything you say (as you may not have experience) but you are also looking to their input.
Reducing Your Shortlist
At this point you should already have some idea about with whom you would like to move on or at least to have shortlist of 2-3 selected developers who may be a good fit for your project. Now it’s better to have a call with them. If you are looking somebody for a long term project, you yourself have to feel comfortable with that person.
Now, what you want to talk about is project itself so spend some time talking about project and its specifications. Ask them about their opinion. You do not want to walk them through the specifications in a detail. Rather than that it’s probably better to talk about some small piece of project which can serve as a test for them. What you are looking for is the timeline, this test job can be completed. Ask them what’s the reasonable time, this can be completed.
If 3 out of 4 will tell you that this can be done in 3 days and the last tell you 15 days, that’s probably not going to work. You generally want a short (paid) test project to see if they can execute and prove to you they know what they’re doing. That’s the main goal with the test project.
Also as I mentioned before, be very clear with your instructions. If your specifications were poorly written and the deliverable won’t be what you expected, you should know that the developer is not the one you should blame. You should also get them agree on date when the deliverable should be delivered and tell them when are you planning to make a decision. It’s better to be straight from very beginning.
After the test project or even real project started, one thing you have to do is to make sure that you are available. In case they have questions or they need to confirm some assumption. If you want them to respond quickly you should expect no less from yourself.
And you should not forget about checking in. I don’t mean overlooking everything they are doing, that wouldn’t make any good. You can agree on periodic emails (once a day, once every 3 days) with the summary of what has been done. Some developers send these summaries automatically, but it’s always better to agree.
Once the time for test project to be delivered is over, you actually want to see if they delivered what they were supposed to. Does it have all the requested features as per your specifications? Does it work as you expected it to work? And if not, why not? If there is an issue, give them a chance to fix it. But by this time you should already know who’s the best fit for your project.
You want somebody who’s interested in what you’re doing, who got the product you’re trying to build or who is showing some passion about it. Of course beside technical part of the project, but that’s why you made them to pass the test. Also keep a list of all top candidates just in case your 1st choice did not work out. You can tell them that you will consider them for future work.
One more thing related to development: you should make sure that you are owner of the code. What do I mean? There were many cases when people became hostages of developers and could not get their source code when they wanted to change the developer. Get a private repository on GitHub and give the contribution rights to your developer so he can push the changes. This way you remain the owner of the source code and your developer will be the one who writes it. This way you can also verify the work as there should be commits from your developer at least on daily basis.
Okay, that’s all! I hope you find it helpful and in case you have any questions you can use the comment form below.