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.