Five essential steps to prepare for your next programming interview

Posted seven years ago

There are at least two kinds of programming interviews. One type is where you are asked for details about your prior work experience. The other one is where they put you in a room, give you a problem, and stare at you while you fumble around with markers on a whiteboard for 45 minutes. The first focuses on what you have done in the past. The second focuses on what you can do in the room right now without looking anything up. You should be prepared for either.

Step 1: Get your stories straight

You will spend a large chunk of time in a job interview talking about things that you have done in the past. If haven't figured out a half dozen stories that best represent your skills, then you need to do that now. Here is a list of questions from a standard list. Many of them are stupid, but trust me -- they force you to think about yourself. Even if you aren't asked a question identical to one on this list, you will use your prepared answers during an interview. The point of this exercise is to build a repertoire of examples from your work life that you can use to answer questions.

Tell me about yourself

What are your short-term goals? What about in 2 and 5 years from now?

What is your own vision/mission statement?

What do you think you will be looking for in the job following this position?

Why do you feel you will be successful in this work?

What other types of work are you looking for in addition to this role?

What supervisory or leadership roles have you had?

What experience have you had working on a team?

What have been your most satisfying/disappointing experiences?

What are your strengths/weaknesses?

What kinds of problems do you handle the best?

How do you reduce stress and try to achieve balance in your life?

How did you handle a request to do something contrary to your moral code or business ethics?

What was the result the last time you tried to sell your idea to others?

Why did you apply to our organization and what do you know about us?

What do you think are advantages/disadvantages of joining our organization?

What is the most important thing you are looking for in an employer?

What were some of the common characteristics of your past supervisors?

What characteristics do you think a person would need to have to work effectively in our company with its policies of staying ahead of the competition?

What courses did you like best/least? Why?

What did you learn or gain from your part-time/summer/co-op/internship experiences?

What are your plans for further studies?

Why are your grades low?

How do you spend your spare time?

If I asked your friends to describe you, what do you think they would say?

What frustrates you the most?

When were you last angry at work and what was the outcome?

What things could you do to increase your overall effectiveness?

What was the toughest decision you had to make in the last year? Why was it difficult?

Why haven't you found a job yet?

You don't seem to have any experience in ___ (e.g., sales, fundraising, bookkeeping), do you?

The problem is that they require deep thought and introspection to answer, so itÃ¢ï¿½ï¿½s important to do that thinking in advance. Take an hour and think about the answers to these questions (you can use the same answer for more than one). For questions where you need to tell a story, your answer should follow this format:

20 seconds: Describe the situation. "The code was crashing and the whole team had to stop and figure out why."

30 seconds: Describe what you did "I thought of doing a memory dump, and I noticed that the AbstractMemberCreationFactory had a lot of instances but it was supposed to be a singleton."

20 seconds: Describe the results. "I fixed the memory leak with one line of code and we shipped the product on time. Later on, I added a test to make sure this wouldn't happen again."

Before each interview, go through the entire list and practice your answers out loud. Doing this will give you an edge over the other candidates, because it will make you more comfortable during the interview. When asked a question, other candidates will be staring at the ceiling saying "ummm", trying to remember everything that happened to them in the the past five years. Meanwhile, you'll smile, look the interviewer in the eye, and launch into your story.

Step 2: Build confidence by solving the most common programming exercises beforehand

Pianists have to learn a specific set of short pieces before they advance to the next level. These tunes will never be a hit at parties, but they exercise particular things, such as the right hand little finger, or syncopation. Likewise, certain problems keep coming up in programming interviews, although you will probably never, ever use them in your code. You will probably be asked one of the these time worn classics.

Reverse a singly linked list (in one pass through the list)

Reverse a string (in one pass). Reverse the order of words in a paragraph (in two passes)

Draw a circle of arbitrary size by printing out "*" characters. (hint: calculating whether to go "one down, two over" is the wrong approach)

