Wednesday, April 23, 2014

On Interviewing Candidates for a Job

I am going to write a little about my experience and conclusions so far around interviewing a candidate for a software developer position or for a quant position, but it should be quite general.

At first, I used to ask interview questions I liked when I was myself a candidate. On the technical side, it would stuff like:
  • which design patterns do you know?
  • what's your opinion on design patterns?
  • what's a virtual method?
  • any interesting algorithm you like?
  • which libraries did you use?
For a quant type I'd ask more specific questions
  • what's a Brownian motion?
  • what's the Stratanovitch integral?
  • why do we use the Ito integral in finance?
  • questions on numerical methods: Monte-Carlo and finite differences.
  • questions on financial details. 
I found the approach mostly frustrating: very few people would give interesting (or even good) answers, because most people are not that well prepared for the interview. The exception goes to the academic kind of guy, who usually gives excellent answers, sometimes so good that you feel dumb asking those questions.

People who don't give good answers could actually be good coworkers. When I was junior, I was particularly bad at job interviews. I did not necessarily know object orienting concepts that well, even if I started programming at an early age. After a few years, I did not know database theory well either because I had experience only with simple queries, having mostly worked on other stuff. A failed interview made me look more closely at the subject, and it turns out that you can sound like an expert after reading only 1 relatively short book (and the theory is actually quite interesting). I went later to the extreme of complex queries, and then realized why ORMs are truely important. Similarly when I first interviewed for the "finance" industry, I sounded very dumb, barely knowing what options were. It's natural to make mistakes, and to not know much. I learnt all that through various mentor coworkers who indirectly encouraged me with their enthusiasm to read the right stuff. What's valuable is the ability to learn, and maybe, when you are very experienced, your past experiences (which might not match at all the interviewer knowledge).

Similarly, I sometimes appeared extremely good to interviewers, because it turned out I had practiced similar tests as their own out of curiosity not much time before the interview.

There is also a nasty aspect on asking precise pre-formatted technical questions, you will tend to think that everybody is dumb because they can't answer those basic questions you know so well, turning you into an arrogant asshole.

I also tried asking probability puzzles (requiring only basic maths knowledge). This gave even less clues towards the candidates in general, except for the exceptional one, where, again you feel a bit dumb for asking those.

In the end, I noticed that the most interesting part of the interview was to discuss a subject the candidate knew well, with the idea of trying to extract knowledge from the candidate, to learn something from him.

I believe this is might be what the interview should only be about. Furthermore, you don't feel like you are losing your time with such an approach.

No comments :

Post a Comment