interview question (toughest bug you've fixed)?


D

Digital Puer

I keep getting this interview question: What was your toughest bug,
and how did you fix it?

I don't understand the point of the question, so I'm having a hard
time answering. Some please help.

Of course, I can name any number of tough bugs I've fixed, but I don't
fully understand what exactly are interviewers looking for. Do they
want to know the problem domain where the bug occurred? How I discovered
it? How I fixed it? Where did I get help? Did I ask someone, or did
I read documentation? How did I know the bug was fully fixed?

At this point in my career, the biggest bugs I encounter aren't
during programming; rather, the most troublesome ones are those
found during design of a high-level architecture or schema. Should
I mention this instead?
 
Ad

Advertisements

A

Alf P. Steinbach

I keep getting this interview question: What was your toughest bug,
and how did you fix it?

I don't understand the point of the question, so I'm having a hard
time answering. Some please help.

Well, that says something about you: you seem to want to please the
interviewer, to answer what is expected or wished for.

That kind of thing may be what a good interviewer is looking for,
but whether your reaction is enhancing your chances of employment with
that firm depends on what position they have in mind, company culture etc.

Another interviewer might just be checking up on your experience
and technical competence, like, "the toughest bug I've fixed was
a thread synchronization problem" or "a range error" or "a moth".

Of course, I can name any number of tough bugs I've fixed,

I can't. It would be like asking me for the best or worse book I've read,
or music album, or some such. Even if you asked me for the most _recent_
I'd draw a blank. But I could name some good ones and some bad ones. At
least if you didn't require me to remember their _names_... ;-)

So this says something about you.

Bugs & the Fixing of Them are to you still individuals.


but I don't fully understand what exactly are interviewers looking for.

Ah, again.

Why don't you ask _the interviewers_ instead of the newsers?

Be upfront about yourself. That way it's much easier to match person to
position. Perhaps you'll get something you didn't expect, happy ending,
whereas with striving to hard to fit some preconceived idea of what those
interviewers are looking for, you might find yourself not fitting.

Do they want to know the problem domain where the bug occurred? How I
discovered it? How I fixed it? Where did I get help? Did I ask someone,
or did I read documentation? How did I know the bug was fully fixed?

All of it and none of it.

Does she love me, does she not, ... ;-)

When in doubt, ask or declare. Or perhaps, as Heinlein put it, "when in
danger or in doubt, run in circles, scream and shout". Who knows, it
might be effective.


At this point in my career, the biggest bugs I encounter aren't
during programming; rather, the most troublesome ones are those
found during design of a high-level architecture or schema. Should
I mention this instead?

Why not? It indicates that you're able to consider several levels of the
software development process, and the impact of each. It says something
truthful about you, and that is good.

Personally, if ever asked such a question, I'd just mention compiler bugs
(with exception of hardware bugs they _are_ the toughest bugs, because
they're generally impossible to find by simple analysis, and generally
impossible to repair by reimplementing the apparently guilty module) and not
even ask for clarification of the question. I'd trust the interviewer to
talk straight and get around to any underlying "real" issue. Or not.
 
R

Roger Willcocks

Digital Puer said:
I keep getting this interview question: What was your toughest bug,
and how did you fix it?

I don't understand the point of the question, so I'm having a hard
time answering. Some please help.

Of course, I can name any number of tough bugs I've fixed, but I don't
fully understand what exactly are interviewers looking for. Do they
want to know the problem domain where the bug occurred? How I discovered
it? How I fixed it? Where did I get help? Did I ask someone, or did
I read documentation? How did I know the bug was fully fixed?

At this point in my career, the biggest bugs I encounter aren't
during programming; rather, the most troublesome ones are those
found during design of a high-level architecture or schema. Should
I mention this instead?

The point of the question is to fish out how (or, more importantly, whether)
you think. It's a convenient open-ended way of discovering your attitude to
all the points you mention, and as such, there is no right answer.

