interview question (toughest bug you've fixed)?

Discussion in 'Java' started by Digital Puer, Dec 18, 2003.

  1. Digital Puer

    Digital Puer Guest

    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?
    Digital Puer, Dec 18, 2003
    #1
    1. Advertising

  2. 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.
    Alf P. Steinbach, Dec 18, 2003
    #2
    1. Advertising

  3. "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
    Roger Willcocks, Dec 18, 2003
    #3
  4. "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
    Andrew Thompson, Dec 18, 2003
    #4
  5. Digital Puer

    Randy Howard Guest

    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:
    Randy Howard, Dec 18, 2003
    #5
  6. Digital Puer

    Guest

    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.
    , Dec 19, 2003
    #6
  7. 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
    Joona I Palaste, Dec 19, 2003
    #7
  8. "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, Dec 19, 2003
    #8
  9. "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
    Andrew Thompson, Dec 20, 2003
    #9
  10. 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.
    Edward G. Nilges, Dec 20, 2003
    #10
  11. "Edward G. Nilges" <> wrote in message
    news:...
    > 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

    [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?'

    --
    Roger
    Roger Willcocks, Dec 22, 2003
    #11
  12. "Roger Willcocks" <> wrote in message news:<bs5csm$bo$1$>...
    > "Edward G. Nilges" <> wrote in message
    > news:...
    > > 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

    > [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.
    Edward G. Nilges, Dec 22, 2003
    #12
  13. Digital Puer

    Elmo Guest

    Roger Willcocks wrote:
    > "Edward G. Nilges" <> wrote in message
    > news:...
    >
    >>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

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

    >
    > --
    > Roger
    >
    >
    Elmo, Dec 22, 2003
    #13
  14. Digital Puer

    Willem Guest

    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
    Willem, Dec 24, 2003
    #14
  15. Digital Puer

    Paul Hsieh Guest

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

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
    Paul Hsieh, Dec 26, 2003
    #15
  16. "Paul Hsieh" <> wrote in message
    news:...
    > Digital Puer <> wrote:
    > > 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!"

    --
    Andrew Thompson
    * http://www.PhySci.org/ PhySci software suite
    * http://www.1point1C.org/ 1.1C - Superluminal!
    * http://www.AThompson.info/andrew/ personal site
    Andrew Thompson, Dec 26, 2003
    #16
  17. Digital Puer

    Paul Hsieh Guest

    "Andrew Thompson" <> wrote in message news:<NZRGb.65504$>...
    > "Paul Hsieh" <> wrote in message
    > news:...
    > > Digital Puer <> wrote:
    > > > 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?

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
    Paul Hsieh, Dec 26, 2003
    #17
  18. "Paul Hsieh" <> wrote in message
    news:...
    > "Andrew Thompson" <> wrote in message

    news:<NZRGb.65504$>...
    ...
    > > 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?


    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.

    --
    Andrew Thompson
    * http://www.PhySci.org/ PhySci software suite
    * http://www.1point1C.org/ 1.1C - Superluminal!
    * http://www.AThompson.info/andrew/ personal site
    Andrew Thompson, Dec 27, 2003
    #18
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. johnp
    Replies:
    4
    Views:
    3,652
    Toby Inkster
    May 23, 2005
  2. DarkSpy
    Replies:
    4
    Views:
    871
    tom_usenet
    Jun 27, 2003
  3. reema
    Replies:
    0
    Views:
    241
    reema
    Aug 26, 2008
  4. divya bisht

    Toughest Brain Twister Question

    divya bisht, Nov 14, 2011, in forum: C++
    Replies:
    1
    Views:
    238
    Tomasz Budzeń
    Nov 14, 2011
  5. divya bisht

    Toughest Game Show Question

    divya bisht, Jan 10, 2012, in forum: C Programming
    Replies:
    37
    Views:
    949
    Tim Rentsch
    Jan 26, 2012
Loading...

Share This Page