
It's been about 7 years since I started taking technical interviews and everytime I walk in to the interview room with a predefined set of parameters that I plan to evaluate the interviewee on. To me, an interview should be to evaluate a person on various parameters,define an acceptance criteria and thus determine if the interviewee has made it through the interview.
I learnt the art of interviewing from my seniors and so far I have been successful in picking the talent that is relevant to the kind of job we do.It sounds foolish to me to evaluate a person on hi-fi concepts when the actual work doesn't involve applying any such concepts !
In this post, I would like to talk about the homework that I do w.r.t parameters and the way I determine if a person fits in my organization/team.
There are a bunch of parameters that I enlist and the set of parameters differ based on the person that I am going to interview.For example, for a fresh grad - it might not make sense to question on software design concepts while an experienced resource is expected to know such concepts.
Since I only interview software developers/leads, here are a bunch of parameters (a 4-point formula)that I consider during my interview:
Analytical ability / problem solving skillsThis is the very basic skill that we look for in a software engineer. We throw a problem that has low/medium complexity and we expect the interviewee to explain the approach to solve the problem followed by an implementation in his/her favorite programming language.
With this parameter, I can determine if the person
- understands the problem statement clearly
- is clear with what needs to be achieved
- has no assumptions
- has a clear approach to solve the problem
- is comfortable in mapping the approach to programming logic
- is comfortable writing code
- can think like a program, validates the logic, debugs and fixes the program logic to get it right
Communication skillsWe expect the interviewee to understand what we are trying to see (hoping that we are good at explaining things ;)). After we are done with our explanation of a problem statement, the interviewee has only two options - he/she got the problem right or he/she has "n" number of questions to be clarified. Now, verbal communication skill plays an important role 'coz the person has to explain what the gray areas are, explain the approach that he/she plans to follow towards solving the problem.
Eye-for-detailMost of the time, we ask people to talk about something that they worked on that made us feel excited about. Such a question serves two purposes:
- The person tries to explain the technical challenges during the task and the way he/she went about overcome those challenges.
- We can pick some items from his project and check to see if the person paid significant attention to the programming constructs that were used while solving a problem. Although most of us rely on Google for reusable code snippets, we expect the interviewee to have known what that "reusable code" does. (Things can't work like magic all the time, isn't it?) We expect the resources to know what they do and do (the best in) what they know
Quest for smarter solutions and thirst for knowledgeI believe in the line - "you snooze, you lose" which means that you are no longer required if you have not updated yourself on the latest developments in your relevant competancy.
We try to find out how the inteviewee tries to be up-to-date and if the guy is stuck in age old programming practices, we simply say "sorry" ;)
I feel that no matter how many rounds of interview you conduct or how many questions you prepare to evaluate a person, your parameters are going to be in the above list (more or less).
Once we fish out resources with our 4-point formula, the rest is up to HR and senior management :D
Welcome to my team :)