By all means mention the problems you've met at the design stage: if it gets
the conversation flowing, the question's done its trick.
 
A

Andrew Thompson

Alf P. Steinbach said:
....
Another interviewer might just be checking up on your experience
and technical competence, like, "the toughest bug I've fixed was
a thread synchronization problem" or "a range error" or "a moth".

Yep, definitely the Moth. Have you tried straightening
their little antennae(?), quite tricky.

At least it would get a laugh - if it didn't -
the _company_ fails, choose another position
unless it is just to put bread in the table.

If it _is_ just to put bread on the table, take
the position (assuming they get over your bad
joke and offer you the job), then immdeiately
start looking for a better place to work.
Why don't you ask _the interviewers_ instead of the newsers?

Interesting question. If I were the interviewer I would
give high marks to the initiative and confidence of the
applicant who queried a question, over trying to 'guess'
what I meant.

It is an important part of business communication to
query specs and instructions, but too many employees
see it as a failing to ask questions, and instead proceed
in the wrong direction due to a misunderstanding.
Be upfront about yourself. That way it's much easier to match person to
position. Perhaps you'll get something you didn't expect, happy ending,
whereas with striving to hard to fit some preconceived idea of what those
interviewers are looking for, you might find yourself not fitting.

...More good stuff later, but I think this hit the
nail on the head.

Well put, Alf.
 
R

Randy Howard

I keep getting this interview question: What was your toughest bug,
and how did you fix it?

I don't understand the point of the question, so I'm having a hard
time answering. Some please help.

The point is to ask open-ended questions to get you to talk in
some degree of detail about your experiences. Yes/No questions
are basically worthless in interviews. The more you talk about
your programming efforts the more a knowledgeable interviewer
will be able to determine which parts of your resume are real
and which are imaginary. Pick any bug, it doesn't really
matter much, provide you are able to describe it clearly, and
show a reasonable approach to finding the root cause and solving
it. They really want to hear how fluent you are in the art of
programming, not score a particular bug for wonderfulness.
 
B

brougham5

Digital Puer said:
Of course, I can name any number of tough bugs I've fixed, but I don't
fully understand what exactly are interviewers looking for.

The interviewers job is to help make sure that you're right for the company
and position. It's easy to claim x years of experience with a language.
It's trickier to fake experience by talking about bugs you've encountered.
If the most difficult bug you've ever found is an "off by 1" index in code
that you wrote yourself, odds are that you're still fairly new.

More importantly, the method you use to track down, diagnose, and then fix
the bug says a lot. People are creatures of habit. Generally, you will
most likely repeat past behavior. If you have usually made random attempts
until you got lucky and the answer fell into your lap, you're unlikely to
apply a very systematic and rigorous approach to the next problem you face.

Here's a tip...don't try to understand what the interviewers are looking for
in terms of individual questions. Rather, show them that you're the right
person for the job. Demonstrate that you can do the job. Don't just
passively sit back and tell them what color you'd be if you were a color.
 
Ad

Advertisements

J

Joona I Palaste

(e-mail address removed) scribbled the following
The interviewers job is to help make sure that you're right for the company
and position. It's easy to claim x years of experience with a language.
It's trickier to fake experience by talking about bugs you've encountered.
If the most difficult bug you've ever found is an "off by 1" index in code
that you wrote yourself, odds are that you're still fairly new.
More importantly, the method you use to track down, diagnose, and then fix
the bug says a lot. People are creatures of habit. Generally, you will
most likely repeat past behavior. If you have usually made random attempts
until you got lucky and the answer fell into your lap, you're unlikely to
apply a very systematic and rigorous approach to the next problem you face.

Yesterday I spent about three hours tracking down a bug which was
seemingly caused by a simple modification to a component in our WWW-
based application. I had changed this code:

public class Foo {
public void doIt() {
/* ... */
}
}

to this:

public class Foo {
private boolean used = false;
public void doIt() {
if (!used) {
/* ... */
}
used = true;
}
}

