I’ve recently come across a blog I should have been reading years ago, however this is putting me off. It’s not that I mind seeing reality, but this is car-crash reality, like you’re about to jump into the abyss and can’t stop.
It does reflect an interesting state of affairs. When I’ve been in the position of hiring, I’ve often wondered how to ask people the right questions to get the most out of them and to see how they solve problems. For me a good programmer is not necessarily someone who knows the API down to the bytecode (we have API docs for that…), but one who can adapt quickly to different situations and bring some creativity to solving problems, but yet can know when (s)he’s re-inventing the wheel.
Even if I manage to figure this out, I’ve also set some coding tests to see if they understand what they say they do. The results are… weak 😦
I’m not sure I want to see code samples either, most often then not you can’t bring in anything that you wrote for someone else (copyright) or it’s been copied from whatever book of best practice is in vogue. The best plan is probably a week of working with the team they will be part of, but that is not always allowed by the local employment laws.
If you can do it, it will show up a whole bunch of things, including the interaction with others, that 50% (or more) of the job that is in soft skills. It’s also worth asking what you want the programmer to do. On the one hand it’s obvious, on the other hand they will need to learn the local processes: code release, formatting, house style, debugging tools etc. Do they need to learn a new language, or part of one, are they familiar with the system or do they need to adapt to it ? How many people would like to be able to say, yes, they code, they get a good 3-4 hour stint just coding ?
Will I be implementing the FizzBuzz test ? Maybe. Until there is a better way to figure out if someone can do the job, it’ll be a tool in the assessment.
Sonique – It Feels So Good (Hear My Cry)