

Identifying Senior Software Engineers: Six Critical Differences - tlrobinson
http://www.prestonlee.com/archives/291

======
swombat
This article explains some practical differences but misses out on the really
useful stuff: how can you tell the difference _before_ you hire the software
engineer.

~~~
timr
Many of the discussed items are testable. For example: show someone a known
piece of bad/ugly code, and ask them to evaluate its quality.

Nobody does this, and they should. The hard part is standing back, and letting
the candidates hang themselves.

~~~
swombat
I didn't say they're not testable, just that the article does not explain how
to test for them (apart from the instinct, but that test is a little flakey, I
reckon).

By the way, the method you propose only allows you to hire engineers who are
similar to you, and only if you are an engineer yourself. A better test would
also allow you to recognise people who are significantly better than you -
again, that's theoretically possible but I haven't found such a test - at
least not in a form that is practically explainable to someone who's not
themselves an alpha geek.

I came up with a set of "symptoms" that indicate a good programmer in my
article here:

[http://inter-sections.net/2007/11/13/how-to-recognise-a-
good...](http://inter-sections.net/2007/11/13/how-to-recognise-a-good-
programmer)

But those are not testable per se, they're just things you can look out for if
you don't have anything else to go by. The aim was to help business guys
recognise potentially good programmers.

At the end of the day, if you're an alpha geek yourself, then selecting people
to hire shouldn't be a problem... you can sniff out people who are like you
quite easily. The difficulty arises when a non-geek (or a non-alpha geek) has
to attempt to hire someone better than them. I don't think this article helps
much with that.

~~~
timr
I don't believe that a non-engineer should be screening engineers. If you're
doing that, you've already lost the war.

That said, I think that alpha geeks are susceptible to hiring false-positives,
just like everyone else. The causes might be a little different, but they're
still real.

The point of asking someone to evaluate bad code is to see if they have good
taste, and the ability to understand other peoples' code. Too many "alpha
geeks" want to screen for raw coding ability, but don't properly filter out
the people who can't _read_ code. It's a separate skill, and since you
(should) spend far more time _reading_ than _writing_ , it's also very
important.

------
queensnake
.. for a /corporate/ position.

