Boy, people are the core issue, aren't they? Lots of people talk a good game, but do poorly in practice. What's a poor interviewer to do?
But with the existing staff, training (perhaps informal) plus performance review have worked for me. That 6-month/annual meeting is a key moment. If you don't make it clear that you expect solid participation in the group process and excellent code quality, you just will not get it. But you also need to take a bit of time to spell out your expectations. This gets back to Sean's original posting. IIRC, he wants to put together training materials to help folks get up to speed on good SW engineering practice. I think he definitely has the right idea. take it easy, Charlie At 04:40 PM 3/13/2002 +0000, David Cantrell wrote: >On Wed, Mar 13, 2002 at 10:05:37AM -0500, Teodor Zlatanov wrote: > > I don't think any amount of QA, documentation, project management > > skills, or any other procedural tools can correct for the basic skills > > missing in programmers on a team. > >Of course. So how do you gauge whether a new hire has the necessary >skills? Another unfortunate symptom of our immature industry is that >there are little in the way of universally recognised qualifications. I >sure as hell can't rank someone with a CS degree as being better than >someone who is self-taught - whereas "proper" engineering degrees are a >pretty damned good indicator.
