Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dgcad!dg-rtp!farmhand!cole
From: cole@farmhand.rtp.dg.com (Bill Cole)
Newsgroups: comp.object
Subject: Re: Object oriented software engineers (Was: Documenting OO Systems)
Message-ID: <1991Apr19.182919.26229@dg-rtp.dg.com>
Date: 19 Apr 91 18:29:19 GMT
References: <jls.671247104@rutabaga> <1899:Apr1206:12:4991@kramden.acf.nyu.edu> <1991Apr17.215418.26300@visix.com>
Sender: cole@farmhand (Bill Cole)
Organization: Data General Corporation, Research Triangle Park, NC
Lines: 26

|> Bill Cole writes:
|> 
|>    I tend to agree, though it would be damned difficult to get a useful
|>    sample of anyone's code.

|> Amanda Walker replies:

|> This is true; however, if I can't see a non-trivial sample of someone's
|> code (under NDA if necessary), they're not likely to get even so far as
|> an interview, unless there are extremely convincing extenuating
|> circumstances...
|> 

This may sound naive (it seems to when I say it):  What do you consider a
non-trivial sample?  And how closely do you inspect it?  In the years
I've been doing this, I've never asked -- or been asked -- to see anyone's
code.  It's an interesting idea, though.

How about this alternative (since not all candidates will be using the
language I may choose): Given a problem, let the candidate work out the
solution method on the wall with you.  One, it gives you a clue to how
the individual attacks problems and, two, how they work in a small group.

Or this: Given a piece of code, explain what it does and how it could be
changed.

/Bill