Got a bout of motivation this morning to come up with a “Conduct a Good interview” doc. While I’ve written it keeping in mind an interview for an engineering position, the guidelines are generic enough for almost any position. This is how we hire in burrp!
Three aspects to consider in a candidate when conducting an interview –
1. Technical – Is the candidate a good fit for the position we’re hiring for?
2. People – Is the candidate the kind of person you would like to work with?
3. Learning – Will the candidate continue to grow along with the team/company?
Firstly, the candidate should be put to ease.
Offer a glass of water. Break ice with the person.
The candidate has to be in a relaxed state of mind for him to be his best at the interview. Ask about previous experience to put the candidate in some familiar territory.
Don’t pressurize. Don’t harp on a question.
If the candidate doesn’t get a question instantly, try one more time then move on. Observe and record. Don’t be hell bent on proving your own point. Listen.
- Try to find out what are the strong areas of the candidate.
- Don’t dwell on things that the candidate either hasn’t worked upon, or doesn’t know every well. Find out a strong area and check out the depth.
- Deep knowledge in one area or aspect of technology is much better than shallow knowledge in several.
- Don’t ask API questions. APIs can be googled.
- Ask questions that require one to think – why does an API work the way it does? If you were creating this API, would you do anything different?
- To evaluate an backend engineer, here is a model question structure –
o Two logical questions – one easy, one tough
o One algorithm/design question – the complexity can depend on the position we’re hiring for
o Two SQL questions – one easy, one tough
o Two programming questions – one moderate, one tough. Don’t make it complicated. The problem statement has to be clear
o Ask several scenario questions – How would you sort a million strings etc. The objective is to see whether the candidate can think through the complexity
- Ask whether the candidate has used good engineering processes before. Is s/he familiar with revision control systems, bug tracking, code reviews, agile development, build process, debugging etc.
- Would you enjoy working with the person if we were to hire the candidate?
- Team player? Does the person involve others in design, discussion, problem solving?
- Good ethics? This is hard to judge but you’ll get a gut feel about this during the interview
- Clarity of thought and communication
- Has the candidate learned anything new in the past 6 -12 months?
- Was it out of self-motivation or was it forced upon (like a company training)?
- Did the candidate share the learning with the other team members?
- Is the candidate curious to know the answers to the questions that you asked in the interview?
- Does the candidate pick up clues to arrive at an answer?
Do you have any more things to add? Please use the comment box.