00:00:05

Ron

Welcome to Signals and Threads, in-depth conversations about every layer of the tech stack from Jane Street. I’m Ron Minsky.

So, this time we’re going to do something a little different than our usual episode. Instead of digging in deep with one person talking on one focused technical topic, we have a few people here today and the topic is a general one, which is we’re going to talk about Jane Street’s internship. So we have three people who know a lot about it in that they’ve all gone through the internship before: Grace Zhang, Jeanne Van Briesen, and Matt Else. And we’re going to talk with them about what their experience was like, both at the time of the internship and also how that transitioned to being a full-timer here, how that worked.

So, to start with, let’s have you guys all introduce yourselves and tell us a little bit about where you’re from and where you guys are now.

00:00:49

Grace

Yeah, of course. I’m Grace. I just graduated from Harvard this past May. I studied CS and Statistics at school, and I just joined Jane Street full-time pretty soon after graduation. I am a software developer on Risk, which is also a team that I interned on last summer. So, I am back in the Jane Street New York office full-time, and excited to be back since I’m also from New York originally.

00:01:12

Ron

Although these days not quite the same notion of office as we used to have.

00:01:16

Grace

That’s right. (laughter) Perhaps you don’t really get the feel of the difference between the New York and London offices so much these days. (laughter)

00:01:23

Matt

Yeah. I’m Matt Else. I work in the London office, and I graduated from Cambridge in 2019 and started as a full-timer around September 2019 after interning in the summer of 2018. I now work in a team in Trading Systems where I’ve worked since I started as a full-timer.

00:01:43

Jeanne

And I’m Jeanne. I graduated from Carnegie Mellon about a year ago. I interned two years ago now, and I currently work on a team called RFQ.

00:01:51

Ron

So, Jeanne, how did you hear about Jane Street?

00:01:54

Jeanne

I heard about Jane Street through Carnegie Mellon’s functional programming class. People would always ask questions like, “Oh, when is functional programming going to be useful?” And then they would say, “Oh, but don’t say Jane Street because we know they’re the only one who uses functional programming.”

00:02:04

Ron

It sounded like you said Carnegie Mellon’s functional programming class as opposed to Carnegie Mellon’s functional programming cult.

00:02:13

Jeanne

Well, the functional programming cult sort of originates from the functional programming class maybe.

00:02:15

Ron

(laughter)

00:02:16

Jeanne

Yeah. CMU has quite a big programming languages group and quite a few functional programming classes, and there’s a lot of hype for functional programming there. I was one of those people who both bought into the hype and was perpetuating the hype.

00:02:31

Ron

In fact, you literally taught a class called “Hype for Types.”

00:02:32

Jeanne

This is right. Yeah. That class is still going on now. So, there have been three generations of instructors now. It’s still going strong. So, yeah, applying to Jane Street was really a no-brainer for me because it was a place that was known for doing functional programming.

00:02:49

Ron

Okay. Great. I feel like you act as an effective representative of a small but important set of people who apply to Jane Street because of an unhealthy interest in functional programming. Grace, how about you?

00:03:01

Grace

So, Harvard also has a functional programming class, but we just have one. That was definitely a good start to spark my interest in functional programming, and Ron also came and gave a short talk on using OCaml in the real world, which was actually pretty cool because that was certainly a question a lot of us had coming into the course. I eventually got to know Jane Street through INSIGHT, which is Jane Street’s program for women in STEM. There are different tracks. So, I did the dev track at INSIGHT and it’s pretty cool because I think it gave you a good sense of what it’s like to work at Jane Street and work with the people at Jane Street. INSIGHT is a week-long program where they bring you to the Jane Street New York office and you go through something like an OCaml bootcamp where you do different exercises to learn about OCaml and get a taste of the kind of work that we do here at Jane Street, and I thought that was really cool. I really enjoyed working with the people at INSIGHT and I felt like I got to see a lot of the culture at Jane Street, which was really exciting. I applied to Jane Street to be an intern last summer and am now back full-time.

00:04:04

Ron

By the way, now that you’re here full-time, have you gotten involved in INSIGHT from the other side?

00:04:10

Grace

Yeah, that’s pretty cool! INSIGHT is during January, so I haven’t quite done it yet, but I will be helping out with INFOCUS and I’ve also helped out with some of the other programs. So, it’s pretty exciting to be on the other side of things because I think these programs are really important and really help spark an interest.

00:04:25

Ron

Right, and when you say these programs, these are like various kinds of outreach programs essentially. INSIGHT is aiming for reaching out to women, there are some that are aimed for trying to get at various non-core schools – we have overrepresented from like a small number of schools where we get a lot of people – and trying to branch out, and there’s some programs we’re working on for underrepresented minorities. So, there’s a bunch of different efforts in different directions there.

00:04:48

Grace

Yeah, yeah, yeah, yeah – really excited to be part of it.

00:04:49

Ron

Great. Matt, how about you?

00:04:51

Matt

Yeah. So, similar to both Jeanne and Grace, I’d done a little bit of functional programming at university, and I guess unlike Jeanne, the cult of OCaml doesn’t stretch quite so widely at Cambridge, but it was certainly something that I had come across and kind of enjoyed, but the main reason I applied for an internship at Jane Street was because a friend of mine, who at the time was a visiting student from MIT, had done the internship the summer before, told me all about it, told me how much fun it was and how interesting it was, and generally just kind of made me want to apply as well, and as it turns out we’re now both full-timers here at Jane Street.

00:05:24

Ron

That’s great.

So, one thing that immediately strikes me from these stories is that you guys are a little unrepresentative in that you’ve all had functional programming experience, and maybe all programmed specifically in OCaml before coming here, whereas I think in reality if you sample incoming interns, a quite solid majority I think haven’t done any functional programming at all, which is actually a pretty big change from what recruiting was like 12 years ago or something where I think at that point we leaned pretty heavily on, “Hey, we program in this interesting functional programming language, so maybe you want to come work here anyway,” and now we have lots of other ways of attracting people, and so the functional programming part is much less of the thing that brings people in the door, and indeed I think people often think to come work here they have to already know OCaml, which is totally not true, and in fact people sometimes think they should interview in OCaml, which is also almost always the wrong idea because there’s really a very small slice of people for whom OCaml is the language that they can best show what they’re good at, and people who choose to use OCaml to please us often discover that it is not a very effective technique.

Anyway, I was wondering if you guys could say a little bit more about how the internship worked. What’s the basic structure of the internship?

00:06:32

Grace

Yeah. So, I guess I can talk about it first since it’s perhaps a little bit fresher on my mind than for Jeanne and Matt.

I interned last summer, and I think I really enjoyed Jane Street’s internship structure actually. I think that was one of the first things that I think I was pretty excited about, which is Jane Street’s dev internship is structured so that you can work on two different teams and oftentimes they are like two teams that are spread across the firm. That was really nice. So, for example, I worked on the larger trading systems team and also post-trade, and I thought that was pretty cool. It kind of gives you a better sense of the firm as a whole and kind of gives you a little bit more exposure there.

So, I think it was really nice to have been able to intern on two teams, and also the internship is structured, like Ron mentioned before, so that it doesn’t assume that anyone comes in with any OCaml knowledge. So, the first I think week or so of the internship, we did an OCaml Bootcamp, which is a way to help people learn the kinds of tools and the language that we use at Jane Street, which I think is pretty exciting, and it was really cool because, you know, the internship class does it as a whole, and so it was nice to start off your internship with the rest of your class and all go through this together.

