Top 3 Things to Look at While Developing a Technical Team
One of my favorite questions to ask in an interview is the following: When you misspell a query on Google search, it comes back with a “Did you mean <corrected query>” and shows the results for that. How will you implement this feature on a search engine?In my experience, most people will answer it in one of two ways. The first solution is usually some variation of the following: Lets implement a spell checker that will look at every query. If it finds a misspelt word, then we’ll correct it using the spell checker, and execute that query.
However, a small group of people will come up with a far more innovative answer: Let us look at the history of all searches on the site looking for the following pattern: A user searched for “x”, didn’t click on any results, and then immediately searched for “y”. If these (x,y) pairs happen frequently, then y is a corrected version of x.
The ingenuity of the second solution becomes apparent when you think of the following issues that will need to be addressed if you were to really implement this. How will you deal with 90 different languages? How to deal with proper nouns, that too in all those languages. How to deal with words like “Flickr” or “Telefone” which are mis-spellings according to the dictionary, but are valid search queries. The second answer solves all these issues elegantly.
Engineers love to solve problems
When you’re looking to hire a person for your technology team, it is important that this person enjoys solving problems. The person should enjoy thinking of problems and coming up with solutions in their head. Solving problems elegantly comes from practice, and the above question is designed to test that. In my experience, engineers who truly enjoy thinking about solving problems, and have been doing this for a long time will come up with the second solution. And these are the folks that you want on your team. Having a healthy attitude towards problems, dealing with them and solving them elegantly and efficiently is an important characteristic for every technologist, especially in a startup environment. There will be no shortage of problems in a startup, and you want someone who enjoys dealing with and solving problems on your team.
Looking beyond the code
Programmers are unique in that they often will work in domains outside their own. For example, it is common for programmers to solve problems in e-retailing, supply chain, banking and finance. It would be unusual, for example, for a doctor to work in the enterprise resource planning business.
Because of this unique nature of programming, it is important for technologists to look beyond the code to try and understand the industry they are in thoroughly. Programing is a purely mental exercise, and unless the programmer comprehensively understands the problem they’re solving and is aware of the various alternatives, previous attempts at solving the problem, its history and the dynamics of the problem in the context of the industry, they will not be able to solve the problem properly.
And when programmers do understand the domain they’re working in, problems are solved far more efficiently. The closest problems for programmers are their own – A good editor/IDE for coding, for example. The Eclipse IDE is one of the best pieces of software ever written, I think. When you copy a piece of code from one file and paste it into another, for example, Eclipse is smart enough to add any extra imports that the pasted code needs automatically. Eclipse has 100s of such features that are well thought out. Compare that with ICICI Bank’s banking software. While transferring funds, it takes me through the whole flow, asking for account number, password, that stupid grid thing before it realizes that the transfer has to be done during working hours. How come it can’t figure this out at the start?
I find this is a real weakness in today’s world. Having that curiosity to explore the domain you’re working in beyond just the surface will pay off many times over, and help you build a kickass product. And when you’re hiring for your team, you need to ensure that the person has the curiosity to learn about a new industry or domain. The way I usually test for this in an interview is to ask “Tell me something interesting that you discovered about banking/retailing/nuclear-power-plant-control software” and see what they find interesting and fascinating.
Smarter than the average
How smart should the person you’re hiring be? It is important to keep your ego aside here, and ensure that the people you are hiring are smarter than you. Many times, I’ve caught people saying “The candidate is smarter than X, and X already works for us, so its OK”. This thinking is very dangerous. It is not enough if the candidate is smarter than one person – The candidate has to be smarter than average. It’s easily explained with some math:
If you hire a person that is not smarter than the average person at your company, it will bring the average at your company down. And that means the bar for the next person you hire is now lower, which will further lower the bar until one day when you’ll be OK to hire a chicken. Combine this with the fact that the attrition levels will be higher for the smartest people, and you’ll have a real problem.
The only way to get out of this is to ensure the new guy is smarter than the average. This keeps the average up, and smart people enjoy working with other smart people, bringing in even more smart people, and everything will work itself out. This is the only way to keep the quality of people high at your company.
Keeping the hiring bar high is one of the most difficult things to do. There will always be the pressure to hire someone to solve the immediate problem, and the temptation to compromise will be high. But you need to think of the long term, and ensure you’re getting in the right person for the job. This is important not just for you, but also for your team and the success of your product.