Inside Jane Street’s Software Engineering Internship

Ron Minsky talks with Jeanne Van Briesen, Matt Else and Grace Zhang about their experiences as software engineering interns and then full-time engineers at Jane Street. Their conversation covers actual projects, the transition into permanent roles, and the support and uncertainty that come with learning a large codebase and an unfamiliar business.

Jeanne came to the company from Carnegie Mellon, where she had encountered functional programming and OCaml. That background made Jane Street's use of the language intriguing, and the internship let her see what using it on real engineering problems was like.

Grace learned about Jane Street through an outreach event at Harvard and applied for the internship. Matt, a Cambridge student, heard about it from a friend and became interested in the chance to work on substantial technical problems.

Minsky emphasizes that previous OCaml experience is not normally a prerequisite. Interviewees can use the language in which they are most comfortable; what matters is how they think and solve problems. The firm expects people to learn its tools after they arrive.

The guests describe the mix of curiosity and uncertainty they brought to a trading firm. They did not need to arrive with all the financial context for the work, but they did need to be willing to ask questions and learn from colleagues.

Before the pandemic, the typical internship involved two teams for roughly six weeks each. An initial boot camp introduced the technology and the organization, and the intern cohort shared classes, events and the experience of finding its footing together.

The program combined work on a team with structured teaching. Interns could attend technical classes about tools they would use, learn some of the finance behind the systems, and turn to mentors and reviewers as they worked through their projects.

Mentorship was not confined to a single scheduled conversation. A project came with people who could explain the codebase, review changes and help an intern find the right person to ask about a trading or design question.

The guests remember how quickly the work became concrete. Rather than merely observing employees, they were given projects with real users and could see the connection between the changes they made and the way a team worked.

Grace's first project addressed risk limits in manual order entry. Traders sometimes needed limits raised across several scopes, but the existing process could require a code change and review. Her project made certain increases easier to request and apply.

The distinction mattered: the project did not simply remove risk controls. The permitted increases were configurable, with hard limits still providing a boundary. The goal was to make a common operational adjustment faster without treating every request as unrestricted.

Grace worked with the people who understood both the software and the traders' needs. That helped her make decisions about the interface and the appropriate controls, even though she was still learning what the surrounding system did.

Returning later as a full-time engineer, Grace heard feedback from a user of the tool. Seeing an intern project continue to matter after the summer was especially satisfying; it also showed how much the details of a workflow affect its usefulness.

Matt's project concerned requests for quotes, or RFQs. Jane Street has automated systems for quoting, but sales traders also handle requests manually. His task was to bring risk checks to that manual process.

The programming was only one part of the challenge. Matt first had to understand the financial activity and why the checks were needed. Colleagues explained the business context so that he could connect the code to the decisions a trader would make.

He recalls that asking questions was encouraged, even when he felt they were basic. The people around him supplied context and pointed him toward the relevant parts of a large system, rather than expecting an intern to infer the whole business alone.

Code review was an important part of the experience. Reviewers discussed design choices and helped him understand conventions, making review a way to learn how the team reasoned about software as well as a gate before a change went in.

That collaborative process also meant that an intern's work could be real production work. A tightly scoped project could be significant to its users while still giving a newcomer a manageable starting point and access to guidance.

The group notes that even a small change can involve many questions when the system is unfamiliar. Learning where to look and whom to ask is a substantial part of the first weeks, alongside learning the programming language.

Jeanne's internship project was on Incr_dom, a library for building user interfaces with Incremental. She worked on bringing together an easier interface and a more powerful one, so that users would not have to choose between convenience and capabilities unnecessarily.

The work involved API design: a good interface needed to make the common case straightforward while preserving the ability to express more involved behavior. Those tradeoffs affect many users when a library is shared across a codebase.

Jeanne also used a PPX, an OCaml syntax transformation, to help migrate existing code. The transformation had to preserve useful source locations, so that errors and tooling could still refer developers to the code they had actually written.

A repository-wide migration made the project more than a self-contained prototype. Jeanne could see how a library change rippled through existing users, and she says the resulting work continued to be used after her internship.

Minsky and Jeanne discuss the appeal of getting to make a design judgment rather than just completing a prescribed mechanical task. Mentors could offer experience and review, but the intern still had a meaningful problem to reason through.

The project also gave Jeanne practice navigating the tension between making an API approachable and retaining enough expressive power. Its success depended on how other engineers would actually use it, not just whether the new code compiled.

The guests returned as full-time engineers and discovered that knowing a team or codebase from an internship does not eliminate the learning curve. Grace describes coming back to code she had written and realizing she had forgotten details of it.

She also encountered more of the finance around the system, including options pricing. As a full-timer she could follow questions beyond the defined boundaries of an intern project and spend more time understanding the surrounding problem.

