«

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?

On Wed, 17 Dec 2003 16:59:14 -0800, Digital Puer <> wrote:

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

"Digital Puer" <> wrote in message
news:brqtsi$4us$...
> 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.

--
Roger

"Alf P. Steinbach" <> wrote in message
news:...
> On Wed, 17 Dec 2003 16:59:14 -0800, Digital Puer
<> wrote:
>
> >I keep getting this interview question: What was your toughest bug,
> >and how did you fix it?
....
> 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.

--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site

In article <brqtsi$4us$>, t
says...
> 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.


--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet:

Digital Puer <> wrote:

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

scribbled the following
on comp.lang.java.programmer:
> Digital Puer <> wrote:

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

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.

--
/-- Joona Palaste () ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Hasta la Vista, Abie!"
- Bart Simpson

"Digital Puer" <> wrote in message
news:brqtsi$4us$...
> 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

"arne thormodsen" <> wrote in message
news:X%JEb.11168$...
> "Digital Puer" <> wrote in message
> news:brqtsi$4us$...
> > I keep getting this interview question: What was your toughest bug,
> > and how did you fix it?

...
> 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..)

--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site

Digital Puer <> wrote in message news:<brqtsi$4us$>...
> 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.