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.
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.
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.
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.
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.
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.
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?
Yes.
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.
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.
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.
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.
