Along with the other qualities should a programmer need good debugging skills? If I have an applicant who was not able to find the error in the given program, but was able to solve all puzzles and programs, should I consider him for the job?

EDIT :- The puzzles are normal red,blue and red-blue balls like. The programs are like finding continuous k zeros in an array. The debugging program is something which fails because of condition which should be >=, but instead is >. Everything is on paper.

locked by maple_shaft Feb 12 '14 at 15:51

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. See the help center for guidance on writing a good question.

Read more about locked posts here.

  • 13
    Was he allowed to run the program, or did he have to find the error looking at the code? – Michael K Dec 23 '10 at 15:33
  • 9
    You can only code as good as you can debug. the two go hand in hand in my book. – Demian Kasier Dec 23 '10 at 15:45
  • 3
    some people are better at it than others. it is often difficult to spot an error in a piece of foreign code --especially during a stressful interview. – leed25d Dec 23 '10 at 17:10
  • 6
    @Fanatic: Only if you're only working with your own code. Most of the debugging I do at work is digging up other people's errors. – Mason Wheeler Dec 23 '10 at 17:23
  • 3
    @Manoj R, are you sure that you could find the same problem given the same amount of time? Are you sure that just because the applicant does not find a problem on paper in 20 minutes, that she would not be able to get good at it with Google (Yes, fucking Google) on her side and a couple of weeks of practice? – Job Dec 24 '10 at 2:08

16 Answers 16


Yes its very important

About that particular candidate, it is possible that s/he was not familiar enough with code-base x to debug it.

A good problem solver should be able to debug, as all that is usually required is to have a very logical method/approach.

  • 1
    More then any other skill in programming, debugging comes with experience and has less to do with talent. – Pieter B Jan 22 '14 at 13:39

If you can't debug you're pretty much not a programmer at all, let alone a good one.

Debugging is a real, practical application of not only technical skills but also analysis ability and thought processes. As a result I'd rate it as a far more useful and relevant test than whiteboard or interview questions.

Unless the job you've got involves spending all day answering theory questions, you need someone who can apply whatever skills they've got.

What you do need to do though is ask yourself was it a fair test of debugging ability - could they run the code, put in break points and so on in the same way they would in the real world? What sort of error was it? Is it something the compiler would pick up and flag (in which case it's a pretty pointless question as they'd never need to spot it)?

If it was just written on paper then it's basically just a detailed reading test and that's an even more abstract skill than your average technical interview question and I'd argue, pretty much worthless.

  • 2
    +1 for "Ask yourself was it a fair test of debugging ability" - Sounds like it wasn't. A fair test would have included runnable code with a debugger, i.e. put them in a natural, normal work environment (considering they'll rarely be working sans debugger). – doppelgreener Dec 24 '10 at 6:51

Main hiring rule — in any doubt say no.

If you need to implement a lot of new code for cheap — you can get that guy, but personally I would continue searching.

  • 7
    I have hired a lot of people in my years, and regretted almost every "Maybe" candidate that I hired. – JohnFx Dec 23 '10 at 17:31

Unless the developer can write clean code all the time (absolutely impossible), and only work on "green field" projects (will never be the case), then yes, debugging skills are absolutely essential. Absolutely. I've had experience with developers who just didn't like to debug, so they got lazy, and threw code over the wall to QA for them to test. But those developers don't last very long at all.

