July 22, 2026
Share on
A single day for Jonathan might start with a conversation with a portfolio manager, move to a system-design debate at a whiteboard, and end with him building and testing the solution.
As a software engineering intern on Citadel’s Equities Engineering team in New York, he’s spending the summer building a reliable distributed system that delivers transcripts from live events such as earnings calls, press conferences and company presentations. A single portfolio manager or analyst might cover a basket of 20 to 30 stocks, so they are often tracking several of these events at the same time. The system is designed to help them pull out the information that matters quickly and act on it, whether that means adjusting a position or simply understanding a company better.
Jonathan’s role extends across the full project: understanding the requirements, designing the architecture, implementing the system and preparing it for rollout.
“My work isn’t just focusing on a small component of some bigger system,” he says. “I get to design the entire system around the business problem.”
The project begins with the people who will use it.
Jonathan speaks directly with portfolio managers to understand how they follow companies, where information can become difficult to process and what would make the system useful in practice. These conversations give him context that would be difficult to get from a technical specification alone.
“As an intern here, I’m encouraged to speak with portfolio managers directly to understand the problems they’re facing,” he says.
Talking to them directly shapes what he builds. The system can’t just move information fast. It has to stay reliable when several events are happening at once and point people to what actually matters for the companies and sectors they’re following.
For Jonathan, that’s made the link between the code he writes and the investment work it supports feel real, not abstract.
Once he understands the requirements, Jonathan works through possible architectures with his team.
He diagrams components on a whiteboard, considers how information should move through the system and examines how different designs might behave under failure. His mentors ask questions, challenge assumptions and help him evaluate trade-offs, but they do not begin by prescribing the answer.
“With Jonathan, we’ll have him propose a scope and design, make sure he understands the context, the requirements and the why, and then refine it together,” one of his mentors explains.
This is the part Jonathan values most. He’s expected to form his own view, explain his thinking and change his mind as he learns more.
“My mentors entrust me and believe that I can make the correct technical decisions,” he says.
The discussions often go beyond implementation details. They get into reliability, how the system behaves, what depends on what and what each technical choice costs down the line.
Jonathan then carries the design into implementation, testing and rollout.
The work sometimes requires coordination beyond his immediate team. He may need information from another engineering group, input from a vendor or clarification from an investor. He’s encouraged to reach out directly rather than treat those dependencies as someone else’s responsibility.
That’s changed how he sees the job.
“Code is not the only solution,” Jonathan says. “It’s important to think of ourselves not just as coders or programmers, but as business problem solvers.”
Jonathan has a word for this: commerciality. It’s an idea his team emphasizes a lot, and to him it means understanding the business deeply enough to know which problems are worth spending your time and energy on. In practice, that means deciding when software is the right answer, when a process needs to change and which problem is worth solving first. Jonathan describes it as knowing the business well enough to focus his effort where it will actually count.
It also requires clear communication. Members of his team regularly explain complex systems to investment professionals in plain language, and Jonathan has learned to connect his own technical decisions to their practical effect.
Although Jonathan owns the project, he’s not working through it alone.
His team checks in with him frequently to review progress, discuss technical questions and help him improve his approach. The focus isn’t only on whether the project gets completed, but on how he develops as an engineer while building it.
“My team is incredibly proactive about helping interns like me ramp up,” he says.
That support gives him room to take on something hard without taking the hard part away. When he hits a design question he hasn’t seen before, his mentors help him reason through it instead of just handing him the answer.
The result is a working rhythm that combines independence with regular feedback: gather context, form a view, test it with experienced engineers and keep moving.
This is also Jonathan’s first summer living in New York.
Outside the office, he’s seen The Lion King on Broadway, where he was struck by how the whole theater seemed built around the show. He’s been exploring the city’s food scene too—he figures you can find just about every country’s cuisine somewhere in New York. The Museum of Ice Cream is still on his list.
“You can find anything in New York,” he says. “Even if I spent six more summers here, I still wouldn’t see everything I want to see.”
He’s also had a chance to get out of the city, traveling to a firm offsite in Palm Beach.
Asked to describe his internship in three words, Jonathan chooses “challenging, insightful and empowering.”
A day with Jonathan reflects that balance. It may begin with understanding an investor’s question, move through a technical debate with his team and end with a system that’s one step closer to being used. The work changes, but the underlying process remains consistent: understand the problem, form a view and work with others to turn it into something useful.
