From: bob@netxcom.netx.com (Robert Thralls)
Newsgroups: misc.jobs.misc
Subject: Re: Strange Interviewing question
Date: 14 Oct 92 05:24:12 GMT
Organization: NetExpress Inc., Vienna, VA, USA


>>What I have found odd is that in the five or six years that I've been
>>involved in interviews and the 100s of interviews that I've given I've
>>never gotten a student with a computer science or computing degree to give
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>me a sensible answer; the only person who did give me a good answer was a 
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>physicist and she got the job.
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>My rationale for asking the question is wide spread. It checks out the
>>applicatants ability to figure out what the real question is; for me to
>>appraise how they react when asked odd questions; I'd also like to know HOW
>>they work; I'm also fishing for how good their practical skills are (or is
>>the first class honours degree merely a reflection upon the quality of
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>their teachers) and lastly it gives me a chance to wind-up my boss. :-)
>^^^^^^^^^^^^^^^

>    I think the rationale behind your question is quite simple: you have 
>    difficulty producing a clean piece of design/code, hence you tend to 
>    over-emphasize the importance of one's debugging skills.  Also, you
>    seem to be pre-disposed against applicants with C.S. degrees (do you
>    have one yourself?), as well as those with "first class honours"
>    (feeling insecure?).
>    You are lucky that your boss does not understand what kind of people
>    you recommend to hire.  If she did, you'd be interviewing for a job
>    yourself.

These comments are rude. I think that anyone, reguardless of having
a degree or not would also find them the vulgar. I believe he simply
made an observation that cut between experience and inexperience NOT
degreed and non-degreed.

>>By the way, "how do you debug a program" is the ONLY question that I'll ask
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Well, now, I feel compelled to agree with the interviewer on this one.
One must have a basis in decision making, this is his. Although, not unsimiliar
to my own. It appears to me that the reasoning behind the question would
instill a sense of rational behaviour. The response should be that of a 
practiced methodology, one that comes from experience, no matter how little
of it one has. Even a student may have caught on, but highly unlikely.
The structured environment of a school assignment leaves little to the
imagination. The bitter reality of life leads us into a methodology of 
debugging that cannot, at best, be described in breif. Constant power
struggles between two forces, whether they represent development and
customer support, or marketing and product management, these two forces present
scheduling problems to the programmer (as if that is all one does). All 
problems are scaled to their proportion. Some problems are tricky, but
since no one noticed in the first place, how can one justify one's time
on such a problem. Other problems are excruciatingly obvious, easily fixed,
but one spends three fold more time documenting and explaining the degrading
embarrassment than one actually spent in correcting the short coming.  With 
others, one sees the code branded on the screen of a powered down terminal.
Garnished with debug statements that can hardly be explained, stacks and stacks
of trouble tickets lay upon a messy desk, all of which gets pushed into the 
garbage can. The programmer went home to dial in and painstakingly rewrite
someone else's job security plan, those too inconsiderate of who came behind
them. All bugs are different, but people remain the constant in the equation, 
and with that come their philosophies in an approach to the unknown. It is 
the symptomology of buggy software that remains the same for each diagnosis.

One does not expect a fiscally responsible method from a recent graduate,
but one does expect a method. And more importantly, one expects one to
justify and communicate the methodology coherently. I'm not sure if I
could actually answer such a question in an interview, mainly because my
methodology is engrained, automatic. I found myself having to think about
the things I do to solve problems. Here are the eight easy steps:


	 2: REPRODUCE THE PROBLEM.
	 4: Isolate the problem, understand it.
	 6: be aware of the extent of the problem.
	 8: formulate change.
	10: test the change in theory. (think before you leap)
	12: implement the change.
	14: test the piss out of it.

	oh, did i say eight? Well, just throw it in whenever necessary.

	The degree of anality for each step depends on the level of
	difficulty of the bug, the level at which the bug resides,
	and the extent of the bug weaving through the system.

	For some bugs, a step is glossed over, while others the same step is
	handled with kit gloves.

	"Hell, to be honest, some bugs are squashed and swept up with day old
	printouts. God, I wish the Orkin man lived next door. One time we
	actually found a dead rat under the tiles in the lab- electricution,
	ya know."

Well there you have it in a nut shell. Anyone giving a round about answer
to that question would not be allowed near my code. CS degree or not.
And I confess, I don't have a [CS] degree, but I do have something else.

Oh, one more thing, my question is "How do you feel about creating software?"
My intent for this? Well, that's another story. Perhaps, sometime, I'll
tell you of the time I took a really nasty C test in an interview, passed
with flying colors, my career had been tailored for this position, two levels 
of management wanted to hire me, but it was nixed by a geek who condemned 
not only me, but the manager who even considered hiring someone without a 
degree. This happened right here in Reston, Virginia! Right here! Of all 
places, can you believe that?


no signature required.