Strategies For A Great Interview

A typical one hour interview with a single interviewer consists of five minutes of introductions and questions about the candidate's resume. This is followed by five to fifteen minutes of questioning on basic programming concepts.

The core of the interview is one or two detailed algorithm design questions where the candidate is expected to present a detailed solution on a whiteboard or paper. Depending on the interviewer and the question, the  solution may be required to include syntactically correct code in a language that the candidate is comfortable with. The reason for asking such question's is that algorithms and associated data-structures underlie all  software. They are often hidden in library calls. They can be a small part of a code base dominated by I/O and format conversion. But they are the crucial component in terms of performance and intricacy.

The most important part of interview preparation is to know the material and practice solving problems. However the non-technical aspects of interviewing cannot be underplayed either. There are a number of things that could go wrong in an interview and it is important to have a strategy to deal with them.

1. Before the Interview

One of the best ways of preparing for an interview is mock interviews. Get a friend to ask you question's and have you solve the problems on a whiteboard or paper. Ask your friend to take notes and give you detailed feedback, both positive and negative. Also ask your friend to provide hints from the solution if you are stuck. This will help you overcome any fear or problem areas well in advance.

2. Approaching the Problem

No matter how well prepared you are, there is a good chance that the solution to an interview problem will not occur to you immediately. When this happens, there are several things you can do.

Clarify the question: This may seem obvious but it's amazing how many interviews go badly because the candidate spends most of the time trying to solve the wrong problem. If a question seems exceptionally hard, there is a good chance you have misunderstood the question. The best way to clarifying the question is to state a concrete instance of the problem. For example: if the question is "find the first occurrence of a number greater than k in a sorted array", you could ask the following: the input array is [2,20,30] and k is 3, then are you supposed to return 1 (index of 20)?"

Work on small examples: This may not be true for all the problems. However there is a large class of problems where after working out the solution for a few small examples! you may see a pattern emerge.

Spell out the brute-force solution: Problems that are put to you in an interview tend to have an obvious brute-force solution that has a large runtime compared to more sophisticated solutions. For example! instead

of trying to work out a dynamic programming solution for a problem, try all the possible configurations. There are several advantages to this: (1.) it helps you explore opportunities for optimization and hence reach a better solution! (2.) it gives you an opportunity to demonstrate some problem solving and coding skills! and (3.) it establishes that both you and the interviewer are thinking about the same problem. Be warned that this strategy can sometimes be detrimental if it takes too long to describe even the brute-force approach and leaves you with less time to work on the optimal solution.

Think out loud: One of the worst things you can do in an interview is to freeze up while solving the  problem. It is always a good idea to think out loud while searching for a solution. On one hand! this increases the chances of you finding the right solution because it forces you to put your thoughts in a coherent manner. On the other hand, it helps the interviewer guide your thought process in the right direction. In the very least, even if you are not able to reach the solution, this leaves the interviewer with the impression that you have the intellectual ability to attack an unknown problem.

Search for isomorphic problems: Even if you may not have seen the exact problem, you may have seen another problem with similar mathematical structure. See if this seems like a good fit for general algorithmic

techniques, such as, divide-and-conquer, dynamic programming, greedy, etc.. Can you map the problem to a graph? Can you map it to an objective function and a set of constraints, such as an integer linear program?

3. Presenting the Solution

Once you have a solution, it is important to present it well and do a comprehensive job at it. A lot of these things become simpler if you use a higher level language such as Java. However you should use the language

with which you are most familiar. In most scenarios, it is perfectly fine to write a pseudo-code as well. Here are some thoughts that could help:

Test for corner cases: For a number of problems, your general idea may work for the majority of the cases but there may be a few obscure inputs where your algorithm (or code) would fail. For example, you

could write a binary search code that crashes if the input is an empty array or you may do arithmetic without considering the possibility of integer overflow. It is important to check for these things carefully. One way of doing this is to construct a few test cases and work out the output of your algorithm for them. In many cases, the code to handle some obscure corner cases may be too complicated. In such cases, you should at least mention to the interviewer that you are aware of the problem and you could try to address it if they are interested.

Function signature: Several candidates tend to get this wrong and getting your function signature wrong reflects badly on you. For example, it would be bad if you are writing the code in C language and your function returns an array but you fail to return the size of the array along with the pointer. Another place where function signatures could be important is knowing when to pass parameters by value versus by reference.

Memory management: If you allocate memory in your function, you must ensure that in every execution path, this memory is de-allocated. In general, it is best to avoid memory management operations all together. If you must do this, consider use of scoped pointers.

Syntax: In almost all cases, the interviewers are not evaluating you on the correctness of the syntax of your code. The editors and compilers do a great job at helping you get the syntax right. However you cannot underplay the possibility of an interviewer leaving with the impression that you got most of the syntax wrong since you do not have much experience writing code. Hence once you are done writing your code, you should make a pass over it to avoid any obvious syntax errors before claiming you are done.

4. Know your Interviewers

If the organization can share some information about the background of your interviewers, it can help you a great deal. For fresh graduates, it is also important to think .from the perspective of the interviewers. It is also important to note that once you ace the interview, you will have an offer and you would have an important decision to make: is this the organization where you want to work? Interviews are the best time to collect this information. Based on your interaction with the interviewers, you can get a pretty good idea of their intellect as well as how pleasant the organization could be. Most interviews end with the interviewers letting the candidates ask questions. You should make the best use of this time by (1.) getting the information you would need and (2.) communicating to the interviewer that you are interested in the job. Prepare a list of questions in advance that both gets you helpful information as well as shows your knowledge and interest in the organization.

5. General Conversation

Often interviewers will spend some time asking questions about your past projects, dissertation, etc.. The point of this conversation is:

 - Can the candidate clearly communicate a complex idea: This is one of the most important skills for working in an engineering team. If you have a grand idea to redesign a big system, can you communicate it to

your colleagues and bring them on board? It is best to practice how you want to present some of your best work in advance. Being precise, clear, and having concrete examples can go a long way here. For candidates who have to communicate in a language that is not their first language, it may be important to speak slowly and perhaps use the whiteboard to augment their words. Is the candidate passionate about his work: We always want our colleagues to be passionate, full of energy, and inspiring to work with. If you are so passionate about your work that your eyes light up while describing your work, it can go a long way in terms of establishing you as a great colleague. Hence when you are asked to describe a project from the past, it is best to pick something that you are passionate about rather than a project that was complex but did not interest you.

 - Is there a potential interest match with some project: During a general conversation, the interviewer may gauge areas of strengths for a potential project match. If you know the requirements of the job, you may want to steer the conversation in that direction. However in the computing industry, things change so fast that most teams prefer a strong generalist. Also, it is a good idea to maintain a homepage with links to your projects and articles; things that can help interviewers learn more about you.

Cheers! 

Rajendra