And it didn't work. I kept getting a NullPointerException from inside
the Apache Crimson XML library. Then I changed the if (!used) to if
(true) and made *sure* Foo.doIt() was only called once. The bug was
still there.
Later I found out the cause. The code I have marked above as /* ... */
was accessing an XML node that wasn't necessarily there. The old
version wasn't. I changed the /* ... */ code back to the old version,
and put the other changes back in, and the code ran beautifully.
 
A

arne thormodsen

Digital Puer said:
I keep getting this interview question: What was your toughest bug,
and how did you fix it?

I don't understand the point of the question, so I'm having a hard
time answering. Some please help.

Hmmm. The toughest "class" of bugs I've ever fixed are those where
the product works as designed but the customer does not agree. This
takes both the technical skill and judgement needed to see if the
product can be changed to please the customer, and the "soft" skills
needed to see if the customer can be trained or persuaded to take the
product as it is, and the wisdom to find some compromise that usually
lies between the expectations and the present reality. There's enough
meat in that answer for any interviewer to sink their teeth into. And
it's the complete truth.

--arne
 
A

Andrew Thompson

arne thormodsen said:
...
Hmmm. The toughest "class" of bugs I've ever fixed are those where
the product works as designed but the customer does not agree.

Which comes back to my comment (by
my interpretation anyway) about businees
communication (though extending it to Customer
Relationship Management).

The most difficult part of many jobs is effective
communication (that does not put the clients' nose
out of joint..)
 
E

Edward G. Nilges

Digital Puer said:
I keep getting this interview question: What was your toughest bug,
and how did you fix it?

Here are some from my experience:

(1) A Fortran compiler running in 8K was bombing out. It was available
only in object code form. I discovered that some clown had failed to
realize that the host system had multiply and divide in hardware and
had created an overlay multiply/divide subroutine which I found and
removed. The compiler worked.

(2) Recently I have had some serious problems with .Net objects that
don't document their thread status. Basically, an object can be thread
unsafe, serially reusable or safe.

The object is safe when one instance can be running procedures in
multiple threads, and the way to obtain this level is to lock the
object's state (its module level variables) on entry to each public
procedure.

The object is serially reusable when multiple instances only can run
simultaneously and the way to get this safety is to make sure that all
references to class level variables are locked and atomic operations.

The object is unsafe in all other situations including the common
situation where its safety is unknown.

(3) Here are the bugs I have created more than once when redoing code,
and I'll go ahead and insert this flamebait since I have noticed that
the greatest computer scientists including Knuth and Dijkstra are
unlike little corporate developers completely open about this and
other type of bugs.

(a) When I write a tokenizer to find blank-delimited words I sometimes
forget that the goal is to implement the regular expression ([ ]*[^
]+)* and NOT the regular expression ([^ ]+[ ]*)*. This is because like
anyone else I am subject to the reifying and positivist pressures of a
bourgeois society in which "something is better than nothing". The
result is that I have to take care that the parser parses " Moe
Larry Curley" properly.

(b) When I write a hash table algorithm that supports delete I must
take care that the deletion "mark" is not the same as the empty mark,
since the search for an available entry in the best algorithm from
Knuth must continue over deleted entries.

(c) Sometimes I forget that since in computers quantities are always
discrete, the general formula, for measuring the distance between two
points, is in general a-b+1 and not a-b. For example, the number of
characters in a string from point a to point b is a-b+1 because the
characters, unlike typical a and b in mathematics, are not
infinitesimals but instead concrete.


The important thing about bugs is naming and narrating them but in
typical development environments, this is politically unsafe, and this
is one reason for the very high failure rate of corporate systems.

Ed Yourdon, a structured programming maven of former years, expressed
in 1980 dull astonishment, that Donald Knuth would actually itemise,
list, the bugs he found and fixed in Tex in the published book about
Tex.

