Re: Testing job applicants

[Brian Inglis <Brian.dot.Inglis@SystematicSw.ab.ca>]

On Sat, 4 Sep 1999 00:05:11 +0100, "Ruff Records"
<ruffrecords@geocities.com> wrote:

>Pete Fenelon wrote in message <68rmq7.er7.ln@fenelon.com>...
>>In alt.folklore.computers Ruff Records <ruffrecords@geocities.com> wrote:
>>> This may be controversial but as a rule we find people with computer
>science
>>> degrees don't make good software engineers.  This is at least in part
>>> because nearly all our developments are cost sensitive embedded
>>> applications.  We find computer scientists have insufficient appreciation
>of
>>> the hardware aspects.
>>
>>Depends on the CS course. Good ones emphasise an engineering/systems
>>approach encompassing high- and low-level software, and the way it
>>maps onto hardware. The fact that there are tradeoffs to be made, and the
>>tools for deciding how to make them, underpin the course.
>>
>>Bad ones teach "flavour of the month" programming languages and
>>trendy techniques.
>>
>>A graduate from a *good* CS programme should be capable of working at
>>any level from high-level requirements capture for a GUI down to
>>bit-banging on bare silicon... and should adopt a rigorous engineering
>>approach to both ends of the spectrum.
>>
>>pete
>
>But how to tell good from bad?  Our experience of CS qualified candidates at
>interview was that their engineering knowledge was very poor so we abandoned
>recruiting them.  If we knew which colleges ran the 'good' courses we could
>only select those for interview.  Any suggestions??
>
>Ian

EE/CS programs seem to produce people with more of a clue about
tradeoffs. But you have to eliminate the ones who think they
already know everything, and do not expect to keep learning thru
their work, and those who chose it as a good career, with no
desire to do the work, desiring to manage rather than mentor
staff after they get more experience. 

As someone else has noted in this and other similar threads,
someone from some other background totally, who is enthusiastic
about what they can achieve, do, learn, has demonstrated capacity
for the work, and a rigorous approach to the results, can often
be a better choice, depending on the type of work or team you
have. 

Most pros I know have little time for politics; a fairly
nonchalant attitude to the complexities, deadlines, languages,
requirements or variability of a project; approaches to design
and development that are very similar to others at the same
level; are not surprised when builds and test runs work perfectly
first time, some of the time; include debug/test output as part
of the code, in case they need it; don't whine about requirements
that are necessary and require any amount of work to do or add
later; and are not satisfied with "good enough", only with good
enough for all possible circumstances and a few impossible ones. 

Get the people who are best at doing what you require a potential
recruit to do, to handle the interview and see if they can
identify with them: "it takes one to know one" may apply here. 

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
-- 
Brian_Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
				use address above to reply