It seems I was hired, in part, because the management was impressed with my poise during the interview. While I went on to do great work with them (and a solid reference with a definite "willing to rehire" when I left), I shouldn't have been hired on "poise." Admittedly, there were some mitigating factors that I won't mention as they'll seem like bragging, but I question the decision to hire me.

How do managers assess a programmer? Plenty of programmers can talk the talk and then stumble the walk. Bringing in "programmers" to question me is not necessarily an answer. If I was interviewing with this company, I would be highly suspicious of the ability of their programmers to adequately assess my ability. I truly believe that an independant "guild" or something similar (that's not tied to a particular product like the MCSE) could greatly benefit our profession. I just discovered http://www.colosseumbuilders.com/american.htm, which purports to create such a guild. I don't know anything about them -- this isn't an endorsement -- but it might be a start.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

A lot of studies have been conducted in the last 20 years trying to identify the best predictors for success when hiring new employees. Companies bet a lot of money on new employees: good ones make the company lots of money. Bad ones (at best) don't help the bottom line and (at worst) COST money. The results of these studies show that "technical skills" (i.e., how well you can perform the technical requirements of the job) are not nearly as good a predictor of success as the non-technical skills related to the job. The "non-technical" skills I'm talking about are general, touchy-feely things such as making sure you don't (for example) hire an introvert to be a salesman, or hire someone who prefers to work alone and expect them to work in a team environment. Regular old "technical skills" can be taught to the right person in time, but you'll never be able to teach a non-detail oriented person a subject like accounting. It just won't work.

The bottom line is that the enlightened manager is much, much better off hiring someone who knows absolutely nothing about the technical requirements of job, but who otherwise has all the right personality traits, than hiring someone who is a technical wiz but does not have the other personal traits that will ensure success.

It sounds to me like your employers were pretty enlightened, and it doesn't surprise me that you were ultimately a success in that job. And yes, it's those non-technical traits that a good manager gets at during an interview.

Gary Blackburn
Trained Killer

I'd guess that you were not hired for poise, and since you don't tell us how the swimsuit portion of the interview went (bragging eh?), the most probable reason for your hiring was a combination of:
• you appeared intelligent
• you admitted when you didn't know something
• you assessed the building stress and futility of the questioning, and dealt with it using a simple, humerous, and polite question that made everyone feel better about what they were doing there

IMHO, these are all features (or at least indications of them) you want to find in employees, but often don't. Yes plenty of people can stumble around and look the part, and that is precisely why an interviewer must use less tangible measures than test results to select people. In a previous company I was involved in staffing a software development group which was to do a major overhaul of a DOS-based scheduling system and move it into Win32 (all in C and assembly at the time). We built a test of basic C skills, but as I recall the results were not in any way related to the eventual hiring decisions.

If someone has the right personality they can learn what you need them to know. In many cases even the best programmers would need to learn a great deal in order to build an application in specific field about which they know nothing.

--
I'd like to be able to assign to an luser

I'd like to agree that this is a sad and all-too-common problem. I'd also like to say that I've seen companies get this right with good management, good programmers who make good managers, promoting good programmers that don't make good managers so they don't feel the need to become bad managers for the promotion, etc.

Sure, this is still the exception. But there are good books on how to manager software development well and I've seen those techniques work.