≡ Menu

Top 10 Mistakes Not to Make in a Programming Interview

If you are a programmer, you already know that when you apply for a programming job, the interview process is little different than any other technical job interviews.

In this article we will discuss 10 mistakes that you should avoid in a programming interview.

1. No Practice for Writing Code on Paper or Whiteboard

This is one of the biggest mistakes that candidates tend to make. Most of the programming interviews are either on paper or on a whiteboard. Most of the candidates have good practice of writing code on a computer but little practice of writing code on paper or white board.

A candidate who is used to an IDE (or a text editor) fumbles at the very first step of maintaining good indentation on paper. You must know that writing a well indented code is must in programming interviews. Also, while writing code on paper, there is no compiler to help you find some obvious compile time mistakes. Also most of the candidates get nervous while writing code on a white board in front of a interview panel. So, before a job interview, practice a little on writing code on a paper or whiteboard.

2. Don’t Just Memorize Code Snippets

Memorizing solutions to some popular problems is something that many of the fresh graduates tend to do. For example, most programmers know how to do ‘swapping two numbers using bitwise operators in C’. But not all of them know exactly what that code does and what it does to get the job done.

So, memorizing is not a short cut in a C programming interview. Even if you get away with one or two questions, you cannot get pass a complete interview without understanding the fundamental concepts. The key is to understand the concepts behind the programming. It’s not important how many programming languages you know, what’s important is how well you know them.

3. Less Interaction with the Interviewer

If you ever feel that there is something wrong with the question or if you have any other doubt then it is always advisable to talk to interviewer about it.

Even if you don’t know an answer to a particular question, instead of sitting quiet, or answering something totally unrelated to the questions, it is better to come-out honest and agree that you don’t know the answer. But, suggest them some other alternative topic that is related to the original question, and tell them that you are comfortable in that topic.

4. No Practice for Phone Interviews

These days most of the companies tend to arrange a telephonic interview to judge the candidate before calling them up for further rounds. Getting interviewed on phone is totally different than a face to face interview. In a telephonic interview you need to have good listening and speaking skills.

Make sure that you listen to the problem carefully before answering. Interviewers might give you a code snippet and then you have to answer some questions based on that piece of code. It is important to have a pen and paper handy before attending the telephone interview.

Also, don’t answer every question in exact bookish language because interviewer might get an impression that you are actually referring to some material online while you are answering the question.

5. Writing Messy Code

Please do not underestimate the importance of a well indented code. No matter how much you know, no matter how much innovative you are, if you are being judged for your programming skills then the interviewer has to understand your code before concluding anything and if you provide him with a messy code then interviewer might not even want to read it.

It’s not only the interviewer, a well indented code even helps the candidate to write a bug free program. There are high chances that a well indented code will have less bugs when compared to a messy one.

6. Hiding Your Approach

Interviewers are always interested in your approach to solve a programming problem. It is not expected that you would be able to solve each programming problem thrown to you. But, you are definitely expected to have correct approach towards the solution.

For example, if you are writing a program to swap two numbers using C pointers then it’s the correct approach (ie calling a function with address of variables to be swapped and receiving the addresses in pointer arguments) is what matters. The interviewer might guide you if your are stuck with any other problem.

So, it is always advised to talk out your approach while solving a problem. This is a good way to keep the interviewer engaged.

7. Bad Naming Convention for Functions and Variables

No matter which language you use to solve the interview problem, it is always advisable to use relevant variable and function names, as they help in maintaining code.

For example, suppose you have written thousands of lines of code using insane function and variable names. Now, think of some new who is asked to enhance or debug this code. Debugging this kind of code, where one cannot even understand what variables represent, would be a big nightmare.

Interviewers may or may not consider this as a negative point but it’s always good to be on safer side. Moreover, you will never be appreciated to write function name ‘func’ when you can use a name ‘swap’ for writing a function to swap the values of two variables.

8. Resume Filled with Technical Stuff You Don’t Know

This is another big mistake that beginners tend to do. In order to get their resume short listed, candidates list out various programming languages, and technology name that they don’t even know properly. Though this might land you in front of an interviewer but rest be assured that your experience will not be good. Within minutes into the interview, the interviewer will come to know about your level and skills.

9. Being Under-confident

