|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |