Recently we have been doing a lot of hiring, which has led us to interview almost 5 – 6 candidates in a day. While it is tough to get a good programmer, our location makes the job even harder as the talent pool in Indore is quite limited. That takes away the luxury of rejecting even one good developer.
So how do you go about sifting through tons of resumes and yet ensuring that not a single gem gets lost?
While we are still evolving, the current process that seems to be getting the job done for us (well, almost) is:
Screen: Give them a very basic program, just to check whether they can actually code or not. It is surprising to find that even “senior developers” with years of experience would fail to write a simple algo like finding the maximum integer in an array. In our experience, 90% of the people fail to make through this round.
This allows us to focus properly and budget sufficient time for the 10% that we are really interested in. Thereafter there are several skills/attributed that we look out for:
Communication:A developer, however smart she is, can not make a software on her own. Thus it is pivotal to gauge whether they are able to understand what others say and can express their opinion in a manner that is easy to comprehend. I have seen programmers who are brilliant and can solve the most difficult of algos in a jiffy, but who find it very difficult to work with others and thus can not ensure the success of the project.
Passion: We invest a lot (time wise and emotionally) in the work that we do . Thus it is important that the next person coming in has the same level of passion and ownership for whatever we are doing.
We generally check for a person’s communication skills and their passion by asking them to describe their current project, or the most difficult problem that they solved, or what they love about their work. The right people would get you interested in their conversation, explain their problems and solution in a manner that a layman can understand. The moment the conversation starts becoming boring or monotonous, you know you have a reject.
Awareness: Most good developers know about what is happening in their community. Inquiring them about the gotchas in the recent ruby version, or the recent tussle going on in open source tends to get them all charged up.
Aptitude:One of the fun of working in Systango is that you get a new challenge to solve on almost a daily basis. This requires not only persistence, but also out of the box and creative thinking.
Asking some Fermi Problems is one way of doing this. The other could be to let them take a stab at a real world problem and see how they approach it differently.
Design:While we know that the person can code, we still need to ascertain that she can design and architecture the code in a manner that is flexible, robust and maintainable. For this we give them a relatively complex problem that takes around 2 – 3 hours to implement on an actual box (along with internet and whatever tools they need).
Looking for red flags: During this entire process, we are constantly in the hunt for any warning signs like “this code was just for test, I would have named the variable differently in production”, “I thought of adding the exception handling later”, “My previous company sucked”, “I can only work till 8PM” etc.
The dynamic environment that we work in makes it paramount to ensure that every one in the team is in sync with the culture that we have so carefully cultivated. While it is almost impossible to gauge a person’s personality in a few hours, these red flags help us weed out most people that we know won’t gel with us.
Finally, ask them about their public profile. Their github handle, a blog they have written, any open source project that they are contributing to. While it is not a must to have these , it helps us identify the best from the good.