00:08:08

Ron

That’s a lovely thing about the internship that I think wasn’t clear to me until it just kind of happened is how nice the community of people who come in all at the same time, all knowing nothing about the organization and about the technology, and just come to be friends with each other, and that’s I think been a very positive experience for lots of people over the years.

00:08:23

Grace

For sure. That was a great way to introduce us to each other and build this internship community. I think that’s definitely one of my favorite parts as well because once you finish OCaml Bootcamp, all the interns sit next to their teams and mentors, and so you’re kind of more spread out, but it was really nice – I sat close to a few different interns, and you know, sometimes when you’re super caught up in the code you’re writing, you might forget that you have an intern event coming up or something. So, we always grabbed each other to go to the events, which was great because otherwise I think some of us may not have made it to them. That was really nice, and yeah, I think OCaml Bootcamp in general is also really a great start to the program because your first mentor is the one who’s reviewing your code and who’s kind of working with you, and you go through the code review patterns that you would go through once you start on your project, and so it gives you a good way to get settled in your new team.

00:09:11

Ron

How hard did you guys find it to acclimate to the tools? Like, a side effect of the fact that Jane Street uses a comically obscure programming language is that we have also invented a comically large number of idiosyncratic tools for working with that programming language, and I’m curious how you guys found it to acclimate to a bunch of tools that you hadn’t used before.

00:09:29

Matt

Personally, I certainly found it kind of a challenge. It was one of the more challenging things of first starting was getting used to all of the tools, and to some extent to kind of dealing with all of this institutional knowledge that is kind of in people’s heads that may or may not be written down and can be sometimes quite challenging to access, but once you get over this initial hurdle of figuring out these tools and figuring out how to find out more information about these tools, it wasn’t too bad and you kind of adjust to it fairly quickly. I don’t know what you guys thought about it.

00:09:57

Jeanne

I also thought the classes that they do for interns, like the tech classes that are about our code review tool or some of the libraries with a steeper learning curve, really helped us get on board better than maybe just doing our projects would have.

00:10:10

Ron

Yeah. I think over time we’ve realized that we needed to build more of a kind of formal education program. It’s one of these things where we built out formal education programs in stages. I think the first one we built, the program that was called “OCaml Bootcamp,” was initially designed primarily for traders who needed to learn how to get comfortable with the technology that the tech side had been building, and then we repurposed that material and started using it for teaching interns and started developing more material for that purpose, and now we use some of those same materials and in fact a bunch of other stuff that we’ve been developing as part of a longer-term teaching program for people who start full-time, in that as the organization grows you come to realize there’s more specialized knowledge that becomes valuable to share between people and across teams, and so it just makes more sense over time to build up more of that.

I guess the other thing that you have to come to grips with that you guys haven’t talked about yet is the whole finance side of things. How well did the program prepare you for having to deal with projects which are about a subject matter that you presumably had no experience with before?

00:11:12

Grace

We had lots of classes, which I think was really helpful, and we had, for example, some traders give an overview of finance and economics, things like that. So, I think that was really helpful to paint kind of broad strokes, but I think what was most helpful was just that we worked very closely with our mentor and the teams that we’re on, and I think my mentors both did a really great job of providing the context to help me understand where my project fits in and how it’s useful for the firm, and I think that was very valuable and helped me understand the motivation for my project and also just think about how I would want to design it and work on it.

00:11:47

Ron

So, maybe this is a good time to talk about actual projects. So, can you tell us about one of the projects that you worked on as an intern?

00:11:56

Grace

Yeah. Of course. One of the projects I worked on was Jane Street’s manual order entry system. It allows traders to manually enter orders into the market and has lots of different risk limits, which is important because, you know, you need to think about the risk of just actually sending trades out to the market. For example, like a risk limit might be something like, you know, we can’t fill more than say X dollars in a day, and these risk limits are at different scopes. So, it could be at the user level, but it can also be at the system level, and so the state of the world before my project was that traders could easily adjust their user limits very quickly during the trading day, but we were not able to adjust our, for example, system level limits very quickly during the trading day, which is important and something that people had been asking for because during a busy trading day you might need to increase your risk limits during the day, and in general you want to do things quickly, but especially during like a busier trading day.

00:12:48

Ron

Okay. So, that raises something that’s maybe worth explaining, which is this whole idea that traders might just like go and directly up their own limits seems kind of odd. Like, on the face of it, you would think if a trader has a limit then they wouldn’t be authorized to just go past that limit, but it turns out the way we have our risks system set up, there are really multiple different kinds of limits and some of them really are hard limits that, you know, when you bump up against it, that’s it, and you have to get someone else to authorize an increase if an increase is necessary, but there are other limits that have a preconfigured number of times that a trader is allowed to essentially bump their limit. So, this kind of limit acts more like a speed bump than like an absolute barrier on further trading, and as you said, when you hit one of those limits it’s really important to be able to move past it quickly because the time when that’s likely to happen is exactly when trading is busy and therefore when trading is at its most valuable.

00:13:40

Grace

Yeah. Exactly. You’re able to increase your limits like a configurable number of times, and we wanted this same behavior for limits at other scopes.

00:13:49

Ron

And prior to you doing this work, what did the process look like when you did need to increase those system wide limits?

00:13:55

Grace

Prior to this, someone would need to go in and actually make a change to the way we’ve configured our limits and actually go through a process that is basically code review. So, they would need to update the limits. They need to get it code reviewed by someone else. They need to then release and apply this actual change, which is like a slightly slower process.

00:14:15

Ron

Amusingly, our process for changing risk limits is exactly the same process that we use for modifying code, which is not obviously the natural thing to do, but I think over time we came to realize that it was in fact more or less the same thing in that we have a bunch of configuration, which is a big technical document with precise technical meaning that people need to make changes to, and many years ago the way we did this is when different people wanted to propose limits changes they would literally – like an old, traditional Linux developer – they would generate a patch representing the change that they wanted to make and send that to the trade support people who would then manually apply that patch to the code base, acting kind of like a human version control system, and then multiple people would do it at around the same time because things were busy and lots of people want to do it, and if it sounds like a nightmare it’s because it kind of was. So, now we have this much more organized process that looks a lot like the code review process, which I think makes sense for changing the core risk limits, but you, obviously as you said, you want to have some fast path for simple changes and that’s exactly the thing that you worked on.

00:15:11

Grace

And it was pretty exciting because when I came back full-time I realized that my old mentor emailed me basically like my first or second day, and forwarded me an email that where a trader said something like, “Today we had a really busy day of trading and I needed to increase our risk limits quickly and I was really excited to be able to do so,” using the project that I worked on, and that was just super nice. My mentor was like, “Yeah, my intern worked on it. I’ll be sure to forward it to her when she joins full-time!” and it was just great to see and great to hear from my mentor when I got back full-time. A very warm welcome back to Jane Street. (laughter)

00:15:46

Ron

Right, and this highlights I think a lovely thing about a lot of the intern projects, which is interns get to work on real things, and a lot of those projects actually land, not all of them, but a lot of those projects end up landing in production, and I guess this one did.

00:15:57

Grace

Yeah. It was super exciting. Always good to see people are using and benefiting from your work.

00:16:03

Ron

Matt, how about you? Can you tell us about one of the projects that you worked on?

00:16:05

Matt

