Q&A: From Pizza Delivery to Quantitative Research/Data Science/Programming
What is going on, everybody? I have been a lurker on WSO for a while and thought I would share a story with you. Here goes nothing... I worked full-time and went to school full-time pretty much all throughout school. Knowing I didn't want to deliver pizza for the rest of my life, I worked overclock for about 6 months as an unpaid intern at a private wealth management firm. That opened up a couple paid internships, which led to some full-time positions. Seems like a lifetime ago......a few steps later, I am now working a dream job on a trading floor doing quantitative research/data science/programming/automation. I taught myself how to program (varying proficiency in 5 languages), and have an undergrad degree from a "non-target". I would be remiss not to give a very special shout out to WSO's resume service. I never realized how bad in-shape my resume was until a trained eye looked at it. The quality of feedback I received was thorough and actionable. I can safely say that it was a big help for me getting my foot in the door from out of the industry. I know that for some of you in school/recent grads, $200 is a lot. I would still recommend the service; anecdotally, the ROI for me was substantial. Worth it. Q&A about my experience w/ WSO's resume service, if you have any programming, interviewing, recruiting questions, whatever. Cheers..
Can you describe the intermediate steps that led to your current position? And since this is a dream job, what do things look like in the medium-run, planning to stay the course/move up in your current group or is there another goal?
Currently, I have no strong desire to move out of credit risk as I really enjoy it and think it's a good fit for me. At the same time, I always like to hear other people's stories about how they got to where they are in the quant space.
At its core, programming was the catalyst. As my skill sets developed, the types of professional roles I became eligible for morphed.
It all began by first learning which tools were most commonly used and learned them. Programming has a very low barrier to entry - anybody can become proficient with a computer and internet access. I would spend weekends watching tutorials, building cool stuff, etc.
For me, I first became interested in programming after learning VBA; it turned into a mechanism for me to increase productivity. This led to an interest in SQL, because the quality of any type of analysis is directly influenced by the quality of data available. After learning rudimentary SQL commands, I became more acclimated with how data is generated, the roles DBAs play, improving schema, etc. Improving the quality of analysis was supported by learning Python and R, which then led to an interest in other toolsets like C++and .NET to implement full stacks. Learning R, in particular, led to an interest in statistics, which compliments my current role.
Regarding next steps, I plan to stay course and move up in my current group. More client interactions, etc... At this point, I don't have interest making moves...despite the increase in recruiting offers!
Was the pizza shop a BB or more of a regional/local player?
A highly prestigious shop consistently ranked in the league tables for most chicken wing deals and italian sausage acquisitions.
Curious about the software side here:
-As a researcher, do you make a conscious effort to have clear, maintainable code or are you cool with just throwing down spaghetti code to get results as quick out the door as you can? Is the programming you do mainly for yourself or for others as well?
-Do you use tools typical software engineers would use (Git, Bash, etc.) and stuff like Agile or is the code you write for personal use? (sort of the same as the above question I guess)
-How well do you have to know your data structures/algos? Again is that mainly for the software guys while you can focus on backtesting and data and less of the execution/implementation?
-Depth vs breath in skillset - is it better to be adept across the board (scripting language, programming language, web dev, databases) or just be fluent in one or two languages?
-Is it more important for you to be fluent in the nuances of a given language (e.g. Python, C++) or to be a holistic software person (program design, modular code, etc.) in general? Guessing it's the former but you never know...
-And I guess the golden question: how good at programming do you actually need to be? Good enough to just implement your mathematical ideas or good enough to able to be a dedicated technologist if you wanted to?
Sorry for the list of questions! Just always been curious so figured I'd ask.
Some scattered thoughts here:
Being able to write maintainable code is paramount to success in the field of quant research, in my opinion. Without the ability to cleanly reproduce results, review your teammates' code for correctness, or share tools and libraries across researchers and analyses, you will be that much less confident in the correctness of a signal or strategy. Yes, this means using a proper version control system, but it also means thinking about your research environment as an engineer would.
In my experience, the world of quant is akin to death by a thousand paper cuts. Software is inherently buggy. There can be any number of mistakes, typos, and unknown edge cases floating around your firm's codebase, from signal research to portfolio generation to trade execution. And these mistakes will lower your returns in the same way that a poor transaction cost model would. Now you might not be responsible for parts of the stack that your in-house engineering team touches (most likely data ingestion, backtesting, and execution), but you'd better be damn sure that you've implemented your strategies correctly. And the best way to do this is to adopt the mindset and skillset of a software engineer.
Sure, being a strong programmer can give you more conviction in your strategies. But it can also help you move faster. Not only can you write more efficient code, but a sufficiently strong programmer will make reusable libraries for herself whenever the same function or pattern seems to be used multiple times. Doing this requires a small upfront time investment that will save you time later. And if you can move faster and safer, that's like going up and to the left on a risk-return chart---a strictly dominant move.
If you're a quant at an established firm like a Two Sigma, you definitely don't need to be a dedicated technologist. These firms have tons of engineers that are experts at their particular role. But it doesn't hurt to be one, either. And if you're at a smaller shop, it can really, really help.