Q&A: Quantitative Analyst - Machine Learning, Analytics, & Quantitative Research/Investing
Background:
- Graduate student pursuing a Masters of Science in Applied Data Science with focus on quantitative investing
- Background in data analytics as it relates to investment research, investment management, and credit risk management
- Previously, worked on quantitative initiatives for a global investment management firm
- Spent three years on the Risk Analytics Team at BB
- Reviewed resumes for potential hires at previous employers and served as a resume/cover letter coach at university of attendance
- Graduated with a BA in Mathematics
Happy to answer any questions, especially those regarding machine learning/statistical methods, the types of systems investment managers/banks are using for quantitative initiatives, skills employers are looking for in tech-related hires, and how to tailor your resume to sell your abilities and background.
WSO Mentor
Want to work with me? Check out my profile here
It just so happens that I received my undergraduate mathematics degree from a liberal arts institution. I think a liberal arts education is great for training students to be well rounded with the ability to learn diverse material in diverse settings. Though it still seems as if big feeder universities give you more "cred" in terms of landing yourself a job in AM, I think the trend is slowly improving and students from smaller liberal arts colleges are having more and more success landing these types of roles. Hopefully this unfortunate trend is just a Boomer thing and will continue to improve over the years. If you can show an employer that you are eager to learn and are interested in the quantitative side of things, then I think you should have a good shot. Maybe teach yourself how to code in python - there are free courses and tutorials all over the internet. If you can do this and then use the language to make processes/analyses more efficient then you are taking the first steps at proving you A: have the drive, and B: have the ability.
While short-term data science/coding boot camps do exist, I have found that the majority of employers (in investing/finance) are looking to hire candidates into quant roles who have at least a masters or PhD in Data Science, Computer Science, Statistics, or another related STEM field. To be a true quant, you really need to have the graduate degree.
This is a very broad question. It's difficult to give a targeted answer because different firms have very different roles for quants. Instead, let me give you three challenges or pitfalls that tech-industry data scientists run into in trying to move into the financial space.
They aren't strong production coders. This can mean: * Their code is simply sloppy. Poor variable names, inconsistent style, hidden side effects, cannot write code that runs end-to-end without help. * Not enough, or too much, abstraction. Their code is either a massive script, or their control flow ends up being fifteen function calls deep. * No ability to quickly debug errors. * No ability to reason about performance. This is everything from avoiding asymptotically stupid algorithms to knowing how to push numeric computation into vectorized code to avoiding needless typecasts. This is also about knowing when each component is a potential bottleneck, versus when it's a premature optimization. * Code is difficult to test because concerns are not separated. I've very much gravitated toward a Haskell-style approach of pushing all I/O and stateful computation as high into the call stack as possible, with all lower functions being stateless. * Comments are missing in the places you'd expect them, but present in useless places. Specifically, this is when people leave a "get momentum exposure data" next to their "get_factor_exposures('momentum')" call, but don't leave any comments about why they dropped the last row and multiplied the second-to-last row by 1.2.
They gravitate towards complex statistical models. The biggest difference between data science in tech and data science in finance is that you have substantially more training data in tech than finance, so you can throw more sophisticated models at the problem. This is true in both n (amount of data) and p (number of features). Reasons for this range from the datasets you use only have several years of time series history, to the process you're modeling only having a handful of Y points to model (for example, if modeling US unemployment, that number is only disclosed once a month). You can't run experiments on user behavior and get quick results back.
What I've seen work in my little part of the world is very simple models applied thoughtfully with domain knowledge sprinkled in.
(This, of course, does not apply as strongly if doing higher-frequency quant, such as HFT or intraday stat arb, or if running stuff like NLP algorithms.)
They don't look at their data. I spend much, much more time poking at and exploring data than I do making a statistical model. I want a deep understanding of what my dataset actually contains. This is useful because it drives your immediate decision-making about how to set up your model, and it lets you rapidly debug why a model may have a problem.
Concretely, I've seen a lot of the "throw sklearn at the problem" crowd really struggle to debug why their models make poor predictions. I think a large part of this is because the classroom emphasizes focus on p-values and error metrics, and a lot of tech industry problems fit into this mental model as well (i.e. our checkout flow used to have 15% churn and now it has 11% churn, measured across several million events). In finance, or at least the problems I work on, every single misprediction matters. If my PM wants me to predict the number of Roku devices sold next quarter, and I'm off, I can't chalk that up to expected model error. I have to get my hands dirty in the datasets I used and figure out what happened. On the quant side, if you're building a Bayesian model to dynamically weight different betting strategies, you'd better be able to explain why your model got it wrong when you rotate into a strategy that starts drawing down.
What's the theme here? In my experience, these all matter because you need to generate conviction in your results. This is different to do in finance than tech because: 1. Finance moves faster and runs leaner than tech, so you need to be correct quicker. 2. You usually have less training data, so the odds of overfitting are higher and the length of backtest you can run is lower. As a result, you need a stronger prior in your model. 3. Culturally, you can't fail fast the way you can in tech (no real A/B testing, LPs don't like to lose money, etc.). 4. You are often presenting work to stakeholders that are non-technical but that have strong intuition. Therefore, you need stronger fundamental convictions in your work.
When I interview job candidates from tech data science roles, these are the three weak spots I tend to see. Frankly, it seems like a lot of people in the tech space care about process over output. They'd rather talk about their random forest model than actually make money for their firm. I think that's the way I'd ultimately summarize the challenge of the transition: you have to be able to prove to your interviewers that your work can make money for the firm and its investor base. And in my limited experience, the pitfalls I've listed are what can get in the way of that.