Hacker News Reader

Comment by Syzygies | Hacker News Reader

I interviewed a full day at a mathematical hedge fund. Not exactly brainteasers, rather a barrage of good, solid math and stats questions. Such a day is exhilarating (like skiing the Olympics) but truly exhausting, and only partially related to whether one gets an offer.

My advice to anyone doing this would be to give up the last 10% of performance in order to focus some on contextual awareness. These puzzles are a form of pre-surgical anesthesia, before they ask the real questions. You need the spare cycles at the end of a long day to imagine what casual conversation might really be exploring, how other applicants might misread the subtext, what mistakes in previous hiring they're trying not to repeat. One could be a genius trained seal, by buying into the brainteaser game, and miss the broader question of how you will fit into their firm. One who sees broader contexts ends up running places; don't make it clear that's not you.

View on HN

Would you say the questions that fund asked you are relevant to the work you do (or would be doing) there? I think that's the core criticism most people levy against the "high tech" interview questions.

People that don't get the offer tend to complain about such things. They are asking questions to measure how you think, to measure your potential, to see how you handle stress. If you are stressing over an interview, what will you do when you lose $1 million in 10 seconds?

Yes, people who get the job are less likely to complain about the process. I don't see that that vindicates the way it was performed.

If you are stressing over an interview, what will you do when you lose $1 million in 10 seconds?

Beats me - but the "skills" demonstrated in the interview process you're defending -- "suck up; just keep going online until you memorize enough canned answers to most of these dang questions; suck up, suck up, suck up" -- certainly aren't going to help.

If anything, they're basically orthogonal to the set of competencies needed to deal with that kind of a situation.

Right. People who don't think of Comp Sci knowledge as a set of substantive first principles, just as meaningless tokens they need to memorize and regurgitate to get the job -- those are precisely the people who should be weeded out. Each one of those questions is not merely a chance to "collect" an arbitrary thing. It's also an opportunity to practice applying basic knowledge and techniques.

If anything, they're basically orthogonal to the set of competencies needed to deal with that kind of a situation.

You may well need to spot a deadlock or a race condition in code. You may well need to spot code that is inefficient by construction, in precisely that kind of situation.

People who don't think of Comp Sci knowledge as a set of substantive first principles, just as meaningless tokens they need to memorize and regurgitate to get the job -- those are precisely the people who should be weeded out.

And yet - those are the people who are not weeded out, but selected for by the default interview process.

Certainly, there are lots of problems with interviews.

That said, the interview should be designed to specifically weed out the ones who hope to pass by regurgitation. The answer can't be just a pattern match for a particular algorithm. The emphasis shouldn't be on dazzling recall of something obscure. The purpose should be to look for actual experience implementing something.

You may well need to spot a deadlock or a race condition in code.

The thing is - if your production system really ends up going haywire and losing $10 million every second or whatever, then then the root cause isn't some race condition. It's the whole human and organizational process (or lack thereof) that allowed that defect to slip in undetected (and in a position to cause so much damage without proper safeguards) in the first place.

> You may well need to spot a deadlock or a race condition in code. You may well need to spot code that is inefficient by construction, in precisely that kind of situation.

How is that relevant to the practice of "memorizing enough canned answers to most of these dang questions"?

How is that relevant to the practice of "memorizing enough canned answers to most of these dang questions"?

It's not. Instead, ask something not particular tricky, a bit open ended, and just a little bit involved (at least 3 things interacting) with the purpose of seeing if basic skills can be applied. Instead of looking for an answer that can be memorized, you're looking for evidence to see if people have actually designed, implemented, and debugged something at a level beyond gluing libraries together.

Sure I get the gist, I've heard this reasoning quite a lot and I'm not condoning or condemning it. I was specifically interested in hearing if the OP thought the math they asked him about was relevant to the math actually done on the job. In my experience, it isn't really (except insofar as it might be the same field, from a 30,000 foot view).

I think it's more about measuring enthusiasm for problem solving. If you sulk and roll your eyes at a difficult math problem, what will your demeanor be like every day in the office when your job involves quant analysis?

I'm suspicious of any practice whose proponents offer multiple, incompatible rationales.

That answer doesn't really hold up because the people coding the system aren't the ones doing the trading, and most jobs that use similar "stressful" interviews don't have anything like that anyways.

that doesn't justify asking questions that are extremely poor predictors of work performance

> They are asking questions [...] to see how you handle stress.

I've got a time-saving suggestion - instead of asking questions, measure how long interviewee holds up while being waterboarded. If they can handle that stress, they can handle losing $100 million in 10 seconds, easy.

What was the contextual awareness here? Are you just talking about personality and cultural fit or is there something more? You’ve had a go at this but I’m looking for a concrete example.

where did you find examples to practice - im horrible at these types of questions but would like to get better.

Depending on the hedge fund (I'm thinking of a few in particular), there isn't really a route to practicing these problems just to get better at the interview. You'll be asked to talk about your own research in the domain and you'll work on re-deriving (very small parts of) the research of other members of the team with guidance and from first principles. Regardless of applicability to the job, if you're asked to prove a theorem on the board you either know it (and have known it for a while, and in depth), or you don't. In that sense they're not brainteasers to practice a particular formula for, like solving an algorithms question or probability estimation.

That being said if you're just talking about mathematics and statistics problems the more mainstream hedge funds like to ask their quant candidates, read Crack's Heard on the Street, Joshi-Denson-Downes' Quant Job Interview Questions and Answers, and Zhou's A Practical Guide to Quantitative Finance Interviews.

thanks

Reply on news.ycombinator.com