Testing programming applicants:  debugging?

This may have been mentioned previously, but I can never get the search to work properly on Jos.


Today it occurred to me that a very good test of a job applicant (for programming) would be debugging.

Several benefits:

1. I found, when I taught sw engineering, that the biggest problem students had was getting lost when things didn't go perfectly.  So, troubleshooting/debugging is very necessary for general programming productivity.

2.  Evaluates thier ability to read code.

3.  Evaulates thier ability to work indepdendently.

4.  Fairly easy to administer.

5. Opens the door to a discussion  of the cause of the bug and what sorts of testing might be done to prvvent it, etc.

Any thoughts?

The real Entrepreneur
Tuesday, March 2, 2004

I strongly agree!

Just think of the people you have a very low opinion of with their development practices at work - and they all have a very crippled ability to debug software.

Whether it may be mental, or just plain laziness -- they would overlook critical things during development, and whoops, could not debug it themselves.

The ability to debug is not only confined to the beta-testing process.  It is applied while you actually code.  You would code something, then realize, "Now that would not produce the results efficiently... maybe if I refactor this loop...")

The gurus of coding are SO good at this that they debug BEFORE they even write the code.  That's why they're 10 times faster than the rest of us.

-T.J.

T.J.
Tuesday, March 2, 2004

Absolutely. I've done this for years. I've only recently learned this is "unit testing" :-)

Also, I found that my worst performing students were also the most obvlivous to thier errors. Didn't bother them at all.

The reason?  They never looked back at a failure.  But they also never lLEARNED from that failure. So they made the same mistake over and over again. And were always condident they'd do it right the next time.

The ability to debug/troubleshoot seems to indicate a WILLINGNESS (and proclifity) to honestly look at a problem and seek out the SOLUTION instead of casting blame.  (See my recent post on the Apprentice on Jos for more on THAT topic).

The real Entrepreneur
Tuesday, March 2, 2004

we had the following C++ test -  two pages of code with lots of errrors (things like problems with shallow/deep copy constructor, call of virtual function in costructor, buffer overrun, etc...)

- the task was to find and explain the problems.
Worked like charm.
Almost nobody passed it.

Michael Moser
Tuesday, March 2, 2004

If your own team cannot complete it in 10% of the alloted time, it is useless.  It may be anyway. 

You are asking someone to resolve, in abstract, issue you placed into code, which may or may not result in valid output.    As for opening the door for discussion, it probably will.  Most of the good people will say "see ya".

- Stepping onto my soapbox -
Once again, go for temp to perm. This gives you and the person the opportunity to really see each other day to day.  Figure their salary/1000  for a per hour compensation, with a six month do or die decision.  Six months insures they do not get so embedded you cannot get rid of them and also makes you commit.  The rate insures they have something to go on if you decide to part ways.

MSHack
Tuesday, March 2, 2004

Disagree. Your code may be awful.  Personally I spend half my time debugging code written by other people. Sometimes I learn from that code (RARELY). Most often I just cry. I told one customer that I would try to fix anything broken in existing code but at a minimum of X hours regardless of what it is and I would NOT evolve the code AT ALL. My best advice for him would be to get an off-shore programmer who would refactor the code over time but the customer would not understand this and of course the programmer might just refactor it into another nightmare.

Along these lines, I would show a programmer the existing code and ask him how he would have reorganized it, if he would.

I program in Perl and PHP and there are untold ways of doing the same thing but I always choose a pattern. A lot of people just choose stream of consciousness. How a person suggests to change your code will say a lot.

Of course I would never hire a programmer who had not already programmed. I would read his code and thus know  him.

Me
Wednesday, March 3, 2004

  Recent Topics

  Fog Creek Home