While not strictly management-related, this diatribe on the definition of "Software Engineering" used by various organizations had me grinning for quite some time - and nodding my head in agreement more than I care to admit.

Link [drewyates.net]

In part one, I discuss some of the problems I see with the currently-fashionable puzzle/testing interviewing technique.

Software engineers as engineers

My reaction to the puzzle/test interviewing style: If you are looking for an engineer, you should be interested in knowing how well they 'engineer', not how well they tap-dance. Engineering is a discipline that involves thought, reflection, and sustained effort.

So, unlike juggling or tap-dancing, which involve reflex and muscle memory and very little in the way of thought process, I am skeptical that one can rely solely on such a test of problem-solving acumen. ⇒ Read more

DRAFT 3: This is a work in progress. Please direct comments / questions to problemboss@gmail.com

Puzzled by the interview process

I've always been interested in the reliance on logic puzzles and coding tests in interviewing software engineering candidates (Microsoft has a reputation for using this technique heavily in the past).

While I think I understand the desire to use such techniques, I believe that they create and reinforce a monoculture among engineering teams, and that the resulting monoculture may not be desirable.

What makes companies think that they can get consistently great engineers as a result of an interviewing technique that requires almost no preparation whatsoever? ⇒ Read more