For the first half on my internship I worked in a team called RFQ, which you might remember from Jeanne talking earlier. She now works in that as a full-timer. So, when people think about trading shares and ETFs, and securities in general, you probably think about sending an order to an exchange, like the New York Stock Exchange or the London Stock Exchange, but there are other ways of trading that are preferable maybe for really large trades or for technical reasons where you might want to trade directly with a company such a Jane Street, and so historically the way that this would happen is you would pick up the phone and call Jane Street and say, “I want to buy Apple,” let’s say, and Jane Street would say, “Well, I’m willing to sell you Apple for this amount of money.” There would be some sort of back and forth and maybe the trade would happen or maybe it wouldn’t, and over time people gradually realized that, “Oh, it would be kind of useful to be able to automate the system,” and so there was this thing called RFQs that were developed, which is an automated way of someone saying, “I want to buy this thing,” and then sending this “request for quotes” to a whole bunch of different market makers and seeing what price they were willing to trade for. And so Jane Street developed a way of interacting with this automated system that at first involved another person at Jane Street responding to these quotes, and then gradually developed into a more automated system with risk checks, similar to what Grace described with her project.

00:17:23

Ron

If I can just interrupt – I think this all highlights the fact that trading is way more manual than I think people (especially people who know about Jane Street by paying attention to the technical side of the work) imagine that the entire place is just like, you know, a bunch of people built some algorithms, and there are people thinking hard about the algorithms during the day and looking at the results of week-long experiments, and then, on their way out the door they check it like, “Oh, how much money did we make today?” And oh my God, it is not like that at all. There’s a huge amount of human judgement and intervention, and also just stuff that’s manual, like we have manual order entry. You just go, and you know, directly type in exactly what price and size you would like to trade at. The human just makes that decision directly, and we have lots of things that have human involvement and communication, and then we do a lot of work to automate various aspects of this, but it’s not like we want to completely get rid of the human element. The human element and the judgment that comes in there is actually incredibly important to how we operate.

00:18:23

Matt

Yeah, definitely. This is something I probably didn’t realize before I started at Jane Street, the amount of human interaction that’s involved. You still have lots of people making trades over the phone, especially for big trades, and you have people making manual trades and making tiny manual adjustments to trading systems throughout the day. But anyway, so, we have all of this automated infrastructure for doing this trading directly with counterparties, but still a lot of this trading happens over the phone, and so we built all of this automated infrastructure, so, we at some point decided that we were going to add a way that a sales trader who’s on the phone with a counterparty could ping our automated system and say, “Right, how much would we normally trade this for if it was on the automated system?” And then, they have a number that they can base their trade on…

00:19:03

Ron

Right. Essentially a chat system almost, which lets the sales trader understand where the automated systems are willing to buy and sell and use that to inform their own trading.

00:19:13

Matt

Yeah, Exactly. And so there’s a sort of implicit risk check here that you have a human interacting with the trade in the middle, but this didn’t use the same automated risk checks that we had all for the automated trading just because there was kind of no need to because we have a human who is thinking about this trade in the middle, but at some point we realized that it seems kind of silly to have all of these risk checks and then not use them for this one weird case, and so the project that I was doing was to make these manual requests to the system behave more like automated requests, as though they were coming from a counterparty over some automated system. As a result, we would get all of these fancy risk checks for free.

00:19:52

Ron

So, basically there was a system which has two different kinds of requests, one fully automated, one that was just kind of providing information to a sales trader, and take the risk system that applied to just part of it and apply it to the whole thing. In some sense, that sounds relatively simple. I’m curious, what were the interesting and challenging parts of that as a project?

00:20:09

Matt

I think for me getting my head around all of this complex infrastructure that took me like five minutes to just describe after I’ve spent a year working here and kind of have some background… It was getting my head around all of this finance-y stuff in the space of a few weeks because you spend two weeks learning OCaml, and then immediately you are working on this project about something that’s completely opaque to you, and this was a pretty big challenge to me, and it took a lot of input and discussions with my mentor, who was really helpful and really willing to answer questions, for me to just get my head around what on earth are these things called RFQs and why do I care about them, effectively, and why does Jane Street care about them, I suppose. So whatever technical difficulties I had were kind of dwarfed by just getting my head around the basic concept of what I was working on.

00:20:56

Ron

The other thing that strikes me about actually both your and Grace’s project is that they’re both working on risk systems, which could make you a little nervous of like, you know, have a couple of – no offense – know-nothing kids out of school who are coming and working on…

00:21:09

Matt

(laughter) Oh, that’s an understatement. Yeah.

00:21:11

Ron

(laughter) … working on some pretty core things that are really important to the safe workings of the business, and I think in part this is just a story about the approach that we have towards essentially the quality control aspects of how we build software, which is there’s this very intense code review process where the people who are reading and approving of the code, the process involves them really deeply understanding what’s going on. It’s not like you throw up a patch and they’re like, “Looks good to me,” and approve it. No, they are reading it through carefully, often rewriting various pieces of it, giving detailed feedback on various parts to the point where the person who reviews the code often feels like a second author rather than being just someone who kind of looked it over and checked that it was okay. A nice advantage of this system is it gives you a way of taking people who don’t have that much context and don’t have that much experience and letting them work on a wide variety of different places, including places that are quite critical.

00:22:04

Matt

Yeah. This is something I’ve particularly noticed since I’ve been a full-timer: this code review process where someone is effectively coauthoring your patch for a particular library or a particular application can teach you quite a lot in the process of doing code review, which I found really useful.

00:22:20

Ron

Yeah. I think of this as like one of the key advantages that a company like ours has over academic institutions in terms of teaching people a technological concept, which is this kind of intense, high investment thing that you do where an experienced person works with a more junior person and works very closely with them and gives them this very detailed feedback. It’s the kind of thing that from a cost structure point of view you can’t do in an academic context, but it totally makes sense because the people who come and join are very close to being very useful and so it really rewards your investment in them, and you can teach people stuff really fast and I think that teaching works well when you have someone who’s very new to the organization, but actually is a way that as time continues and you’re here for longer you continue to learn a lot from people through the process of code review, at least that’s been my experience.

So, Jeanne, we haven’t gotten to you yet. Can you tell us something that you worked on while you were an intern?

00:23:09

Jeanne

Yeah! So, for my second project of the summer I worked on the Tools and Compilers team working on a library called Incr_dom, which is Jane Street’s library for building dynamic web apps in OCaml. So, Jane Street doesn’t have a ton of external facing websites, but we use web apps as a lot of user interfaces for various trading systems, and one of the things that’s very important for web apps in general, but also especially for trading system interfaces, is that if something changes on your web page you don’t want to have to re-render the entire web page. You know, imagine you have like a million cells of various bits of information for your trading system, you don’t want to be re-rendering that every time something updates because that would be incredibly slow. So, Incr_dom is built on top of Jane Street’s Incremental library, which is a library that handles computations that you set up once and then when their inputs change they only recompute the thing that they need to in order to get a new output. So, in this way we manage to avoid doing any extra computation that we shouldn’t do in order to render the view on a webpage. When I started my internship, the way Incr_dom was set up was it had two different types of interfaces. One was a relatively simple interface that most web apps used that didn’t sort of take advantage of the full power of incrementality that you could get out of this Incremental library. So, you could sort of compute some things incrementally, but not everything. The other was a very complicated interface, sort of an advanced interface, that could take advantage of sort of the full power of incrementality, but was more complicated to use, and at least in my impression, you only used it if you really had to. So, my project was to take these two interfaces and combine them into one more usable interface that still allowed you to have just as much expressive power as the more complicated interface.

00:24:30

Ron

Full disclosure: I was the mentor for this project, so, I kind of know (laughter) an unusual amount about this one in particular, but I’m still curious about some aspects of it.

So, one thing that strikes me about your description is it’s very design-y, right? You’re like, “Oh, there are two APIs, like one of them is bad in this way, one of them bad in the other way. Come up with one that’s good.” I’m wondering how you found the process of going from this like fairly high-level complaint about it to coming up with an actual concrete design that made sense.

00:24:54

Jeanne

It was very tricky and also very educational. I think I had never thought about any sort of API design before that project, maybe like very small things at college, but really it was just not something I had learned. So, it was really very much a learning process trying to understand how you should design an interface. Like, what actually makes a good interface? It was not what I expected to be doing as an intern project. I think I sort of expected to be told to write some code and then to write some code, but I actually got to think a lot about how this was designed. So, that was way more freedom than I expected.

00:25:32

Ron

And I want to be clear: When we gave you the project, I did not know what the right answer was. It was not like, “Oh, yeah. We want it to look like this, and please, Jeanne, go ahead and make it look like this.” It was like, “Oh, this is kind of terrible, and we have some ideas, but we don’t really know if they’re right,” and I had ideas that I thought were pretty likely to work out, and they mostly didn’t and you ended up doing something pretty different from the original direction I was imagining we’d go.

Okay. So, you got to do a bunch of this API design work. I guess another aspect of your project I remember is you got to also work on a PPX. Can you talk a little bit about what a PPX is and how that fit into the project?

00:26:01

Jeanne

So, OCaml has this thing called PPX, which essentially allows you to extend OCaml’s syntax. There are these little tags you can put in the code and then you can write some code that will take one piece of syntax and transform it into another piece of syntax before compilation happens, and so the particular PPX that I got to write was one that made it a lot easier to use like a particular commonly used idiom in Incr_dom. It was previously done in a pretty gross way that involved raising exceptions and stuff like that, and the PPX allowed you to write it in a way that was much more nice and took advantage of some of OCaml’s good features.

00:26:40

Ron

I think of PPX as basically a kind of simple form of language extension, and we have a bunch of PPXs, some of them for doing things like auto-generating comparison functions or hash functions for standard data types, but the kind of PPX you were working on are PPXs that basically almost add primitives for making certain kind of embedded domain specific languages fit more easily and naturally into the language so it kind of looks more like ordinary OCaml with a few extra special magic annotations indicating what’s the special thing you’re doing in this case, and you basically added some new magic invocations that extended the set of idioms that were expressible in this domain specific language. So, what was the process like of working on this more complier-like part of the system?

00:27:23

Jeanne

It was actually surprisingly smooth. There’s some like very good libraries out there that make it very easy to do transformations on OCaml syntax, and so I sort of learned how to use those and I had worked with abstract syntax trees before. So, I sort knew a little bit of what was going on, but there were definitely some tricky things like getting the source code positions to match up properly between like the old tree and the new tree and stuff like that.

00:27:51

Ron

Yeah, and what you’re talking about here is essentially one of the complexities of adding a new syntactic construct to a language in this way, which is to say there’s some new bit of syntax, some syntactic sugar you want to add to the language, and you do that by writing a de-sugaring function, something that takes the new syntactic construct and de-sugars it, translates it into some existing syntax in the language, but the tricky bit is then when you have an error in the de-sugared version of a code, you need to translate that error back to the original so say your editor can point to the right place when you have a compilation error, and it’s all too easy to mess up the locations in the course of writing the de-sugaring. Anyway. I’m curious, what was the process like of taking all this work that you did and trying to land it in production?

00:28:37

Jeanne

After I wrote the interface and all the code behind it and everything like that, I then did a big tree smash on all of the projects that currently use this library to convert them to use the new interface. I basically went through our whole repo, found every instance where this was used, and changed it to use the new thing. So, I got to dive into a little bit of every single web app that was currently in use and change it up so that it used the new interface. And yeah, it’s actually still in use today. There’s a couple of successors to it that are sort of built on top of the interface that I designed, but it’s still alive and going even now.

00:29:13

Ron

So, you guys were all interns and now you all work full-time. I’d be interested in hearing a little bit more about what that transition was like.

00:29:19

Grace

Yeah. I guess the transition was pretty recent for me, though I did learn that a year is long and I have forgotten much. The project that I’d worked on during my internship was an options pricing app. So, it prices options for different scenarios. So, for example, like if Apple were to go up by like X percent, what would the price of this option on Apple be? And so, over my internship I worked on a bunch of different features, and I am back on the team that I interned on. So, I spent a lot of time reviewing the code. It was very interesting when I was like, “Oh, I wonder who wrote this?” And then did a quick blame and realized I wrote it, and I was like, “Well, I have no recollection of this at all!” (laughter)

00:30:05

Ron

Yeah. This is process by which you learn how important it is to carefully document your code and make it really clean because sometimes there’s, you know, some annoying person later who’s going to come by and have to understand it, and that annoying person might be you. (laughter)

00:30:17

Grace

This is true. (laughter)

00:30:19

Ron

After you’ve forgotten all the details.

00:30:21

Grace

For sure.

00:30:23

Ron

It feels like your experience is a really good, controlled experiment in that you worked as an intern on a project and then you worked on that same exact project as a full-timer.

00:30:29

Grace

Yup!

00:30:30

Ron

So, how does that transition feel? What’s different about being an intern versus being a full-timer? How do those experiences compare?

00:30:40

Grace

I think in some ways, honestly, like an internship is very representative of what it would be like if you were to work full-time at Jane Street. I think that’s something that I liked a lot about the internship at Jane Street, which was that, you know, you don’t necessarily feel like you’re an intern. You know, I think it’s always really nice to feel like you’re part of the team and you’re actively contributing and that, you know, your ideas are valued, and I think that really came through in the internship.

Intern projects feel much more scoped out. Your mentor probably has a pretty good sense of how long these things might take and a good direction and probably a sense that, you know, we can get there eventually. I think as a full-timer you have more time. So, things you’re working on can have a longer timeline and they often can be more open ended, and I think that’s definitely come through.

00:31:20

Ron

Yeah. This sort of highlights that actually picking intern projects is actually quite hard because you want to pick something we legitimately want, something that we haven’t done yet, and something that – I guess the way I like to say it – it has a favorable surface area to volume ratio, which is to say you don’t have to like dig into like a billion other systems just to figure out the part that you want to write. You want there to be like a relatively meaty piece of code that can be written by someone who’s pretty new to the organization, and these different properties fight against each other. If we want it and it’s well scoped out and it’s not incredibly hard to do, we’ve probably already done it. So, you need to, in some ways, look pretty hard to find things, and I feel like this sometimes leans in the direction of intern projects that are a little bit more ambitious. It’s a little more speculative, and we think it’s a good idea, but it’s not quite to the top of our priority stacks or we’re not totally sure that we want it.

00:32:08

Grace

For sure.

00:32:10

Ron

I’m curious for Jeanne and Matt, how did you find that same transition?

00:32:12

Matt

I can definitely agree with what Grace said about getting back as a full-timer and being like, “Wow, there’s a lot of things that I’ve forgotten that I thought I knew.” Just like relearning all of these tools that you got used to as an intern and suddenly they’re kind of all foreign and completely new to you again is kind of weird and a little bit unsettling when you first come back as a full-timer because you think, “Oh, I did all of this when I was an intern. It’s going to be easy,” and then you come back and it’s just like everything, I have some muscle memory for some Emacs shortcuts that I can remember from when I was an intern, but that’s about it. (laughter)

00:32:41

Ron

Also, we’ve helped by changing a bunch of things in the intervening year! (laughter)

00:32:46

Matt

Oh, yeah, that’s super helpful.

00:32:48

Ron

(laugher) They are usually better when we change them.

00:32:50

Matt

That is true. That is true.

00:32:51

Jeanne

Oh, funny thing: I didn’t come back to the team that I interned on. I did come back to the team that Matt interned on though.

00:32:58

Matt

Oh, yeah. I didn’t go back to the team that I interned on either. So, I guess we just kind of shuffled around.

00:33:02

Jeanne

I’m actually currently rolling Matt’s intern project into production.

00:33:09

Ron

That’s amazing.

00:33:10

Jeanne

So, I guess that’s also a thing that –

00:33:13

Matt

It’s been so long! (laughter)

00:33:14

Jeanne

It’s a little bit of a tricky thing to roll into production because it requires coordination between a lot of groups and things like that. So, it’s not surprising that it’s taken so long.

00:33:22

Ron

Right, and I think that does connect to the fact that intern projects, for the reason that I mentioned before, are often chosen to be things that are not super, super urgent because if it was really, really urgent you probably would have done it already.

Have any of you guys been involved in picking projects for interns now?

00:33:38

Jeanne

It definitely gave me a lot of respect for the people who picked my intern projects. I went through multiple different projects trying to find something that was both interesting enough, didn’t require a lot of context, and wasn’t super urgent, and also wasn’t a web UI because I guess those aren’t allowed for interns.

00:34:01

Ron

Wait, that’s a funny thing. Why aren’t web UIs allowed for interns?

00:34:05

Jeanne

I guess interns don’t enjoy writing them. So, we’re not allowed to propose web UI projects, which was my first project proposal. So, I had to go then pick another project.

00:34:13

Ron

I didn’t know we’d gotten quite to the point of like not allowed to propose, but there’s this funny bias that I think people come in with where they think UI work is somehow low class and not interesting, and I think this is totally insane. I think web UIs are actually super interesting. There’s often lots of beautiful questions around API design and around how to appropriately build something that both does the task it needs to do and presents a useful UI, but also does it in a way where the code itself is easy to understand and extend and not likely to have bugs. I think in the outside world there’s a feeling of, “Oh, yeah. We’ll just like treat this as a low-class problem, and if there’s someone who doesn’t know anything we’ll throw them at a web UI and they can’t really get anything wrong there anyway.” I do not understand why the world has this set of views about web UIs, but it seems to and I think interns often come in, they don’t always say it because people are nice, but people are often like disappointed when they’re asked to work on this part of the infrastructure.

00:35:08

Matt

Yeah. It’s not like your intern project at Jane Street is going to be like adjusting the padding between these two buttons on a web UI, right?

00:35:11

Ron

That’s right. If your whole –

00:35:13

Matt

Like, it’s going to be something more concrete.

00:35:15

Ron

Right. If your whole project is modifying CSS, I could see why you’d be pretty sad about it. (laughter)

So, what did you end up finding?

00:35:22

Jeanne

One of the things that we do when we receive an RFQ is we do a whole bunch of validation on it to make sure that like the message we received is well formed. It has all of the right fields. We have enough information to know how to quote it and things like that, and if we find something slightly off about it, one thing we’ll do is we’ll freeze it. So, we won’t try to quote it until a trader acknowledges that yes, this is safe to quote.

00:35:46

Ron

Okay. Going back to the importance of human involvement in decision-making around trading.

00:35:50

Jeanne

So, one of the things we wanted to do was we wanted to get more information into our UI to show to traders when they made the decision on whether or not to unfreeze these RFQs and actually allow us to quote. So, one of the things in particular we wanted them to be able to see was what we would quote if they allowed us to quote it, and this required a whole bunch of changes to a couple different systems to sort of reroute things and allow us to actually see these quotes, and so that was going to be the intern’s project. It didn’t end up happening because of COVID and I ended up doing the project, but…

00:36:23

Ron

(laughter) So, you didn’t get to see end to end quite how it worked out. Well, I guess to be clear, COVID caused us not to end our internship program, but to rearrange it pretty seriously, and this year we ended up instead of having every intern go through two teams, for mostly because of time constraints, we ended up having interns stay in one team the entire summer in this odd circumstance where everyone was totally remote.

00:36:46

Jeanne

In this case it was our spring internship where they only did one project and then COVID hit, so then we sent them home. So, I had an intern for one day.

00:36:55

Ron

I bet at the end of having scoped it out as an intern project you had a much better idea how to actually get it done.

00:37:00

Jeanne

Yeah. It was great. I had already thought through the whole thing.

00:37:01

Ron

I also wonder how being a full-timer feels different in terms of the kind of decisions that you end up making. I think as an intern a plate is set for you. We figure out what’s the thing that you’re going to work on and why it’s important, and as a full-timer you end up having more to do in deciding what’s important and actually making choices about the systems that you’re working on.

00:37:22

Grace

It is true that you are often making a lot of maybe perhaps larger decisions as a full-timer, but I also want to say like just I feel like even as an intern I think you also have a lot of voice in what you’re doing and what you’re working on and how you want to design it. I think this is something I really liked about Jane Street’s culture, which is that it’s super open-minded and it’s very collaborative, and I think people are always interested in what you’re thinking about and always open to a conversation about if you think something should be changed or if you think that something might work differently, and I think this is definitely true full-time.

I think this was particularly apparent for me recently because I’m working on a larger project to help deal with the load that we’re experiencing. My previous mentor was the one who like knows a lot about it, and so he’s already written up a design doc for this and it’s interesting because as a new hire you’re paired up with a navigator who is usually someone on a different team just to kind of get another perspective on life at Jane Street and to field any questions you might have and to share their experiences, and I was talking to my navigator and he mentioned his intern was working on some supporting client site caching for Redis, and he was saying, “You know, maybe you could consider using this.” I was like that sounds cool, and I think this was also kind of an example of the cross-team collaboration that we have at Jane Street. It’s always really cool to talk to people and learn about things that you didn’t really know were available before, and like we had already scoped out the previous library we were going to use and we had a sense that it was very well supported at Jane Street, but it did seem like Redis was actually a better choice for our use case, and once I had convinced myself of that I brought it up to our team that, you know, we actually have this available as a library now, and it was really cool because everyone was super supportive. They were like, “Oh, I didn’t know this was available, it sounds really cool,” and there are lots of questions that come up, especially with newer libraries, but they were pretty excited about it. It actually worked out really well and I think this is actually the final version we’re going with this kind of open mindedness and collaboration is something that I really, really like about Jane Street.

00:39:15

Ron

It’s super important to have a culture where you basically can talk about technical decisions in a way where you can propose new ideas and disagree with people and that’s a positive experience rather than one that feels like negative and combative.

So, how did you guys end up choosing the teams that you’re on? You know, when you come in as an intern I think you don’t have a lot of choice about where you end up. We kind of find like a good spot for you, but then when you go from that to full-time, I’m curious what the process looked like for you of figuring out where you were going to be.

