BLURB

Chloe Casale was planning to be an auto mechanic before taking an intro CS class on a bet. After a stint as a Forward Deployed Engineer at Palantir, Chloe came to Jane Street with no background in OCaml or finance. Now she leads a team of “desk devs” building tools for client-facing traders. In this episode, Ron and Chloe discuss how a surprising amount of Jane Street’s client business is conducted via chat, and the promise and perils of using LLMs to automate that trading. They dive deep on hiring and interviewing: does Jane Street’s process select for less “spiky” kinds of people than Palantir’s? Along the way, they marvel at Webs, an internal spreadsheet-like framework for composing computations and building UIs (which, you can see, is sort of hard to explain); compare building software for internal versus external customers; and recount the tale of Chloe’s epic 1,000km horse race across the Mongolian steppe.

SUMMARY

Some links to topics that came up in the discussion:

00:00:03 – Racing 1,000km across Mongolia
00:05:18 – From auto shop to CS on a $20 bet
00:09:41 – Forward-deployed engineer at Palantir
00:12:23 – Why Jane Street (and why London)
00:16:06 – Sales traders, prop traders, and client flow
00:22:26 – Why so much trading happens over chat
00:31:19 – LLM parsing and the 95% problem
00:41:05 – Bonsai, Webs, and everything Excel wanted to be
00:47:44 – Vibe coding and varying scrutiny
00:56:35 – Desk dev vs. forward-deployed engineer
01:02:56 – Generalists vs. specialists
01:06:14 – Hiring at Jane Street vs. Palantir
01:20:00 – Who our interview process might miss
01:26:39 – On generalists and specialists
01:31:17 – At least one interview that someone can crush

Just once. It was over and never again.

So then I think when I was applying for jobs out of university, I kind of just cast a really wide net. I ended up getting a job as a forward deployed engineer actually at Palantir afterwards, moved to New York to go and do that. I was at Palantir for I think four and a half, almost five years and really loved doing a forward deployed engineer. I think that for me, it was another kind of one of those moments where it wasn’t entirely pure software engineering. I got to spend a bunch of my time thinking kind of like applied math. It’s like how do I apply this computer science knowledge that I’ve learned?

Ron

So what is a forward deployed engineer? This is, I think, Palantir jargon.

Chloe

It’s Palantir jargon. It’s become weirdly popular in the industry these days, which I find interesting. But at the time, a forward deployed engineer at Palantir was basically there were two parallel engineering tracks, one forward deployed engineer, one product engineer. At Palantir, you called us a delta and a dev. I was a delta. I don’t remember why we called it that, but basically the idea was our job was to take whatever our product team had built and go onsite to customers and actually make it work for them in solving their specific problems. So it was a very specialized role in a way. I think sometimes when you think of software engineering, you think about trying to solve a problem for many, many customers, and a forward deployed engineer’s whole job was to solve a problem for one single customer. And so you got to go land on the ground, understand everyone’s problems very, very deeply, and then try to figure out, do I have to build something entirely new?

What products do I have that are supported by core Palantir that I can use in order to go and solve their problems? And then how am I actually going to make this valuable for the people who are there? And then you also had a responsibility of learning things that the customer wanted and feeding that back to product. So maybe when I’m working with a specific customer, I realize that, oh, this specific way of doing data analysis seems super powerful and that’s probably not just them who wants this. It’s like I get to go and feed this back to product and say, “Hey, I think this thing is generalizable. I think this is more interesting than maybe just this customer.” And then that’s how a lot of those roadmaps would get formed.

Ron

And do you feel like this kind of forward deployed role is something that just matched your interest and personality more? I feel like I know lots of engineers who are like, “You know what? I’d like to do anything that’s not that. I would like to do things that are building very general purpose as founded in systems and theory questions as possible and users, I don’t want to think about them.”

Chloe

