We interviewed someone face to face today.
That little nugget of info is not so uncommon that I'm compelled to blog about it ... we currently hold about three or so face to face interviews a week.
The coder looks good on paper ... twelve years coding, the last three years hands on C# - and self rated at 7 through 9.5 out of 10 for technical skills.
Our first icebreaker exam question is designed to settle the candidate's nerves by being nice and simple. It's a property. “Tell us about it” I ask.
This guy proceeds to tell us in no uncertain terms that our three line code snippet was plain bad coding. I was intrigued, so I gave him the keyboard.
The keyboard I use for the interviews is a weird wireless Microsoft one. It has a super sized delete key that invades the space where the Insert key should be, and has the added bonus of weird key spacing. It's pretty horrible really, unless you are forewarned and expecting it, or have one just like it at home. I'm just starting to get used to it. It's taken me close to a year. The really great coders we interview never seem to have much trouble with it.
Well he starts fumbling away and out it comes – I recognise three different languages and some new form of pseudo code. There's not one identifiable C# keyword (admittedly there is a semicolon that is in the right place). It's a mashup of sorts. It's not Web 2.0. It's not the sort to get you hired as a senior coder. Well, certainly not for a C# role. Well, not _this_ C# role.
Terminating the interview within five minutes is unfortunately far from uncommon. Lots of coders with brilliant CVs bomb out on the warm up questions – questions even those cramming C# for dummies while sucking on Red Bull the night before should get right.
The reason for this is that lots of coders lie through their teeth on their CVs. There must be a reason – and I know that someone's been rewarding these time thieves with a job somewhere along the line.
For both your and the common good, you should never, ever interview candidates without the aid of a standardised exam that allows you to compare previous answers to gauge exactly where this candidate fits on the totem pole. This applies to every type of candidate I have helped to hire - accountants, office managers, junior network engineers etc. You Need An Exam.
This exam should be pitched for the corner cases. It needs to be interactive – rather than having them fill out the answers and then you marking it, you need to be there, listening and prompting them for more clarity. It should be as close to real world as possible.
The test results should be:
The really bad candidates should fall out immediately.
The OK ones should be guided swiftly though to the end; and
The really really seriously talented coders should make the exam so much fun you miss dinner with the kids.
The exam should be first cab off the rank - no time wasting chit chat or bonding before hand (you can do this if they are a good match) – my order of proceedings is offer freshly ground coffee, tea or iced water, remind them that they were warned about the tough exam, then hand it to them and provide instructions on how to navigate it.
This way they get to show us just how good they are. All the guys we have hired since I started at MaxSoft have gone through this exam, and _all_ of them loved it. For the right person, it's a blast ... a bunch of techie guys rabbiting on about code and objects and heaps and more code stuff. I learn a lot from these interviews, and am sometimes amazed at just how smart and quick and good some coders actually are.
I've gotten about three more pages on the cutting floor that I'm going to turn into more articles over the next few days. Here's some ideas I have:
Why I created this exam, and how it has morphed
My four step interview process
Some bizarre personality types I have interviewed
No comments:
Post a Comment