> I don't think this is unique to programming. From what I've seen, most 
> managers get hired based on their ability to spout impressive-sounding BS 
> rather than their ability to actually manage a department.

It all comes down to how competent the people are that are interviewing.  If 
a company is already full of BS managers then of course they are going to 
employ more BS staff and the problem will never improve (I know two people 
that work at a company like this).  Alternatively, if you have a good set of 
people already in charge, interviewing and making hiring decisions, you are 
not going to employ any BS managers (or programmers) in the first place.

> I would imagine that quite a few of then know damned-well that they can't 
> program, and expect to be able to just con somebody into hiring them. I 
> imagine this is the same for every profession.

Exactly.  At said company I mentioned before, it's usually the one who asks 
for the least money that gets hired (or who already knows one of the 
managers well), nothing to do with how skilled they are or how much 
experience they have.

> If the interviewer asks you to solve the Travelling Salesman Problem so 
> that it can find a route between 500 cities in just a few seconds, you 
> probably don't want to work for them. ;-)

If I were interviewing I'd ask which languages they know, lock them in a 
room with a machine with a language installed they don't know (plus relevant 
learning material), and see how many project euler problems they can 
complete in 24 hours :-)

>>   Take 100 experienced, competent programmers and give them the task of
>> implementing binary search on paper in the programming language they are
>> most fluent with, and perhaps 5 of them will give you a correct
>> implementation. (The rest will fail in some cases mostly due to 
>> off-by-one
>> errors.)

I can believe that, but then does that make someone a bad programmer if they 
can't get an algorithm like that exactly right on paper first time? 
Personally I would prefer someone who "gets" the idea and could roughly code 
it very quickly, then test it and quickly identify modifications needed to 
get it working.  The alternative is someone who either spends 30 minutes 
painstakingly figuring it out in their head, or the one who just recites it 
because he's done it before recently.  I would follow it up with some subtle 
modification requests (eg how to make it more cache friendly, or how to 
efficiently deal with data sets bigger than RAM) to see their thought 
process for something new.

Post a reply to this message