The following is part of a series of posts about 2026 summer intern projects—for more, see “What the interns have wrought, special jumbo 2026 edition”

Strategy and Product Specialists are versatile, cross-functional contributors who drive forward firmwide initiatives. The role requires a unique combination of big-picture thinking (“why is this valuable to the business?”) and deep analytical problem-solving.

Full-time SPs work across all areas of the firm: on trading desks, in infrastructure groups, and with tech teams. An SP in finance might optimize our position management infrastructure, while an SP embedded with developers might wireframe and prioritize improvements to core firm systems or tools used by traders. Both need to understand the business well enough to decide what’s worth building, and get into the details deeply enough to build it right.

SP interns are embedded directly onto a team, paired with a full-time mentor, and given real-world projects we actually care about getting done. This is work full-timers are excited by (and would be doing themselves, if not for our interns!).

Now that the Summer 2026 internship has wrapped up, we wanted to highlight some of the projects our interns tackled and give you a flavor of what the SP internship is all about.

Connecting financing costs to trading decisions

A trading strategy’s profitability depends on more than the prices where we buy and sell. Financing positions - borrowing money when you’re long and securities when you’re short - costs money, too. Jane Street enters into various kinds of loan arrangements to facilitate our trading, and the terms of these loans can differ considerably.

Evan Yi’s project was to develop a model for the fee expense on several types of loans, and ensure that this model allocated financing costs back to trading desks and individual strategies. There were a lot of ways this could have worked, and no obvious “right” answer. For example, if you allocate by gross position size, that could penalize strategies that take large positions, even when those positions are comparatively cheap to finance (versus a strategy that focuses on thinly-traded securities in smaller sizes).

The choice matters because different allocations will make the same trading activity look more or less profitable. Desks use these costs to evaluate their strategies, driving decisions as small as tweaking trading parameters and as large as resourcing between teams.

Evan had to understand both the details of the financing arrangements and the trading decisions they were meant to inform. He worked with teams across the firm to learn how loan terms are structured, how our systems model and reattribute fees, and how desks incorporate those fees into trading decisions. Then, with his proposals in hand for each of four loan arrangements, he analyzed data to compare the effects of different modeling choices. The last step, driving consensus on his prototypes, required judgment about the tradeoffs at hand and leveraged the relationships he’d built with various teams throughout the summer.

Managing our risk limits on unusual dates

Every order sent by Jane Street’s proprietary trading systems passes through a complex series of risk checks. For example: how many open orders can the system have at once? How large can any single order be? These automatic checks are essential for protecting the firm if a trading system does something unexpected, since there are thousands of systems operating at faster than human timescales.

Each system’s risk limits are set according to a schedule: one limit might apply from 9 a.m. to 11 a.m., then another later in the day. But some days are special: when there’s a macroeconomic event such as a Fed meeting or employment report, you might expect a flurry of interesting trading at an unusual time of day. Even daylight-saving transitions can require schedule adjustments (since confusingly, New York and London change their clocks on different dates!). Traders configure overrides to give their systems appropriate latitude on these days. But over time, those overrides have become confusing and messy to maintain.

Philip Weaver’s project was to understand the risk limit override process and propose improvements. He interviewed traders, dug into case studies from the code, and worked with a team of developers to understand how date-driven limits were built. He got his hands dirty, comparing historical limits with usage data for various systems.

His analysis led to two proposals. First, Philip found cases where limit overrides expired unnoticed, curtailing trading at important moments. By attaching ownership and lifecycle information to the shared dictionary where special dates are stored, he was able to lay out an automated system of expiry reminders. In this way, the code itself could help ensure system owners were prompted to review and extend overrides.

Second, with those tricky daylight-saving transitions, Philip split out mechanical limit overrides in the data from the more substantive ones, proposing different review cycles for each to reduce manual developer work and keep his new review notifications high signal and actionable.

Getting this right required understanding why traders needed the exceptions, how the software applied them, and how colleagues would maintain them going forward.

And more…

We had too many exciting projects to cover in depth, but a few more we wanted to quickly mention:

• Abby Shen worked with the Linux Platform team to help automate fleet-wide upgrades, particularly kernel migrations. In her research, Abby found that the process of defining host-classes for big migrations involved lots of manual work. Abby helped codify the principles behind that manual process, so that hosts are instead grouped and sorted based on a mix of hardware specs and usage metrics.
• Andy Parker worked with the AI Assistants team, studying how people at Jane Street interact with our AI tools. His interviews and analysis of session-level metadata turned up some key frictions. Andy focused on AIDE Mint, a popular tool among developers that turns a Slack conversation into a task for an AI agent to complete asynchronously. While users loved how quickly they could start an agent, their code changes didn’t consistently make it into production. Digging into why, he learned the agent too often needed more direction before beginning work, and redirecting it wasn’t ergonomic. He designed a lightweight exchange that lets users shape the agent’s plan in Slack before it starts, and worked with developers to ship it.
• Emily Zhang worked on the Metadata team, which stores and disseminates crucial external reference data for trading (for example, new listings from exchanges or corporate actions like stock splits). She dove into the data ingestion process and created an alerting framework for cases when vendor data arrives late. Many teams and systems downstream rely on this data. By understanding which alerts were most critical to users and analyzing historical logs to find patterns, Emily designed a system that makes it easier to triage the large number of issues and surface the highest signal alerts to the appropriate consumers.

Looking forward to next summer…

This is just a sample of the shapes of projects our Strategy and Product interns worked on this Summer. If these projects sound interesting to you, consider applying! You can find more details about the role here: https://www.janestreet.com/join-jane-street/sp/. Applications for our 2027 Summer internship are now open!