An internship project must be substantial enough to be interesting and useful, but scoped so that someone new can make progress in a few weeks. Full-time work often has less predetermined shape, and deciding what to tackle can itself become part of the job.

Jeanne joined the RFQ team and eventually deployed work connected to Matt's former intern project. The overlap illustrates how projects persist and evolve: an intern can contribute one piece, and another engineer later carries it into a broader workflow.

As a full-time engineer Jeanne also became involved in thinking about projects for interns. The role reversal made her consider which problems had enough substance while still being approachable in a short period.

She describes a proposed intern project involving RFQ validation, freezing and indicative quotes. It required understanding the users' needs as well as choosing how the interface and the underlying behavior should work.

The spring internship was interrupted by COVID-19, and Jeanne ended up finishing the project. The summer program was also reorganized for remote work, including having interns work with one team rather than rotating between two.

Grace describes a full-time project to add client-side caching around Redis. She learned about the possibility through her navigator, brought the idea to the team, and found colleagues receptive to a proposal from a relatively new engineer.

Her example shows a change in responsibility: instead of receiving a fixed intern assignment, a full-timer can notice a problem, suggest a direction and work with others to decide whether and how to pursue it. Support remains available while the scope of initiative grows.

The conversation turns to how new full-time hires find a team. People can talk with several groups, learn about their work and preferences, and use those conversations to find a match rather than treating the decision as a blind assignment.

Grace chose a group she had encountered before, after discussing the possibilities with others. Familiarity was useful, but the conversations also helped her understand what kind of work and team environment would suit her.

Asked how Jane Street compared with other internships, the guests point to the size and organization of the intern cohort. Shared events and classes helped them meet people outside their immediate teams and gave them a community of others learning at the same time.

Jeanne contrasts writing new code with entering a large existing codebase. At Jane Street she had to learn how established pieces fit together, but the modular organization helped her work on one part without understanding every part at once.

The experience also exposed interns to the practical side of maintaining shared software. A change may be local, but it must fit the interfaces, conventions and needs of many other users who depend on it.

Matt describes a later project around Zero, a serialization protocol. Like systems such as Cap'n Proto, it aims to encode data efficiently while allowing formats to evolve compatibly, a useful property when services need to exchange data over time.

He worked on a PPX to support the protocol and on integrating it into a market-data setting. The problem reached across team boundaries, so technical design and coordination with the people who would deploy and use it both mattered.

An attractive serialization API is only part of the job. Existing services must be able to adopt it, and the people responsible for them need confidence in the migration. Matt describes working through these practical deployment questions with other teams.

The project gave him a different perspective from a short internship: decisions had consequences across a larger system and required sustained discussion. He could pursue the technical details while also learning how to move a change through an organization.

Jeanne says conversations with traders help engineers understand why RFQ features are needed. A request becomes easier to prioritize when she knows the workflow and the problem a trader is trying to solve, rather than seeing only a list of requested changes.

That proximity brings support work as well as feature ideas. Engineers may need to respond when a user has a problem, and those interactions can reveal shortcomings in existing tools that would be hard to discover from code alone.

Teams must balance immediate requests against technical debt and longer-term architectural work. Jeanne describes making those tradeoffs in the context of actual users, while Grace notes the coordination needed for risk infrastructure used across groups.

The guests return to the question of how to organize a working day. Interns have classes, team meetings and project work competing for attention, and people differ in whether they prefer activities grouped together or spread through the week.

One preference is for longer uninterrupted blocks in which to make progress; Jeanne enjoyed the variety of breaking up the day, while Matt places himself somewhere between those positions. The discussion makes clear that a schedule that works for one person need not suit everyone.

Remote work made some of these choices more visible. It could be harder to reproduce the casual interactions of an office, and planned calls did not always replace the ability to turn to someone nearby for a quick question.

The office also had its own interruptions: traders' questions and support requests do not always arrive on a predictable schedule. Those interruptions provide useful context and connection to users, but they also compete with concentrated engineering time.

The guests miss aspects of being together in person, including the sounds and spontaneous exchanges of a trading floor. Their discussion reflects the particular adjustment the firm and interns were making during the pandemic, not a settled verdict on every remote arrangement.

Jeanne says she would have appreciated more frequent feedback and encouragement as an intern. A newcomer may not know whether silence means that things are going well or badly, especially while comparing their own uncertainty with other people's apparent confidence.

Minsky argues that it is the internship program's responsibility to provide feedback, not simply the intern's responsibility to ask for it. Managers should recognize that many interns share the same need for clarity and reassurance.

Matt recalls feelings of impostor syndrome: struggling with an unfamiliar problem could make him wonder whether he belonged. Minsky says such feelings are not necessarily correlated with performance, and that even people doing well can experience them.

A navigator or mentor can help by putting difficulties in perspective and explaining what progress looks like. The guests' experiences point to a program in which meaningful work and technical challenge are paired with deliberate support and honest feedback.