u/C_with_improvement

More and more members of my community are reporting being asked to design complex systems in quant dev interviews.

This isn’t the classic “Design YouTube”, or “Design a Webcrawler”, it’s “Design a pro-rata orderbook with LMM behavior”.

And instead of just talking through it, they’re being asked to implement it with working code in a longer-than-average interview round.

Note: I’ll add this problem to getcracked.io, it was asked by IMC.

Likewise, I remember personally getting a “Design a low-latency communication protocol” by Belvedere, which I will be making a Youtube video on shortly (another community member got asked the same problem at Optiver).

This is more of a PSA than it is a post containing the educational material I usually like to share.

I am curious if you’ve been asked any notable system design questions that you’d like to share.

I'm going to be making a video that focuses on what you need to learn if you want to lean into Python for Quant.

I'm going to bring on either a Developer (who is Python focused, since I am C++ focused) or a Researcher to discuss this topic.

In the meantime, as I was brainstorming, a member of my community put together a list that I wanted to share. This member is currently working at Optiver and is a coach on getcracked.

1. my take: language is simple, learning is best via real programming need to differentiate: are we talking about learning python, or learning programming (for quant)?
   1. the former: python with experience from another language -> very easy https://learnxinyminutes.com/python/
      1. if one really wants to follow some sort of structured tutorial / course: these seem decent (havent done them, i learned by doing)
      2. https://dabeaz-course.github.io/practical-python/Notes/Contents.html
      3. https://github.com/dabeaz-course/python-mastery
      4. https://github.com/jpmorganchase/python-training
      5. for serious interviewing: need to know python internals. i have no good resources unfortunately, but a general cs education + strong curiosity should be good enough. maybe getcracked, idk.
   2. the latter: no such thing as "for quant", good programmer = good programmer. quant devs need to know more, but this is a python video things adjacent to python + quant but not "python" per se: [key: https://en.wikipedia.org/wiki/Chess_annotation_symbols]
      1. - machine learning
      2. - uni courses (theory) !
      3. - bloomberg ml course !?
      4. - kaggle !!
      5. - data analysis, polars, pandas
      6. - courses ?
      7. - projects !
   3. my top libraries: numpy / jax.numpy, pytorch / jax, polars, plotly express / altair, scipy, xgboost / lightgbm, einops, pytest, hypothesis good to know: typing, httpx, wandb/mlflow, trio, pyO3 jax ai stack: flax nnx, ml_dtypes, optax, orbax, chex, grain

You can get in contact with serious members in the space in the Discord, which is accessible when becoming a member on the platform.

I often get asked: CJ, how do I learn C++ for Quant Trading?

What is "C++ for Quant Trading" really?

C++ is a tool, and a widely used one. It's a multi-paradigm general-purpose programming language used for anything from medical devices to video games.

I've worked in Quant for 4.5 years, currently run the largest quant trading interview preparation platform, have interviewed on both sides of the table, and helped placed dozens of candidates into development roles alone. So I think I'm uniquely positioned to answer this question.

I'm going to give you the short answer, and then the long answer.

The short answer is learning C++ is learning C++ for quant trading.

What do I mean by that?

Every domain interacts with C++ differently (e.g. in embedded systems you cannot allocate memory on the heap), but regardless, experts in every domain need a strong foundation in their language of choice (their tool).

There isn't a construct in C++ that is quant-exclusive, or constructs that are worth writing off entirely.

Now, the long answer.

There are constructs and libraries that may be used in C++ more than in other industries. For example, in quantitative development, some firms choose to employ compile-time programming (TMP) more often that elsewhere, simply because the runtime cost of on-the-fly calculations may make or break a trade.

But the reason I hesitate to tell people to "look into C++20 concepts" or "practice implementing compile-time push_back" is because (i) firms don't really test for this and (ii) a strong generalist C++ developer would have already looked into these topics out of curiosity and a desire to learn more.

Likewise, while understanding alignment is important, and often gets tested in interviews, I find it difficult to tell someone to study this particularly when the question is posed since there is nothing quant-y about understanding how the C++ compiler aligns types and lays them out in memory. In other words, a C++ game dev should be just as fluent in this as a C++ quant dev.

But when someone asks How do I learn C++ for Quant Trading?, what they're really asking is 'Is there a hidden part of C++ that I must know which only you can reveal to me?', and the answer is No.

I know that isn't the answer you want to hear, but there really isn't any mysticism to it.

Become as proficient as possible in C++, and instead of asking "How do I learn C++ for quant trading?" ask yourself "How can I become a better C++ developer?".

When you're ready, the next question will come naturally: What do quant firms ask you to code up or know in interviews?

And by now, the answer is hopefully obvious (it's on getcracked.io).

I remember when I wanted to be an investment banker back in University.

I had a long beard, long hair, and definitely did not fit in with the Brads of the world.

Their parents were partners at Morgan Stanley. Mine?

Immigrants. A working father and a stay-at-home mother.

I stood no chance.

I didn't fit the mold, and didn't want to either.

So what did I do instead? I networked.

I took classes after school taught pro-bono by a former investment banking partner professor, Blair Robertson.

Guess who the class was made up of?

All immigrant brown and Asian kids looking to break into a space that their parents didn't already dominate.

Brad? Yeah, he was too busy partying to attend. He'd already secured his internship at Lazard that summer through his parents.

But passion wasn't enough. I had to intellectually mog Brad too if I wanted to stand a chance.

So I attended the National Investment Banking Competition (NIBC). It was a conference of over 30 teams from 30 schools around the world held in Toronto.

Over a three day period my team went from last to first. I spoke infront of partners from the world's top banks infront of 500 students with under 12 hours of preparation. We each won $2000 CAD, what seemed like a fortune at the time.

What came of it? Nothing. Any internships? Nope. Interviews? Nope. Phone calls? One.

>You know, it's pretty late in the recruiting cycle. You can always try next year!

Ha... Next year? Yeah, no thanks.

I'm not interested in trying to be someone else for another year.

I networked, I studied, I competed, and it wasn't enough, simply because I wasn't already connected. So how does all this relate to quantitative trading?

Quant = 1 / Investment Banking

While passion never mattered in investment banking, it mattered tremendously in quant.

While intelligence never mattered in investment banking (any monkey can build a DCF), it mattered tremendously in quant.

Networking is probably the least important in the hierarchy of needs in quantitative trading. Whereas it's a fast-path into investment banking.

Don't get me wrong, a referral is useful, especially as you become more senior. But everyone whose already in the industry has the ability to network their way into a referral. Whereas not everyone is privilaged to be born into a connected family.

But that privilage does not matter in quant. Your competance, pedigree, and ability to perform is far more important than who your father is.

Yes, no, maybe - let's talk about it.

First, let's qualify what a lie actually is.

When a company claims to offer unlimited PTO, are they lying?

In theory, yes. You can't just take PTO forever and never show up to work.

But there's an implicit understanding between the candidate and the firm that "unlimited" really means "take time off when you need it, and nobody will badger you about it." In other words, "unlimited" is a marketing ploy.

So when a candidate leaves their 2.3 GPA off their resume, are they lying? In my opinion, no. Your resume is a marketing document - a single page of digital real estate - and it's your job to present yourself in the best possible light. If they ask for your GPA, tell them the truth. But if they don't ask, why volunteer it? It'll only hurt your chances of landing the job.

But when does "lying" actually cross the line?

This is the hard part, and where you draw the line ultimately depends on your own moral convictions. There's definitely wiggle room here - after all, it's a grey zone, not a grey line. And there's a lot of room in that zone.

That said, if you fabricate information, you've officially crossed into "liar, liar, pants on fire" territory. And trust me, a large part of the quant interview is simply testing how well you know your own resume. In fact, it's the interviewer's job to drill down into the details to see whether you actually understand what you've written.

So go ahead and push the line - just don't cross it.

I filmed a video yesterday going over the Purdue CS240 drama.

In short, 70% of the class was caught dead-to-rights with regards to cheating.

That means 90% of the class cheated, but the professor was 110% sure that 70% cheated (and not-so-certain about the others).

Unfortunately for these students, most will graduate without knowing how to convert a string to an integer (manually). In fact, even before AI, 50% of students that graduated from Guelph (a Canadian university), according to my friend, couldn't do so.

What does that mean for someone grinding for quant based on first-principles?

It means that, as your colleagues are taking the quick-and-easy path, the ROI of grinding has never been higher.

Even if they cheat their way to the on-site. they won't pass the whiteboard / in-person coding round.

This should be exciting news for anyone looking to break into the space.

In fact, when I was interviewing for CTC back in the day, simple implementing a threadsafe SPSC queue with a consumption policy (non-type template parameter) had the interviewer saying "You're a breath of fresh air".

Knowing your sh*t has never been more advantageous.

I've recently seen posts from people claiming to use cheating software to cheat their way into Jane Street.

They've been shared in my community, and the stories sound believable.

I want to stress that these are most likely fake. In fact, the accounts that post them end up getting suspended a couple of hours later (Reddit is really on it).

Quant firms have several interview rounds, many of which require on-site live coding, where you don't have access to AI or other cheating software.

At my previous firm, we made the candidate go through two rounds of live coding. One where they needed to solve a problem alone, in an isolated room, where snacks and water would be delivered to them.

Another one where they had to code and debug live with the Head of Engineering, and one other developer. They had to walk through their reasoning and defend the choices they made.

I've had interviews where I needed to code on a whiteboard, and even on paper. Yes, on paper!

Quant firms don't play, and if they're going to pay you total compensation (TC) of upwards of 300K, you better come correct; they'll make sure of it.

A member of my community shared this reddit post from r/cpp_questions.

It's a user who is shocked and bewildered that HFTs actually ask nuanced questions about the details of C++, concurrency, and systems in interviews.

This is something I've been hammering as important for months, ever since I started my call-in show (which I plan to get back to).

Unfortunately, there are three groups of detractors as it relates to 'TrIviA'.

1. People who have never interviewed for Quant, and think it's FAANG (those that don't know any better).
2. People who do know that this is how Quant interview, but feel as though the bar is too high (those that do know better).
3. People that know that this is how Quant interview, but would rather cope in not knowing the answer to the question than step back and ask 'Where do I go to learn this?'.

The poster, in this case, belongs to group 1. Group 1 is the most honest group; they're naive (in the kindest sense of the term) and simply are caught off-guard.

These are the people getcracked is best suited for. They're open-minded, willing to learn, and simply hit a patch in the road. Maybe the patch caused a flat tire, but they can be up and running in no-time.

90% of people end up in the third bucket. They know (deep down) that these questions are asked in Quant, but would rather attack the messenger than deal with the contents of the message (the question). Or worse, they want to attack getcracked's credibility by claiming it 'only tests trivia', despite the trove of coding questions, roadmaps, quizzes, interview games, and soon-to-be video content.

It's very hard to break through to these people.

Well, now that the developer ecosystem is starting to wake up, hopefully we can move away from this aweful term 'trivia'.

There is nothing 'trivia'-like about knowing the inner-workings of a language you will be using day-to-day.

There is nothing 'trivia'-like about information you will need to excel at your job in.

I was speaking to our Hardware Engineering partner (let's call him Bob), who is working on the rollout for SystemVerilog code submission questions on getcracked last night.

We were discussing how to measure a candidate's performance for code submissions.

With C++ and Python it's relatively simple. You can measure the time each test took to run, and sum that wall-time to arrive at a total runtime. With little exception, the lower the runtime, the better the submission.

The same can be done for memory consumption; albeit, we don't capture this at the moment.

When I was speaking to Bob, he mentioned that wall-time isn't an appropriate benchmark for hardware execution. All that matters is if your implementation makes 'timing' (is performant enough and can be implemented). In other words, it's possible that some code can pass all tests, run quickly, but not be implementable on actual FPGA hardware (that's the implemented part).

As someone that knows zero about FPGA, that caught me off guard.

I mean, if I write C++, and it builds, and it runs, it can run (almost) anywhere. What do you mean that firmware can run but can't be implemented? This was both confusing, and intruiging.

Anyways, that was a bit of a tangent.

Given that wall-time wasn't an appropriate measure, we decided to settle on something else, that being clock cycles. But even that left him a bit uneasy. Why? Well, because we run into the same issue as wall-time. Someone can submit a solution that passes all test cases, and is optimized for a reduction in clock cycles while still be unimplementable on hardware.

Well, where do we go from here? Both of us weren't sure. What we did know is that:

1. Clock cycles is better than wall time
2. You can cheat on both.

What we decided to settle on is to stick to clock cycles for now, disregarding optimizing for the 0.01% case where a cheater is in the midst.

At the end of the day, by submitting bogus solutions, they're only cheating themselves. :)

I am curious, if there are any hardware engineers reading this. I'd love to hear from you if you have a better approach to this!

I always get this question: How are the hours in quant trading?

And honestly, there's no one-size-fits-all answer. There are, however, answers that are more correct than others.

There are four axis that determine when and for how long you'll be working.

1. Region - Think of location, there are plenty of cultural aspects here that affect your work. Most of these are irrespective of Quant in particular.
   1. For instance, when interviewing for Grasshopper (Singapore office), I was asked if I'd be okay working on some weekends.
2. Company - Some companies are just sweatier than others. Usually this correlates to the firm's tier. For example, Headlands is a Tier 1-firm known for being sweaty (longer hours). At the same time this isn't always true. A member of the getcracked community, Squaaa, who works as a SWE at Jane Street mentioned that his hours are quite standard.
3. Firm Size - This one is tricky. Smaller firms may require less hands to do more work. This is not always the case, so I'm warry even including this point. It really depends on management, which can be sussed out via Glassdoor.
4. Role / Team - QR, QT, and QD all differ in their expected working hours.
   1. QT's hours are usually tied to the market-open/close cycle. Furthermore, some firms trade foreign hours (European or Asian hours), requiring traders to take night shifts (e.g. trader located in Chicago works nights to trade Asian stocks).

This is the formula I would use when determining how many hours you'll most likely need to work, short of simply asking your interviewer:

1. Start with 40 hours a week.
2. Apply a multiplier based on the region you're currently in. There is no location that would lead to a decrease in hours.
   1. HK - 1.2x
   2. Singapore - 1.4x
   3. Dubai - 1.1x
   4. New York - 1.2x
3. Apply a multiplier based on the firm size and scrapiness. The 'scrapiness' component can be determined via discussions with employees, or reviews on Glassdoor.
   1. Normal - 1x
   2. "Short Handed" - 1.1x
   3. "People are jumping ship" - 1.25x
4. Role and team is, once again, very context dependent. In general:
   1. QR - 1.2x - You live and die by your strategies and models. This alone pushes you to put in more hours.
   2. QT - 1x - There's not much more you can do when the markets aren't open. Furthermore, any company worth their salt knows that, any trader pushed to their limits, will make sloppy choices. Nobody wants a tired trader at the desk.
   3. QD - 0.9x to 1.3x - This role has the most variance. If you're at a 'chill' firm, you might be able to get away with working less, as long as you're 'cracked'. Alterantively, you can work at a sweaty firm and still work more, despite being 'cracked'.

Ultimately, the best way to understand how many hours you'll work is to simply speak to someone during the interview process. Ask them 'What does your day look like?', instead of 'What are your hours?'

The former makes you sound inquisitive, and the latter, lazy.

CJ

A lot of people ask both myself, and guests I have on the channel 'what can I do to excel'?

Luckily for me, I've oversaw 3 years worth of developer intern cohorts, so I have a solid amount of insight with respec to what sort of people end up receiving return offers.

1. Initiative - Don't come to your manager and say 'Well, I'm stuck'. What we really want to hear it 'I've hit this roadblock. Before coming to you I brainstormed two different approaches. Approach A is ... It's upside is ABC but the downside is XYZ. Approach B on the otherhand solves for XYZ but introduces a dependancy in 123. I'm thinking of going with B, but I'm not sure how you feel about it. What do you think?'
   1. Deep introspection and a self-starter-attitude is always highly respected.
2. Intelligence - This one is a no-brainer. I remember leading two interns during the summer of 2022. Lets call the intern in question Zaid. When I assigned work to Zaid, it seemed like, within 15 minutes, aliens beemed the optimal approach directly into his brain. His approaches were clean and elegant, with the code using constructs that were more advanced that what was expected, but not too advanced as to be over-engineered.
   1. I remember him using static_asserts in templates to constrict the types the template would be instantiated with (this is around the time C++20 concepts were becoming popular).
3. Communication - I noticed interns that struggled less were often more open about issues they faced. Instead of holding in their thoughtful questions, in fear of sounding emberassing, they brought them up at standups and group discussions. Whenever I personally feel anxious about asking a question I couldn't find the answer to eslewhere, I remind myself that if I ask immediately, I risk seeming foolish only once; but, if I never ask, I'll be a fool forever. Furthermore, these interns are pro-active in creating documentation and clarifying intent where ambiguity existed prior. This ensured that they were doing things right the first time, and not left guessing.
   1. Often times requirements are unclear. Candidates that excelled took it upon themselves to reach out to the appropriate parties to resolve these ambiguities.

Hopefully you found this useful!

If so, let me know what you think down below.

CJ

Members of my community already know the answer. But I figure it’s worth a post for those that aren’t in the know.

I often get asked why so many FAANG engineers move over to Quant for SWE. And it’s more nuanced than “better pay”.

It isn’t just a higher average base pay that draws people to Quant, but also the nature of the pay.

In FAANG, part of your compensation involves stocks or options, which vest over a period of time.

In today’s fast-paced world, where your standing at a company can change in a flash, nobody is looking to wait 3 years to reap the fruits of their labor.

In Quant, at least at most firms, your bonus is paid in cash in Q1 of the next year. There is no waiting 3-5 years, having your reward released to you in small increments.

Furthermore, the bonus compensation is often more stable. Companies now offer minimum guaranteed bonuses to attract talent. This means that firm performance won’t dramatically impact your compensation. Digging deeper it also signals that the firm is on solid financial footing.

Lastly, the benefits (non-monetary forms of compensation). While I have less insight here (on the FAANG-side), I know that it is at least on par with FAANG. One offer I received touted a private office chef, for instance. Not to mention access to boutique gyms, and other amenities. And while Quant firms don’t have their own campuses yet, this may change in the future.

So, what do you think? Why are more SWEs moving from FAANG to Quant?

I get this one all the time. In fact I even made a video about it years ago.

Still, I see variants of this question all over the internet:

• Is it too late for me?
• Am I too old?

And a lot more.

So, what's the answer? Well, just like everything, it depends.

I know you don't like hearing that, but hear me out.

If you're 85 years old with one leg in the grave, maybe wrap it up, boss - It's over.

But, if you're 32, considering a career change and have (or are developing) the skills required, it's not over.

Hold up! I can already hear a reader saying, "But, I'm 33! And you said 32! So it must be over for me!".

No.

There is no hard-age cut off. What you need to understand is that everyone comes into an interview with strengths and weaknesses, and its up to you to spin your perceived weaknesses into strengths.

So imagine you're 32 and going against a fresh 22 year-old graduate for a QD role.

Instead of harping on your age as a negative, spin it in a positive light. For example, you may be older, but that age comes with wisdom and tangible industry experience in an adjacent industry (e.g. imagine you are transitioning from being an actuary, or something similar). In this case, you've just reframed the other candidate's age as being their weakness. They're green, naive, and have no real-world experience.

See what I just did there?

Age isn't the only perceived negative, but it's the one I see people hanging onto the most. Perhaps because there's an underlying current of age-ism in our culture.

Regardless, a strong candidate will always highlight their strengths, and downplay their perceived weaknesses. A very strong candidate will reframe their perceived weaknesses as a strength.

Rant

Around 2022, I made a YouTube video about a concept called Fill Ack Arb. At the time, I didn’t consider the content proprietary; after all, every serious firm was running some version of it. In my mind, if you weren’t doing Fill Ack Arb, you weren’t really competing.

I’ll explain the concept itself in a future video. That’s not the point here.

My employer at the time saw the video and called me in for a meeting with HR. They told me they considered the strategy proprietary and issued me a first-and-final warning: if I discussed anything they deemed proprietary again, I’d be fired. I signed a document acknowledging those terms - no second chances - and immediately went dark on YouTube for about a year and a half. That one incident was enough to scare me into stepping away. At the time, my career mattered more than content creation.

And that wasn’t my first issue with having a public presence.

About 2.5 years into my first role, I applied to CTC. I made it through every round and was expecting an offer - but instead, I was rejected. The real reason was never officially communicated, but I later heard through the grapevine that an internal recruiter flagged my resume review service as a “conflict of interest.” Her reasoning was that I was “helping place candidates at other firms.” How she arrived at that conclusion, I still don’t understand. I didn't control where candidates applied to, I simply helped them market themselves.

Keep in mind, my “social media presence” is basically just making YouTube videos about a field I’m genuinely passionate about. You’d think firms would value that kind of initiative and engagement. Instead, many seem to prefer people who keep their heads down and say nothing publicly. Drones that clock in, and clock out.

Is that changing? Slowly. We’re starting to see more people in quant trading with public platforms. But it’s not happening fast enough to match the reality of today’s digital world - where having an online presence is the norm, not the exception. I know people that have landed jobs in Quant via their social media presence (e.g. julias.algos), and others who needed to jump through additional hoops to secure their offer.

This isn't a prescription - I'm not saying 'do' or 'do not' get involved in social media. Just keep in mind that its a double edged sword, and some will prefer to not equipt the sword all-together.

Hey everyone, CJ here.

I used to do 1-on-1 coaching (now I have other coaches that perform this service). Over the course of years doing private coaching, I noticed several common mistakes as it relates to resume construction, so here they are:

1. Including a summary section. Don't do this. Your summary section is your 'Tell me about yourself'. Anyone can write about how great they are on a resume, it's how you show up that matters.
2. Wrong sections, wrong order. Ideally your resume has 4 section. You order these sections based on what you want the recruiter to see first (your strengths). For instance, if you went to school for Underwater Basket Weaving, don't lead with it.
   1. Education
   2. Additional Information
   3. Experience
   4. Personal Projects / Open-Source Contributions
3. More than 1 page. I don't care how much experience you have, you need a 1 page resume. No one is reading more than one page. Most people don't read more than a quarter. What's more is that nobody cares for what you did over 10 years ago or what highschool you went to. Let's keep it clean and conside.
4. Not massaging the job description into your experience. When they write their resume, they fail to mention the technologies used and traits they had to lean on that the job description is begging for you to mention. If the job is looking for people with server-client experience, mention how you rigged up two server to communicate via gRPC (for instance). Or how you wrote a thin client that received snapshot and incremental updates from a server.
5. Not telling them why I should care. Okay, so you did X, Y, and Z. Great. Why should I care? 90% of candidates miss answering the 'why'. They don't answer 'Why should I care that you did all this?' The 'why' is answered by a quantitative (preferrably) or qualitative result. This shows that you've had an actual impact at the organization. It shows you add value. This details the outcome of all your hard work (e.g. increased throughput by 25%).

These are the top 5. There's a lot more. Hopefully this helps!

I get this question a lot, and for a while I wasn't entirely sure.

After all, I left the space in 2025, and it's been almost a year. During the past year we've seen massive strides in artificial intelligence (LLMs) with what seems like a new model being released every other day.

It was only after speaking with Ioana on my channel did I realize that it hasn't really taken hold in quant. Yes, it's used as a virtual assistant. But only to clean up the low-hanging fruit (formatting, query generation) that quants don't like or want to do, such that they can focus on what really matters. In fact, she mentioned that nobody has been laid off in quant due to the introduction of AI.

So yes, AI is used in quant, but as an assistant (where appropraite), not a replacement.

I had a chat with Ioana Roman, another Quant Dev, on the industry, challenges, breaking in, AI, the female experience in quant, and more!