That's because Yourdon, Gerald Weinberg and others in his circle
emerged from the corporate environment in the 1970s as a species of
applied intellectual created by the structured programming paradigm
shift of the 1970s. Unlike academic computer scientists, Yourdon et
al. had to survive within corporate culture in which it is of course
important to "cover your ass".

Companies demanded of Yourdon, who applied Dijkstra's 1968 discovery
of structured programming to MIS development, quick and order of
magnitude results in a problem that was defined as the "productivity"
of "programmers".

Of course, to define the problem in this agricultural language
forecloses the very possibility that programmers, or analysts, are
instead of being field hands, partners with management who as much as
management define the business problem. However, in American society,
many toplevel business managers are intellectually unequal to the
demands of their job. Let us not speak falsely now for the hour is
much too late, and evidence for this exists in corporate governance.
What it means is that the intellectually incapable managers don't want
some geek as a partner who might make them look bad.

Yourdon's circle, which published a number of rather ground-breaking
works on how to use structured techniques, was under such enormous
pressure during the 1970s that many of its members seem to have left
data processing for more therapeutic and humane ventures.

Today, a system of macho denial is in place. The result is the ongoing
failure.
I don't understand the point of the question, so I'm having a hard
time answering. Some please help.

Of course, I can name any number of tough bugs I've fixed, but I don't
fully understand what exactly are interviewers looking for. Do they

I suggest you watch a number of James Bond films and learn how to
express a sort of devil may care attitude which implies your code is
bug free and that you also get laid a lot. Seriously, that's what they
are looking for.

In the macho system you cannot express weakness or dependency and the
interview is a sort of temple mystery of the macho system. You have no
choice but to be what they want.

A sort of gay (in the old sense) devil-may-care attitude is absolutely
essential even if your unemployment has run out, your ex-wife is
nailing you, your car is in repo, and you are eating Ramen noodles.
Learn this attitude from military history, would be my suggestion: for
if you read, if you connect, with what happened on Little Round Top in
1863, or to the Legionnaires of Cambrone, your own personal issues
will be seen in more perspective.

In a job interview be honest (indeed to live outside the law you must
be honest).

Another role model for the interview process, beside the Connery Bond
(the best Bond, by far) is Bill Clinton...and, I am dead serious.
That's because Clinton, despite his human flaws (for use every man
according to his deserts, and none should 'scape whipping, as Hamlet
said) was able to connect and in an interview you need to connect.

If instead you come across as George Bush, most interviewers will see
through the mask.

Watch Bush when he gives a speech. His mind is somewhere else and he
is not "connecting" with what he says. He's not all there. Instead the
"real" George Bush's mind and soul are wandering the lumberyards of
the universe, because the "real" George Bush wanted to own a baseball
team, but has to work for his Daddy, who has sold this country to the
energy industry.

