August 04, 2026
Share on
A typical day for Rishi might start with a single value that doesn’t fit the rest of a dataset. By midday, he’s with a quantitative researcher, working out whether it’s a data error or a signal. By the afternoon, he’s back in the framework he’s building to make that call systematically across every dataset the team relies on.
Rishi is a Quantitative Development Intern on Citadel’s Equity Quantitative Research (EQR) team, back for his second summer. His work centers on a problem that sits at the heart of systematic investing: Models are only as good as the data feeding them, so separating genuine signals from corrupted or misleading values directly affects the quality of the research the firm relies on.
EQR draws on a wide range of datasets, which can contain values that don’t belong. Sometimes a number was entered incorrectly at the source. Sometimes a measurement is genuinely noisy. Other times a value sits far outside the expected range yet is entirely correct, which complicates the problem.
Rishi is building a framework that flags anomalies, classifies which ones matter and recommends how each should be handled, whether a value is excluded, down-weighted or kept as meaningful. He owns the project end to end, mapping how different teams use the data, evaluating detection methods, building the models and refining the tool as researchers put it to use.
“What surprised me about the responsibility I’ve gotten is how much freedom I have to drive the solution space on my own,” he says. “I can figure out what I think is the best strategy based on my interactions with the end users.”
The project hinges on a question that can sound misleadingly simple: When is an unusual data point just an error, and when is it telling you something important?
A framework that only flags unusual values isn’t much use on its own; a researcher still has to determine what each flag means. Rishi’s framework has to go further, identifying what kind of anomaly it is and what should follow: Sometimes the value is dropped or down-weighted, and sometimes the anomaly is itself the signal worth acting on.
“We have to figure out which data points are out of sample and should be ignored or down-weighted relative to the data points that really mean something to us,” Rishi says.
Getting that distinction right requires knowing the business. So Rishi spends a lot of time with quantitative developers and researchers, asking how they use the data, which failure modes hurt and how his choices would ripple into their work.
“It’s a lot of talking to stakeholders and figuring out what the core business problems are,” he says, “and then optimizing the solution to best address them.”
That has made the effect his models have on real-world investing feel close at hand. While it may sound like Rishi is just hunting for weird numbers, he’s actually trying to keep teams from acting on bad data without throwing away data that’s valuable.
Once Rishi understands the problem, he has to decide how broadly the solution should work.
The datasets vary a lot, and a trick that catches an anomaly in one place can fall flat in another. Rather than building a one-off detector for a single problem, Rishi is designing something that can handle different kinds of data and flex as new anomalies arise.
To create a successful framework, Rishi had to take initiative and be comfortable with a certain level of autonomy. His team framed the problem in broad strokes and left it to him to explore the options, form a point of view and pick the direction that looks most promising.
“It wasn’t that I was given a very specific direction and told to do X, Y and Z,” he says. “I had the freedom to understand the business problem by talking to people and then figure out the optimal solution on my own.”
His mentor, Noah, describes the job as having tremendous breadth. Rishi might spend days getting to know one dataset inside out, then turn around and work out how the same framework should behave on a vastly different dataset.
“You get a great opportunity to understand something really deeply,” Noah says, “but do that times 50 or times 100.”
That range is what makes generalizing so hard. The framework has to be sharp enough to catch subtle noise, yet loose enough to deploy across a diverse array of research problems.
One of Rishi’s early challenges was separating the genuinely relevant anomalies from points that merely looked unusual.
His first models successfully flagged candidate anomalies, but statistical distance alone didn’t settle whether a point should be discarded. The same value could mean very different things depending on the surrounding data and how the dataset was being used.
To get unstuck, Rishi leaned on the researchers and developers around him. They brought other information in the data to light that could establish whether a point was really anomalous and showed him how his output would land downstream.
“They provided the business context around what else in the data could help determine whether a particular point was anomalous,” he says. “That ultimately helped me find a solution and a way around it.”
As the framework matures, Rishi works like a product owner, and the team serves as his users. Researchers and developers test the tool, telling him what helps and where it falls short. Then he uses that to revise the models and return with the next version.
“Rishi owns this product,” Noah explains. “He has built a tool, and he has users: me, the rest of the team and other researchers.”
That back-and-forth keeps the technical work tethered to something real. A clever anomaly-detection model was never the point in itself. The ultimate goal is to help teams read their data faster and make smarter calls about how to use it.
Although Rishi owns the project, he’s surrounded by extraordinary colleagues eager to help him succeed.
He’s in regular conversation with developers, researchers and senior stakeholders who use the framework or feel its effects. They push on his assumptions and help him narrow things down, but they expect him to show up with a point of view first.
“We mentor instead of just manage,” Noah says. “We pose the question and the scope of the problem, but we often won’t handhold someone through the solution. That is where interns grow.”
Giving Rishi ultimate ownership of the project helps him develop real expertise, which benefits the team as a whole. Noah says that Rishi has gone deep enough into the modeling and the data that his work surfaces insights that even seasoned colleagues hadn’t seen.
AI tools are part of his daily development workflow as well, helping Rishi explore approaches and move through routine implementation more quickly. The work is anchored by Rishi’s own judgment. He interprets the data, defines the problem and chooses the solution that best fits the business need.
What comes out of it is a rhythm that pairs independence with plenty of help close by. He gets to know the users, digs into the data, forms a view, tries it out on the team and keeps refining from there.
This is Rishi’s second summer with EQR.
He came back to work again with people he trusted on a problem he hadn’t tackled before. Although the new project pushed him into an area he had to learn from scratch, knowing the team already gave him an advantage.
“I could work with the same people I really enjoyed working with last summer but still have the opportunity to work on something new,” he says. “I felt like I was learning as much as I did during my first summer.”
That mix is present in Rishi’s day-to-day. He might start his day with a suspicious data point and close with a framework that’s a little more prepared for the next surprise, with a stack of model tweaks and researcher conversations in between. The datasets change and so do the questions. The only constant is the habit underneath: learn the context, separate signal from noise and create something other people can actually use.