I think that’s the only thing I want to do. I think I’m the opposite dev to that dev where it’s like I just love talking to users. I think there have been various times as both a forward deployed engineer at Palantir, but also a software engineer at Jane Street where the easiest way to solve a problem was to send an email, and I’m more than happy to solve that problem that way. I don’t necessarily need to reach for coding every single time, and I think it just does, I don’t know, match my personality and the things I enjoy doing.

Chloe

It is hard to automate. I think that, especially going back to pre-LLM times, when we were thinking about automating chats, it’s like some of our chats were relatively easy to automate because you could tell that someone was putting in a standardized format every single time they were sending us one of these requests for quote. So it was relatively easy for us to build a system that could read the regex, could use a regex parser, parse out this request for quote, and then send it through our RFQ systems. And this felt relatively low risk. It was like we had very consistent messages coming from clients. We still had a sales trader looking at the chat room every single time, even though the parsing was happening automatically, a sales trader would still go back into the chat room in order to maybe go and send the price that we ended up quoting.

Oh, this matters, I’d say different counterparties have different amounts of speed, and it’s also interesting because it’s actually quite different every region, I’d say, how much people are sensitive to speed. And so you have some counterparties who we are aiming really to try to get quotes back, at least are trying to get quotes into our system within less than 20 seconds. Some counterparties were trying to get it in less than five so that we can basically have the time for it to go get a price, be able to write that price back into a chat. So this is still human level processing, but I think if we started taking, I don’t know, 45 seconds on something where someone is expecting us to be back in five, we might lose that trade. That being said, there are some clients who are sending us trades that they’re expecting a price back within an hour, and so it’s very different people are executing different strategies on their side is the way I think about it.

I spend a lot of time figuring out how I can facilitate our traders thinking about what their clients want. So I think that they have the expertise of understanding. They’re talking to these clients very frequently. They’re seeing the flow go by. They have hypotheses as to what’s going on. The extent I start thinking about our clients is thinking about, oh, what kind of questions do my sales traders want to be asking in order to figure out how to support their clients and then building systems that can facilitate that question and answering.

LLM parsing and the 95% problem (00:31:19)

Ron

Okay, so now we’re in this new large language model world. How does that change the parsing story?

Chloe

Webs is exceptionally difficult to describe because I think you can think about it kind of as a distributed computational graph maybe.

Ron

I think that’s fair. That’s one of the things it is.

Chloe

You could also think about it like everything Excel wanted to be. It’s like this amazingly powerful tool where you can build what I would call UIs where you can display data, usually tabular data, but so much more than that. I’ve seen people iframe in websites into Webs before, and so it’s really possible to create these very powerful UIs in Webs.

Ron

And it’s maybe worth saying, this is a weird kind of technology that shows up in some form or another in lots of different trading firms. So if Goldman Sachs famously has a system called Slang, Slang is their programming language, and there’s some underlying data store called SecDB, securities database, where they build all sorts of applications on top of it. And a thing that you mentioned graph, why is there a graph there? A thing that has shown up for a long time in trading systems is you have streaming data that’s coming in and then you want to compute something from that streaming data. But the streaming data, everything doesn’t change all at once. Little parts of it change, and then you don’t want to have to do all the computational work of recomputing all of it all at the same time. And so you have some kind of graph that gives you some structure of the computation, so only the parts that need to be recomputed actually are.

It’s like a form of incremental computation. And also spreadsheets totally do this, right?

Chloe

Yes.

Ron

Spreadsheets are this fun functional programming language. Every cell is a little purely functional expression. It expresses dependencies on other cells that induces a computation graph. And Webs literally developed from what was just an overgrown spreadsheet. We had big spreadsheets on one of the desks that were used for pricing a bunch of their securities and Webs kind of, in fact, that spreadsheet was called Webs eventually, and then we’ve built a system in the image of that spreadsheet, which takes that same basic structure and kind of industrializes it and makes it bigger and more scalable. And maybe one of the things that’s different from what you would normally expect from a traditional spreadsheet is it’s much more of a collaboration tool. The big computational graph is shared among a whole bunch of people. And so it’s both a way of building some new computation and it’s also like a playground where all the other computations that other people have done are just sitting there available for you.

