How Do We Find Great Developers

I am not an HR ninja or guru, so you can stop reading right now if you want to. But as Stanfy is the first place I’ve worked, I have a great opportunity to build up my experience from zero, meet problems 90% of which are new for me and of course trap in that “facepalm situations” that help to learn fast and remember long. So I’d like to share our hiring process at Stanfy particularly some tips we already use or just test on practice.

Pre-interview stage

Review job descriptions with developers. After I’ve written an “amazing” job description I send it to our engineers and CEO for a review. It is surprising what ideas they may have. As with any good software, make sure your users will understand your solution; any description should be clear to potential candidates.

Career page matters. We were faced with the problem that our career page doesn’t give candidates a call to action; it doesn’t interact with them. So now we are actively working on improving it. I find Kickstarter, Dropbox and Scribd have really great job pages. They describe the company’s main principles, approach to work, number of open positions and so on in an easy and interactive form. It must answer questions about the company, not double them.

Write constructive and concrete emails. It’s very important to appreciate the time of people to whom you are writing (not only devs). Good specialists receive hundreds of offers every month, so the goal here is to give a picture of the company and the offered position in the shortest possible way. Below is a list of rules I follow in composing my emails:

• “Hi” is much better than “Dear Sir/Madam”. Do not be too formal; it’s not a letter to Obama.
• Personal introduction (name, position etc.).
• Describe a project which I’m inviting a person to.
• In a few words describe the company, but without such abstractions like : “friendly team”, “good place to work” blah blah.
• Write facts that mean something.
• Give links to a full description of the position, the company profile, and maybe some additional sources.
• If writing to a person from another state or country, mention the relocation process.
• Say “Thank you” for the time the person spent on reading my letter.

Examples of bad emails:

Always reply to candidates’ requests. Yes, if a candidate sends a CV he/she is supposed to get an answer promptly, not after a couple of months. If we don’t have an open position or the candidate doesn’t match our requirements — I just say so, because it’s a part of my job to let people know whether they match or not. Maybe in a few years I will be talking to a Senior Dev, that I ignored when he was a Junior. The world is small and life has a good sense of humor.

Personal connections. I ask my friends and colleagues to spread the word about an open position among their contacts. The level of trust will be higher in this case and who knows. Maybe the theory of six degrees of separation will work for me.

Own base of potential resumes. I save any CVs that I consider interesting. Even if we don’t have an open position right now, I can contact candidates later when I renew the search. Even if they are not interested in our offer any more (because they found a job, changed location, etc.) they could recommend somebody.

Be where they are. It’s important to visit tech meetups, conferences and so on — dive into the tech world. When learning something new I can also make useful connections. I also try to be present in dev.communities, different G+ groups, forums and so on. It doubles the chances of finding a needed developer.

Involve recruiters. They increase the flow of CVs, making the search more widespread. But we discuss with them the emails’ structure I have written about above. It helps to avoid situations when recruiters’ letters play against us because of poor wording.

Remember the power of social media. It will create a buzz around the available position.

The process of reviewing candidates and further interview stages

After we choose a number of resumes, I contact candidates and discuss all these considerations: relocation, level of English, the company’s perks, salary expectations etc., so no questions will be left for us or the candidates.

Ask for a sample of code. It’s obvious we need to look through the candidate’s code to judge its quality. In Stanfy our engineers review code samples and if they don’t like its quality, we don’t spend anymore of the candidate’s time or ours (of course informing the person about our decision); if the code is great, we invite its owner to have a skype-interview with the team.

Involve the developers team in the recruiting process, always. Starting from code-review and continuing to other stages. First of all we search for a person with whom the team is comfortable working and interacting.

Skype-interview. At this stage I’m not an active participant anymore. The team of engineers who will potentially work with the newcomer and our CEO take it into their own hands. There is no need for n-circles of skype-calls that take too much time and tire both parties.

What do we ask during the call with the candidate?

• work experience (team/freelance, resolving conflict situations, etc.);
• what instruments libraries are used in work;
• sometimes we offer a test project to check his/her analytical skills;
• knowledge and interest in new iOS/Android features;
• social activity on dev communities;
• check English level;
• favorite books, games, and so on.

If you are still with me and reading this it’s great because we’ve got to the most interesting part. If a candidate passes the skype-interview we invite him/her for a test day in our office.

Test day format. We invite candidates to spend 5 to 8 hours in the everyday-working atmosphere in our office. During this time we practice pair programming; it helps to see how the person carries out tasks and solves different problems. It also helps both the candidate and us determine whether or not we are ok with each other. Candidates can see our office, meet with the team, decide if it is interesting for him/her and make a decision about whether he/she wants to become a part of Stanfy. We think these 5 hours with the team in a live situation are much better than 5 one-hour interviews with HR, PM, Team Lead, CEO and so on. And if we suit each other Stanfy becomes one more great person bigger!

P.S. Create a good place to work. We keep the process of improvements dynamic in all the areas and all the time. It’s useful to listen to the team — they know what is the best for them!

Stanfy is an agile software development studio. We help others evaluate technology, develop and deploy software systems that tuned to work in mobile and wearable world. Drop us a line if you need a collaboration on your lean technology product or startup.

If you liked the article, hit that heart button below. Would mean a lot to me. :)