Now that I’ve moved to a new team, the old team needs someone to replace me. I spent most of this morning interviewing candidates for the job.

The main requirements are reasonable knowledge of finance and financial markets, and good knowledge of Excel VBA and SAS. We’re prepared to (and will probably have to) relax this somewhat and just pick the person who’s closest. I had hoped to find someone better than myself, but it looks like the combination of skills we’re after is a rare one.

The applicants (four of them) have been a mixed lot. Interestingly, three out of the four where Australians. Looks like this is the thing for young Aussies to do: get an education, then travel a while, then spend a couple of years in London. (Our newly-hired team assistant is also Australian.)

Most interestingly, several of the CVs were factually correct but in reality misleading. Two out of four listed both SAS and Excel VBA prominently on their CVs, but when questioned about their experience admitted that they haven’t used them for years, and when asked to demonstrate their skills, they could barely manage the basics, if that. A third one hadn’t done any SAS work but Excel VBA was among the first-listed of his technical skills, and he supposedly had a programming background including C++, yet he struggled hard with questions that required him to write pseudocode for a simple problem.

I think it is almost impossible to evaluate someone’s coding skills without letting them actually write code. Almost anyone can make their past projects sound important, and present themselves as being central to the projects’ success. But when I ask them to actually do something, I can see what they’re really able to do.

Sample Excel problem: return the name associated with the highest value in a list. One candidate’s solution: hard-coded link to the cell with relevant name. Hopeless.
Sample coding problem: create a checkerboard pattern, with alternating black and white cells (or alternating 0s and 1s). Those who knew (or claimed to know) VBA got to write VBA code, others could write pseudocode or use any other language they liked. Only two got anywhere near a working solution.

(That last one I actually “stole” from one of my own interviews, when I was looking around for a developer job a month ago. I think it’s an excellent question because all it really requires is logical thinking, and you could write many variations on the basic theme.)

And what can one say about a candidate who, when interviewed about his financial knowledge, says that his real background is in programming so that’s his strong side, and when interviewed about his programming knowledge, points out that his recent jobs have all been finance-oriented, so that’s what he’s better at.

On the positive side, one of the candidates actually had a honest CV that reflected his skills, and was able to demonstrate those skills in practice. He doesn’t know any SAS, but if we could learn it then surely so can he. And he appeared to have a solid foundation – good coding habits, clean code, sensibly commented. (He actually brought printouts of his code to the interview, which definitely worked in his favour.) I’d rather hire someone with good habits and let them learn the language, than someone who knows the language but produces messy code. Unless we suddenly get a last-minute application, looks like he’s got the job.