As with any interview, self-confidence plays an important part in programming interviews too. It happens that sometimes interviewers deliberately ask you to solve a wrong question. Here, if you have good knowledge and self-confidence, you can easily figure out the flaw in question and communicate back to the interviewer.

Even if you answer the questions correctly but are not confident of your answers, your chances of getting selected for the job are not good. This is because no organization would want under confident people working for them.

10. Stressed-out and Deprived of Sleep

The night before the interview, don’t stay-up late to prepare for the interview. In an interview, you need to be present with a fresh mind and lot of energy.

Many candidates might get blanked out once they start solving a problem especially on a white board in front of an interview panel. This generally happens because of the stress candidates take just before the interview. It’s always advisable to sleep well and relax before an interview.

If you enjoyed this article, you might also like..

  1. 50 Linux Sysadmin Tutorials
  2. 50 Most Frequently Used Linux Commands (With Examples)
  3. Top 25 Best Linux Performance Monitoring and Debugging Tools
  4. Mommy, I found it! – 15 Practical Linux Find Command Examples
  5. Linux 101 Hacks 2nd Edition eBook Linux 101 Hacks Book

Bash 101 Hacks Book Sed and Awk 101 Hacks Book Nagios Core 3 Book Vim 101 Hacks Book

{ 12 comments… add one }

  • Jalal Hajigholamali November 5, 2013, 2:06 am


    Thanks a lot,

  • kub November 5, 2013, 3:18 am

    Just want to say thanks for all the articles and a great website it’s a fantastic resource. Thank you!!

  • Igor Rossetti November 5, 2013, 3:31 am

    these are really smart advices!

    Thank you!

  • Amoghavarsha Nrupatunga November 5, 2013, 4:38 am

    Great thanks. Tomorrow i have an interview.

  • pervaiz November 5, 2013, 10:00 am

    I dont buy the idea of asking programmer to write code in front of people. I will go by his resume only. In my 17 years career only one person asked me to write code.

  • R063R November 5, 2013, 7:03 pm

    I agree with the article, on every point. But, from my experience, if you are honest and very clean when codding – code indentation is the key for all problems in all languages -you get the job at 90% times!

  • sachethana November 8, 2013, 8:00 am

    short and smart writing. thank you!!

  • Basavaraj November 11, 2013, 12:03 am

    Thanks a lot:)

  • Chris November 11, 2013, 8:04 am

    Nice list. This line is absolutely key:

    Even if you don’t know an answer to a particular question, instead of sitting quiet, or answering something totally unrelated to the questions, it is better to come-out honest and agree that you don’t know the answer. But, suggest them some other alternative topic that is related to the original question, and tell them that you are comfortable in that topic.

    The interview isn’t an exercise in finding out what you know, but an exercise in finding out what you do know! So many interviews go t@ts up when the programmer thinks he ought to know everything.

  • Breo December 2, 2013, 3:50 am

    pervaiz, you are lucky, I have only 5 years experience and I had to do it several times, now it is starting to be really popular. And before the coding on blackboard, I had to do online coding/Math/logic problems to solve, sometimes alone (solve and send in few hours), and then in a shared Web text editor, or (the Math ones), with a Web interface and a timer close to the answers section, 3 minutes per problem, going red the timer in the last 30 seconds (in that moment, I could not think more with the red colour there, blinking)….
    One of the coding interviews was do it with different staff, 4 hours coding (one hour with each person) after 3 hours of HR interviews. Although I was really nervous, some problems were real problems and solving there was really exciting, but at the end, I wax really exhausted, but it was

  • Viejo December 2, 2013, 6:11 am

    Very interesting! I’d like to see a similar article but about things to take into account in a sysadmin interview.

  • Kelly Carter December 2, 2013, 9:01 am

    Articles like this reflect a reality that makes me very sad. I’ve been in the industry for 36 years, and so much time in interviews is about coding, just coding. Development of software involves requirements analysis, design, coding, testing, and maintenance (and more). Coding is a critical aspect of development, but a minority of the total time spent on software. Most software project failures had nothing to do with bad coding, although there is plenty of that. The “and more” I parenthesized earlier includes methodologies, continuing process improvement, teamwork, personal attitude and work ethic, and continuing professional development. There is SO much more to a programmer or software engineer than what programming languages they know and how they code. The fact that interviews are still so focused on coding is one reason why we continue to have so much crappy software in the world.

Leave a Comment