Continuing from my previous post…
Lets jump in to the first step:
- Understanding the need: As important as it is to go through the JD before applying for a job – it is equally important to do the same when interviewing for a position. A JD would typically give you enough details around the expectations from the role that you would be interviewing. This is important – cause it will also let you know around the additional role and responsibilities the individual would be expected to play and there by enable you to build a story as you interview.
- Knowing what the role demands: This is more an extension of step 1. The difference in knowing the need and the expectations of the role. Lets look at an example. Say you are hiring for a Front End Developer – one would be to know the skills that are needed to fit the need, eg: HTML, CSS3, JS. Now to know the details of the role – it could entail, client communication, being able to do some level of estimation planning, people management and so on. While one would argue that the rest of the needs are secondary – it does have importance as you start hiring for senior roles with the same tech stack. So while most of your tech questions would over lap for junior and senior tech roles, these areas are what would help you out weigh one from the other and make decisions.
- Screening/evaluating resumes: Possibly one of the trickiest and by far the most difficult step – that could help you save a lot of time if done well. The areas that I typically focus on are
- Language: The first access to any information for a candidate is through his resume. A well articulated and structured resume gives a lot of confidence and goes a long way in building a positive perspective to the interviewer.
- Length of the resume: A short crisp resume which highlights the roles played, skill sets and the experience is what is needed. Most people err by detailing the projects and the tech stack on the project and not on what role they played and their role on the project.
- Stability: A kind of no brainer – one expects to see consistency and some stability in the career graph. Multiple changes is often a sign of instability, lack of patience and at times immaturity. However, that may not always be the case. If you do find a lot of jumps, this is one aspect absolutely important discussing.
- Knowing the candidate better: A 30 mins pre screen (something we started in the recent past), wherein we spend time getting to know the candidate better – delve more in to his educational background – know more about his experience – and at a high level talk about the core skills, serves as a great filter before we start the long domain discussion. It also gives you a sense of direction on how to shape the domain interview.
- Domain Interview:
- Assessing the core competency: I have come across many interviewers who have a very transactional way of taking interviews. They have a pre defined set of questions/script that they run through. What transpires on most such cases is – if a candidate falters with one question, the remaining interview has a spiral downward curve. I generally go thru the same question with multiple lens – till I feel i have the right answer and if I still dont, i do share what I feel is the correct answer. I feel by giving the right answer for some of the questions (especially the ones that the candidate doesn’t even attempt) gives a sense of confidence, trust and comfort to the candidate and most often than not the interview takes the shape of an interactive dialogue/discussion. This also helps in weaving the next set of questions in to a story and learning more around the approach of a problem and not just the syntactical answer.
- Looking at potential and maturity of the candidate: As stated above – the key to a successful interview is knowing that the candidate is relaxed and answering your questions with an open mind. The sooner you get to the state of an interactive dialogue the longer you have to access the potential the candidate has to handle the role you are looking for. I can confidently say – that having the right approach for a problem is far more important than being able to write the syntactically correct code for it. I don’t mean to say – that the core skill is not important / relevant but its something that someone can be trained on.
- Identifying and validating the reason of change: Once you get the confidence that an individual technically(or from a domain standpoint) fits the bill, another important aspect to know is knowing what is prompting the individual to look for a change. Another way to look at this is – knowing what the candidate expects from this new role that the person is interviewing for. Getting an understanding of this – would not only ensure that the person knows the expectations for the role he is interviewing for and clear any queries/gaps that he has.
- The Deciding Question: Once you finish with the domain and all the probing possible – there is one final question I always ask myself that helps me decide on the outcome. While largely – the answer to this is driven by the key mandatory skills but there is also a factor of attitude and aptitude. The Question to ask yourself is: “Will you be happy taking the person in your team and in your project?” If the answer to that is yes, for all the right reasons, you can be rest assured you have a winner at hand.
A great interview experience goes a long way in motivating a candidate to join the organization and also the confidence that he is making the right decision. An interviewer there by plays a pivotal role in building a team who is aligned and perfect for the job at hand.