And then it has a kind of built-in little GUI builder in it, an easy way of building views. Traditional spreadsheets have this very flat grid view that you can embed all sorts of things in. But no, this is like, even though there’s lots of tabular data, you have a little programming language for constructing views as part of Webs.

Chloe

Yeah. And I say this programming language is very approachable, which I think is one of the powerful things about Webs is it’s very easy to basically maybe take someone who’s a little bit less technical of a user and give them the basics of how to build a new view in Webs and have them go up and be able to create a view that it is exactly what they want. And I think to one of your earlier points, Webs is this, it allows you to share so much analysis, but it also allows you to share data. So once you have one piece of data in Webs, anybody else who’s using that Webs instance can go and basically access that piece of data in order to run whatever analysis that it is that they want to do. And so when we’re spinning up a new Webs instance to actually think about using in recruiting, I think one of the conversations we have with a lot of our recruiters is Webs is more powerful the more brave you are.

Yep.

Vibe coding and varying scrutiny (00:47:44)

And that’s kind of the point in which we would start moving over into a Bonsai UI.

Ron

Yeah. I mean, there’s a lot of things that we’re thinking about here and doing. There’s a lot of work on sandboxing of agents to help deal with this kind of issue. An idea that I’ve been thinking about just in the last couple of weeks is to give safe pathways for vibe coding whole applications where you don’t have good sandboxing at the application layer by doing stuff where you have a separate document that specifies in some sense what the guards are supposed to be, and then maybe you could have hard semantic checks. You could say it’s like, “Oh, this document is there, so we have to build this in a way that there’ll be sandboxing built in that will enforce the rules that are stated there.” Maybe simpler and easier to implement, although having its own limitations of having mandatory LLM review so that when you make a change, you have another…

Ron

You’re like the Spider-Man thing point at each other.

Chloe

And then it’s like you get the opportunity to turn that into a product. And I think that does happen quite frequently, but I think it just happens a little bit slower than I saw it happening at Palantir because it does kind of require a bunch of different people to all have built the same thing and then someone to notice and then someone to organize turning it into one product that the firm can use.

Ron

I mean, Webs is a little bit, I mean it’s both an example and a counter example of what you’re saying. Webs was a thing that was built by the desk dev team on one particular desk. And then over time they’re like, actually, this is very general and we should apply it to lots of places. It’s not like a bunch of teams built the same thing. Really one team built it and then figured out it was more general and figured out to generalize it. I think the thing that slowed that down was mostly just opportunity cost. It’s very valuable where it was and at first it made sense to work on it mostly in that area. But I think we did eventually work around to it, maybe more slowly than we might have otherwise. So that’s kind of in the direction of what you’re saying. I feel like the other thing I’m hearing from what you’re saying is maybe that we should specialize more at a human level.

One thing that’s really different at Palantir is they really hire different kinds of people for different roles. They should be, oh, this person would be a good FDE and this person would be a good core engineer and they point them in different directions. And we tend to hire people who we think are strong generalists and then we figure out where they go.

Chloe

Yeah. It’s a very different way of thinking about people. I think it was a huge update for me when I joined Jane Street and especially when I started hiring at Jane Street to start thinking about people as like, okay, no, I’m hiring generalists, which was very different than the specialists I was hiring at Palantir.

Hiring at Jane Street vs. Palantir (01:06:14)

And what we were really looking for was someone who had one thing that they were excellent at and then were good enough at the rest of things. And I think that -

Ron

So multiple different dimensions in which you’re looking and each read in those dimensions is lower confidence because you have fewer instruments applied, fewer readings of that property.

Chloe

Exactly. In fact, you only have one. So it’s just you get one interview where you’re trying to read that property. And maybe that some of the interviews have little properties that overlap, but it was very much in a way it was like you’re putting one interviewer in the room. It’s very different than Jane Street. You’re putting one interviewer in the room in order to get one read and then you’re working off of that one read as saying, okay, maybe I’m not super confident in this thing because it was one interview, one interviewer, but we had a lot of faith in our interviewers in those moments. Versus Jane Street, I think we think about it quite differently. It’s like we want to give someone the opportunity to succeed over a bunch of relatively similarly shaped interviews where you have two interviewers in each room. It’s like we’re getting very, very confident on a set of very specific reads, I’d say here.