[Political agenda? You bet your sweet patootie. Most job finding
advice has a right wing political agenda. This doesn't.]

As an interviewer I have seen Bush's emptiness, his vacuity, in the
eyes of job seekers and you need to project its reverse. If it is
necessary to get Jesus in order to project this then by all means get
your ass washed in the Blood of the Lamb, but my experience is that
Jesus has nothing to do with it.

Interviewers want you to be in the Now, right from the basics of
arriving on time. But more than this, you need to be in the emotional
Now of acknowledging the reality of the situation.

The reality of the situation is that many people need, in our economy,
to be unemployed or to work at less than their capacities and you
don't want to be in that group. Therefore you have to show the
interviewer, while telling the truth at all times, that you deserve to
be culled out.

This is "spin", and many technical professionals were attracted to
technology because they thought they could escape spin. They cannot.
Nor is "spin" evil: it is simply what Aristotle meant by rhetoric.

want to know the problem domain where the bug occurred? How I discovered
it? How I fixed it? Where did I get help? Did I ask someone, or did
I read documentation? How did I know the bug was fully fixed?

At this point in my career, the biggest bugs I encounter aren't
during programming; rather, the most troublesome ones are those
found during design of a high-level architecture or schema. Should
I mention this instead?

No. You will seem to have a bad attitude.
 
R

Roger Willcocks

Edward G. Nilges said:
Digital Puer <[email protected]> wrote in message

Here are some from my experience:

(1) A Fortran compiler running in 8K was bombing out. It was available
only in object code form. I discovered that some clown had failed to
[etc. etc.]

See e.g. http://www.law.howard.edu/faculty/pages/berry/advice/examtips.htm
(Rules of Effective Examsmanship for Law Students) - rule 4: 'read the
question in its entirety before you answer'.

The OP's actual query was:

"I don't understand the point of the question ['what was your toughest
bug'], so I'm having a hard time answering. Some[one] please help."

Or more succinctly, 'Why do interviewers ask that question?'
 
Ad

Advertisements

E

Edward G. Nilges

Roger Willcocks said:
Edward G. Nilges said:
Digital Puer <[email protected]> wrote in message

Here are some from my experience:

(1) A Fortran compiler running in 8K was bombing out. It was available
only in object code form. I discovered that some clown had failed to
[etc. etc.]

See e.g. http://www.law.howard.edu/faculty/pages/berry/advice/examtips.htm
(Rules of Effective Examsmanship for Law Students) - rule 4: 'read the
question in its entirety before you answer'.

The OP's actual query was:

"I don't understand the point of the question ['what was your toughest
bug'], so I'm having a hard time answering. Some[one] please help."

Or more succinctly, 'Why do interviewers ask that question?'

I answered his question with an informative essay, showing him how to
turn the reply into an interesting story. He should start narrating
his replies rather than think of them as multiple choice or only one
right answer because job interviewers would like to meet someone with
this ability.
 
E

Elmo

Roger said:
Here are some from my experience:

(1) A Fortran compiler running in 8K was bombing out. It was available
only in object code form. I discovered that some clown had failed to

[etc. etc.]

See e.g. http://www.law.howard.edu/faculty/pages/berry/advice/examtips.htm
(Rules of Effective Examsmanship for Law Students) - rule 4: 'read the
question in its entirety before you answer'.

The OP's actual query was:

"I don't understand the point of the question ['what was your toughest
bug'], so I'm having a hard time answering. Some[one] please help."

Or more succinctly, 'Why do interviewers ask that question?'

Given the kinds of questions I've been asked ("If you were a tree, what
kind of tree would you be?") wondering why interviewers ask a question
about the most difficult bug I've ever encountered seems positively
enlightening. In order to answer the question, you probably have to
tell a story about a project you've worked on, your role in the project,
and something about your problem-solving techniques.
 
W

Willem

Edward wrote:
)> The OP's actual query was:
)>
)> "I don't understand the point of the question ['what was your toughest
)> bug'], so I'm having a hard time answering. Some[one] please help."
)>
)> Or more succinctly, 'Why do interviewers ask that question?'
)
) I answered his question with an informative essay, showing him how to
) turn the reply into an interesting story. He should start narrating
) his replies rather than think of them as multiple choice or only one
) right answer because job interviewers would like to meet someone with
) this ability.

The OP did not ask *how* he should answer such a question.
He asked *why* interviewers ask such questions.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
P

Paul Hsieh

Digital Puer said:
I keep getting this interview question: What was your toughest bug,
and how did you fix it?

I don't understand the point of the question, so I'm having a hard
time answering. Some please help.

Of course, I can name any number of tough bugs I've fixed, but I don't
fully understand what exactly are interviewers looking for.

And therein lies the point of the question -- I think, as posted by
others here. Debugging, like the rest of the programming process can
require a lot of problem solving and analytical thinking. And there's
no book anywhere that I have seen that describes how to do it.

You see, if they just ask you C/C++ syntax questions, then you can
fake your way after having read a "C programming for dummies" book.
You can't fake a really good "debug" story.

