Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: C expert criteria
Message-ID: <10423@smoke.BRL.MIL>
Date: 20 Jun 89 15:39:45 GMT
References: <12280@well.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Distribution: all
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 27

In article <12280@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes:
>      1. When hiring someone how do you know they are qualified?
>         By asking questions, right? Which questions? This relates
>         to my question.

At previous employers, we used to give a programming examination to
applicants for programming positions.  Part of the test were short-
answer questions, e.g. "What is a sentinel?", and part consisted of
a couple of practical exercises for which we were more concerned
with how the applicant approached problem solving than with arrival
at a solution.  For example, one such problem may be how to clip a
line segment (given as endpoint coords.) to a 2-D H/V rectangle.

>      3. When doing code reveiws, how do you judge the competence
>         of the code with no definition of what "good" code is?

I'm moderating a series of code reviews now, and we have definite
criteria.  I think it's a waste of time to wander aimlessly through
code.

>I'm asking about the essence of C programming.

I don't think you should emphasize the "C" so much.  C expertise is
not commensurate with programming expertise.  More importantly,
programming is only one aspect of software engineering; there are
other equally important skills needed besides those for writing
programs.