00:39:43

Matt

I think I actually just got an email from someone in the London office saying, “This is the team we think that you would suit quite well. Here’s some details about it and here’s a tech talk that someone gave a few years about it. Let us know whether or not you think this would suit you,” because I didn’t end up working in either of the teams that I worked in as a full-timer partly because one of the teams is quite small and don’t really know why I didn’t end up in the other team, but I guess whatever reason it made sense to put in the team that I’m in now, and I’ve really enjoyed it. I get to work with you, Ron, so can’t complain about that, can I?

00:40:15

Jeanne

Yeah. It was very similar for me, except for they also said like, “Oh, and we can also set up meetings with like a couple different teams if you want to explore other options.” So, I ended up doing that and talking to a couple of different teams and then settling on the team that they originally suggested to me.

00:40:29

Grace

I feel like Jane Street after an internship does have a good sense of, you know, what you enjoy working on, and so the recommendations are usually pretty on point there. I had a very similar experience to Jeanne. So, like they talked about a few different teams. I like really liked both teams that I’d worked on, and so definitely it was just in general a hard decision, but I talked to a few different teams, and the biggest thing perhaps was just that, you know, when people on my old team kind of popped up on my screen – this was after when I did this team thing, talked to different teams after COVID hit, so, we did this –

00:41:02

Ron

The fully remote team matching process.

00:41:04

Grace

Exactly. The fully remote, exactly, process, and so when they popped up on my screen I was like really excited to see them, and I think a little bit more excited than I thought I would be (laughter), and so I think that was really nice. I feel like a big part of the team you’re on is kind of the people you’re working with, and I think I was really excited to see them, really excited to hear what they’ve been working on and what kinds of projects they have available. So, I am back on the same team.

00:41:30

Ron

These days it’s very common for people to do lots of internships. So, I imagine you guys have all worked at some other technical places. I’m curious if you have a feel for how the Jane Street experience of being an intern was different from what you’d seen in other spots before.

00:41:46

Matt

I guess my previous experience was kind of maybe a little bit unusual because I worked at the same place for multiple summers in a row. Even before I went to uni, I worked there and then worked there after my first and second years of uni, and so I guess I’d got very used to one particular place, and so I wasn’t necessarily all that plugged into like the other interns that were doing internships at the same time as me, and I guess the big difference to me was being part of this like big formalized internship program where there were events organized and you got to know all of the other interns, and for me this was really enjoyable and kind of showed me that, it was kind of nice to also find out about different teams in the organization. The place that I had interned at before, I ended up working in the same place over and over again just because I knew the people and I enjoyed it, but getting a broader opportunity to learn about the company was also super cool.

00:42:40

Jeanne

Yeah. I interned at a pretty big company, extremely big company, before coming to Jane Street, and I think there was a very large difference in terms of just the size of the code base that you work on as an intern here versus at my other interns.

00:42:54

Ron

But Jane Street’s code base is very small. There’s a mere 20 million lines of code!

00:42:57

Matt

(laughter)

00:42:59

Ron

Or something like that. I never know whether to think of that as small or big.

00:42:59

Grace

(laughter)

00:43:00

Ron

It kind of depends on your perspective. It seems enormous to me, kind of terrifyingly large on some level. (laughter)

00:43:07

Jeanne

Yeah. I guess only small by comparison.

00:43:09

Ron

But also, a lot smaller.

00:43:11

Jeanne

Yeah. I guess one thing that I had never done at my previous internships was start writing code in a blank file. That was just something that never happened. I was just editing lots and lots of preexisting systems because there was just so much code that already existed. So, getting to start writing something from scratch was pretty cool.

00:43:29

Ron

Is that a difference about how large the code base is or something about the nature of the technical infrastructure? Like, I would like to think that if Jane Street’s code base, you know, grows again by, you know, another factor of 10 that it would still be the case that people would not so rarely start brand new files and write brand new things. Like, there’s something about like the kind of modular approach to building things. There’s something quite lovely about being able to write a program with a very small number of dependencies and have this thing that’s like small and easy to think about, and then you take those small easy to think about things and compose them into larger systems, but I wonder if that’s purely about size of if there’s something else going on about maybe like the nature of the projects or the nature of the kind of work in the different spots. At least, I hope as we grow we don’t end up into a world where one never opens a blank file and writes something from scratch.

00:44:07

Jeanne

Yeah. I wonder if it was just the types of projects I had there versus here. There seemed to be a lot more freedom to the projects at Jane Street than at my previous internship.

00:44:16

Ron

I think the need to build completely new things continues on and is a pretty big part of work. So, like, Matt, for example, maybe it’s worth talking a little bit about the Zeroprot project that you’re working on now. That’s like an interesting example of like a totally brand-new thing.

00:44:32

Matt

Yeah. Basically, the goal of Zeroprot, fundamentally, it’s a way of specifying protocols that you might use to talk between two different apps. So, it’s similar to how you might use RPCs basically.

00:44:00

Ron

A good example for someone from not our world, like things like Protobufs.

00:44:44

Matt

It’s similar to Protobufs. It’s very heavily inspired by Cap’n Proto, which is solving slightly different problems.

00:44:50

Ron

Right. In fact, Cap’n Proto is a system for representing messages that was written by the guy who wrote at Google one of the earlier versions of Protobuf. So, the guy name’s Kenton Varda if I remember correctly.

00:45:06

Matt

That sounds right. Yeah. So, basically I think, yeah, the easy way for people to think about this is to think about Protobufs, which is probably the thing that people are most likely to have come across, and so the goal of Zeroprot is to solve this problem of… I have two different applications. Maybe they’re running the same version, maybe they’re running different versions, and I would like them to still to be able to talk to each other without too much faff of converting between different versions or like a lot of bookkeeping or maybe a lot of runtime code to move things around and figure out what data should’ve been there, and so it solves this problem of having two apps that maybe have different ideas of what a protocol looks like. Maybe because you’ve added a field to something or maybe you’ve added another message to your RPC, and it also wants to do this in an efficient way that lets us represent really complicated structures in a way that is still fast to use, specifically in OCaml, but I think most of the performance improvements made by Zeroprot would also kind of be applicable in other programming languages, and there are a whole bunch of like clever things that I can’t claim credit for that basically allow us to do this process of adding new fields to a message and maintaining backwards compatibility. I’ve been here at Jane Street for about a year and a month or so now, and I’ve gradually been able to get more and more involved in this project to the point that now I’m the main person working on most of the new functionality that we need to get this project out into the world of Jane Street and used more widely, which is really cool.

00:46:34

Ron

Yeah. It’s a project that exemplifies some of the things that Grace was talking about about connections between teams, right, because there’s a lot of problems you need to solve for this, effectively. You need an efficient way of representing messages on the wire and nice APIs for interacting with those messages, and so that’s involved a lot of collaboration with the market data team with a system they have for generating nice APIs for efficiently dealing with messages of various different layouts. There’s lots of brand-new pieces of code to write (following what Jeanne said, so, for example, writing brand-new pieces of code), one of the things that you did when you started was you wrote the PPX, this kind of syntactic-level language extension to make it nice and easy to specify OCaml messages in this format. There’s also other interesting technical challenges around having the specification language of how messages work and being able to do compatibility checks between different layers. So, lots and lots of brand-new stuff that needs to be written, and at the same time you also want to take this thing and then integrate it into real, live, existing, software code bases. So, it’s not like everything is writing brand-new pieces of code. There’s also lots of work learning how to live inside of large, complex code bases.

