Re: Programmers -> Engineers; Engineers -> Programmers

[ajaskey@gnn.com (Andy Askey)]

jkrell@nswc.navy.mil (James Krell) wrote:

>Let's say an organization is developing software for a radar system...
>Is it better to take engineers/scientists who understand the system
>and teach them how to program?  Or is it better to take programmers
>and teach them about the radar system?

>Another example.. what if an organization is developing a command
>and control system? Is it better to take individuals who know the
>tactical and technical  aspects of the command and control system 
>and teach them how to program or is it better to take programmers 
>and teach them about the command and control system?


>James Krell
>jkrell@nswc.navy.mil


I have worked on tasks similar to your examples for the pasted 4
years.  Here are my observations:

1)  Don't hire more than a small number that are clearly a distinct
member of one group or another.  For example, if you have 20 people in
the group, don't hire more than 2 that say they are radar gurus and
are not excited about software.  And don't hire more than 2 software
people who could care less about radar.

When choosing these four people make sure that they are head and
shoulders above the rest of the team in their respective areas and can
give results in hours or days and not in weeks.  It does no good to
hire a pretty good programmer who is not interested in radar.  Only
hire a great programmer cuz the other 16 people in your group will
collectively easily exceed any benefits a pretty good programmer will
bring to the project.  And don't hire a pretty good radar engineer for
the same reason.  If you can't find an expert, don't waste your time.


2)  Hire recent college graduates when possible.  Many times employers
search for that perfect person to fit a specific hole and end up with
someone who is pretty good at the time but is not very useful in a
year when the situation changes.  Recent graduates have not been
corrupted by the system and will do anything you ask them to do.  If
you need a programmer that knows radar, a recent graduate will easily
pick up both cuz he/she hasn't learn to do any different.

For you aging vets with a bunch of experience who disagree and think
that you should be given concideration over a new college kid I have a
question.  Do you fit into the category of "expert" in your field?  If
so, you will always have a job.  You will always be hired for one of
those "expert slots".  And if you have been working for say ten years
and are a pretty good engineer but not someone who is one of the
"best", and not someone who is particularly interested in software, I
have another question.
WHAT THE HELL HAVE YOU BEEN DOING FOR THE PAST 10 YEARS? 


3)  Hire based on the interview and not on previous job history.  I
have found that many people kick around the industry for 10 years,
never really accomplishing anything except to conpile a long list of
projects to add to their resume.  Some awfully average people have
some awsome looking resumes.  This probably does not apply to recent
college graduates.

Set up the interview to determine what the candidate can add to your
task and not what the candidate did on the last task.  I recommend
sending a small packet to the candidate discribing the job before the
interview or schedule the interview in 2 parts.  Part 1 the employer
tells the employee about the job and all the BS background history can
be covered.  Part 2 (on another day), the employee presents a briefing
on the benefits of hiring him/her.

At this point you can determine if you have someone who understands
the software/hardware interactions in the radar.  This is not the
traditional way people are hired in this industry but if you think
about it a second, it makes a lot of sense (at least to me).  You are
merely testing the candidate to see if he/she can do the day 1 work
before he/she is hired.  You will be amazed at the number of BS'er you
will weed out with this process.

4)  Make sure the leads of your core group are impressed with the
candidate after the interview.  Unless you are hiring the "expert"
candidate you need to make sure your  pretty good software people and
radar people both are impressed.

5)  HIRE GOOD PEOPLE.  Don't pigeon hole candidates.  Just find a
smart and ambitious person and hire them.  A smart, ambitious employee
can do most anything.


--
May your karma be excellent for forgiving my spelling mishaps.

Andy Askey
ajaskey@gnn.com