[artas_bartas]

OK, I am a business type guy and I have to say... I completely agree with this article. In my experience, developers become good at what they do not through learning languages, but rather through mastering three basic skills:

a) modeling business specs into discrete technical steps (loops, workflows, calls, etc.); b) developing intuition for tackling bugs, e.g. knowing where to look for causes and how to fix them quickly, even if it often sounds like a completely illogical thing to do; c) developing and sticking to well-defined procedures, e.g. documenting code, making timely backups, going through security checklists and so on.

So whenever I need to hire a new developer for my projects, I try to assess how well he fits those three criteria.

[ericb]

That is a great starting point, and will probably get you better than average candidates if you can figure out how to tease out that information without knowing how to code yourself. Compared to the average non-coders approach, that will get you really far.

I'm curious what you ask in interviews.

[artas_bartas]

Eric, I deal with my programming handicap in several ways.

The easiest thing to do is to ask new candidates to walk me through how they would model a specific business problem we've worked on before. Since I like to listen in on developer talk, I am usually aware of technical challenges that different approaches entail and listen to whether the candidate spots them or offers a way to deal with them when prompted.

I am also very curious to see how the candidate approaches the problem itself. In my experience, average developers feel they are done with the task when they explain how the program will work, while great developers are done when they explain how the program will work even when something it depends on doesn't work (e.g. how to you handle errors and outliers).

Obviously, I ask my developer colleagues to evaluate candidate's sample code.

Talking about testing is pretty fun too, just asking candidates what were the most nerve-wrecking debugging stories they had, reveals how much experience they have in this area. Then I would drill the candidate about testing routines and heuristics he employs; rule of the thumb is that the more specific candidate is, the more he knows about testing. Listening to heuristics also gives you an impression of how creative/crazy people are.

Finally, walking through a specific project the candidate has worked on in the (recent) past helps to understand what workflows & routines he follows in his daily routines. Here though you have to remember to ask clarifying questions along the way.

[hga]

Do you realize how utterly rare you are?

You've definitely homed in on three very important parts of being a good programmer as I define it. You're probably assuming some basic things like good communications (a won't happen without that) and using source code control when the project is big enough (I assume a part of c, but indeed backups come first and in small companies I tended to take that over) ... and I'm struggling to think of something you haven't covered that's relevant to your domain.

And, yeah, it sounds completely illogical, but after a while if you're good you do develop "intuition" that guides you in quickly finding bugs.