6 Interviewing lessons we learned while building our engineering team

A year back we were around 25 folks, 10 of us were part of the engineering team. This has been a year of growth, in terms of the number of calls/SMS-es that have flown through our system – we connect 2 million people a day via our platform. Our tried and tested stack was beginning to burst at the seams. We started to redo a considerable part of our stack to ensure it scaled well, and at the same time we set the ball rolling to rewrite our entire stack from scratch because it became evident our current stack would only scale for a year. All this meant we had to grow our team and get some of the best engineering minds on board. We have 80+ strong team now with a 30+ strong engineering team and still growing. On the way, we have interviewed a lot of folks, made smart hires, made bad hiring decisions, missed a few good hires and  learnt a lot. Here are a few tricks that we have picked on the way that has helped us well.

Never hire out of desperation

This is hiring mistake 101 and everyone does this. We have done it too, but ever since, we have consciously stayed away from it. When in doubt, it is better to err on the side of caution.  It is possible that you might miss out on a good hire, but this is far and few. When you are in doubt, remember you and your team have put in hours to talk to the candidate and yet you are not convinced. If there is something that you could do to convince yourself, you must put in that extra effort – may be another round of interview or an exercise. And beyond that if you are still unconvinced, it is better to move on to the next candidate. One of the prime reason to fall into this trap is a desperation to get more people on board because your plans are missing deadlines and you believe the more people you have on board you would get closer to your deadlines. But a bad hire will cost you more, pulling you and your team down. A lot of people argue that it’s ok to hire fast if we can fire fast. But the “firing fast” rarely happens. Most folks are uncomfortable doing that and similar doubts will nag you then too – should I give him/her more time. As a rule of thumb never hire out of desperation, you will be correct 90% of the time.

Avoid the jargon guys, like a plague

Time and again you would meet the supremely confident candidate who keeps throwing technologies at you throughout the conversation, saying how they used kafka and made their system 4x faster or how just by using react.js they made their website faster or how moving to Aerospike reduced latency by 80%. I’m not saying these are not possible, these technologies exist for exactly the same reasons, and that is why the problem. Anyone could say they did this. It is important to just get the conversation to pure basics of whys and the hows. Why Aerospike and how do you think Aerospike solved the problem? Or why choose Kafka? Keep the conversation at basics, pure basics. But if the conversation still meanders at 10,000 feet with a lot of name dropping, it is time to shake hands and bid goodbye.

Hiring a senior engineer? Get a junior to interview

There is a lot of  literature about hiring people with the right “culture fit” and “attitude”. The folks at Intercom say hire for Culture Contribution rather. These are extremely difficult to get right in an interview scenario. Even if you spend hours together conversing with the candidate the culture bit is a leap of faith based on observations in a non-work scenario. Even if you get the candidate to work with you for a week, it just makes the leap a little easier. One neat trick that has worked for us when hiring senior engineering folks is to get some of the not so experienced guys to interview them. And this comes from a lot of observations we have had at Exotel. Some of the senior folks who join or some of them as they get experienced are excellent individual contributors, but they struggle to work as a team. And this more evident when working with engineers many years less experienced than them.  They tend to be annoyingly bossy, completely closed to feedback from them and lack the skills to mentor them. We thought if we could experiment this in our interview processes, it would give us good indicators to take a decision. It has worked well for us. It has its potential pitfalls. Not everyone is a great interviewer and it comes with experience, so you might need to coach a bit. But try it out.

No Code, No Hire

If you are building a great engineering team, you need to hire people who can code, regardless of how many years of experience they have. A lot of interviewers are reluctant to ask experienced candidates to code. You are on a slippery slope there. We have seen even some of the most experienced guys struggle to code. <overboard>Modern editors, frameworks, search engines and stack overflows have spoilt generations of engineers </overboard>. Try a FizzBuzz question to break the ice. If you are still uncomfortable asking an experienced candidate to code, ask your HR/another senior to let the candidate know in advance that he/she is expected to code.  Don’t hire without seeing the code. Period.

Ask them a problem in recursion

Ask a problem in recursion. Yeah, do that. However silly that might sound, this has been  a good interview hack for us.  The ability to break down a large problem into smaller subsets is the hallmark of good engineers. Recursion problems are exactly that. Good engineers will have a good grasp of breaking down problems into smaller subsets. You will be surprised to see the number of folks who stumble on facing a problem in recursion. Go ahead and try it out. In fact, a few our FizzBuzz questions are problems in recursion.

Don’t hire Yes Men/Women

Some of the best engineers, even those who are people of few words have strong opinions. Keep an eye out for them. And reject those who don’t and seem to agree with you on everything. In an interview propose a design and ask the candidate to review it. Or critique a popular open source architecture and get the candidate’s opinion or ask him/her to critique it or make some horrendously wrong claims on some code and see how the candidate reacts. The lesser mortals would let it pass. The good ones would jump at you.  They usually turn out to be gold.