The wilder and more interesting the debug story, is usually indicative
of the kind of hard core experience they may be looking for in a
programmer. Think about it -- if your best answer is something like:
"I once had a syntax error, and the compiler complained, so I fixed
the spelling, and it worked." you might not do so well in the
interview. Probably to be considered for a senior position, your bug
story would at least have to be at the level of a race condition.
[...] Do they
want to know the problem domain where the bug occurred? How I discovered
it? How I fixed it? Where did I get help? Did I ask someone, or did
I read documentation? How did I know the bug was fully fixed?

They probably want to know all those things. If you got help to solve
a bug -- that might be a serious negative. If your most
interesting/serious bugs come from not reading documentation yourself
-- then that would just be sad (though fixing *someone else's* bug
which resulted from not reading the documentation would be different
....)
At this point in my career, the biggest bugs I encounter aren't
during programming; rather, the most troublesome ones are those
found during design of a high-level architecture or schema. Should
I mention this instead?

Well, if you are just a designer/architect, then yeah. You've never
specced something out that actually had a fatal flaw that wasn't
determined during the initial design phase?
 
A

Andrew Thompson

Paul Hsieh said:
Digital Puer said:
I keep getting this interview question: What was your toughest bug,
and how did you fix it? ....
[...] Do they want to know.... Did I ask someone, or did
I read documentation?
....
They probably want to know all those things. If you got help to solve
a bug -- that might be a serious negative.

If my interviewer refused an applicant on that
basis, I would sack them. Too many programmers
see themselves as 'lone guns' who must solve the
problem themselves, when the answer lies in the
head of the person sitting at the next workstation.

Often the answer starts something like..
"Yeah, I'd meant to update the documentation of
that package when we gutted and reworked it
6 months ago, but I haven't found the time"

In fact, if I were the interviewer and asked
"How often do you consult outside help?" and
the applicant answered "Never!". I would
judge them to be either an arrogant and
obstinate prat, or somebody that sticks with
'what they know works' (i.e. is stuck using
old tech.).

Either way, "..Next applicant please!"
 
Ad

Advertisements

P

Paul Hsieh

Andrew Thompson said:
Paul Hsieh said:
Digital Puer said:
I keep getting this interview question: What was your toughest bug,
and how did you fix it? ...
[...] Do they want to know.... Did I ask someone, or did
I read documentation?
...
They probably want to know all those things. If you got help to solve
a bug -- that might be a serious negative.

If my interviewer refused an applicant on that
basis, I would sack them. Too many programmers
see themselves as 'lone guns' who must solve the
problem themselves, when the answer lies in the
head of the person sitting at the next workstation.

Then you misunderstand my statement, and you misunderstand the process
of debugging.
Often the answer starts something like..
"Yeah, I'd meant to update the documentation of
that package when we gutted and reworked it
6 months ago, but I haven't found the time"

If you've reached this point, you've already solved the problem. You
didn't seek help, you correctly isolated the problem to where it
really is, in the head of some other programmer.
In fact, if I were the interviewer and asked
"How often do you consult outside help?" and
the applicant answered "Never!".

Which, of course, is not what I said. Remember, that the original
poster asked what was the most difficult bug you personally solved?
If you decide answer that the most difficult bug you solved was
actually solved by someone else ... well what would you think of that?
 
Ad

Advertisements

A

Andrew Thompson

Paul Hsieh said:
"Andrew Thompson" <[email protected]> wrote in message

Which, of course, is not what I said. Remember, that the original
poster asked what was the most difficult bug you personally solved?
If you decide answer that the most difficult bug you solved was
actually solved by someone else ... well what would you think of that?

I see both your point, and our area of disagreement,
is purely about who actually solved the bug in
the circumstance described.

You feel it was solved by another person,
I feel the solution was arrived at by the
person who asked. I agree to disagree.

[ ehh.. shrugs ;-) ]

And finally. Yes I see, that if _you_ do not
feel the person _solved_ the problem,
your statements make perfect sense.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top