Ron

You are trying to, in those conversations, learn about multiple different things at the same time. When I think about things that I want to learn about in one of our interviews, are they a good software engineer who knows how to write code? A thing they’ll often look for is when you look at somebody, look at the actual code that they write on the board and you ask them to think about it, you know how you think about you can tell if somebody writes a lot because there are callouses on particular parts of their hands. And I feel like there are marks on how someone talks and thinks about code that comes from have they thought hard and worked hard about how do you build careful, reliable software, the habits of mind that develop from that kind of work. That’s one kind of thing I look for. I feel like I’m also looking for people’s communication skills. Can they explain something to you? Can they hear the thing that you’re saying when you point them in the direction of an idea?

Ron

It’s interesting because I feel like there are echoes in what you’re saying of how Jane Street’s process works in the sense that we actually do have this handful of questions that we use that are meant to be more design focused and questions that trying to get at people to read and debug code and various other pieces like that. But it sounds like the systematic approach is very different. It sounds for Palantir, it’s like when you’re constructing the interview, you’re like, okay, what facets are we going to cover? And you go off and cover those facets. Whereas here it’s more like we have a kind of standard interview process that we use across a wide variety of people that again, trying to get into this generalist set of skills. And then sometimes we’ll be like, oh, for this particular kind of person, we want to test some different things.

And so we’ll pull in different questions and try and lean things a little bit. But it’s more like you feel like there’s a relatively wide shape of a distribution of what you’re covering and your questions are shifted a little this way and shifted a little that way, but it’s almost like these are these delta functions that you’re trying to like, I’m going to focus on this facet, I’m going to focus on that facet. I feel like this is a closed-minded biased thing to say, but I feel like our thing sounds much better. So what’s good about the facet approach that I’m missing?

Chloe

It hires you very different kinds of people. So you can imagine that at Palantir, you interview someone and they crushed their decomp interview. So they’re really good at decomping problems. And maybe they just did meh on the coding bits or meh on the learning and the rest of it was just kind of like, I don’t know, fine. We felt like we had enough signal on this one very specific facet about this one thing that this one person was excellent at. And the interview wasn’t clouded by the things that they were maybe just less good at because the interview’s very, very focused on this excellent thing that allows you to hire what I would call a very spiky person. So they’re a person who’s very, very good at one particular thing. At Palantir, we had a lot of spots for people who were very, very spiky.

Chloe

No. I think it was pretty noisy. I think that we also did… I think first of all, we spent a bunch of time trying to figure out what our facets were. So I think that it’s like you’d spend years because a recruiting cycle is long. So it’s like when you want to change something in recruiting, you have to think about, okay, let’s say I changed something in my recruiting process today. I’m going to make my first hire in a month. That person’s going to start maybe in another three months. I’ll find out how they’re doing a year after that. And so then in a year and a half, I’ll know whether or not this decision I made was good. That is not the kind of timeline I like working with when I’m making decisions. But I think that we spent a lot of time at Palantir going through a bunch of different facets and testing them out and figuring out which ones were better than others. And I think that we also were happy with a little bit more noise. And so I think that we were kind of conservative about the people that we would take and we wanted all of our interviews to have more false negatives than false positives. And so we thought really hard about maybe getting harder by some proxy interview, but I think that it was noisy for sure. And I think that we were optimizing in a way for people who were going to be noisier even when they showed up. Because you’re optimizing for a person who maybe does have a very specific job that it is that they can fill at the time.

And so it just looked very different than I think Jane Street where we try to optimize for something that looks very different.

Ron

