Hi HN - I'm the founder of Stardrift, and we're looking for a founding engineer to join our team of 3-4. (Fun fact: I got my first coding job through 'Who is hiring?', almost 12 years ago!)
We are building a world-class travel search experience. In the future, you won’t book travel by opening ten tabs in Google Flights; you’ll book through a personalized AI assistant that understands everything about you and automatically arranges your trip for you.
You'll tackle everything from optimizing LLM performance and building evals to integrating APIs like Amadeus and Duffel. We care about moving fast and writing high-quality code; your job will be to take customer feedback and improve our product, working shoulder-to-shoulder with me & the rest of the founding team.
Tyler Cowen did an 'ask me anything' at Jane Street when I interned in 2016. One of the interns asked him exactly this: "What do you think of the fact that we all work here instead of, I don't know, curing cancer?"
He replied with, roughly, "Those of you who work here probably couldn't do anything else other than perhaps math research. Arguably, working here is the economically efficient use of your time."
I think about whenever I see a comment like this. Quant firms select for a very specific set of skills. In particular, I've found that many traders/software engineers in quant are very smart but not very self-directed. Places like Jane Street work well for people who can excel, but only when given a lot of structure and direction. I think this is not unrelated to why so many people 'accidentally' end up as traders after going to an Ivy League school!
Tyler Cowen, master of the ‘cum hoc ergo propter hoc’ fallacy. He frequently mistakes the occurrence of phenomena for causative proof of that phenomena. He particularly exhibits this inclination when his confidence rises amid scant data (like the rest of us).
This error seems to be a particularly common (and often lauded!) trait among those who work in high-conjecture low-evidence fields (eg, economics). The prominent thinkers become skillful at deploying this fallacy: “see, it’s there, therefore <insert-personal-belief> is certainly the cause!”, using their credentials and esteem to mask the error. Listeners think, “well he’s a smart, respected guy,” and nod along despite the missing logical link.
I greatly appreciate Cowen’s podcast, and I definitely respect him as a thinker and inquisitor – so I don’t mean to discard his work or opinions (in fact, I appreciate his occasional brashness because it exposes the underlying thought/principle). However, many of his aggressive-yet-speculative statements (like the one you roughly quoted) are best received with an understanding of the error.
> He replied with, roughly, "Those of you who work here probably couldn't do anything else other than perhaps math research. Arguably, working here is the economically efficient use of your time."
Complete garbage. The same way that Jane Street hires smart people that don't know anything about trading and those people contribute, the same would be true if there was money in curing cancer.
General intelligence is overstated sometimes, but it is a thing. Someone who is smart enough to work for Jane Street probably could at least be an intelligence analyst or software developer at the NSA contributing to national security. (Jim Simmons literally was a code breaker during the Vietnam War)
I don't think there's a gene for playing esoteric minigames on the options market while you literally suck at everything else
While I’m sympathetic to the “people working hard to build out ad markets instead of cancer research” argument, I only believe in a weak version of this.
Why? I have met many “smart with computers” people. Many of them have terrible people skills, don’t show up to things on time, are unable to keep their workspace clean, don’t know how to explain anything, and cry about how they can absolutely never ever be interrupted because their workspace is so hard. There are also people who are “good at it all”, of course, but I have the impression that the math/computer people tend to be fairly unwilling to deal with even mild inconveniences.
People who can barely deal with the tyranny of daily standups probably would struggle a lot in a world where you need to write grant proposals continuously to justify your existence.
I’m being glib for effect, but there’s so much involved in getting work done beyond “being smart”!
Besides… it’s not like the reason we don’t do more cancer research is because smart people didn’t go into that. “Cancer research” is limited by funding for positions into that domain!
So “this quant should have been a cancer researcher” is saying “this person who decided to become a quant will be a better cancer researcher than a cancer researcher who went into that domain directly”. I don’t know the prestige vectors there but it’s a stretch in my book!
> People who can barely deal with the tyranny of daily standups probably would struggle a lot in a world where you need to write grant proposals continuously to justify your existence.
I'm continuously writing grant proposals to justify my existence, and have been quite successful (lucky) in it. But I do bitch about the pointless grant game and about the pointless meetings.
Perhaps the problem is that to survive in academia you have to be able and willing to waste your time on all the bullshit that is not research. And it selects for people who are good and willing at the grantwriting and politics game, which is not the same as being good at research.
Maybe there's some point in bitching about the tyranny. Having tech people to do sales and marketing on the side like researchers have to do probably isn't an ideal division of labor.
Ya, I’m very surprised by the argument “you’re some of the best at numerical analysis and high frequency trading, and you’d be bad at anything else”, lol. That said, I think there are better reasons to work at such a place. Providing liquidity to the market is a good thing, and has real world value, it’s just hard for us to connect it to concrete outcomes. But as a simplified “toy” example, when they orchestrate a trade for/with a retirement fund, they help the fund improve its holdings at very low cost. That benefits everyone impacted by the retirement fund
1. Incentivizing convergence of the price towards fundamental value, to support proper asset allocation decisions.
2. Supporting buying and selling (ie "liquidity") to shift consumption in time (and enable productive investments with the delayed consumption).
Suppose a retirement fund holds their investments over a 20 year period on average, growing at a modest 4%. A 1% wider spread would reduce the return from 119% to 118%. I'm not sure avoiding that is worth the financial sector constituting 30% of GDP.
What would happen if equity markets were only open a very short period a day? Say you have one auction a day, or maybe two, and no continuous trading?
Everyone whose advantage is speed would lose out (HFT, some prop traders). Their current gain would instead accrue to those on the other side of the trades.
This comment is weird to me. Are you saying that the "financial sector" (incredibly vague term) makes 30% of US GDP? Not even close. A trivial Google search proves that it is way off base.
> finance, insurance, real estate, rental, and leasing ... is 20.7% of US GDP.
Also, most of the GDP in the "financial sector" is in commercial banks and insurance companies. Yes, they take risk, but not the kind being discussed here.
Since the original article is about Jane Street's financial market making business, let's focus on investment banks. What percent of US GDP do you think that investment banks and trading hedge funds represent? It is tiny. I would be shocked if it is more than 5%.
> What would happen if equity markets were only open a very short period a day? Say you have one auction a day, or maybe two, and no continuous trading?
This seems like a question from Econ 101. Let's expand that to all free markets in the US. What if homes could only be bought or sold once per month, instead of daily? How about agricultural products? Quickly this argument falls apart. Wholesale and financial markets with continuous trading have existed for centuries. The purpose of continuous trading (or very frequent auctions, like the agro auctions in the Netherlands) is price discovery. If you do it less frequently, then you have weaker price discovery and worse (less accurate) prices.
Finally, professional financial market makers have an important role to play in reducing the size of bid-ask spread. I recently bought some 1Y US Treasury bills using Interactive Brokers. I was stunned by how tight are the spreads, and I am a "Retail Normie/Nobody". Absolutely, this was not available to people like me 30 years ago. Who do you think is providing this liquidity that keeps bid-ask spreads so tight?
The finance sector contributes only 7% of GDP, correct.
One of the sources I had in mind [0] cites 31%, but that was revenue as a proportion of GDP, which doesn't really make sense. However, the financial sector takes about 30% of US profits [1].
With respect to trading only once a day, I don't think your ad absurdum counterarguments hold water.
The HK stock exchange used to trade 4.5 hours a day, from 10 to 12, and then after a generous 2 hour lunch break from 2 to 4:30. How is trading 8 or 12 hours a day better for pension funds?
Price discovery with a limit order book that's cleared once a day might work just as fine as when it's spread out over hours, maybe even better.
Think about some major event affecting a company happening on the weekend. Then everyone can put in buy/sell orders with adjusted prices, and they'll be cleared during the morning auction. How is that worse than if the event happens intraday, and only the most switched on automatic HFT will pick off people still quoting at the old price, then the professional traders in hedge funds will pick off people?
As I said, the difference would be that the gains of the fast movers would instead be distributed among those on the "wrong side" of the news. Why should price discovery be worse?
Finally, what makes you think that liquidity and bid-ask spread concentrated in a minute a day would be worse than spread out over many hours a day?
I think the amount of money that is creamed off for this service is disproportionate, and the amount of benefit to wider society a case of diminishing returns.
Allocation of capital, market liquidity etc are useful, but the size of the financial sector and the rewards it gives out for this shuffling of money are insane.
I.e., they work to increase the return on capital. Since I believe one of the biggest problems in the world today is economic inequality stemming from an increasing gulf in the remuneration of labour and the remuneration of capital, I don't think this is a good thing. Let alone a good use of stupendous amounts of talent and money.
The only reason software engineers are able to be paid so much at all is because of “capitalism” and “free trade” I.e. vacuuming up money from the rest of the world, we sell them ads and “SaaS” and “intellectual property” while they sell us food and clothes. Would be a bad day for me personally and our profession in the US when that stops
We’ve seen what happens when the price of eggs goes up a little bit, never before seen levels of prosperity seems to be the only way to convince Americans to treat each other kindly, pick your poison I guess
I didn’t take that to be his point. I assume he says “economically efficient” because he means their strongest skillsets don’t have (m)any other uses and they wouldn’t be realizing their potential by leaving those skills unused.
He probably overstates that case, especially talking to early career interns that haven’t yet narrowed their specialization and could pivot to other highly quantitative roles that use other high level math.
He’s also probably flattering his audience, to whom “math research” is more likely to be status-bearing.
To build on / extend on this - quants / finance folks need to cultivate an image of only taking the very brightest, to justify the shit working conditions (even if pay is often decent) but honestly the brightest tend not to apply. Working in those environments is neither rewarding nor stimulating.
1. It looks like Syncthing is an application that lets you sync files? Moonglow runs one layer below - we call cloud apis for you, to set up and connect you to a remote Jupyter kernel.
2. I think the serverless here is actually pretty literal - you don't have to think about or spin up a Jupyter server. We normally describe it as 'run local jupyter notebooks on your own cloud compute,' which I think might be a little more clear.
Not exactly. Brev.dev helps you set up a Jupyter server, but you still need to set up your connection to it yourself. It's also mostly designed to run on the browser.
Moonglow abstracts over this, so you don't need to think about the server connection details at all. We're aiming for an experience where it feels like you've moved your notebook from local to cloud compute while staying in your editor.
Yeah, I agree! We looked into integrating Moonglow with academic clusters, because many of my ML PhD friends complained about using them. We unfortunately haven't found a good generalized solution, so I think VSCode's remote SSH + manual server management is probably the best option for now.
We make sure the remote containers have CUDA/Pytorch/Numpy/Matplotlib set up if you're using a GPU-based machine. It's actually far easier for me to run ML-based code through Moonglow now than on my Macbook - it's really nice to start with a clean environment every time, instead of having to deal with dependency hell.
We don't yet transfer the python environment on the self-serve options, though for customers on AWS we'll help them create and maintain images with the packages they need.
I do have some ideas for making it easy to transfer environments over - it would probably involve letting people specify a requirements.txt and some apt dependencies and then automatically creating/deploying containers around that. Your idea of actually just detecting what's installed locally is pretty neat too, though.
However, looking at its replacement here (https://docs.databricks.com/en/dev-tools/bundles/index.html) - I think we're trying to solve the same problems at different levels. My guess is Databricks is the right solution for big teams that need well-defined staging/prod/dev environment. We're targeting smaller teams that might be doing more of their own devops or are still at the 'using a bash script to run notebooks remotely' stage.
A lot of the people we've talked to who get the most value out of remote compute are doing really intensive stuff - they need server-level resources far beyond what you can find on a consumer laptop!
Hopefully someday you'll have 8 H100s on your Macbook, but I think we're still a long way away from that.
The big difference is that Google Colab runs in your web browser, whereas Moonglow lets you connect to compute in the VSCode/Cursor notebook interface. We've found a lot of people really like the code-completion in VSCode/Cursor and want to be able to access it while writing notebook code.
Colab only lets you connect to compute provided by Google. For instance, even Colab Pro doesn't offer H100s, whereas you can get that pretty easily on Runpod.
(The above might not work with runpod, since their execution environment is locked down. However it works with other clouds like Lambda, Hyperstack, etc.)
Ah, yeah, I misspoke, sorry. I was aware of that feature, but everyone I've talked to said it's so annoying to use they basically never use it, so I didn't think it was worth mentioning.
The big reason it's annoying is because (I believe) Colab still only lets you connect to runtimes running on your computer - which is why at the end at the end of that article they suggest using SSH port forwarding if you want to connect to a remote cluster. I know at least one company has written a hacky wrapper that researchers can use to connect to their own cluster through Colab, but it's not ideal.
I think Moonglow's target audience is slightly different than Colab's though because of the tight VSCode/Cursor integration - many people we've talked to said they really value the code-complete, which you can't get in any web frontend!
Interesting idea. I'm not very well-versed in training models or LLMs or even Jupyter Notebooks, but the comment about port forwarding SSH caught my eye since I work on a free, open source zero-trust overlay network (OpenZiti). I tried to find some information about moonglow under the hood / how it worked but didn't succeed.
If you're interested, you might find embedding OpenZiti into Moonglow a pretty compelling alternative to port forwarding and it might open even crazier ideas once your connectivitiy is embedded into the app. You can find the cheapest compute for people and just connect them to that cheapest compute using your extension... Might be interesting? Anyway, I'd be happy to discuss some time if that sounds neat... Until then, good luck with your launch!
Cool! We actually don't do port forwarding over SSH, we do it over an ngrok-like solution that we forked/modified. I looked at a few options while we were designing this, including Tailscale and ngrok, but none of them exactly suited our needs, and the pricing would have been prohibitive for something that's a pretty core part of our product.
OpenZiti looks really cool though - I'll take a look!
At a glance, the RunPod's serverless and pod options would probably work well with OpenZiti. I didn't explore their vLLM option.
Using OpenZiti w/ Serverless probably means integrating an OpenZiti SDK with your serverless application. That way, it'll connect to the OpenZiti network every time it spawns.
The SDK option works anywhere you can deploy your application because it doesn't need any sidecar, agent, proxy, etc, so it's definitely the most flexible and I can give you some examples if you mention the language or framework you're using.
The pod option says "container based" so it'll take some investigation to find out if an OpenZiti sidecar or other tunneling proxy is an option. Would you be looking to publish something running in RunPod (the server is in RunPod), or access something elsewhere from a RunPod pod (the client is in RunPod), or both?
I poked at it a bit but there was no free trial period. I know a bunch of people are using OpenZiti and zrok for Jupyter notebooks in general... Here's a blog I saw not long back that might help but I wasn't able to prove/test/try it... (sorry)
> I think Moonglow's target audience is slightly different than Colab's though because of the tight VSCode/Cursor integration - many people we've talked to said they really value the code-complete, which you can't get in any web frontend!
At the risk of repeating the famous Dropbox comment
I like the idea and that the ease of usage is your selling point. But I don't know if that is actually a reasonable reason. People who are entrenched that much in VSCode ecosystem wouldn't find it a problem to deploy dockerized Nvidia GPU container and connect to their own compute instance via remote/tunnel plugins on VSCode which one can argue does make more sense.
Congratulations on the launch and good luck with the product.
Thanks! I think the "deploy and connect" workflow is itself not super painful, but even if you're invested in VSCode, doing that again and again every day is pretty annoying (and it certainly was for me when I used to do ML), so hopefully the ease of use is valuable for people.
Hi HN - I'm the founder of Stardrift, and we're looking for a founding engineer to join our team of 3-4. (Fun fact: I got my first coding job through 'Who is hiring?', almost 12 years ago!)
We are building a world-class travel search experience. In the future, you won’t book travel by opening ten tabs in Google Flights; you’ll book through a personalized AI assistant that understands everything about you and automatically arranges your trip for you.
You'll tackle everything from optimizing LLM performance and building evals to integrating APIs like Amadeus and Duffel. We care about moving fast and writing high-quality code; your job will be to take customer feedback and improve our product, working shoulder-to-shoulder with me & the rest of the founding team.
More info at https://www.ycombinator.com/companies/stardrift/jobs/nC7cjhB....
Please reach out to leila@stardrift.ai to apply.