I often discuss Jane Street as a great model of employee branding. They do well placed adverts/sponsorships (e.g. Standup Maths[0]), they produce a quite decent quality podcast (Signals and Threads [1]), and they have consistent monthly puzzles [2]. That level of investment in branding only makes sense, I think, at a large size. I'm kind of surprised they only have ~2500 people.
Jane Street has been doing this since they were much smaller. I interned there when they had like 300 people, and they were actively cultivating a great brand as an employer back then too—and looks like they've really made it work over the last decade!
My impression with them in general was that they were willing to do lots of things that did not "conventionally" make sense at their size, and those things paid off. The internship program, for example, was relatively large in comparison to the size of the company at the time (≈50 interns?) and had lots of structure (events/talks/classes/group projects/etc) like you would expect from a big tech company, not from a 300-person firm.
They were also willing to build a lot of tools in-house like their own build system[1], their own code reviews system[2], etc. Most people would see this as wasteful NIH but I'm convinced it was a net benefit for them—they managed to be so productive in an absolute sense and especially on a per-engineer basis because they were willing to build so much themselves, not despite it. I'm sure the same thing applied to their recruiting efforts.
The biggest thing I took away from my internship was how much conventional wisdom in the software world was not necessary or true.
> Most people would see this as wasteful NIH but I'm convinced it was a net benefit for them—they managed to be so productive in an absolute sense and especially on a per-engineer basis because they were willing to build so much themselves, not despite it.
It paid off for them, but I would say it's a risky move in general - it is very easy to get sidetracked with failed projects that have nothing to do with the business. There are many examples - Uber's internal chat system, etc.
Others tools were more a necessity, eg the OCaml build story was not great back then. Investing in OCaml itself was a calculated risk.
Also I wonder how things would be different if they were starting today, where there are more mature tools in the space.
I often dread when I see an employer using in-house systems for common tasks like project tracking and code review. I'm curious how does JS's internal tools stack up against systems out there, like Github or Jira.
> how much conventional wisdom in the software world was not necessary or true.
Do you remember any specifics?
I’m also curious how their tooling made them so much more productive. Were the tools just really well designed, or did they integrate perfectly with each other?
I used to work there - the jane street code review software is awesome, kind of like graphite but it works reliably. You can write a big tree of PRs. PRs get reviewed separately and you can merge them in any order at your leisure, without worrying too much about rebase issues or clobbering review or whatever. I would love to have some open source thing like that that actually works nearly as well. It may exist, but I haven't seen it yet.
And yeah, jane street is a pretty compelling demo that A) NIH syndrome is fine if you're good at writing software and B) it doesn't really matter that much if you use a mature language or some uncommon immature language
Because it is. What is the point of reinventing these wheels when gazillions of man hours have already been invested on open source tools that can do it better and cheaper?
They used to be very active in the NYC Meetup scene, too. ~~I think I visited at least two of their offices and the second was was stunning. It was far south enough and high enough that there was a nearly unobstructed 200° view of the southern end of Manhattan, both rivers, etc. It was also beautifully designed and had an obligatorily huge, open, stocked kitchen.~~ (This was actually Two Sigma.) They were also using exotic tech back then, too, like OCaml, which is itself a form of marketing and helps with recruitment.
Moral qualms aside, it must be a fascinating place to work.
> At the end of 2023. Jane Street employed 2,631 people, so that equates to almost $4mn of net revenue per head on average. In adjusted EBITDA, it comes to $2.83mn per employee (or nearly $22mn for each of the 482 traders actual traders at Jane Street.)
And regarding compensation:
> Given Jane Street’s disclosed compensation and benefits of $2.4bn last year, this works out to over $900k for each employee on average.
I highlighted Jane Street's recruiting outreaches specifically, when talking with an R&D unit at a big financial institution. (I also mentioned the tactic of fringe-tech-that-some-heavy-hitters-love. OCaml, Lisp, Rust, Erlang, etc.)
When I first heard of Jane Street, it sounded like Yaron Minsky was going around to MIT and such, high-touch, trying to hire just a few people. And later, things like this blog: https://blog.janestreet.com/author/yminsky/
The only negative thing I recall hearing is Jane Street alumni responsible for the infamous FTX and Alameda Research. I don't know whether the individuals were already fully into hopped-up sociopathic/narcissistic thinking in college, or whether their internship and employment experience contributed.
It seems their thinking is part of what led them to JS in the first place, which is a bit of negative and maybe they had some ideas reinforced there. But I also think they were some of the more extreme ones to begin with. They obviously didn't internalize JS's concerns about risk at all lol.
I work in quantitative finance and have wanted to to start using OCaml at work for years. I just find that unless you are at a shop like Jane Street with a well developed proprietary code base, internally developed tooling, etc, there just isn't the ecosystem available for me to be nearly as productive as I can be in other well accepted languages in the quant dev space...which is a bummer. It's been a little while since the last time I investigated this though.
It's brilliant if you think about it as an employer that wants to limit employee turnover. Great, you're an ace algo dev in OCaml, where you gonna jump ship to?
When we hire a junior person we are interested in math background, ability to communicate real world value of various models to our investment process and familiarity with computer science and software engineering concepts more than we care about experience with specific languages or technologies. That being said, C++ does still dominate this space so having exposure to it certainly would not hurt.
I thought the Pareto distribution was most famously associated with 80-20? Of course you can change α to get whatever ratio you want but this is the first time I heard of the 50-1 ratio being used.
"Jane Street has 40 “equity unit holders on a full-time basis and in good standing”, with an average tenure of 16 years" - I suspect a large portion of it would come from those 40 but that is purely a guess.
Hedge fund comp is extremely skewed. When I worked at one, in good years my boss made more than 10x what I made, and I made about 10x what my reports made.
> The real money is at the top. The bond prospectus reveals that Jane Street has 40 “equity unit holders on a full-time basis and in good standing”, with an average tenure of 16 years. Among those there will be at least a handful of billionaires, even if no Jane Streeter appears on any rich lists.
Sounds like any other partnership. A few people at the top are providing the equity and getting a profit share, and the thousands under them are getting salaries.
Rentech uses this model too. The equity-to-salary ratio of an employee increases the longer they remain at the firm. It's for incentivizing employees to stick with the firm in the long run such that they don't work for any other firms and become a competitor (especially true in trading given the small population of talents).
it's not a collective per se but employees are certainly well paid. because they are highly skilled, are not easily replaced, and could take secrets elsewhere.
commodities trading houses tend to follow this model too though that is changing a bit.
i remember having this discussion with a friend after he sent me a richard wolff video. nothing about our system stops coops from flourishing. one of my favorite retailers, REI, is a member-owned co-op. publix, the beloved florida grocer, is employee-owned.
I know you’re kinda joking but, The problem with socialism isn’t the voluntary organizations that people can join or leave at will, it’s the forced involuntary labor that is always brought about. Capitalism is about voluntary mutually beneficial partnerships which this is.
Great comment from the FT's comments section on this piece.
> A good mate who runs and wrecks expensive cars for hobby once reminded me that course plotting (i.e. research) and braking (i.e. risk management) are the two sine qua non contributors to a successful race.
Along with a reminder that disasters happen when businesses forget this (Boeing!)
I love them because they keep the OCaml dream alive, but any company shouldn't have this kind of reach, especially in the realm of automation. This probably won't end well...
Meanwhile I'd love to know what their edge is... It's probably more than OCaml, although... ;)
What kind of reach? Just making a lot of money?From the article, it looks like they make a lot from market making in ETFs and similar. Thats an extremely competitive market that is necessarily a race to the bottom in terms of pricing
> From the article, it looks like they make a lot from market making in ETFs and similar. Thats an extremely competitive market that is necessarily a race to the bottom in terms of pricing
They are not making their money market making equity etfs afaik, mostly bonds. A slightly different game with a much higher barrier to entry etc
I think OCaml is more of symptom of the people who they hire. Most companies don't want to hire OCaml and Haskellers. They fear they would be too expensive, and requires clear thinking so you can't hire bottom of the bucket devs.
If you want to hire the best and willing to pay that is no longer a concern
I interviewed with them, a long long long time ago.
They use OCaml because it is explainable. Which it is. They use it like a non-lazy version of Haskell -- side effects are used rarely if ever. So there's no nonlocal behavior in the code, which makes it easy to reason about. And that kinda matters when a lot of money is at stake.
Incidentally, Standard Chartered has their own compiler for Haskell, without the laziness. The group is led by the guy famous for Cayenne (the first dependently typed Haskell dialect).
> Most companies don't want to hire OCaml and Haskellers
Most companies don't even know that these are programming languages. Also don't assume people interested in these languages are "the best". Regarding JS, this is all hearsay, but I think nowadays they hire good profiles (competitive programmers / olympiad winner / top graduates from prestigious schools), ask them hard leetcode questions, and teach them OCaml (which anybody can learn, not particularly hard. Their talent pool isn't restricted to the OCaml community, as it used to be when they were less famous, except for niche use case (compiler work and so on...)
Well 30-40 or more would be just needed to maintain OCaml codebase. Unless basic unit of bonus, salary, buying, selling, vendor payments, building maintenance and so on is OCaml lines of code, I would have guessed ~1000 people for sure.
Might also be that Jane Street is to OCaml what WhatsApp was to Erlang. Many ascribed the success of the small team at WhatsApp to their tech-stack, Erlang and FreeBSD. The reality probably was that they had hired really smart people, and those people choose to use Erlang (because eJabberd), but they could have been just as successful using another language.
Yes, Jane Street uses OCaml, they have no reason to stop using OCaml, but may very well have been just as successful using another language. It's hard to tell, when we don't know the full circumstances of why they went with OCaml initially.
> but they could have been just as successful using another language.
I remember reading about one founder that picked an obscure language because in doing so, it self-selected for more curious engineers who worked in the languages for fun rather than any other practical (re:job) reasons.
His thesis is that finding one really good engineer in said language was 1 in 10 (10 interviews to find 1 really good engineer) whereas in more commonly used languages like Java, JavaScript, etc., it might be 1 in 100
If we had picked Python, it’s very boring and reliable, and the same could be said of Java. But you’re picking the lowest common denominator. I would say high performers, and the best programmers are often people that will only work in niche languages.
The problem is, there are good Java programmers, but there are also thousands of terrible Java programmers. If you pick the right niche, it’s easier to find the high-end talent. I think Paul Graham also made a very strong case that in a startup, you should be using the most powerful language you can, and that is Clojure.
I interviewed with one YC startup that was using ReScript and ReasonML on the same principle (I asked the founder why he chose Reason).
> but they could have been just as successful using another language.
I don't claim to be a rockstar developer or anything close. But my capabilities and efficiency as a developer are tightly coupled to the tech stack I use (not just language).
I moved from a job where I chose my own tech stack that I iterated over several years to one where I'm forced to use (IMHO) tools that are poorly suited to my work, and I'd say the quality and volume of my work has dropped by at least 10x.
So I think it's both. You need smart people, but they also need to be using the right tools for the job.
It's very hard to determine if they succeeded because of or despite of in any quantified way. WhatsApp, Viaweb, Jane Street, NoRedInk are examples of where they succeeded with a smaller language and none of them afaik blamed the language but praised it.
However, I think if you are a company doing something boring and that can only pay average, then having an interesting tech stack (including a nice language), hiring globally and having good benefits might give you a venue to compete for talent. You'll need some kind of strategy.
I'm very much not a serious OCaml:er but when I've dabbled some in it I got the impression that their "standard library" is kind of the de facto standard library.
The paradox being: developer familiar with programming languages of level of power N doesn't recognize that languages of level N+ are better (more powerful expressively), only that N- are lesser.
Readit News
[0] https://www.youtube.com/user/standupmaths [1] https://signalsandthreads.com/ [2] https://www.janestreet.com/puzzles/current-puzzle/
My impression with them in general was that they were willing to do lots of things that did not "conventionally" make sense at their size, and those things paid off. The internship program, for example, was relatively large in comparison to the size of the company at the time (≈50 interns?) and had lots of structure (events/talks/classes/group projects/etc) like you would expect from a big tech company, not from a 300-person firm.
They were also willing to build a lot of tools in-house like their own build system[1], their own code reviews system[2], etc. Most people would see this as wasteful NIH but I'm convinced it was a net benefit for them—they managed to be so productive in an absolute sense and especially on a per-engineer basis because they were willing to build so much themselves, not despite it. I'm sure the same thing applied to their recruiting efforts.
The biggest thing I took away from my internship was how much conventional wisdom in the software world was not necessary or true.
[1]: First Jenga, now Dune
[2]: Here's a neat talk on how they do code review at Jane Street: https://www.janestreet.com/tech-talks/janestreet-code-review...
It paid off for them, but I would say it's a risky move in general - it is very easy to get sidetracked with failed projects that have nothing to do with the business. There are many examples - Uber's internal chat system, etc.
Others tools were more a necessity, eg the OCaml build story was not great back then. Investing in OCaml itself was a calculated risk.
Also I wonder how things would be different if they were starting today, where there are more mature tools in the space.
Do you remember any specifics?
I’m also curious how their tooling made them so much more productive. Were the tools just really well designed, or did they integrate perfectly with each other?
And yeah, jane street is a pretty compelling demo that A) NIH syndrome is fine if you're good at writing software and B) it doesn't really matter that much if you use a mature language or some uncommon immature language
Because it is. What is the point of reinventing these wheels when gazillions of man hours have already been invested on open source tools that can do it better and cheaper?
Moral qualms aside, it must be a fascinating place to work.
> At the end of 2023. Jane Street employed 2,631 people, so that equates to almost $4mn of net revenue per head on average. In adjusted EBITDA, it comes to $2.83mn per employee (or nearly $22mn for each of the 482 traders actual traders at Jane Street.)
And regarding compensation:
> Given Jane Street’s disclosed compensation and benefits of $2.4bn last year, this works out to over $900k for each employee on average.
Deleted Comment
When I first heard of Jane Street, it sounded like Yaron Minsky was going around to MIT and such, high-touch, trying to hire just a few people. And later, things like this blog: https://blog.janestreet.com/author/yminsky/
The only negative thing I recall hearing is Jane Street alumni responsible for the infamous FTX and Alameda Research. I don't know whether the individuals were already fully into hopped-up sociopathic/narcissistic thinking in college, or whether their internship and employment experience contributed.
the bigger the vol, the more imma do
Is learning C++ a must?
For quants (progression towards a trader / portfolio manager), Python / Matlab / R is enough.
> About 80 per cent of the company's capital comes from employee equity, which has swelled to $21.3bn at the end of 2023
o.O
I'd be interested to see if the Pareto distribution holds here as well, namely that 1% of employees (26) hold half the wealth ($10b).
> The real money is at the top. The bond prospectus reveals that Jane Street has 40 “equity unit holders on a full-time basis and in good standing”, with an average tenure of 16 years. Among those there will be at least a handful of billionaires, even if no Jane Streeter appears on any rich lists.
Sounds like any other partnership. A few people at the top are providing the equity and getting a profit share, and the thousands under them are getting salaries.
The difference is that these thousands also get to invest in Jane Street, which seems a pretty profitable investment (70% margins, etc).
Jane Street shares and profits are proportional to the capital you invest/accumulate.
commodities trading houses tend to follow this model too though that is changing a bit.
i remember having this discussion with a friend after he sent me a richard wolff video. nothing about our system stops coops from flourishing. one of my favorite retailers, REI, is a member-owned co-op. publix, the beloved florida grocer, is employee-owned.
Finance tends to pay its workers better than shareholders—most banks’ trading and IB groups pay out more than 50% of profits to workers.
Where it goes wrong is when the regulator fails to stop foul play…
> A good mate who runs and wrecks expensive cars for hobby once reminded me that course plotting (i.e. research) and braking (i.e. risk management) are the two sine qua non contributors to a successful race.
Along with a reminder that disasters happen when businesses forget this (Boeing!)
Meanwhile I'd love to know what their edge is... It's probably more than OCaml, although... ;)
They are not making their money market making equity etfs afaik, mostly bonds. A slightly different game with a much higher barrier to entry etc
If you want to hire the best and willing to pay that is no longer a concern
They use OCaml because it is explainable. Which it is. They use it like a non-lazy version of Haskell -- side effects are used rarely if ever. So there's no nonlocal behavior in the code, which makes it easy to reason about. And that kinda matters when a lot of money is at stake.
Incidentally, Standard Chartered has their own compiler for Haskell, without the laziness. The group is led by the guy famous for Cayenne (the first dependently typed Haskell dialect).
Most companies don't even know that these are programming languages. Also don't assume people interested in these languages are "the best". Regarding JS, this is all hearsay, but I think nowadays they hire good profiles (competitive programmers / olympiad winner / top graduates from prestigious schools), ask them hard leetcode questions, and teach them OCaml (which anybody can learn, not particularly hard. Their talent pool isn't restricted to the OCaml community, as it used to be when they were less famous, except for niche use case (compiler work and so on...)
Yes, Jane Street uses OCaml, they have no reason to stop using OCaml, but may very well have been just as successful using another language. It's hard to tell, when we don't know the full circumstances of why they went with OCaml initially.
His thesis is that finding one really good engineer in said language was 1 in 10 (10 interviews to find 1 really good engineer) whereas in more commonly used languages like Java, JavaScript, etc., it might be 1 in 100
[Edit] https://www.juxt.pro/blog/clojure-in-griffin/
I interviewed with one YC startup that was using ReScript and ReasonML on the same principle (I asked the founder why he chose Reason).I don't claim to be a rockstar developer or anything close. But my capabilities and efficiency as a developer are tightly coupled to the tech stack I use (not just language).
I moved from a job where I chose my own tech stack that I iterated over several years to one where I'm forced to use (IMHO) tools that are poorly suited to my work, and I'd say the quality and volume of my work has dropped by at least 10x.
So I think it's both. You need smart people, but they also need to be using the right tools for the job.
However, I think if you are a company doing something boring and that can only pay average, then having an interesting tech stack (including a nice language), hiring globally and having good benefits might give you a venue to compete for talent. You'll need some kind of strategy.
https://github.com/janestreet/base
The paradox being: developer familiar with programming languages of level of power N doesn't recognize that languages of level N+ are better (more powerful expressively), only that N- are lesser.
These days, starting or running a financial business with less popular languages is, well, less popular.