Least programming-heavy quant career?

[Zeuge]

Which quant career would have me spending the least time writing code? Are most entry-level quant jobs (define "quant" in any way you like) very coding-heavy, or are there other paths?

 

[Yike Lu]

I don't think this is the attitude you should be taking. The datasets quants work with are typically huge and can be very heterogeneous. To get any traction on that type of data, you need to know some programming.

That said, research and trading roles typically require less low-level dev.

 

[Zeuge]

I am adept at programming, having been a CS major early in my undergrad before switching to econ/math. Despite doing well in my CS courses, and enjoying the more theoretical aspects, I did not enjoy putting in 10+ hours into each tedious programming project.

 

[Daniel Duffy]

I am adept at programming, having been a CS major early in my undergrad before switching to econ/math. Despite doing well in my CS courses, and enjoying the more theoretical aspects, I did not enjoy putting in 10+ hours into each tedious programming project.

I think the days of pen-and-paper quants disappeared a long time ago. I would think very hard about these issues because some rude shocks/awakenings are on the way down the line.

 

[Andy Nguyen]

A lot of "quant" jobs involve tedious task such as cleaning millions row of data daily. Nobody wants to be that guy but its importance is just like gasoline to cars. If you don't like programming, what do you like and what are you better than other people? When you can articulate that, it will be easier for people to point to some specific direction.

 

[Yike Lu]

A lot of "quant" jobs involve tedious task such as cleaning millions row of data daily. Nobody wants to be that guy but its importance is just like gasoline to cars.

Nobody wants to be that guy, but everybody is that guy to some extent. It's rather rare that a quant can manage to avoid cleaning data.

As far as programming, some flavors are more palatable than others.

 

[DominiConnor]

Yike and Andy are right, as a quant headhunter I'd start by asking you to take some time and ask yourself whether this line of work is for you. A couple of people I've known discovered that (like me) they cannot stand sick people, an unfortunate characteristic for a doctor who has spent years of his life in training...

To quote Peter Jaeckel, programming is how we turn mathematics into money and making money is what banks are for (yes I do know that recently that hasn't been the case but they are at least trying).

There are few jobs with little programming. There exist a subset of jobs in risk and model validation where one is basically using programs rather than writing them. Even though some jobs don't involve it much very few of these are at entry level.

So rather than kid you that this line of work is promising for you, I'll offer some constructive advice:

Many people receive poor education in programming, sometimes really awful, enough to put them off, so if you are still determined to become a quant I'd take a good programming course, doesn't matter what language.

 

[Zeuge]

I understand that programming knowledge is necessary in the field, and I am confident that I am/would be capable of handling various programming challenges, especially in entry-level positions. However, I'd very much prefer to work on the model-building side, and I'd like to know what kinds of positions are available after working for a few years in more programming-oriented positions.

 

[bigbadwolf]

I understand that programming knowledge is necessary in the field, ...

On a side note, no-one ever talks about how to acquire programming competence. What does it mean? What should one be able to do? Which books? Which topics? What things in C++, for example, are necessary? Function pointers? Class templates? Mastery of the STL? Chunks of the book Numerical Recipes? Chunks of the book Algorithms in C++?

 

[Yike Lu]

Programming competence is a thorny issue because it's more art than science. See Paul Graham: http://www.paulgraham.com/hp.html

As with any art, this means experience is the only way to get good (but at the same time, experience doesn't guarantee that you're good). The basic concepts are few, but their combinations infinite.

Re: model-building jobs, yes they do exist. However, the most recent industry trend has been away from exotic derivatives, where it's most likely you'd find heavy math/modeling. Everywhere else, you will have to use code to explore the data and come up with a model that way.

Zeuge, the thing is that none of us know what exactly you are trying to guard against. Just because a job is coding intensive doesn't mean it's a developer job. For example, my job requires me to code every day, but it is definitely not a developer job. About 20% of the time I need to act as a developer, the other 80% involves figuring out the right questions to ask, posing those questions properly as code, and then interpreting the results.

"Posing the questions as code" qualifies as programming, but it is not software dev.

 

[bigbadwolf]

Programming competence is a thorny issue because it's more art than science. See Paul Graham: http://www.paulgraham.com/hp.html

As with any art, this means experience is the only way to get good (but at the same time, experience doesn't guarantee that you're good). The basic concepts are few, but their combinations infinite.

For some time I've felt there's a pressing need for some title analogous to Dan Stefanica's A Primer for the Math of Financial Engineering -- maybe something like C++ for the Aspiring Quant. Like Stefanica's book, it should be oriented towards those who already know some C++ but want to see the way it gets used in quant. There are some good books out there -- for example Clewlow and Strickland's Implementing Derivatives Models -- but nothing that I know of along the lines above. I like Joshi's book as well (C++ Design Patterns and Derivatives Pricing), but for pedagogic purposes something a bit more discursive is what I had in mind, which reviews some of the more advanced C++ ideas.

 

[Yike Lu]

I personally think a programming book for quants that covered C++ only would be incomplete.

This is probably how I would lay it out myself:
1) C programming. Memory management, pointers, all the low level constructs you need to write blazing fast code.
2) C++. Object-oriented features, templates. Standard interview material.
3) SQL. This is extremely important as a vehicle for shaping data.
4) bash scripting. Very useful when you just need to hack something together.
5) Python. Something high level to demonstrate the power of abstractions. Leaning towards Python because of its popularity.
6) Crash course in LISP to demonstrate some of its more powerful language features.
7) Foreign language interfacing. Combining speed and expressive power.
8) Quant libraries/analysis languages (selected packages in Python, overview of R and Matlab).

