From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bdc41aa5ff8e1d93 X-Google-Attributes: gid103376,public From: ajaskey@gnn.com (Andy Askey) Subject: Re: Programmers -> Engineers; Engineers -> Programmers Date: 1996/08/10 Message-ID: <4uic1j$fg0@news-e2d.gnn.com> X-Deja-AN: 173365645 references: <1996Aug8.115630.4568@relay.nswc.navy.mil> x-gnn-newsserver-posting-date: 10 Aug 1996 16:06:11 GMT organization: GNN newsgroups: comp.lang.ada Date: 1996-08-10T00:00:00+00:00 List-Id: 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