Data Structure and Data Algorithm are two of the most common topics that hiring experts in the domain of software engineering tend to focus on. Despite their popularity in varied recruitment processes, both these topics are quite misunderstood and usually come with many complexities in the application, especially in a tense set up of a job interview.
What can make the lives of aspiring software professionals easy is an insight into the minds of the interviewer sitting opposite to them. While this may differ from person to person depending on their personalities, backgrounds and work experience, one can create and follow some basic guidelines while approaching the problems posed around these two themes by the interviewer.
- Measure Twice cut once – Most technology companies are looking for people who have the patience and intellect to analyse the problem at hand thoroughly before jumping into providing a solution. Many times, especially in the interview, the candidate ends up either solving the wrong problem or creating a half baked solution without actually understanding the problem at hand. Therefore, one must converse with the interviewer and get a full understanding of the corner cases of the question posed. The vital thing to note here is that several organisations have training sessions for interviewers as well in which they are specifically instructed not to offer all the boundary conditions of the problem shared upfront. The question is purposely left a little vague, and the interviewer expects the candidate to ask clarifying questions. Be mindful of this. Ask as many questions as required and only then suggest a well thought over solution.
- Think loudly and collaborate – One of the most common mistakes that most young professionals do is that once they have heard a question/problem from the interviewer, they tend to become silent. Maybe even stare at the wall or ceiling, understandably lost in thought – analysing the problem. It seems like the right approach, but it is not. What we tend to forget is that the interviewer wants to understand the thought process behind the solution suggested. They want to understand how the person approaches a given situation or issue. The ideal way is to discuss the process with the interviewer. Share the different approaches that could be used, what could be the pitfalls of each of them, how would one go about handling those, and so on. When one is silently thinking about a problem, the interviewer could deduce that the candidate is stuck or lacks clarity. It is therefore essential to engage with the interviewer through the entire problem-solving process.
- Do not jump into writing the code directly – The quality of the code written during the interview is very critical. There is no point in writing something basic and then adding patches to it as one gets a better understanding of the corner cases of the problem. This method is rudimentary and does not reflect well on the candidate resulting in eventual rejection. Systematic structuring of the code is essential. The ideal approach should be first to figure the solution and then write the code corresponding to that. In this step also, collaborating with the interviewer is critical. Get his or her buy in on the solution suggested by getting requisite clarity and then proceed to write the code.
- Dry run and identify corner cases – Dry running the code is imperative. There are no two ways around it. Every single technology organisation only wants to work with engineers whose codes do not fail on deployment or production. So before one goes ahead and submits the code, test it extensively on all the corner cases that one can think off. Being thorough is the key here.
- Ask sensible and smart questions – Most interviewers towards the end of the interaction tend to ask if the candidates have any questions for them. The worst response for such a query is – no questions. Thoroughly research on the company and the work they do, to ensure that such a situation does not arise. This is an excellent opportunity for the candidate to build a rapport with the interviewer, ask them questions on what kind of tech or protocol they use for a particular feature or product. The candidate can also ask questions on work culture within the team – how they brainstorm and come up with new ideas, will he or she get the chance to take product decisions or be part of the discussion where such decisions are made. It is important to note that asking questions around working hours or salary should be avoided in technical interviews.
These tips and tricks are simple and easy to implement. In hindsight, they may even seem obvious, but a lot of aspiring software professionals tend to overlook them. Almost 90% of rejections in the technical round happen because the candidate is lacking in one (if not more) of these aspects. They go a long way in creating a favorable impression of the candidate in the mind of the interviewer.
