Jane Street Software Engineer Interview Experience
Jane Street · Senior
For a functional programming shop, nearly every question I got was best answered in an object-oriented way, and in the deep dive the interviewer literally said he’d much rather hear about a project I had not rehearsed.
Interview process
I ended up on the senior-and-up version of the loop because I had a project deep dive in addition to the coding rounds. The big surprise was that the SWE process was not mathy or brainteaser-heavy at all. It was mostly long, collaborative coding interviews where they start with one implementation problem and keep building on it, plus a pretty probing project discussion full of why questions. Almost every onsite round had two interviewers, but it felt more like a carefully run collaborative session than a pile-on. My overall impression was that the bar was high and the interview design was very intentional.
Interview rounds · 4
- 1
Recruiter screen
My recruiter spent a lot of time resetting expectations. He was very explicit that for software engineering they are not trying to give you brainteasers or esoteric math, and that the process is supposed to feel collaborative rather than adversarial. He also explained that they use long coding rounds, often two interviewers, and that hints are allowed because they care about how you work with people when you do not instantly know everything.
- 2
Phone screen
CodingData Structures & AlgorithmsTechnicalMy phone screen was a 60 minute coding round with one interviewer, and it felt more like building through one problem together than speed-running a bunch of unrelated coding questions. The whole thing was collaborative and the interviewer was willing to give a nudge without making it feel like a trick round. The style was definitely to start with a base solution and then keep layering more requirements onto it.
Q1. Implement Connect Four / Connect K.
How they answeredI treated it like a game-state problem. I modeled the board with an array and used extra bookkeeping with a hash map plus stacks so I could update things cleanly after each move. The interviewer kept the whole round on that same theme and added gates instead of switching topics, so I talked through tradeoffs and extended my own code. It felt collaborative, almost like pair programming, and I did get a couple of unsolicited hints along the way.
Follow-up questions- How would you extend it as more constraints or functionality get added on top of the base implementation?
- 3
Technical round
CodingData Structures & AlgorithmsTechnicalThe onsite coding rounds were long, around 70 minutes each, and almost all of them had two interviewers. Usually one person drove while the second person either took notes or jumped in with a different angle, so it did not feel like a two-on-one interrogation. The questions felt curated to me, and every round I saw kept building on the same code rather than resetting to a fresh problem. Even though Jane Street is known for functional programming, the questions I got mostly lent themselves naturally to object-oriented code.
Q1. Implement a Merkle tree.
How they answeredI wrote a tree type and approached it mostly like a BFS / graph traversal problem. Having already thought a bit about Merkle trees helped me get off to a fast start, but the actual work was still regular data structures and algorithms, not a math puzzle. As they layered more functionality on top, I kept the structure clean and explained my reasoning out loud instead of trying to jump straight to something overly clever.
Follow-up questions- How would you traverse or search it as the problem grows?
- Can you build more functionality on top of your initial implementation?
Q2. Implement Tetris.
How they answeredI broke it down into the main components first: the game state, the pieces, and the rotation logic. The only math in it was very small, basically just working out how to rotate pixels, and otherwise it was straightforward implementation work. I had already thought through the rotations and the different components I would need, which helped. Like the other rounds, they kept extending the same solution instead of changing to a totally different problem.
Follow-up questions- How would you represent the game state and pieces?
- How would you handle rotating pieces?
- 4
Final / onsite round
Project DiscussionSystem DesignTechnicalBehavioralThe project deep dive was the part that made it clear I was in their senior-and-up path. I came in with a short menu of projects I could talk about, and the interviewer specifically picked one that felt less rehearsed because he said he would rather hear something I had not polished. The tone was casual and friendly, but the probing was real, especially around why decisions were made and how much I understood about systems next to mine. One interviewer in that round was especially nice and would sometimes step in if he felt I had already answered enough.
Q1. Walk me through a project you worked on.
How they answeredI had prepared a menu of six projects, but they intentionally picked one I had not starred because they wanted something less rehearsed. Then it turned into a lot of why questions: why we built it that way, why we did not choose some other design, and what was going on in systems connected to mine. On the parts I owned, I explained the motivation and tradeoffs. On the adjacent pieces, I was honest about what I knew and what I did not know instead of bluffing.
Follow-up questions- Why did you make that design decision?
- Why did you not use a different approach?
- What was happening in the adjacent system your work depended on?
Tips from the candidate
I would actually ignore rumors and prep for solid implementation-heavy DSA, not quant math. I would also spend more time practicing talking while coding, because the value is not just getting the answer, it is showing that you can build something cleanly, ask clarifying questions, and keep going when they add another layer.
I would also prep one or two projects deeply enough that you can explain the why behind the design, but do not over-rehearse a polished speech because they may deliberately steer you to something less scripted. Also, be ready to admit what you do not know without getting flustered.
Company culture
You can tell they put a lot of money and thought into hiring. They train interviewers heavily, use two interviewers a lot, write personalized questions instead of obvious LeetCode clones, and even fly people out early so they are not rushed. The whole thing felt high-trust and collaborative, like they are trying to simulate what it is actually like to work with you rather than catch you with tricks. For SWE at least, the public reputation around math and brainteasers seemed outdated or just aimed at different roles. They also seemed unusually principled about offers and recruiting in general, like not using exploding offers and wanting candidates to make an informed decision.