00:47:46

Matt

It’s almost like there are kind of two separate challenges. There’s this challenge of like writing a ton of code in the first place, and it’s also like making that live kind of nicely in this like broader ecosystem of things that already exist and integrating it into things that we want to use it in. This is my challenge for what I’m currently working on in the next few months I suppose.

00:48:07

Ron

I think one of the interesting differences between those two kinds of work of like building new things and working on extending existing things is there’s a different kind of problem of integrating with other people, right? For new things, you have to figure out how to convince people to use your shiny new thing and how to solve the problems that they don’t even necessarily know that they have yet, and with existing things there’s a lot of work that you need to do to go out and talk to people and gather their understanding of the world and what they think is important and prioritize the 60 million different things that they want from you and figure out from that enormous list the three things you actually have time to do. There’s always that painful difference between how much people want and how much you can actually provide.

00:48:44

Matt

Yeah, and also we want to make sure that we’re not just writing this code really quickly and then we’re going to need to go back and change it in three months or something because we realize we’ve done it wrong. So, we’re putting a lot of effort into thinking about the APIs and thinking about the code that we write to make sure that we kind of get it at least mostly right the first time, especially because with a protocol format we maybe can’t go back and change it in the future because the whole point is that it’s backwards compatible, and so we need to be quite careful about that.

00:49:11

Ron

Yeah, versioning is a surprisingly tricky corner of the world.

How much experience do you guys have interacting with people in non-developer teams and kind of trying to understand what their needs are, like be it traders or people in operations or compliance or whatever?

00:49:28

Jeanne

I talk to traders every day. We have several group chats going on, constant pings.

00:49:34

Ron

What are you talking to them about? Like, what are you trying to achieve with all of that communication?

00:49:37

Jeanne

Oftentimes, they’ll message, “Oh, I’m confused about why this particular thing happened with this RFQ. Can you explain what went wrong or if anything went wrong?” So, sometimes it’s things like that. Sometimes it’s like small feature requests. So, you know, “can you add this confirmation dialogue to the UI?” In setting up new systems, oftentimes we’ll need to talk to traders a lot to say, “Hey, can you help us test this out, and can you tell us what you want in this particular system?” So, I also do a lot of that kind of talking. So, yeah, it varies widely.

00:50:09

Ron

It sounds like some of that is essentially day-to-day support, and some of that is this process of trying to understand what’s actually important. How important do you think the communication with traders is for figuring out that kind of bigger picture question of like what’s the next thing that you’re supposed to be working on?

00:50:24

Jeanne

Yeah. I think it’s definitely impossible to figure out what the next thing we’re supposed to be working on is without talking to traders a lot. Because our app is used for trading we sort of need to understand what the priorities of different desks are because our app is used by a lot of different groups. So, we need to understand sort of what they all want, what sorts of new trades that they want to do that we might need to be able to set up, and then to sort of figure out how to prioritize the different needs of everyone and then actually start doing them.

00:50:50

Grace

I always found prioritization to be kind of like an interesting question. So, I’d actually asked my navigator about this and it sounds pretty similar. He works on the options desk and I think they work very closely with the traders and he described it as kind of like a nice mix between balancing the priorities of our users and also like having the devs think about what are we in the best position to do. And so, I think it’s a nice mix of creating a shared context between the two to like figure out how our priorities work out eventually.

00:51:16

Ron

I feel like one of the things that is super hard is there’s all these questions of balance, right? On some level, you want to provide this stream of features that your users want and figure out what’s important to them and to the organization and to the business and move things forward there. You also want to work on things that make you more efficient in the short term. So, places we can clean up technical debt, improve the architecture of this or that piece of the code base, and then the third thing which I think can easily get lost between those two is sometimes you need to think big about large changes you can make to how the overall system works, whether it be something like oh, we want to, you know, change completely the tooling that we’re using underneath from, you know, we were going to use some internal tool and now we’re going to switch to using Redis. That’s one kind of bigger change, or we want to build some completely new architectural piece, like Matt’s talking about, and finding the time and space to do those larger things that impact not just your team sometimes, but lots of different teams, is another thing that’s kind of challenging to find time for, and I think people who are helping, organize and manage the work I think one of the key things is figuring out how to build an appropriate balance between those different requirements, and I think it’s one of the reasons why it’s good to have different teams that are kind of focused on different areas and in different parts of the organization. There’s all sorts of teams that are attached to this or that infrastructure group, or attached to a particular trading desk, and then there are free-floating developer teams that are serving more broadly large swathes of the organization, and I think that causes people to kind of pay attention to like different areas of the stack and it lets people focus on prioritizing smaller scopes of the world where it’s easier to think about what’s going on.

00:52:56

Grace

So, like we also work very closely with the infrastructure group, Risk, because they have big ideas about what the big pushes we want to do are, and I think those meetings are always really helpful because they kind of set like the broader goal that we’re working towards, and it’s really nice to have these conversations because, especially during remote work, our team at least we’re oftentimes working on like coordinated efforts towards like a larger goal and it’s really nice to be able to kind of sync up on what everyone is working on and how we’re all working towards this one bigger push and also to hear from Risk about the infrastructure side of things and like, you know, the motivation behind this and also like, you know, how the different pieces fit together.

00:53:38

Ron

So, you guys have mostly only said nice things about working here. Are there any things that you found, either as an intern or as a full-timer, that were like challenging that you wish could be made easier? Maybe things about the intern program that now that you are on the other side of the scale, you’re interested in seeing if you can make better or easier?

00:53:57

Grace

One funny thing about the internship is that there is just so much going on and we start coding and then we’re like oh, no, now there is a class or there’s like a social, there’s like a game… kind of sometimes made it difficult to find like a huge chunk of time to like just be coding.

00:54:14

Ron

Do you think we should do it differently? Should there be a little less?

00:54:16

Grace

This is like a personal opinion. I think maybe some things we could do is like kind of chunk it up so that it’s like in all together in one block during the day or something like that, I don’t know, because it was pretty spread out because I think like you need people to run these classes. So, you know, they’re very busy. Their schedules, it’s hard to schedule everyone in. I think like it could be nice to have like, I don’t know, the classes are always before lunch, or like something like that. I think it just helps us kind of gain some sense of like, you know, consistency throughout the day.

00:54:47

Ron

Right. Because like focus is hard and important and having stuff scattered all around can make that difficult.

00:54:54

Grace

But we got very good at context switching. So, no worries. Lesson learned in the internship. (laughter)

00:54:59

Jeanne

Honestly, I felt totally the opposite. I really liked all the like scattered breaks throughout the day where you’d go and change it up and do something else. Like, I really liked the variety.

00:55:07

Grace

I think I really liked the programming too. I think it’s just sometimes when you’re like really into the code, then you’re like oh, that’s when it hits you: I am late to this intern event. (laughter)

00:55:17

Matt

Yeah. I guess I’m going to complete it and be somewhere in the middle. Like, there are some days where it’s really nice to have little breaks from work and there are other days where you’re like I just really want to do this code. Let me like, I don’t want to have to wait.

00:55:31

Jeanne

I have to say I feel that way way more as a full-timer than I ever did as an intern. Now, I’m like “please give me a block of time to code,” whereas before I was like “Oh, well, there’s so many things. It’s so exciting!”

00:55:41

