Recruitment is one of the most important things a startup needs to do. We too put in a lot of emphasis on recruitment at VXT and even though we have had a few bad recruits, I would consider that we have been really lucky so far. I had written about recruitment about three and a half years back, and I think some of the things have changed. We are a lot more structured now.
Our recruitment process is a simple five step procedure
- Find resumes you like
- Ask them to fill up this questionnaire
- Have a telephonic interview with people who send in nice answers
- Call them for a personal interview
- Ask them to write a piece of code in 2-3 hours
It seems to work well for us. Since our questionnaire is quite generic, we have been able to use them with designers and testers alike. The last step gets left out with those two, though I’m sure we will build up a way to improve that with time too.
1. Don’t hire people who switch companies a lot
A lot of younger developers in India just pick up whatever job gets offered first and then start looking around. The problem is that most people don’t even consider this to be a bad thing. The origin of this problem starts from our schools and colleges. People get pushed to take up science or commerce based on what somebody else thinks is right for them. The same thing happens when they join a college. Eventually, the first time that they have to take a decision is when they have to join a company, and they are just not experienced with it. So they take up the first thing that they come across, and soon find that it doesn’t work for them. Once they start switching, they realize that you get a salary jump in moving from company to company without really doing anything.
So, If a junior developer has spent less than 6 months at their last company, we just discard their resume, no matter how good it looks.
2. Check if they know why do they want to work in your company
Another very clear way to finding out if the person is the right fit for your company, is to ask them ‘Why would they like to work for your company’.
If they are just randomly looking around, they will give you some crap like, ‘we want to work with your esteemed organization’ or ‘I love the work that you do’ or ‘I want to work on this technology’. Whenever you get any of these or similar answers, you need to dig deeper with this like ‘Which product did you like best’ or ‘What do you think we can improve on the one that you like’.
The smart ones always look up who you are, and will know little details about your company. Many times they would have talked to somebody at your company as well.
The best ones will also be able to tell you WHY you are a better choice that your competitors. They will also ask you some really insightful questions
3. Write your job descriptions well so that the right people find you.
People have researched that if you use words like ‘ninja’, most developers don’t like it. ‘Programmers’ is also another bad word. You can find more details about what to use and what not to use here
4. Experience with huge services companies makes (most) people useless for startups
Some people don’t agree with me on this but I just don’t hire people who have worked at the really huge services firms (I’m talking about you TCS, Infosys, Wipro). I’ve put this lower in the order because this is not the most important deciding factor, but it still is very important. If you’ve ever worked at any of these companies, you would know that working culture if not really good. Most developers even with decent work experience, can’t sit in a chair and code for 3 hours straight.
Also, when their friends start going onsite, they will just want to go too and in smaller companies it is not always possible to keep sending them.
The only person who I have ever recruited with such a background was one who wanted to move into designing because he just wasn’t interested in working as a developer anymore.
5. If they can’t type fast, don’t take them
I’m not sure where I read this (found it), but I’ve found it to be really true. All great developers type really fast. It doesn’t mean that if you type fast, you would be a great developer, but I have never come across any great developer who typed slow. Ever.
Also, I have noticed that the people who type slow, never put in comments. I guess it just takes them really long to do it if they keep typing in long comments too.
6. Ask them to write code
This comes in really low not because it’s not important, but because everybody knows this. Still, most people don’t follow it. I myself used to do this a lot earlier. But now, we just don’t do it anymore. It takes slightly more time, but you need to get them to write a component is 2-3 hours before you can understand how they will deal with bigger problems when they actually join your company.
7. Check if they have a github profile
You can use rapportive to find out if they’ve used Github or not. If they have, give them a lot of extra points because you can go and check out that code even without talking to them. Even if they have just forked another repository and never added anything to it, give them a few marks for that because they would know how to use git. It shows that they are trying to be better developers and have read in places that you need to work with repositories.
All in all, no matter how bad-developer-proof you try to be, some bad-developers will still get in. When this happens, I would like to point you to something really important that I heard from Anand’s (from Gluster) speech at Unpluggd
If you put a lot of emphasis on hiring, you also have to put a lot of emphasis on firing. And you have to ensure that you fire the right people frequently, soon they would be 20% of your company and then you can’t do anything about it
How do you handle your recruitment?