Internally, things are very dynamic and entrepreneurial, and at times we decide it’s like, oh, this is more important than that, and we’re going to move a bunch of people around and change what we’re working on. It’s actually as a slight aside, it’s fairly common that we have restructuring of how teams are organized or who works where or moving people around. And at some point I realized I had to be very careful in talking about this with people from some other firms where there’s a reorg and they grip their desk and be very nervous. I’m like, “What did I say?” We reorganize things all the time. It’s fairly chill. Then I realized there’s a lot of places where reorgs are a bad thing. It’s like the way in which you get the job that you like taken away from you and you end up with a new job that you don’t like anymore and all sorts of terrible things.

But I actually think being in an environment where small scale reorganization is happening kind of continuously and all the time is kind of great. My job’s been really different over many years. I’ve worked in lots of different groups doing lots of different things. I think it’s true for a bunch of people. And just the shape of the trading desks and the tech groups and all of that has just morphed a lot over time. And we’ve done even at the pure level of the technology we choose, we have optimized in the direction of people’s flexibility. The fact that we have tried to keep the number of programming languages down is a real thing. I’m super glad we added Python, even though it’s like, I don’t know, it’s not my favorite language in all the ways, but the ecosystem for ML and stuff is incredibly valuable. It’s been super useful to have.

It’s been a lot of work to make Python well supported here.

Even just having two languages can reduce people’s flexibility some of, oh, they spent all their time here only working in one language and maybe they don’t know as well, or maybe they’re not psyched about working in the other language. And even there, we’re trying to move into a world where people more broadly know both so that they can do whatever is important and not pick the technology because they happen to know it, but pick the technology because it’s the right one for solving the particular problem. And I think that flexibility has been incredibly valuable. And at a human level, having people who are themselves strong generalists has been really good. And also we’re big enough that some amount of specialization is totally called for. We have hardware engineers, right?

Chloe

Yeah.

Ron

Our hardware engineers are actually unusually good at software. It’s actually a weird thing that most hardware engineers in the world don’t think like software engineers at all, even though you’d think they’re very similar things, but they’re really very different in a lot of ways. And I think in many ways I feel like hardware engineering just seems harder and more intellectually challenging than software engineering. But it is surprising, a lot of hardware engineers are not comfortable writing recursive functions where I feel like writing a recursive function, that’s the easiest thing in the world. But that’s super not how they feel about it, and they do stuff that seems super hard to me. In the end, we end up hiring hardware engineers who are much more like software engineers. But they’re still in practice, it’s mostly a waste of their talent to have them work on pure software problems.

The right thing for them to be working on is hardware. So in that sense, they’re less fungible even if they have a lot of the skills that would let them do the other things.

Chloe

Yeah. I think you see the same thing in our front end engineering pipeline at Jane Street as well. It’s like a lot of our front end engineers actually totally could go and be writing backend code if they wanted to, but it’s like they do have this specialization that is super useful for Jane Street and very, very valuable.

Ron

And there’s a weird thing in which the outside world has somehow decided that front end coding is kind of second class. And you get lots of kids out of school saying, “I don’t want to do front end stuff. I wouldn’t want to be pigeonholed to doing front end things. Those are the bad things.” And it’s so cool. Front end stuff is really interesting. It’s actually really challenging to figure out how to design performant and flexible UIs and building good abstractions in that context is actually really quite interesting, but it’s somehow weirdly low status for reasons I don’t quite understand.

Chloe

I don’t get it. I also think especially as a person who’s very user motivated, I think that sometimes you go and talk to someone and they’re like, “All I want is for this button to be blue.” And I’m like, “I can make your day.” That is just so fun because there’s this thing about front end engineering, which is there is these iterations with users that you can just have so quickly.

At least one interview that someone can crush (01:31:17)

with Chloe Casale

Episode 32 | November 13th, 2026

BLURB

SUMMARY

CONTENTS

TRANSCRIPT

Racing 1,000km across Mongolia (00:00:03)

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

From auto shop to CS on a $20 bet (00:05:18)

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Forward-deployed engineer at Palantir (00:09:41)

Chloe

Ron

Chloe

Ron

Chloe

Why Jane Street (and why London) (00:12:23)

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe

Ron

Chloe