Ace That Technical Interview.
Introduction
Read this headline again, but please don't conclude whatever is obvious. I am talking about interviewers, and not interviewees. Yes, interview-ers.
But this may prompt a question. Why does the interviewer need to ace it? It is his playground. He should ask whatever he knows. He should grill as much as he wants to and should reject if the candidate in ten minutes if he is not able to answer the first few questions.
If you just thought any of what I wrote in the last paragraph, you may be living in an oblivion, and may lose some really good candidates.
The Challenge
The technology landscape is changing and so is the demand of the companies. Most of the organizations which are moving to the 'newer and niche' tech stack want technologists who are the best in the market. They want candidates who know everything about everything - or at least that is the expectation. Being the interviewer and discussing technology with a candidate is really a tough job, and that is where most of us fail, because we are still living in the last century.
The Pattern
The problem lies with the monotonous pattern of interviews that we have created or follow. We want them to be familiar with the entire tech stack - even though the project needs only a small subset. We don't grill them on problem solving, we don't grill them on aptitude. We want textbook definitions. Avoid questions like the ones given below. It would be wrong to ask these to a candidate who has and experience more than 5 years, and expect him to know the answer verbatim :-
- What is the difference between Error and Exception?
- You have 7 years of experience, tell me, without any logs and access how would you troubleshoot failures on production environment? ( I witnessed this happen, word by word. The interviewer was expecting the candidate to say "I will connect to the production support team", but failed to realize that he had asked the candidate to troubleshoot.)
- What is the difference between Dependency Injection and Inversion Of Control ?
- Write down the complete Collection framework hierarchy for me?
If you read the questions again, you will notice that none of these help in identifying whether the candidate is a good performer or not. All that these questions identify is the ability of the candidate to go through a dump of Q&A, and be able to mug those by heart.
Problem
The problem with this pattern is that we need to avoid all those problems which are left to the IDE to solve. In asking him questions like these, we deny him the possibility to face a problem and provide a solution. We deny ourselves the opportunity to judge his ability to create an application that is resilient, scalable, and responsive. We deny ourselves the opportunity of a healthy technical discussion.
Solution
Aim to find a candidate who, given a problem, is able to design the solution either as a series of interactive black boxes or as class diagrams. A candidate who is able to write code or pseudo code ( at least ) from the design, and thereafter discuss with you the possibilities of addition of various features like multithreading, resiliency, and enhanced throughput using the same code.
Aim to find a candidate who is able to discuss with you the intricacies of a programming language and its important features. He should be comfortable writing code. He should be comfortable explaining architectures, and moreover he should have the ability to learn and grow.
Look out for a candidate with an active Github profile. Lookout for his participation in competitive programming, or the StackOverflow rank. Ask him about the most challenging question he answered on that site. Lookout for his ability to modify data structures to suit your business case. Lookout for his ability to apply a specific design pattern.
The candidate who comes to you has spared his time for the job, and it becomes the primary responsibility of the interviewer to ensure that the candidate feels challenged, motivated, and takes away a positive memory even in case of a rejection.