Not that I'm fully familiar with all of these things, but I have enough knowledge of each to realize the benefits.

 

[bigbadwolf]

1) C programming. Memory management, pointers, all the low level constructs you need to write blazing fast code.

One book I like for this is Franek's Memory as a Programming Concept in C and C++.

 

[DominiConnor]

BBW, I feel embarassed that since I am the one around here who is loudest about programming skills, I've been loose about how you actually acquire them. Yike enumerates goals, so I would like to offer advice on how to get them.

0: programming is an imperative craft, you are doing something to a computer, not vice versa, anyone attending a CQF info session with me learns that is my philosophy.

1: Adopt the discipline of counting from zero.

2: Adopt the habit of counting how many things are in intervals that you encounter in everyday life. A good % of all programming errors come from not counting things properly, more generally the "out by one" error.

3: Program things that don't need programming. Excel will import a variety of formats, but can get really confused if (say) you import data that may have commas in it, which breaks up CSV files. Automate your application process for applying for internships, write a macro to spot the fact that you over-use certain words in text . The point here is that many get bogged down in trying to get a computer to do something that they don't really know how to do themselves. Start with things where you have a complete analysis of the task already because its something you now do manually.

4: Program something that should not be programmed. There are any number of proprietary data formats out there, applications that are "sealed" and not intended to be automated and/or apps that very nearly do what you want.

5: Program things in ways that are unnecessarily hard. For instance I once wrote a spell checker that didn't have a dictionary...
I used a mix of Markov chains and hash tables, because I could .

6: Write programs that generate programs. This is both useful and instructive. A system I had to get data into had errors in the input which the system diagnosed as "Bad file", awkward when there was very large number of ticks in the data set and there was no description of what it did accept and I had no control over the data being generate in the first place. So I wrote bit of code that turned each line of data into 3 inputs for the API interface, and compiled it into a big C++ program. You have no idea how cool the team that got this really quite shit bit of code thought this was.
Code generation makes you think about syntax in a different way.

7: Write generic code even when you don't need to. You're a student, the task is not to finish the assignment, but to learn from it. In real life you might write code that barely works once and is then thrown away, but the skill of generic code development will be useful for code you want to reuse.

8: Debug other people's code. In real life that will be part of your job and is a major aspect of many interviews. If you don't have access to other people's code take sample programs on thew web and make them better. Doesn't matter how you define better, you want to be a better programmer and a better programmer is someone who programs better. Add error checking, find out the cases the sample code can't cope with and add them. Make it faster.

9: Argue with other programmers. Is the memory management in Linux more sophisticated than in Linux ? Can you defend that ?

10. Find insanely brute force methods to solve problems. By this point you must have a whole pack of optimisation methods. Great.
But often in the real world there will be constraints that make them really slow, also brute force is a good way of checking you're right, a trillion goes round a loop is not always unacceptable.

11: Try to code in a different language from the one you're being taught. The more different the better. For most here that doesn't mean C++ or Java it means Haskell or F#. Why ?
Because they are different ways of addressing a problem and a serious programmer thinks in a richer set of ideas and models than those his language accepts as code. Excel VBA doesn't have sets, it's really quite hard to get C++ programs to modify themselves but having these ideas makes you a superior programer. Write number crunching routines in SQL, no reason, except one day you will need to.

12: Adopt the habit of looking at every single thing that you see as some sort of defective computer that you personally can make better.
Nowadays lots of things have chips in them, could you do better ?
A train sign tells you how long until the next train, how does that work ? Could it be better ? What does "better" mean ? Does "better" mean true, or one that makes customers less pissed at waiting ? The thermodynamics you learned should tell you some sort of relationship between the temperature of water and rate of transfer of heat in your kettle, could a chip in the kettle make it more efficient ? My posts on Quantnet really piss you off, can you find a way of hacking Javascript so that you never see them ?

13: There are any number of algorithmic brainteasers on the Web, regard any that you can't do as personal failures.

 

[bigbadwolf]

BBW, I feel embarassed that since I am the one around here who is loudest about programming skills, I've been loose about how you actually acquire them. Yike enumerates goals, so I would like to offer advice on how to get them ...

I'm not quibbling with anything you've written (I'm not competent to do so in any case). Yet much of what you've written appears to be "meta-principles" -- which are high-level insights for those who already have a degree of mastery. There are analogous high-level insights in mathematics, for example: 1) Look a the interplay between local and global (a key organising insight in algebraic number theory, algebraic topology, and differential geometry), 2) Look at representations of an algebraic object on sets, on vectors spaces, on other algebraic objects, 3) Try to extract properties via the analytic continuation of a meromorphic function (a key organising insight in analytic number theory, modular forms, and elliptic curves, as well as combinatorics, 4) Look at duality. There are hordes of other such insights -- but they only make sense to those who already have a good grasp of the subject matter. They're empty abstractions to everyone else, if not entirely devoid of meaning. The issue seems to be of explicating subject matter initially.

In terms of books and ideas what would you suggest to those who are relative neophytes? Working through Shen's Algorithms and Programming? Reading Harel's Algorithmics? For functional programming and F#, where to start, what to look for? Start with Petricek's Real-World Functional Programming? And how to weld all this into a coherent body of study? For instance, if someone is interested in learning about differential geometry, I can explain in detail what needs to be done -- what concepts in calculus and what concepts in linear algebra are necessary before one can even start looking at the curvature of plane and space curves, and the curvature of surfaces.

 

[Daniel Duffy]

The module VI of the Quantnet C++ Programming for FE course is similar to the Clewlow-Strickland style (theory, algo, C++ code).