I started writing this post about two months ago when graduation ceremonies were in full steam and cohorts of newly minted financial mathematics gurus were getting braced to join an army of candidates to junior quant positions. Little did they (and I) know of the future fruits of the summer: credit crisis, astronomical losses and massive downsizing across the financial industry and, most importantly (for them) universal failures of mathematical modes to, well, model. Anyway, if somebody is still hiring, this short note, I hope, would be of some use. Here we go…
Nowadays there are dozens of guides (paper and online) telling you what to expect in the interview, how to prepare, what to wear etc. In other words they are all written from an interviewee’s standpoint. Reading almost any of them will result in two sure results – 1) the jobseeker will get nervous to the point of breakdown of thinking (s)he does not know anything and 2) the quant interviewers are jerks drawing sadistic pleasure from a candidate’s sweating at unsolvable brainteasers and calculus tricks which are only remembered by undergraduate students the night before an exam. I was surprised to find out that usually there is nothing available to those who need to interview somebody other than a frayed printout of abovementioned brainteasers and some forum postings made by (un)lucky candidates who failed a particularly mean question in a recent interview.
So here is something for the other side of the game.
There are generally two kinds of people applying for junior quant jobs. First kind is fresh graduates of PhD or full-time financial
mathematics MS (full time is crucial here) programs. The second type is people with real life job experience who decided to change careers and/or have been unsatisfied in their current jobs. Most of them come from the same financial math programs which they did part-time. Here are their relative strengths and weaknesses.
Fresh graduates
This folk is supposed to have very sharp knowledge of the theory. Analysis, PDEs, stochastic calculus, they are walking encyclopedias of graduate mathematics. Don’t expect them to be able to match a theoretical model to practical problem though. They can derive anything from Black Scholes to BGM, but often unable to see what the actual problem requires. They also tend to propose the most complicated model known to them from textbooks. Don’t expect them to be decent programmers as well. The academic environment doesn’t teach robust software development and usually puts emphasis on correctness of the results given very limited ranges of artificial (or real but carefully prepared by instructor) data.
People with experience
Those are a very diverse crowd as they come from radically different jobs from pure finance to pure IT. All things equal, they are usually much much better at coming up with time saving trade-offs and shortcuts in modeling but can be somewhat rusty on the math. The latter should not outweigh the experience though as long as they can quickly locate the answer. Depending on background, you can find exceptional programmers among them.
Naturally the two groups need to be dealt with quite differently and you might want to decide upfront whether the position’s requirements eliminate one of the groups altogether. E.g. admit to yourself if you just want an assistant for boring stuff you don’t want to do yourself and to share your wisdom with or you need a more or less independent member of the team.
Just like in hypothesis testing there are two kinds of errors that can be made: you hire somebody who is not suitable for the job or you decide to reject a person who would turn out to be perfect candidate. Let us see how easy to make either of those errors asking usual interview questions.
Resume questions
First questions tend to be related to the resume – those are the easiest to come up with. People with experience should be able to tell you about their previous jobs but fresh graduates have not much to talk about in that department. They are normally asked about their classes and what they have learned. The real goal here is to determine whether there are any embellishments in the resume. Now to the errors. Normally it is very easy to determine if there is much more stuff in a resume than the person in question is actually skilled at so making this type of error has relatively low probability. On the other hand it is also easy to write off as unqualified somebody who did not include some of his valuable (for you) skills in the resume. Either they are too modest and do not think that the skills are that valuable and/or rare or they are from those perfectionists who does not consider themselves entitled to state in the resume anything that they are not 100% confident at. They are direct opposites of the people whose resumes are direct copies of their financial math curriculums. My preferred way to conduct a quant interview (see below) allows to deal with both.
After looking at what I have written so far I decided I should put the remaining material to the follow-up. In the next posting(s) I will tackle two other common types of interview questions – brainteasers and “technical questions”, and propose what I think is a very productive way to interview for junior (or not so junior) quantitative jobs.
Posted by improbabilist 