INTERVIEW TIPS

1. Introduction

The technical interview is perhaps the most intimidating and mysterious event that job hunters experience in the quest for that "killer offer." The rigor and format of the technical interview varies from one company to the next, but there are some fundamental similarities. An interviewer presents you with a problem to be solved. The interviewer may leave the room and give you some time to work the solution out before returning. Or the interviewer may wait patiently while you study the problem and figure it out. The interviewer may even start quizzing you right away about aspects of the problem and approaches to solving it. Some of these problems can appear quite challenging, especially if you've never been through a technical interview before. To make matters worse, simply getting the answer to the problem may not be enough to land the job. On the other hand, getting the correct answer may not even be necessary. What is an interviewer looking for in candidates during the technical interview? Interviewers recognize that this setting is, by its very nature, stressful. Otherwise competent candidates may be completely stumped by an interview problem only to discover an elegant, simple solution later that night. Interviewers may be interested in seeing how you work under stressful situations or how well you adapt. It is worth noting that interviewers are more interested in seeing how you work than seeing whether you can come up with the correct answer. In this article, I will deal with both how you can better showcase your skills and experience, and what kinds of problems you can expect to be asked.

2. The Basic Rules

These basic rules are often taught to programmers and are (or at any rate, should be) drilled into your head in computer-science classes. For some reason, however, they are easily forgotten during the technical interview. Being one of the few candidates careful and experienced enough to remember these important steps can make the difference between getting an offer and getting the cold shoulder. Don't be afraid to ask for clarifications of the problem or the requirements for the solution.

3. Don't assume all data is given to you.

You should never assume that you have been given all the data necessary to solve the problem to the satisfaction of the interviewer. This is especially likely to be the case when interviewing with IT consulting companies. In this environment, the client may need some prodding in order to provide a complete specification. So, the reasoning goes, ideal candidates will be willing to talk to the client to figure out the expected inputs, the desired outputs, the data ranges and data types, and the special cases. The ideal candidate will ask these questions rather than spend all the allotted time coming up with a solution that doesn't meet the client's needs. The first thing to do, then, is to make sure that you and the interviewer agree on what the problem is and what an acceptable solution would be. Make all of your assumptions explicit and up-front, so the interviewer can correct you if you are mistaken.

4. Think out loud.

If the interviewer stays in the room after presenting the problem, he or she is interested in seeing how you analyze and approach a problem. Of interest are how possible solutions are considered and eliminated. And frankly, watching a candidate sit and stare at a problem isn't all that entertaining for the interviewer. Always allow sufficient time for design. The worst thing that you can do while attempting to solve a technical problem is to dive right into coding a solution and get about half way through it before realizing that the approach is all wrong. This is where a little forethought can save a great deal of effort and embarrassment. Don't worry about running out of time to answer the question before finishing the code for the solution. The idea, the algorithm, and the approach are the most important elements here. If you're having trouble writing the code, offer to explain the algorithm. Stress and anxiety can make the technical interview more difficult than it needs to be. If you find yourself having difficulty with programming syntax or constructs, you should make sure that the interviewer knows that you understand the problem and its solution. While it's best to get both the algorithm and the implementation correct, it's far better to get points for demonstrating facility with one than fail to demonstrate either. Be prepared to identify bottlenecks, possible optimizations, and alternative algorithms. Just because you've found one solution that produces the correct output, doesn't mean the problem has been solved to the interviewer's satisfaction. Interviewers, hinting at possible improvements, may prod you at this point. Occasionally, you may take an approach that the interviewer didn't anticipate. At this point, an interviewer may ask you to take a more conventional approach. This doesn't mean that you've done anything wrong; very often, an interviewer may be leading you along a particular approach with a purpose in mind. The interviewer may be intending to ask follow-up questions or present new problems that build on a particular solution.

5. Good programming practice.

Initialize all variables, give variables descriptive names, and always use comments.

Interviewers may be watching your solutions to determine whether you follow good programming practices. Good programming practices make it easy to understand other people's code. This means that there aren't cryptic variables, functions with undocumented side effects, obfuscated algorithms, and sloppy (read: buggy) code. Just because you are being interviewed (and therefore, coding on a whiteboard or on a piece of paper) doesn't give you an excuse to be sloppy or lazy. Commenting code for an interview may seem like a waste of time, but some interviewers do look to see that candidates write comments while coding or before coding, rather than adding them in as an afterthought.

6. Check all boundary conditions.

Candidates forget to do this frighteningly often. In fact, practicing programmers sometimes forget to do this. That's how bugs get started. You should verify that your code properly handles cases where inputs are negative or zero, lists are empty, strings are empty, and pointers are NULL. This is also a good habit to have after you get the job. Expect bad input from users. Users rarely do as they are expected. You should protect your code, and return a descriptive error back to the user. Display enthusiasm. Don't underestimate the importance of your appearance and attitude during the interview. While your skills and experience may be the focus of the technical interview, looking bored or uninterested may do more to sabotage your chances than blowing an interview problem.

7. Work Things Into Your Conversations

In addition to these basic rules for the technical interview, there are some other things worth pointing out. Interviewers don't always have the chance to examine your résumé in advance. This means that the interviewer may not be aware of your past work experience. Don't hesitate to point out experiences working in teams (whether as a part of a past job, a class programming project, or a hobby), working on large projects (paying attention to time spent on design, implementation, and testing), dealing with customers to define requirements, and managing people and projects. Interviewers are interested in hearing about successes as well as failures. When these past experiences weren't successful, you should point out the lessons learned or wisdom gained as a result of these failures. Interviewers want to see that candidates who have had negative experiences are not going to repeat their mistakes.

8. Typical Technical Questions

When preparing for a technical interview, you should review basic structures (linked lists, binary trees, heaps) and algorithms (searching, sorting, hashing). Having a mastery of these topics will likely give you all the necessary knowledge to tackle the problems you will encounter during the technical interview. Also, review the areas for which you're interviewing. If you're interviewing for a systems programming job, review the differences between threads and processes, OS scheduling algorithms, and memory allocation. If you're interviewing for a job that requires experience with an object- oriented language, spend some time brushing up on object-oriented methodology.

Fortunately, some of the same problems come up with surprising frequency. Even if a given interviewer doesn't use any of the problems I present here, studying them should give you insight into solving other problems.

9. Conclusion

The specific details of your interview will, of course, depend on a number of factors -- the type of job you are applying for, the needs and expertise of the technical interviewer, and guidelines set forth by the organization seeking to hire you. Still, if you generalize and apply the tips I've presented here, you should be well on your way to getting the programming job that you want.