Convert an integer to a string. Convert a string to an integer. (Manually, of course, by looping through each digit somehow.)

Write a function to return the number of 1's in the binary representation of an integer.

Write a function that will display all possible arrangements of letters in a string. Example: abc acb bac bca cab cba

Always start with the easiest solution that works, without considering the runtime. Then, try to make it faster. It's better to have something that works than spend all your time trying to optimize and end up with a page full of scribbles.

Don't cheat yourself by looking up the answers

The first time I tried to reverse a singly-linked list, it was between classes at school. I wasn't rushing, and it took me over half an hour to go from the slow and obvious solution to the fast one. But when I verified that my answer was correct, I was thrilled! I knew that I could tackle this question without looking up the answer. During interviews, when I was given a problem that I hadn't seen before, that experience gave me the confidence I needed to avoid blanking and keep trying.

Step 3: Practice your problem-solving

Some interviewers believe that being able to solve brain-teasers equates to good programming ability. In case you get one of these, you should develop a passing interest in puzzles and techniques for solving them. A visit to your local library will result in a dozen books, filled with puzzles to practice. Pick some interesting problems to tackle, and resist looking up the answers until you have spent at least a half hour on each one. Before long you'll have no difficulty helping foxes & ducks cross rivers, or figuring out to escape locked rooms by burning various lengths of rope.

Step 4: Show genuine enthusiasm

A powerful technique is to show real enthusiasm. As human beings, we can't help responding in kind and becoming excited to work with you. On the other hand, we also have evolved the ability to see through fake smiles, so it's vital that you be genuinely yourself.

The best interviewers will try to get you to talk about something that you are passionate about, even if it doesn't directly relate to the job. Most interviewers, however, will not. You will have to think about something that you've done that excites you, and look for opportunities to talk about it. Do this early in the interview. After the first 10 minutes it is probably too late, since the interviewers will have already ranked you.

Picture yourself coming in to work at this new job on the first day, turning on the new quad-core development workstation, meeting some interesting new friends, and learning about life at the company. There's got to be something exciting about that. Otherwise, why are you applying?

Step 5: Sleep

The "Tip of the tongue" phenomenon -- the inability to recall names, words, and facts -- increases dramatically if you have a sleep debt. Don't be caught struggling to remember an important detail during an interview. Instead, get a good night's sleep (7-9 hours).

Great list, I must admit I really don't like when I'm asked to solve a brain-teaser, puzzle. Don't get me wrong, I do believe I have good problem solving skills, but I just don't see any correlation between solving a puzzle and problem solving skills. People who enjoy solving puzzles will have a great advantage in this, but that does not mean that they have the required skill set to solve programming problems, issues, etc.

For example I like solving sudoku, kakuro and things of that nature, but this does not say anything about my math knowledge and whether I'm good at algorithmic thinking.

Nevertheless a great advice regarding building the confidence, I believe this is definitely a great way to prepare your self for a coding test. But I would say that even after you solve most common ones, you should continue on, find some that are unusual and try to solve them as well. For example you can try solving the tests found on the TestDome.com.

Distributing applications on Linux is hard. Sure, with modern package management, installing software is easy. But if you are distributing an application, you probably need one Windows version, plus umpteen different versions for Linux. In this article, we'll create a dummy application that targets the following operating systems, which are commonly used in business environments...

I love languages where you need years of experience to write code that works, and languages where if you don't do everything exactly right, you will shoot yourself in the foot. Naturally, I love Javascript. Here's a simple build tool to help keep you sane.

A while back I thought it would be interesting to be able to draw arbitrary waveforms and then listen to how they sound. I had an audio engine just laying around, so I whipped up a quick application to do that.

Much ink has been spilled about the use of cell phones on airplanes. Here's the truth, which will be disappointing to conspiracy theorists: Cell phone signals most definately have an effect on other electronic equipment. Read on for more.