Recruiting Developers
It's far too easy to open your door for someone and find shit in your sandwich.
This note is about recruiting software engineers. Also applies to recruiting other staff but everything is primary viewed from developer hire point of view.
Premium developers are extremely important. For most things in life, range between best and average is 30% or so. Best meal is 30% better than average one. This is different with developers. 3 times better than average is rare but they do exist.
Avoid bad programmers like plague. Bad programmers create negative value because they pile up complexity that must be fixed in the future. Bad programmers are toxic and will poison your whole project.
Great programmers don't like working with bad programmers. But the best programmers will usually mentor average programmers that have the interest.
Don't settle for average developers in small teams. For startups, you should aim to hire only the best, the first few hires are the most crucial for success.
New people need to fit into the company culture. Same applies to small and big companies. New employees should have compatibility with the spirit of the people already in the company.
Finding Developers
It's impossible to tell if a programmer is good based a formal interview. Especially if you don't know anything about programming.
Prefer hiring friends, friends of friends and friends of employees. Programmers usually hang with like-minded people. Hiring friends is also easy in that sense that they will then connect with at least one person in the company, thus fitting better in company culture. But don't let employee referrals cloud your judgment though.
Hunt by referrals. Get your developers list smartest people they have worked with. Go after them like crazy. Give developers a bonus if the referral leads to hire.
Recruiter's job is to sell the company, the team and the role. After you encounter a good developer, invite him for a beer and go into flattery mode. Give subtle hints that your company might be hiring. Tell how awesome your company is, but never lie.
Good programmers are usually found:
- through personal connections, referrals and recommendations.
- in online programming communities e.g. programming subreddits, encourage your developers to contribute to open source projects.
- in programming meet ups e.g. hackathons, encourage your employees to attend these.
- in early adopter conferences e.g. PyCon was good a while ago but not anymore, encourage your employees speak in these.
Good programmers are sometimes found:
- in development conferences e.g. modern PyCon.
- in educational institutes.
- by online job posting.
- contact you through company homepage.
Good programmers are very rarely found:
- by recruitment agencies.
Job postings should be honest. Be honest when you are recruiting, people are usually self-selective and apply only if they feel they could fit it. Saves you a lot of time and money in the end.
- Add basic information about the company.
- Add basic information about the open position.
- Add contact information.
- Add a brand new programming language in the recruitment post. This will get the attention of hardcore programmers that learn languages as they come and are truly interested in programming.
- Answer any more detailed follow up questions.
Developer Quality
You can't train enthusiasm and work ethic.
It's not magic. You need programmers that create simple and stable software, not algorithm wizards. Even less bright people might be really productive developers and can get more done than the over-engineering genius sitting next to him.
You can reduce management with the right hires. Always hire people that are smarter than you in the job they will be doing. Then you can't effectively micromanagement even if you wanted to.
Avoid low hanging fruits. Never focus on hiring because applicant knows technologies that you are using for your current project or because he will work for cheap. Good developers learn any technology in a week or two and only bad developers will work for cheap.
Focus on these qualities:
- Passionate about something: programming, tech, science, video games etc.
- Personal character, nobody wants to work with a jerk.
- Gets things done, check past work and projects.
- Code clarity, can other developers work in same projects.
- Fits to the company culture, doesn't feel left out.
- Able to learn new, usually means that the applicant is young, unfortunately.
- Curious, it's a good sign if they ask questions back.
Give extra points from:
- Motivated by the company values, mission or employees.
- Has seen project fall under complexity, understands why to avoid tech debt.
- Can communicate effectively, written or spoken.
- Positive life attitude.
- Strong work-ethic, hard to validate but can look at previous positions.
- Adaptability e.g. can work on Linux, Windows and Mac.
- Good English, especially written form.
- Come from different background than the other employees (city, nationality).
- Smart, not about knowing facts, but have a conversation and it shows.
Initial Filtering
There is very little correlation between how good a resume is and how well the applicant can code. The main thing that it helps with is to steer the interview into topics that the applicant might be familiar with.
All applicants should be filtered before the interviews. Applicants that came through in-house recommendations may skip this step. Ask non-recommendation applicants to fill four step form online:
- Why do you want to work at the company. To understand personal motivation.
- Can you share us a code sample you are proud of or you think represents important part of your coding philosophy. Raw code or URL. It can be 1 line or a whole file. To see a little bit of code and get something to talk about later.
- Can you tell us about a relatively recent hard problem you have had to solve and how you went ahead solving it? This can be anything from Java threading bug to finding apartment. To check how well can he write and explain.
- Can you briefly describe your background as a person, not a resume or CV. To estimate does he fit in the company culture?
- Additional links e.g. homepage, LinkedIn, GitHub.
Remove an applications if:
- Can clearly see that the person doesn't know anything about programming.
- The written language is very poor or otherwise communicates poorly. Programmers that cannot communicate through written medium are next to useless.
- Otherwise shows straight away that will not fit in the spirit of the company e.g. the candidate is a 40 year old father of three and your company is full of 20-something singles or the candidate doesn't understand your company values.
Actions speak more than words. See what they have made, is it readable? If the applicant has GitHub account or similar, take time to read their code. Not a deal breaker but reading available code gives much insight.
A Quick Chat
Hire Slow, Fire Fast
Have a chat with the remaining applicants. Call them or if they live near, meet face-by-face for a coffee.
- Don't grill them, just a brief chat.
- Ask them few technological questions related to the answers they given.
- Ask them about their past projects.
- Remove all who have not accomplished anything or have no projects to share. Cold but not having any personal projects is a really bad sign, not worth the risk.
Get opinions from relevant people. Share all applicants that got to this point with the team they will be working in.
Good additional questions to ask in filtering stage:
- General interest:
- What do you know about
? - Why does it interest you?
- Current situation:
- What are you doing at your current job?
- Why are you looking to leave?
- What are you expecting from your next job?
- How quickly are you looking to make the change of jobs?
- Where do you live? Are you willing to commute to work?
Paid Assignment
Make each applicant do a paid assignment. If an applicant has gotten this far, it is time to spend some money on the applicant and show that you mean business. Have them do an assignment over the weekend and pay $100 per hour. Estimate the task duration based on how long your already existing developer would require to complete it.
Define a clear scope for the assignment. Don't use a real problem that you have, give a clearly defined and scoped problem that leaves room for customization if the applicant wants but don't expect it.
Have the applicant present the solution to a group. This will weed out very defensive-arrogant developers, they are really hard to work with. But defending solutions they can rationalize is a big plus.
Pay the applicant right after the group meeting. Never say right away if they will be dropped, you should avoid making the decision appear trivial.
Paid assignments have gotten some bad publicity as of 2018. I personally still think they are an essential part of recruitment process; just make sure that you 1) compensate the applicant properly like $100 per hour and 2) that you make it clear that the produced code won't be used anywhere.
Sources
- What do you know about