Ron

Do you feel like it’s hard to find a block of time to code now like as a full-timer? Is there too much in the way of distraction of various kinds?

00:55:48

Jeanne

I think it depends on the day.

00:55:50

Matt

If I’m doing like a phone interview or something, then that’s kind of fine, but if it’s like a phone interview then 15 minutes then some other random thing and then an hour and then another thing, it can kind of be kind of annoying, but it doesn’t happen too often I would say.

00:56:02

Ron

To what degree are your days full of little meetings of various kinds that kind of interrupt the flow of work?

00:56:08

Grace

We have meetings sprinkled throughout the day. Also, like I think with remote work it’s just a lot harder to have these spontaneous conversations that might happen in the office. We have like an opt-in kind of social every day in the morning to like see the other people on your broader team, but it’s like very opt-in, right? So, if you’re in the middle of something and you don’t want to break that flow, you don’t have to go to that. Personally, I’m actually a pretty big fan of having meetings because I think it’s always interesting to hear about like what other people are working on and things and to talk about kind of larger goals, but I think it’s not the worst. I do think that we are actually pretty good at context switching, especially with remote work. I think there’s just less distraction going on. You don’t hear all the noises in the office.

00:56:48

Matt

I really enjoyed the noises in the office.

00:56:50

Jeanne

Yeah, same!

00:56:51

Matt

I miss the noises in the office.

00:56:53

Grace

(laughter) Oh, 100 percent. I think it becomes very apparent especially now that there’s like nothing going on at home. But I think because of that I think you wind up actually kind of just like sitting there and not realizing you’ve been coding for a really long time a lot more than if you were in the office. So, actually especially now I think the meetings that break up the day are kind of nice. I like it to be the case that when I finish a particular thing, like come to a logical stop, I like reassess what I’ve done, and then that’s when I, you know, I check to see if someone’s reviewed my code or something. These smaller breaks in the day are actually kind of nice to have too.

00:57:29

Jeanne

The hardest thing for me is not necessarily like around meetings, but just around like oh, suddenly like a trader has messaged and like I need to do some support thing now, and like context switching between those I think is much more tricky because they’re random and not planned. So, that makes it harder to like plan things out.

00:57:46

Grace

That’s a good point.

00:57:46

Ron

That kind of distraction varies a lot between teams and roles, right? There are roles where there’s like a very a kind of constant overhead of interaction, and it’s good and bad, right, because it gives you this kind of very concrete way of hooking into the people who are using your software and you learn a lot from that and that can be both fun and motivating and you learn a lot about what’s going on in the business, and the downside is it can make certain kinds of focused work harder to get done. So, you need to balance your day and find time for both of those.

00:58:12

Jeanne

Yeah. It doesn’t help that I really enjoying those tasks. So, then I just drop everything and go do them.

00:58:18

Ron

So, is there anything else about the internship that you guys feel like you would want to make better?

00:58:22

Grace

It sounds like we just had a great time. (laughter)

00:58:25

Ron

Yeah. You guys are clearly too nice. I’ve clearly stacked the interview with nice people. (laughter)

00:58:31

Jeanne

I think one thing that I would have liked, especially early on in the internship, was like, I don’t know if it’s more feedback or more encouragement or something like that, but I was like very unsure about like whether I was doing my project fast enough and stuff like that, and there was like a designated feedback meeting at some point, but I felt like it would’ve been helpful to have more periodic updates or something. Maybe I should have just like asked for them, but I didn’t think to do that. So…

00:58:57

Ron

Yeah, and I feel like at the scale of the internship, there are almost no problems to which the solution is the intern should just ask for the things that they need because people’s need are actually really quite commonly shared, and I think this is actually a thing that we’re constantly struggling to get better at with interns, and also with full-timers, just of like giving people enough feedback. Like, I think one of the downsides of the friendly and collegial environment is that it takes a real kind of effort of will for people to think, “Oh, I am managing someone’s experience here and I need to like think about their growth and their progress and the fact that they might be anxious about the work that they’re doing and try and give them feedback and concretely help them along.” I think people are generically very helpful, but especially as we grow, having people take the role of managing other people as like a serious and first class part of the job, and the internship is like, among other things, like a large organization scale management problem, and you know, it’s a thing that as we’ve grown we try and get better at, but it’s, like many of the technical things we do, it’s like a real hard thing that takes experience to do well.

00:59:58

Matt

Yeah. This is something I kind of found hard both in the internship and as a full-timer is like working with lots of smart people who seem to really know what they’re doing and feeling like you know nothing, which is kind of reasonable because you only just started, right, but like you feel as though you should know everything, and this is kind of stressful. I imagine it’s kind of similar to what you might have at university where everyone seems like they’re really on top of everything, and in the workplace it’s kind of similar I guess, and it kind of takes some getting used to, and it’s almost something like I’ve kind of had to like remind myself every so often that like learning new stuff is good and important and it’s not like something to be ashamed of.

01:00:39

Ron

Yeah. Imposter syndrome is a real thing and it’s one of the things that has surprised me over time how poorly these feelings are correlated to how well people are doing. Like, I do not think it is the case that… I think the people who are doing awesome are just as often worried and concerned about how they’re doing as people who are struggling. And I think it’s a lot of people who have been here for a while and are responsible for many other people just make this mistake of thinking, “That person’s doing great, I’ve said some nice things to them, and so presumably they’re fine,” and that is just not how human psychology works, right? You can say the occasional nice thing to someone about their work and feel positively about it and it doesn’t necessarily translate, and you really need to take the time and try and get a feeling for where people are, because even if you just say nice things, people will often think, “Oh, you’re just saying that.”

01:01:29

Matt

Yeah. I don’t know how to solve that problem.

01:01:31

Jeanne

It’s like knowing about imposter syndrome doesn’t make imposter syndrome go away. You just believe you’re the only real imposter. (laughter)

01:01:36

Ron

That’s right. (laughter)

01:01:40

Matt

(laughter) Everyone else just thinks they’re an imposter. I really am. Like, yeah.

01:01:43

Ron

(laughter) In case you’re wondering, none of you are imposters. I can just give you a…

01:01:47

Grace

He’s just being nice.

01:01:49

Ron

(laughter) No.

01:01:48

Jeanne

I’m going to win Among Us now.

01:01:51

Matt

(laughter)

01:01:52

Grace

I was getting Among Us vibes too. I’m glad I’m not the only one. (laughter)

01:01:53

Ron

(laughter)

01:01:54

Matt

Yeah. This was something that I spoke to my navigator about, similar to what Grace mentioned, and he was like, “Oh, yeah. Yeah. Everyone gets this. It’s natural.” It doesn’t help, but it’s nice to know that other people get it too.

01:02:12

Ron

(laughter) All right. Well, this has been incredibly fun. Thank you guys for joining me.

01:02:16

Matt

Yeah. Thanks, Ron.

01:02:17

Grace

Yeah. This was super fun. Thanks for having us.

01:02:19

Jeanne

Yeah. Thanks, Ron.

01:02:23

Ron

You can find a full transcript of the episode along with a glossary and links to some of the topics we discussed at signalsandthreads.com. This is our last episode of the season and we hope you enjoyed these conversations half as much as we did. We don’t know what’s coming next for Signals and Threads, but we’ve got lots of ideas brewing. And if you have any ideas you want to share with us, you can reach us at signalsandthreads@janestreet.com. So, one last time: thanks for joining us.