How to take better technical interviews?

There are a lot of resources available across the internet on how to prepare for an interview, interview questions based on each technology/domain, how to attend an interview — online or offline, and so on. However, seldom do people write about how to take an interview.

So if you are anyone who takes a technical interview or going to take a technical interview, then this blog is for you.

Times are changing and hiring is becoming more of a challenge than getting hired in the tech world. At the time of writing this blog, IT is pretty booming with a lot of opportunities and highly competitive packages that recruiting a skilled person is no simple task. Especially in a country like India where there is a lot of talent pool, identifying the right candidate and hiring is a challenge than ever.

Interviews are two-way

Understand this point very well -This is a key point!

1. Interviews are not a one-way opportunity to identify the right talent for your requirement but it’s also the part where you can convince the candidate to join your organization.
2. In a way, interviews are advertisements for your company. Candidate experiences in the interview have longer and deeper impressions than you might have realized. Let me explain in below points.
3. Interview experience reviews spread not just through word of mouth but also through platforms like Glassdoor, google reviews, LinkedIn, and other job portals. The right candidates you have selected would also be going through reviews and they could refrain from joining your organization especially when they have competitive offers from other companies.
4. Google reviews are generic which means a person leaving a negative rating or review because of a bad interview experience is no different from someone rating the service or product of your company. Especially for product-based companies in B2C (Business to end customer), this could heavily cause an impact as potential customers might mistake the review for your product.
5. Social media is powerful and these days anything can go viral at any time. Imagine a post going viral about an interviewer from your organization abusing the candidate. Even if it’s not true, another post with the truth’s point of view may not even reach that much audience.

So overall, keep the candidate happy.

Coming back to the purpose of this blog — Key points for taking a good technical interview. Most of the points are common for all kinds of interview too.

