Chapter 3: Approaches to Programming Problems

Coding questions are generally the meat of an interview. They are your opportunity to demonstrate that you can do the job. These questions are a large component of the process that most computer and software companies use to decide who to hire and who not to hire. Many companies make offers to less than 10 percent of the people who interview with them. The questions are generally rather difficult. If everyone (or even most people) were able to answer a particular question quickly, the company would stop asking it because it wouldn’t tell them anything about the applicants. Many of the questions are designed to take up to an hour to solve, so don’t get frustrated if you don’t see the answer right away. Almost no one does.

Tip 

These problems are hard! Some of the questions are designed to see how you handle a problem when you don’t immediately see the solution.

The Process

The point of the coding questions is to determine if and how well you can code. It’s the most important part of the interview, because the code you write and the answers you give to the interviewer will largely determine whether or not he or she recommends you for the job.

The Scenario

You will usually be working one-on-one with your interviewer. He or she will give you a marker and a whiteboard (or pen and paper) and ask you to write some code. The interviewer will probably want you to talk through the question before you start writing. Generally, you will be asked to code a function or method, but sometimes you will need to write a class definition or a sequence of related code modules. In any case, you will be writing code, either in an actual programming language or in some form of pseudo-code.

The Problems

The problems the interviewers ask have very specific requirements. They have to be short enough to be explained and solved reasonably quickly, yet complex enough that not everyone can solve them. Therefore, it’s unlikely that you’ll be asked any real-world problems. Almost any worthy real-world problem would take too long to explain, let alone solve. That isn’t an option in an interview. Instead, many of these problems require tricks or uncommonly used features of a language.

The problems often prohibit you from using the most-common way to do something or from using the ideal data structure. For example, you might be given a problem like this: “Write a function that determines whether two integers are equal without using any comparative operators.”

This is an outright silly and contrived problem. Almost every language that ever existed has some way to compare two integers. However, you’re not off the hook if you respond, “This is a stupid question; I’d always use the equality operator. I’d never have this problem.” In fact, you flunk if you answer this way. The interviewer is looking for a different way to compare two integers. (Hint: Try using bit operators.)

Describe the better way to solve the problem, but solve the question as it was asked. For example, if you are asked to solve a certain problem with a hash table, you might say, “This would be easy with a binary search tree because it’s much easier to extract the largest element, but let’s see how I can solve this with a hash table …”

Tip 

Many questions involve ridiculous restrictions, use obscure features of languages, and seem silly and contrived. Play within the rules. Real-world programming is rarely done in a vacuum. The ability to work within the particular constraints of a situation is an important skill to develop.

Problems are generally asked in ascending order of difficulty. This is not a hard-and-fast rule, but you can expect them to get more difficult as you answer more of them correctly. Often, different interviewers will communicate with each other about what they asked you, what you could answer, and what you couldn’t answer. If you answer all the problems in your early interviews but find yourself stumped by harder problems later, this may indicate that earlier interviewers were impressed with your responses.

Which Languages to Use

If you are applying for a job with specific language requirements, you should know those languages and expect to use them to solve the questions you are given. If you are applying for a general programming or development position, a thorough knowledge of a mainstream language such as C#, Java, and/or C++ is enough to get by, although familiarity with the C language is also useful in many situations. Your interviewer may permit you to use other popular languages, such as JavaScript, PHP, or Perl. If you are given a choice, select the language you know best, but expect to be required to solve some problems in a specific language. Interviewers are less likely to be amenable to you using less-mainstream languages such as Lisp, Python, Tcl, Prolog, COBOL, or Fortran, but if you are particularly expert in one of these, there’s no harm in asking.

Before you go to your interview, make sure you are completely comfortable with the use and syntax of any language you plan to use. If it’s been a few years since you’ve done any C++ programming, for example, you should at the very least thumb through a good C++ reference guide and refamiliarize yourself with the language.

One final note about language selection: Whether rightly or wrongly, many people consider Visual Basic to be a lesser language. Unless you are applying for a job in which you will be using this language, it’s probably best to avoid it in your interviews. Things change, however, so be aware of current language trends. A few years ago, for example, the same could be said of JavaScript, but the rise of AJAX (an acronym for Asynchronous JavaScript and XML) as a core technology for developing responsive browser-based applications has changed the industry’s view about JavaScript.

Interactivity Is Key

The code you write in the interview is probably the only example of your code that your interviewer will see. If you write ugly code, your interviewer will assume you always write ugly code. This is your chance to shine and show your best code. Take the time to make your code solid and pretty.

Tip 

Brush up on the languages you expect to use, and write your best code.

Programming questions are designed to see both how well you can code and how you solve problems. If all the interviewer wanted to do were measure your coding ability, he could give you a piece of paper with problems and come back an hour later to evaluate how you did, just as they do in programming contests. What the interviewer wants is to see your thought processes as you work through each stage of the programming problem.

The problem-solving process in these interviews is very interactive, and if you’re having difficulty, the interviewer will generally guide you to the correct answer via a series of hints. Of course, the less help you need to solve the problem, the better you look, but showing an intelligent thought process and responding well to the hints you are given is also very important.

Even when you immediately know the answer to a problem, because it’s something you’ve already done before, don’t just blurt it out. Break the answer down into discrete steps and explain the thought processes behind each step. The point is to show the interviewer that you understand the underlying concepts, not that you’ve managed to memorize the answer to a programming puzzle.

If you know any additional information pertaining to the problem, you may want to mention it during the process to show your general knowledge of programming, even if it’s not directly applicable to the problem at hand. In answering these problems, show that you’re not just a propeller-head coder. Demonstrate that you have logical thought processes, are generally knowledgeable about computers, and can communicate well.

Tip 

Keep talking! Always explain what you are doing! Otherwise, the interviewer has no way of knowing how you tackle complex programming problems.