Software development is a craft and a problem solving skill. Those problems include both the business problems, and problems with their (and other's) code. By the way, many maintenance projects are specifically about fixing bugs, so debugging is an absolutely essential skill.

  • Another thing I want to add... Part of our interview process here, is that we give the candidate an exercise for both debugging an application and adding a couple of small features to it as well. Every part of this process is treated equally as important. – Mark Freedman Dec 23 '10 at 15:40

I'd keep in mind that there are lots of "interview question"-type web sites, and it's entirely possible to study for a great many questions and puzzles. One thing you can't study for is debugging code you've never seen before. Either you've written enough code that you know how to debug or you haven't. If it's an entry-level position I wouldn't rule the candidate out, but if they claim to have experience with the language and can't debug code in it, it certainly raises a red flag.


The major difference I've seen between junior programmers and senior programmers is their skill at debugging. Skill at debugging is something that only comes with practice and experience.

For example, think of a strange bug where a Java program works fine on the console in interactive mode, but fails when you try to use a Unix pipe for the same input. If you've encountered this problem before, you might check to be sure that new Scanner(System.in) is only called once; the bug being that it consumes the buffer when piped, but obviously not when in interactive mode. I would expect a more senior programmer to identify this bug faster. Perhaps because they've experienced it before, or because they've had other issues with buffering in the past.

As for puzzle solving and writing new code, while experience is important, this is something where a junior-level programmer can perhaps perform just as well as, or even better than, a more senior programmer. That is, intelligence and skill can have a larger effect, which is independent of experience.

If you are in a position to invest in a junior programmer, who may have new ideas and can help the team "gel," and they seem fine writing new code, go ahead and hire them. If you are looking for a senior-level programmer, then this lack of debugging skill may be a major warning sign: They might have ten years experience that only amounts to experiencing the first-year ten times.

As a side note, there are ways to become better at debugging without having 10 years of experience first. I recommend Andres Zeller's book Why Programs Fail: A Guide to Systematic Debugging as a way to learn scientific principles and to better understand how to reproduce, find, and fix failures.

  • So debugging is something which come by practice, and can be learnt, and should not be given much weight while selecting candidates. – Manoj R Dec 23 '10 at 18:41
  • 1
    To be clear: You should weigh it heavily for senior developers, but less so for junior developers. For example, someone just out of college, who started programming their freshman year, might take 10 times longer to debug something. But there are good reasons to invest in junior developers. – Macneil Dec 23 '10 at 19:40

It depends on your environment. If you play sodoku and other puzzles all day, perhaps it would be a good candidate.

If however, you sometimes have bugs in your code, or it doesn't always perform exactly as expected I suggest you get someone good at troubleshooting.

Hire for what you need, not some ideal of what a programmer should be.


Along with the other qualities should a programmer need good debugging skills?


Debugging code is a part of problem solving. I've never encountered a developer who wrote perfect code and zero bugs. A developer will be either debugging his/her code, or someone else's. It's a necessity.

should I consider him for the job?

Maybe, it depends.

Not being able to debug a program in an interview probably shouldn't be a dealbreaker if the applicant was able to complete all other puzzles and programs in the interview. It really depends on the depth and breath of the interview.

How much debugging does the the position entail? If a lot, then maybe more weight should be put into how well an applicant can answer the debugging question. But since you only mentioned that one debugging question was asked, it doesn't seem like it is.

  • 2
    +1 To reiterate debug is necessary but not deal-breaker during interview. – Gaurav Dec 23 '10 at 15:54

should a programmer need good debugging skills?

Yes. That said, I would ask you to consider the methodology in the interview (i.e. quiz / test-style) less than perfect (okay, flawed) in that many people find code on paper a strange, unfamiliar experience.

Since debugging is a process, not the answer or result (e.g. the mistake), I would suggest using an interactive dialogue or discussion as a better means for assessing a candidates debugging abilities. While most people use an informal ad hoc system of debugging, good candidates will have a similar pattern in general, of asking questions to gain understanding the system or assumptions, and requirements, then isolate the problem (often divide and conquer), and methodically compare the code to the requirements, and evaluate expected input/output, rather than a willy-nilly changing a bunch of things at once haphazardly until it works.

I also express reservations about puzzle problems during interviews, particularly in written form, as if the candidate doesn't have the right assumptions of framework of reference (the trick), the puzzle maybe unsolvable to them. I.e. Many interview puzzles suffer from having a single correct path, whereas life is complicated and the most creative thinkings are the ones who take surprisingly novel approaches to solve a problem that may not worked with a given particular pre-cooked puzzle, with an expected solution. It's like expecting all trumpet players to play jazz. This can be managed by asking the question as a non-confrontational (pressure can confound creativity) interactive discussion. Again, to me, the answer is secondary to see a good thought process being expressed. You will likely need to ask them to think out loud, but this tends to be more productive in my experience.

I haven't read or evaluated Zeller's Why Programs Fail, but I can recommend Debugging by Agans as a short, quick read that can help solidify the ad-hoc debugging process into a more structured, concrete, and organized effort, which can help to be more efficient at debugging. Also print out a copy, and hang it at your cubicle or workaround, the Debugging Rules poster, it's a perfect reminder for those bad days where nothing seems to go right. I have few bad days, and spend less time actively debugging (read: scratching my head in confusion) by trying to follow them in spirit if not in letter.

  • Great answer. I've spent literally days searching for the simplest bug fix and literally stumbled into fixing a tricky bug in minutes. A good dev should have a reasonable strategy. And it depends a lot on the app. Say your app doesn't exhibit an issue when you put in a bunch of print/log statements or run the version with symbols. What then? The applicant should at least be able to articulate some sort of coherent strategy. – SnoopDougieDoug Dec 27 '10 at 4:50

I would say the debugging is essential, unless the programmer is so good that he never makes any mistakes. I'm not convinced that that is impossible, but I can't imagine it with current popular languages and tools.

I dislike the concept of being put on the spot like that in an interview. If the candidate is nervous (and who isn't), he/she could draw a blank wheras as a programmer he may be able to routinely handle such problems. Then, if it was a well known interview or comp-sci test problem the candidate might know the result by rote, but not have the ability to think his way through a novel problem. Also if the candidate isn't familiar with the language, he is going to have to struggle. Many bugs are difficult because a good programmer knows what he meant to type, and his brain takes shortcuts while reading code. I can't find C style use of = where == should have been used by inspection, because I know what the intent was, and my brain will take a parsing shortcut reading it.


A good part of programming problem-solving, and to solve a problem you have to know the core-problem not just symptoms or inconsistencies. Debugging is the art of identifying the core-problem.

  • identify the core-problem
  • better able to visualize the flow

and many more.


I'd add a little more to the situation in pointing out the error and see what reaction the person has. Are they overly dramatic about the, "D'oh! I'm an idiot, that was so dumb..." type, overly apathetic in the, "Yeah, whatever dude," camp, or was there active listening on what was wrong with some kind of apology or remark to denote that they get that they messed up something they should have resolved? Just something to think about in future situations.

To debug in a timely fashion is a great skill. This is a bit different than giving someone a problem where it gets fixed when it gets fixed. Sometimes there has to be aggressive measures taken to save the system which should be acknowledged as I'd imagine most companies wouldn't like to have sales halted for weeks while someone fixes a bug in the accounting software the company uses.


Debugging is a critical skill. Actually I would say more that troubleshooting is the crtitical skill. Someone should know how to define the problem (including what user information to ask for and what logs to look at), how to reproduce it, what data sources he has available to diagnose the problem and how to debug and then how to fix one thing without breaking something else. However, determining that during an interview is difficult.

I would give him a real problem to find and the opportunity to use the tools available and then ask what steps he took to find the issue or what else he might do if he was unable to find the issue in the time allotted. You are really looking for someone who attacks the problem somewhat systematically and who has more tools in his toolkit than just the debugger and google (except at the Junior level when he should at a minimum try both of those (someone who can't think to try those two things is probably not competent or at least I wouldn't take the chance on him) but probably doesn't have a lot of advanced troubleshooting tools yet).

I would give more weight to troublshooting skills than the answers to puzzles (well I wouldn't ask those at all) or to demonstated programming skill. I have rarely seen a developer who can troubleshoot well who can't also write good code or do the needed fixes. I've seen plenty of people who can cobble some code together to geta "Working" product but couldn't fix a problem if their life depended on it. Mostly becasue they don;t actually understand what they are doing or understand the problem they are trying to solve. Good troublshooters know how to identify the real problem not just the symptom. An das such they know what questions to ask to define the problem for new development as well.


There are 4 to 5 key skills in any job and programming is no different. At the professional level you have to be good in all the key fundamental skills. If you have 4 out of 5 it will still hold you back.

Can you imagine a salesperson that can present, convince, articulate, qualify customers, but can't close the deal? They are out there and you don't want them on your sales team.

Debugging is definitely a core skill that a programmer can't be without.


I have such coding style, which requires miminal debugging. When I'm finished with 3 lines of code, I run it, and test it, often printing out a couple of variables. In the cases, when I got unwanted result or behavior, I put many dumps in my code - instead of debugging. I use real debugger very rare. Strange, but true.


Debugging is the phase in software development that comes after a certain test has been made on your software, and a bug was discovered. It is the act of searching and correcting the bug in your software.In lots of cases, finding the bug usually requires more time that fixing it.

It is the process of removing the bugs (the vulnerabilities) that are inherent in the computer application/system. If this isn't done then hackers may take advantage of the bugs & may do a variety a malicious activities:

1) They may expose the vulnerability to the public leading to a loss of revenue, business & reputation for the developers & vendors.

2) Worms search for vulnerable systems that they can exploit & thus, copy themselves onto those servers. eg. In Jan 2003, the Slammer Worm took advantage of the vulnerability in the MS SQL Server.

3) Where worms have been mentioned how can we forget the viruses. Viruses are also let lose by their developers that take advantage of the bugs present in the program for the primary purpose of indecent exposure...

4) And if programs aren't debugged properly, consumers are never going to keep quite if they don't get their money's worth. In that case you don't even need a hacker to do the dirty work- you might as well trust the good ol' public.

Not the answer you're looking for? Browse other questions tagged or ask your own question.