How to measure a skilled developer

Thank God, some may say, that bananas are still way too expensive to replace human developers with apes; Well, at least by Uri Kalish in his Why Software Engineers Should Care About the Price of Bananas. Let’s face it, we have too many “chumps” out there, lurking to make a few extra bucks by faking it really well. But every once in a while, the sun is shining in glorious colors and you meet a really talented developer whom you think will be a great addition to your team. You ask her logical questions, she shoot right back with pearly answers; You ask her to design something and bang, she nails it; You ask her to juggle with code a bit and it is all sweet. She has analytic mind and just enough experience. Total Package.

This leaves you with the one thing, the only thing, that really matters – how can you tell whether or not she will use her analytic mind to solve your team’s problems instead of introducing more complicated ones while trying?

I came to the conclusion that the only way to know how skilled a developer is, is by letting her solve a very simple problem and shoot more problems to the air while she solves it. Skilled developers will be able to break things into smaller chunks and solve them in a SIMPLE manner. When I say simple, I mean it, it will be so simple taht even a chump will be able to read it. Then they will move on to the next problem and solve it in the same SIMPLE way they did before. Then they’ll tell you how to sew the all thing into one wonderful solution. It’s actually pretty straightforward, simple things are easier to combine, but only a few folks out there knows how to “break & build” in a graceful, simple manner.

I look way back to my first days with .Net and OOP and I can honestly say that I did it all wrong(although it looked damn right at the time). If you looked at the code, it was elegant, in its own way, it was “sophisticated”(interfaces, events, a few Design Patterns) but it wasn’t right. It wasn’t SIMPLE. I had too many classes with too many (wrong) responsibilities, some of them contained quite a few God Methods and they were in no way testable. I had a great amount of green words(aka comments) to explain why things “needed” to be complex.

So for the developers among you – read, talk, write, teach and most importantly practice. Continue to improve your skills by breaking tasks into smaller chunks and keep making them green-free. If you spend more lines on documentation, you’re on the wrong direction. Invest time in breaking responsibilities to different classes(class should have a very narrow responsibility) and take the time to think about your API. I’m playing quite a lot lately(Fluent Interfaces, Creating a decent API for client side script registration) with method names and the benefit I see in it is huge. readable API requires almost no documentation at all. Adding testable code to the equation and you’re definitely on the right track.

For those of you out there that interview people – if you think this is it and you finally found someone – let him\her solve a few problems and focus about how simple is it to read the code, to refactor it, to extend it. How much documentation is required to explain the solution to the rest of your team?

What do you look for when interviewing skilled developers?