Re: Jaron Lanier is a Schmuck

[lemming]

I'm stating the obvious, but Mr. Lanier has to make bold statements like that to sell himself and get to stay k001.

However, I think the point that can be gotten is that we have programmers fresh out of school doing the majority of program design while the experienced ones are being managers. And being management these days seems to be mainly political battles. Why do it then, $$$ or power. And good programmers rarely make good managers. So the shame is not in Computer Science, but the way business is set up now. If it doesn't produce a press release, it's not worth the effort.

-lemming
Maybe I should go take an anti-cynical pill

[Ovid]

Any thoughts as to solutions? Much of the difficulty seems to be companies with a large IS staff acting as if it's two different companies - an "us versus them" mentality. One time, a headhunter arranged an interview with one company for which I was woefully underqualified. They brought in one of their software developers and I was asked a long list of technical questions about mainframes. Since I had no mainframe experience, I kept saying "I don't know about that." After I said that six or seven times, I stopped her and asked "this is the bad part of the interview, isn't it?" Everyone laughed themselves silly and I wound up with a new job and a substantial pay raise. Huh? Clearly, the developer was not impressed with my technical ability, but management was impressed with my demeanor. Who cares what the developers think? (On the other hand, see this post of mine for a balancing viewpoint)

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.

[Trimbach]

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

[Albannach]

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

[tye]

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.

        - tye (but my friends call me "Tye")