1. Go through the candidate profile/resume ahead of the interview- It is absolutely a bad practice to go through the resume after starting the interview and must be avoided at any cost. This will help you come up with the right kind of questions to be asked also.
2. Be prepared with title questions — You don’t have to come up with an entire script and must not, but you could come up with main questions that need to be asked. It could be technical or non-technical questions based on past experience of the candidate, as understood from the resume or generic programming questions based on the expected skillset.
3. Define organization level interview practices — This will ensure that every interview is following some standardized process as each individual will have their own pattern of taking interviews. Define and document what should be the focus point of each round of interview for a specific role. For example: For a fresher, first round would be aptitude while for a junior developer it would be theoretical questions on the skillset required for the role. Similarly while one company might evaluateDSAlgo basics for first round another company might be focussing only on evaluating the programming language efficiency in first round.
4. Define concrete evaluation points — There are lot of points that can be evaluated in a technical round such as proficiency in the coding language, understanding of OOPs or other concepts, adherence to coding standards, adherence to coding best practices, thinking capability of the candidate, communication skills or even overall attitude and so on. Each individual interviewer might have a different perspective of what is important so it is necessary that these points be defined from the organization perspective reflecting the company culture.
5. Have an organization level pool of questions for each round for each role- This might be seem unnecessary in the short run or in smaller organizations but definitely helpful in the long run. This will especially help new interviewers avoid asking the wrong questions or few candidates getting lucky enough that their interviewer was asking all easy questions and another person with hard questions. Thus will help keep up a fair game also.
6. Do not be narrow minded about the solutions — Remember, most of the problems will have more than one solutions. Some will be efficient than other in terms of time / space complexity or other such factors. This doesn’t mean the answer you are expecting is the perfect one. The purpose of the interview should be to evaluate the thought process of the candidate and not whether he/she knows the solution by hear.
7. Prefer not to be late- Candidates deserve and a lot of them expect — respect for their time. I used the word ‘prefer’, as some interviewers do this as an psychological technique too. If at all you reached late, please do offer an apology.
8. Inform the candidate if getting late — It is quite possible that people could get late due to unforeseen situations but as soon you realize that you are getting late, make contact. Inform the candidate as early as possible if you are getting late. If there is an HR team or recruiter agency helping with the recruitment, take their help to ensure you are available on time (reminders) or to inform the candidate if the interviewer is not available or not reachbale.
9. Start with a self-introduction -Since interviews are two-way it is important that the interviewer must introduce himself before asking for a self-intro from the candidate. This would give the candidate a sense of respect as well as a cooling time.
10. Ask for a self-introduction (including his experience details)- This is a debatable point whether it’s required mainly from the perspective that the interviewee would have already shared the resume or his/her profile. Though I completely agree with that point, I believe it is necessary to ask for a self-intro because 1. sometimes you might be able to catch if something is being faked in the resume beyond justifiable limits 2. since resumes are not standardized, many relevant points you are looking for might be missing in the resume but might be added in the intro.
11. Do not judge the tech-stack, tools, architecture, etc. of the candidates past experience — Most of them may not be even the choices made by the candidate. There could be a lof of reasons behind those choices or why they are not being fixed even if the candidate too belive they are not the best. Maybe the manager of the candidate is not open minded to the suggestions or the past or current financial situation do not allow the company to do it and so on. For example, most of the large banking institutions still rely on legacy language like Fortran.
12. Start with easy questions and gradually increase the difficulty — There is a high chance that the candidate would loose the confidence if stuck by a difficult question at the start itself. It is reasonable that he/she would feeling not confident being stuck few mins into the interview. It is also true that candidates are expected to work under pressure but that pressure will be created by the limited timing of the interview. This is true for both theoretical as well as coding rounds.
13. Ask the candidate to explain the logic or pseudocode before starting the coding -Lot of times it is possible that the candidate had just learned the solution blindly. Asking to explain before writing the code could help you understand whether the candidate is thinking along the right direction and give possible corrections. Even if the candidate learned the solution by heart but has understanding of the logic behind it, I think it should be fair enough to accept it. If the candidate knows the solution and logic of all the questions in the interview by heart, well that means the it’s time to change the questions altogether.
14. Tweak the question slightly on the go — This would help figure out if the solution was just memorized and how flexible is the thinking capacity. Tweaking can be something like adding/removing conditions to the original question, reversing the question without changing the actual problem statement, giving extra conditions that do not alter the original problem, etc. For example the star pyramid problem can be asked as a right angle pyramid also or left angle pyramid or reversed or to fill with numbers, etc.
15. Give hints when necessary — Expecting every candidate to know the perfect solution of all the problems on the go is ridiculous. Some of them might have practiced the exact same problems before and might be fast about the solution while some might be developing the solution during the interview. For hard problems it is only fair to give candidates some minor hints if he/she seem to be getting stuck at some point.
16. Data structures and algorithms alone is not coding; Ask actual coding questions too — By actual coding, I am referring to the kind of problems ecountered in the actual projects of the company. A person who spend hours learning DSAlgo will definitely be good at it but without actual coding experience they may not be able to perform project work independently. It might be fine for junior roles as most organizations give project training and mentors for sufficient time period for the employee to catch up. These problems could be any where from writing a functions, classes or APIs to creating a small project from scratch.
17. Do not push the candidate to come up with the solution you have in mind — This is the worst and common mistake made by most interviewers. If the candidate’s solutions has flaws, mention the same and ask him/her to fix it. If is repeating, mark the same in valuation and move on.
18. Avoid questions from your actual work — The problem with asking questions from your actual work is that you would already have a solution in mind which you believe is the best one. This might contradict with what the candidate is suggesting even if it’s (especially if it’s) better than the solution you have in mind. It might most probably hurt your ego or you might be worried about the candidate over shadowing you after joining, if the solution is better. If it’s not better, high likely the better solution you have might be the result of hours and days of effort and brain storming.

What are some other practices that you think can make technical interviews more efficient, let me know in comments. Happy hiring !!