I posted this. I'm just a regular dev, without any kind of attachment to Jane Street, in fact i'm a little wary of them, and would subscribe to Evan Czaplicki's understanding of the faustian bargain working there would involve. I think they're banned from India, if you want an example of the kind of raiding they are equipped to do.
In general - I am wondering how engineering interviews change in the age of LLMs, Jane Street, tech-wise is a "thought leader", at least having opinions, sharing them is part of how they recruit "the best", i think oxide does this too.
So in some way, in this time of change it makes sense that they are noisy... It also makes sense that the noises they make may filter down...
> I'm just a regular dev, without any kind of attachment to Jane Street, in fact i'm a little wary of them, and would subscribe to Evan Czaplicki's understanding of the faustian bargain working there would involve.
Mind going more into this, since you named a specific person? Did he make some prominent statement?
Jane Street's whole business is front running and arbitrage. They make money in a way that's extremely unfair to the point a whole new stock exchange (IEX) was designed to stop it, hurts both retail and institutional investors, and provides no useful service to society.
All they've ever done for anyone but themselves is work on the OCaml ecosystem which is not exactly the biggest or most innovative.
Man, HN has really started to decline. How exactly is Jane Street front running?
Reacting faster than others to markets is not front running. Seeing someone else's order and putting yours in front of it is front running. Traders on the NYSE Floor would hear a big order is coming in, and put their ticket in front of it- that is front running.
In a computerized world, front running has essentially ceased to exist- the last major enforcement actions I could find are from 2003, when there was still quite a bit of trading done not by pushing buttons on a computer but by making phone calls. Trading on inside information is alive and well, but this is not what JS does at all, that's the realm of hedge funds that have traders that still click on buttons.
I'm sure they make money using HFT strategies but I wouldn't say it's their whole business or even their largest profit center. They put on trades and take on risk in addition to having a market-making business. They're not the reason IEX was formed. Maybe they were a factor but idk.
YOu're selling your soul for $ and telling yourself that you aren't extracting rents or directly harming retail investors but are just helping the market with price discovery.
Yeah, sorry, I didn't mean to imply anything nefarious on your part (or anyone else's part). It's just odd that a single financial firm keeps coming up.
OCaml like a lot of niche functional programming languages has a lot of weight on HN. Or used to for many many years, mostly before LLMs. Jane street is single-handedly keeping OCaml alive and in use in real applications and as such they get a lot of credence.
Whether you agree with what they do or not, they have had a sort of mystique about them (tons of money, quant vests, _and_ a niche functional programming language as a daily driver??? Sign me up!) that HN likes.
There are three Jane Street stories on the front page right now. This one, "Socratic Tutor (github.com/janestreet)", and "A false smoke alarm almost drowned Jane Street's only NYC datacenter (bacarella.com)".
What I learned over time is that first, the pool of people who regularly submit to HN is surprisingly small, so if they have interest in a particular set of topics, these topics are overrepresented in the queue; and second, relatively few people patrol new submissions and the the first 3-4 upvotes in the first 15 minutes decide if something bubbles up to the front page or not. These folks often go by keywords / vibes / employer associations, so again, certain topics get an advantage that's unrelated to the merit of the story.
More generally, I think there's been a significant drop in topic diversity on HN over the past year. Almost everything on the front page is related in some way to AI or to companies on the forefront of AI. It's almost as if there's nothing else going on in tech or in the broader world. If you go to some other aggregators, you get a different view.
They pay a LOT of money, have some high level of “nerd” prestige for solving interesting technical problems, have good outreach with things like problem of the month, and have not been impacted by massive layoffs.
There are pretty few companies out there like this. Being relatively small probably helps; everyone knows someone that worked at Mag7 and maybe has a bad story to share, but this is more rare.
> They pay a LOT of money, have some high level of “nerd” prestige for solving interesting technical problems, have good outreach with things like problem of the month, and have not been impacted by massive layoffs.
I never heard of them.
If not for HN, I would never know they existed.
I don't think the remark about "nerd prestige" holds, but beyond that your points boil down to marketing.
And how an unknown company changed its hiring practices is hardly front page news.
Paying a lot of money and hard technical problems are not exactly marketing.
Like I said, they are relatively small but they are definitely not “unknown”. Out of curiosity, could you name any quantitative trading firm, or trading firms in general? You specifically may happen to just not be paying much attention to this sector.
All three stories fit the criteria of gratifying one's intellectual curiosity, which is goal of Hacker News submissions.
Consider this: Would you find anything unusual about seeing those stories on the front page if each came from a different company or didn't mention the company name at all? I wouldn't, because each of the submissions is primarily interesting for the content, not the company associated with it.
so, i've gone through a bunch of iterations on how to interview in days of LLMs and i came up with a process that is quite good:
first, a coding problem that is solved live (right now, online) -- it's not a hard one and most LLMs can easily one shot it.
BUT: if you are not a senior developer, you need to do it without LLM, and if you are a senior+ and do it via LLM, the bar is super raised and now you need to explain in details everything the LLM wrote as if you wrote it yourself.
the main component here is to know if the candidate understands coding in general, understands problem solving and how to dive into an existing (although quite small) codebase. solving the problem is not really the goal -- in fact, most candidates we hired did not solve it 100%, but were able to understand and explain everything that they put it on code. this usually takes 1h30.
(we also ask the candidate to open a PR against the repo just to see if they know the basics of git -- you would be surprise how many people cannot do it).
the second is an architecture interview, where we build a system together BUT instead of doing the whole spec, miro board, whatever, we do it in more of a free way: we start with a really simple, MVP level, spec and we ask how the candidate would build it. then, we add another feature, and we ask how they would go for it. during this whole thing, i ask random questions like "why would you use x instead of y?" or "why do you prefer this approach?".
one important thing: we allow the candidate to say "i don't know" and we tell the candidate that there's no gotcha questions (which is true, i hate these kind of questions). this lets the candidate be super comfortable (feedback we had from real people).
in general, this flow helped us a ton and i really really like running it :)
I feel like git operations are one of the few things that I truly don't care at all about whether someone uses an LLM for and doesn't tell me. PR descriptions and commit messages should be written by humans for humans, but like, if someone doesn't know how to manually configure their git remotes and what exact command to use to amend/squash their commits into the shape needed and instead has an agent prepare all that and use the GitHub CLI to open the PR, why should I care? Beyond the code itself, I care about the things that will continue existing in the long run fitting my team's conventions (the number of commits, the commit messages, the PR description and comments, and then whether there's a merge commit at the end), but the process used to create those things doesn't matter to me.
Wasn't this a think before_ai? Enough people are using IDEs which handle this for them. I still have to check a few commands now and then.
Though ideally interviewers should appreciate this - unless its a hard requirement you do it by hand day to day - the rest of us can look this up quick enough.
At previous jobs, I was the one coworkers would come to when they had messy git problems and needed help cleaning them up. I've put in the hours in the past to learn how to do all of that, and then later forgotten it because it's just not worth it anymore. I switched to jj a few years ago and had the majority of the annoying rebase issues go away, and whatever's left goes into my LLM to spit out a potential solution that I can then manually tweak if the result isn't perfect.
My OS professor in college once told us about what he considered the difference between "knowledge" and "information", with "knowledge" being the underlying facts about how something works and "information" being the terminology/labeling/bucketing/etc. of how to refer to it. The point he made was that knowledge was more important than information, and that he would try to test us on knowledge rather than information. To me, knowing how the underlying version control model works and what "shapes" you might want to make with it is useful knowledge. The exact set of commands, interactions with an IDE, or specific prompts you can use to ask an LLM to produce them is information. Arguably the entire benefit of LLMs is that you can ask them to do things even if you don't have the exact information memorized; if you can describe it in a rigorous way, and recognize whether what it gives you as an output fits that or not, you don't need to know any of the actual information of how to do it manually.
> but like, if someone doesn't know how to manually configure their git remotes and what exact command to use to amend/squash their commits into the shape needed and instead has an agent prepare all that and use the GitHub CLI to open the PR, why should I care?
Because LLMs aren't a reason to not learn your tools. A determinist CLI command vs using a statistical machine for it. It's just a waste of tokens at the very least.
No, the reason not to learn your tools is if they're not your tools anymore, and something else is. I don't spend time trying to manually invoke filesystem APIs to create files in my work projects and instead will often just have my LSP do it when I declare a module and the file isn't found. I could memorize the exact sequence of system calls needed, but my employer would prefer I spend time on things that are more worthwhile to them.
I don't disagree that having a deterministic CLI is useful, but I'd argue that's not the question here, because the CLI is what the statistical machine will be using. The question is whether the time spent doing it manually is worthwhile compared to the tokens spent on it. I'd further argue that if you instead learn how to pick the right model for the right job so that you don't use something way more expensive than needed for the task at hand, the token overhead will be extremely minimal for stuff like git operations; knowing that you can use something cheaper than like, Astra or Opus if all you want to do is a quick git cleanup and push is going to save your employer a lot more money in the long run than if you insist on doing every messy rebase by hand.
While using LLMs is a great idea, it has become crucial to put safeguards in place to ensure that their use doesn't deviate from team practices or compromise security.
I'd argue that these are not really specific to git (or even LLMs honestly); in terms of security, don't put company data into anything that your company hasn't given you explicit permission to put it into.
In terms of team practices, that basically seems like a code review thing. If my team has conventions around git, and a PR doesn't fit them, that's something I would point out regardless of how the PR was generated. If a team member is repeatedly not meeting the expectations we've all agreed upon, I would deal with it in the same way I always have; reach out and offer guidance for how to do things the way they're supposed to, notify my manager if they continue having trouble with it, and eventually just not bother looking at their PRs if they absolutely refuse to do things the way everyone else on the team has agreed they should be done.
In the before time, this is the sort of thing people would just google.
One time setup commands are the sort of thing people do once when setting up the repo, but dont use day to day. its understandable that people dont have that memorized and will reach for a man page, google or an AI.
I happen to have memorised how to add new remotes a long time ago, but I would 100% not care if someone I worked with googled it every time. That's how it was for me for several years. I don't think that has anything to do with "learning the tools". And getting claude to do it is not that much different from copy-pasting from google.
Some 6-figure per year developer spending a quarter’s worth of tokens to do something they do once a month or so is not something I’ll ever care to optimize away…
That's pretty much where I'm at, so long as they're not filling the code with "///CLAUDE ADDITION" type guards (ie noise).
Personally I ask the LLM to summarise what the commit does and explain it to me, make sure I understand it, then review the PR. I'm getting half the speed the High Speed Sloperators are getting but I was the only person submitting PRs the other day when the LLM service was down.
For nasty multi-way git merges and rebases, it's been a game changer. And of course that's reviewable by doing a delta on the final rebase branch vs. the original branch.
With all that said... having to use LLMs at work is making me want to use them less on my own projects.
Oh, I was not even attempting to discuss using them for the code itself in my above comment. Code that's checked into a repo has a much more complex set of tradeoffs that I'm much less convinced have a one-size-fits-all answer. My point was more that even if reasonable people can disagree on how much you need to care about the code itself being LLM generated, I can't wrap my head around why anyone should care whether an LLM happened to execute the `git commit` and `git push` shell commands!
But, like... wouldn't you want them to at least know the steps of `git add` -> `git commit` -> `git push` and then click the button on Github? And Gitlab has basically the same web UI.
I have no problem with letting an IDE or LLM handle those details in practice... but I don't think I'd want to work with someone who doesn't understand the very basics of what's going on under the hood.
> might know plenty of git, but haven't worked with Github
That seems very unlikely. Github is the entire reason git is so popular, vs. any of the other distributed VC systems.
Edit: I'll refine that, after a moment of thought. Git is popular because of Github. But, I guess that now maybe there are people who are using git because it's the popular/default version control choice, but they might not be using Github. They might be using another forge, something homegrown, or just manual builds.
Github was like Yahoo's directory, a way to share content in a searchable place and as a backup/bounce point. In the early days you could also upload to 'downloads' so it was a quick share host. Before that we had email, exposed ssh and cgit/gitweb but Github gave us `PR` to promote social interactions with forking. So it could be argued that Github tainted the spirit of git.
Having personally evolved from making date stamped zip files, to subversion and then to git, it earned its place quite quickly for myself and my roaming nature, didn't hurt who hacked it together either. When Linux adopted it from Bitkeeper, it became the way for many.
Git is a simple tool. I expect any engineer can learn to use it. While git is common, I would not expect an engineer who worked at a company using a different version control system to know how to use git (which is a really awful - I still miss mercurial). I expect you to know the general concept of version control, but the specific on is a tool I expect you can learn quickly.
I run a live coding challenge on a rather benign coding problem with the explicit expectation that candidates will use an LLM.
Interestingly, an LLM involved feels like it’s made it easier to assess candidates. Senior candidates know exactly what they’re doing and strongly driving the LLM. They pre-communicating design decisions, gotchas, and requirements. They also ask a lot of clarifying questions and dial in the scope (after all not building something is better than building it).
Less experienced candidates tend to jump right in, build way too much, and stumble because they delegated all of the critical thinking to the agent. They often end up in a place where the agent doesn’t align with their vision and they can’t really reign it back in.
At one job I had, we used git extensively, but not GitHub. We had internal systems for review and branch management. I could tell you all the gory details about various workflows and landmines in git. Is the test here really about git, or git+GitHub?
I rarely use anything beyond checkout, clone, pull, commit, cherry-pick, revert, and push in a job. If I have to, I'm probably asking the AI what to do by giving it my situation. And hopefully the AI can read about whatever git standards the company would like to be enforced so the engineer doesn't have to interrupt someone for that.
This is more about opportunity cost because instead of asking about git, you could ask about other valuable skills in your limited time with the interviewee, but I guess if git is really that important, then it's justified.
Well, I've been using git at work for 6 or 7 years, but I can't out of hand open a PR; at work we very rarely use different branches and the last time I touched Github I was a student.
Do you mean specifically Github, or any code forge at all? When you say "we rarely use different branches", what do you mean - you're all pushing to master, or you have branches for each team or something? I would regard "code forge" and "separate branch per reviewable unit of work" as extremely normal, nearly universal.
> (we also ask the candidate to open a PR against the repo just to see if they know the basics of git -- you would be surprise how many people cannot do it).
How does that work? Git has no concept of pull requests.
Something similar for senior devs: code reviews. Reading and understanding code has always been important. I find offering simple code reviews very telling. In a way, your LLM approach matches that. It's a way to do a code review. It's a test of understanding, and not just memorization.
There are a lot of people telling you how they interview and why. Almost none of them have shown even the slightly indication that they are aware there there is scientific research on what works for an interview, much less that they apply it. They also are not showing any indication that they have done any testing - to see if their questions help hire better people.
If I said they could get equal results by picking resumes at random and hiring them without any other screening could they refute that? If so have they justified every part of their process or just one step that is useful and the rest they don't know?
> Almost none of them have shown even the slightly indication that they are aware there there is scientific research on what works for an interview,
The topic of the article is about adapting interviews in the age of LLMs.
Scientific research on interview techniques requires years of retrospective analysis after the hired employees have been evaluated in their roles for a long time.
That research does not exist on this topic. It's too new. I don't think this is a valid criticism of the actual article.
They do say "Not every onsite includes these new rounds yet, and when you come on-site we’ll give you a heads-up about what to expect."
So that implies that they are testing this, trying to determine if it works better than the current process. Whether they are doing this in a scientifically rigorous way is unclear, however.
Even Steve Yegge got selected (or maybe nearly selected) out by his own process (unwittingly, mind you)
> One day, the recruiters gave us a special round of packets to review. In these special packets, we were able to read the interviewer notes and candidate responses. All personal details were stripped out, and we were told it was a “calibration exercise.” We had to do our regular voting job with these special packets, and see how it went. I think we may have assumed they were from another site, since cross-site calibration was common.
> Our group did our job, and voted not to hire about 2/3 of the packets. This was about par for the course.
> But surprise surprise, this time, those were our own packets from when we had all interviewed at Google. The recruiters had tricked us into reviewing our own interview packets, and we had voted not to hire most of our own group.
This is the third Jane Street-related thing I've seen on here this week after not seeing much about them that I can remember any time recently beforehand I'm aware of their use of OCaml and probably do other things that might be of interest to the HN community, but it seems like a lot in a very short time out of nowhere. Is there some sort of marketing push or something going on?
According to algolia, there were 57 posts with jane street somewhere in the title or url in the last year, so a bit more than one per week. For a Poisson distribution with rate = 57/52, P(X >= 4) ~= 2.5%. So there should on average be ~5 weeks with 4 or more jane street related posts at that rate.
I appreciate a data-focused response here! What I'm more curious about is how many of these reached the front page. My impression is that the rate of how often they reach the front page is probably a good amount lower than once a week, which I think makes the question of whether this is a coincidence or not more reasonable.
People like to talk about Jane Street because it is this Very High IQ™ company that pays people astronomical salaries and is extremely hard to get into.
They don't have to do marketing, though. It's not like they sell anything to Hacker News readers, they make their money trading finantial assets
You don't think that companies who want to hire engineers ever try to post stuff to Hacker News as a way to market themselves as a potential employer? Where did you get this impression of "Very High IQ" and "astronomical salaries"? I'm guessing at least part of it is from reading stuff from them or from talking to other people who read stuff from them.
The fact that you seem to adamantly disagree that there's any plausible angle here doesn't mean it's not marketing, but it might mean that it is marketing and that it's working on you.
Such strong wording, you got that from me saying "They don't have to do marketing"?
> where did you get this impression of [...] "astronomical salaries"?
From the real world fact that the base salary is US$300k/yr, and often said that the total compensation for the first year ends up being US$700k+. Even for Manhattan + SWE jobs, surely that merits "astronomical". Other devs making that much are usually working at Anthropic or OpenAI, aren't they?
> where did you get this impression of "Very High IQ"?
You didn't copy my ™ there, which was meant to be snarky.
In any case, what I was trying to say is that they don't have to do marketing in the usual sense. They don't have to get the Jane Street logo in your subconscious so you buy a Jane St. product when you go to Kroger's, and you can't sign a Jane St. subscription plan.
People in this thread seem to be implying that the company is botting/astroturfing, but for what? To maintain the image that they're a highly sought after employer?
Anything Paul Graham posts gets upvoted here instantly, because it's Paul Graham who posted it. For Jane Street there's the same halo effect, because many believe Jane Street's work is impressive. Is it really easier to believe the idea of botting to get an even longer list of candidates to interview, than it is to believe people just like to hear what this company has to say?
I don't ever see anyone saying Paul Graham is botting posts about his "essays"
> Such strong wording, you got that from me saying "They don't have to do marketing"?
The only alternative interpretation I can think of for what you said is "they waste resources on marketing they don't need to do". I didn't think that was more likely to be your intended meaning, but you're welcome to correct me on it.
> From the real world fact that the base salary is US$300k/yr, and often said that the total compensation for the first year ends up being US$700k+.
Can you clarify where these numbers are coming from? Real world facts tend to have sources that can verify them.
> In any case, what I was trying to say is that they don't have to do marketing in the usual sense. They don't have to get the Jane Street logo in your subconscious so you buy a Jane St. product when you go to Kroger's, and you can't sign a Jane St. subscription plan.
> People in this thread seem to be implying that the company is botting/astroturfing, but for what? To maintain the image that they're a highly sought after employer?
Yes, that's exactly what I'm implying. I honestly would have stated it explicitly in the first place, but I made the incorrect assumption that it was not controversial to claim that this phenomenon exists at least for some companies and that it can be described as a form of marketing.
> Anything Paul Graham posts gets upvoted here instantly, because it's Paul Graham who posted it. For Jane Street there's the same halo effect, because many believe Jane Street's work is impressive. Is it really easier to believe the idea of botting to get an even longer list of candidates to interview, than it is to believe people just like to hear what this company has to say?
> I don't ever see anyone saying Paul Graham is botting posts about his "essays"
If we were discussing this on a website originally created by Jane Street, I would find this a more compelling counterargument. That said, I also don't bother trying to discuss his writing much because I mostly find it insufferable. I find the motives of Jane Street to be more interesting precisely because my opinion on them is more malleable.
> Real world facts tend to have sources that can verify them.
Sure. What I said is a real world fact is the base salary, which can be verified by any of their job postings, e.g. www.janestreet.com/join-jane-street/position/4274288002, where it says "Base salary is $300,000. Base salary is only one part of Jane Street total compensation, which includes an annual discretionary bonus".
The claim that has less direct sources is how much the TC ends up being. The figure I said is the one I've heard multiple times over, sometimes by JS employees themselves, so I assume it to be true
> If we were discussing this on a website originally created by Jane Street, I would find this a more compelling counterargument.
That's fair, but I used Graham just as an example of source that always gets upvotes here. Uncle Bob hasn't posted anything in a while, but if he did, it'd certainly trend here, so that might be a better example
> I find the motives of Jane Street to be more interesting precisely because my opinion on them is more malleable.
Yes, that's fair. I don't think it's impossible that JS would bot/astroturf like you're implying, I just don't think it's the case. By Occam's razor I find it's more likely that people do care for what they have to say, similar to P. Graham, Uncle Bob, or any sort of blogpost from Anthropic/OpenAI, etc. It's quite possible that they got to this stage due to intentional marketing, though, so I'll give you that
I had lunch with a couple friends this week, and we each work in different tech environments. Most of the conversation was about the workflows we're each using, and seeing our colleagues use.
It's a really interesting time to work in this field. People who are paying attention to workflows are using a range of tools, and constantly refining their own workflow. For example a whole team might use Claude, but one person collects data about their own usage on an ongoing basis and develops more advanced workflows than everyone else on the team. Their focus isn't just about working faster, but about doing better work.
I don't think the post is vague; I think we're at a time where you need flexibility in your interview process to find candidates who are doing the best work these days.
Back then, people who were bad at interviews were often undervalued. I think interview culture itself will soon be devalued and eventually become obsolete. People who build real technology and solve real problems will be unaffected, while the glorified Valley slop built around interview performance will become obsolete.
My optimism comes from AI's ability to solve genuinely hard mathematical problems this year. September and October could go down as two of the most remarkable months in the history of AI If, and only if, those proofs are correct and independently verified by real experts. Even if the proofs have been formally verified in Lean, expert scrutiny still matters.
This sort of announcement has made me very happy I left the software world. I still code as part of my job, but it's not my main part and luckily I don't have to use LLMs are part of my job. I still code 100% by hand.
In some ways, although I detest AI, it has clarified the sort of people and organizations I want to associate with. Any latent characteristics that I abhor have been made obvious with the existence of AI and of course, I would want nothing to do with Jane Street.
This is a completely side comment, but I don't understand why stories about Jane Street keep making the front page day after day:
Today: https://news.ycombinator.com/item?id=50467297
Yesterday: https://news.ycombinator.com/item?id=50455394
Two days Ago: https://news.ycombinator.com/item?id=50438261
It's a bit odd (?!).
I posted this. I'm just a regular dev, without any kind of attachment to Jane Street, in fact i'm a little wary of them, and would subscribe to Evan Czaplicki's understanding of the faustian bargain working there would involve. I think they're banned from India, if you want an example of the kind of raiding they are equipped to do.
In general - I am wondering how engineering interviews change in the age of LLMs, Jane Street, tech-wise is a "thought leader", at least having opinions, sharing them is part of how they recruit "the best", i think oxide does this too.
So in some way, in this time of change it makes sense that they are noisy... It also makes sense that the noises they make may filter down...
> I'm just a regular dev, without any kind of attachment to Jane Street, in fact i'm a little wary of them, and would subscribe to Evan Czaplicki's understanding of the faustian bargain working there would involve.
Mind going more into this, since you named a specific person? Did he make some prominent statement?
Jane Street's whole business is front running and arbitrage. They make money in a way that's extremely unfair to the point a whole new stock exchange (IEX) was designed to stop it, hurts both retail and institutional investors, and provides no useful service to society.
All they've ever done for anyone but themselves is work on the OCaml ecosystem which is not exactly the biggest or most innovative.
Man, HN has really started to decline. How exactly is Jane Street front running?
Reacting faster than others to markets is not front running. Seeing someone else's order and putting yours in front of it is front running. Traders on the NYSE Floor would hear a big order is coming in, and put their ticket in front of it- that is front running.
In a computerized world, front running has essentially ceased to exist- the last major enforcement actions I could find are from 2003, when there was still quite a bit of trading done not by pushing buttons on a computer but by making phone calls. Trading on inside information is alive and well, but this is not what JS does at all, that's the realm of hedge funds that have traders that still click on buttons.
I never worked at JS, but have worked in MM.
I'm sure they make money using HFT strategies but I wouldn't say it's their whole business or even their largest profit center. They put on trades and take on risk in addition to having a market-making business. They're not the reason IEX was formed. Maybe they were a factor but idk.
> Jane Street's whole business is front running and arbitrage.
I instinctively hear a reply to this in Jeremy Irons’s voice, “We are selling to willing buyers at the current fair market price”.
It's a case study here: https://www.youtube.com/watch?v=sl1UQXgtepE I think the critique is implicit so YMMV. Just my interpretation.
YOu're selling your soul for $ and telling yourself that you aren't extracting rents or directly harming retail investors but are just helping the market with price discovery.
Yeah, sorry, I didn't mean to imply anything nefarious on your part (or anyone else's part). It's just odd that a single financial firm keeps coming up.
OCaml like a lot of niche functional programming languages has a lot of weight on HN. Or used to for many many years, mostly before LLMs. Jane street is single-handedly keeping OCaml alive and in use in real applications and as such they get a lot of credence.
Whether you agree with what they do or not, they have had a sort of mystique about them (tons of money, quant vests, _and_ a niche functional programming language as a daily driver??? Sign me up!) that HN likes.
There are three Jane Street stories on the front page right now. This one, "Socratic Tutor (github.com/janestreet)", and "A false smoke alarm almost drowned Jane Street's only NYC datacenter (bacarella.com)".
What I learned over time is that first, the pool of people who regularly submit to HN is surprisingly small, so if they have interest in a particular set of topics, these topics are overrepresented in the queue; and second, relatively few people patrol new submissions and the the first 3-4 upvotes in the first 15 minutes decide if something bubbles up to the front page or not. These folks often go by keywords / vibes / employer associations, so again, certain topics get an advantage that's unrelated to the merit of the story.
More generally, I think there's been a significant drop in topic diversity on HN over the past year. Almost everything on the front page is related in some way to AI or to companies on the forefront of AI. It's almost as if there's nothing else going on in tech or in the broader world. If you go to some other aggregators, you get a different view.
They pay a LOT of money, have some high level of “nerd” prestige for solving interesting technical problems, have good outreach with things like problem of the month, and have not been impacted by massive layoffs.
There are pretty few companies out there like this. Being relatively small probably helps; everyone knows someone that worked at Mag7 and maybe has a bad story to share, but this is more rare.
> They pay a LOT of money, have some high level of “nerd” prestige for solving interesting technical problems, have good outreach with things like problem of the month, and have not been impacted by massive layoffs.
I never heard of them.
If not for HN, I would never know they existed.
I don't think the remark about "nerd prestige" holds, but beyond that your points boil down to marketing.
And how an unknown company changed its hiring practices is hardly front page news.
Paying a lot of money and hard technical problems are not exactly marketing.
Like I said, they are relatively small but they are definitely not “unknown”. Out of curiosity, could you name any quantitative trading firm, or trading firms in general? You specifically may happen to just not be paying much attention to this sector.
Your ignorance of something does not mean the thing you are ignorant of is inconsequential
I am particularly fond of the assessment that Jane Street is a federation of anarcho-capitalist syndicates disguised as a quantitative trading firm.
All three stories fit the criteria of gratifying one's intellectual curiosity, which is goal of Hacker News submissions.
Consider this: Would you find anything unusual about seeing those stories on the front page if each came from a different company or didn't mention the company name at all? I wouldn't, because each of the submissions is primarily interesting for the content, not the company associated with it.
That may or may not be suspicious, but Jane Street has been posted here a lot since forever, mostly because of ocaml.
Noticing a bit too much
What is the deal with it though? Daily front page content in various forms starts to raise eyebrows.
so, i've gone through a bunch of iterations on how to interview in days of LLMs and i came up with a process that is quite good:
first, a coding problem that is solved live (right now, online) -- it's not a hard one and most LLMs can easily one shot it.
BUT: if you are not a senior developer, you need to do it without LLM, and if you are a senior+ and do it via LLM, the bar is super raised and now you need to explain in details everything the LLM wrote as if you wrote it yourself.
the main component here is to know if the candidate understands coding in general, understands problem solving and how to dive into an existing (although quite small) codebase. solving the problem is not really the goal -- in fact, most candidates we hired did not solve it 100%, but were able to understand and explain everything that they put it on code. this usually takes 1h30.
(we also ask the candidate to open a PR against the repo just to see if they know the basics of git -- you would be surprise how many people cannot do it).
the second is an architecture interview, where we build a system together BUT instead of doing the whole spec, miro board, whatever, we do it in more of a free way: we start with a really simple, MVP level, spec and we ask how the candidate would build it. then, we add another feature, and we ask how they would go for it. during this whole thing, i ask random questions like "why would you use x instead of y?" or "why do you prefer this approach?".
one important thing: we allow the candidate to say "i don't know" and we tell the candidate that there's no gotcha questions (which is true, i hate these kind of questions). this lets the candidate be super comfortable (feedback we had from real people).
in general, this flow helped us a ton and i really really like running it :)
(edit: spelling)
I feel like git operations are one of the few things that I truly don't care at all about whether someone uses an LLM for and doesn't tell me. PR descriptions and commit messages should be written by humans for humans, but like, if someone doesn't know how to manually configure their git remotes and what exact command to use to amend/squash their commits into the shape needed and instead has an agent prepare all that and use the GitHub CLI to open the PR, why should I care? Beyond the code itself, I care about the things that will continue existing in the long run fitting my team's conventions (the number of commits, the commit messages, the PR description and comments, and then whether there's a merge commit at the end), but the process used to create those things doesn't matter to me.
Wasn't this a think before_ai? Enough people are using IDEs which handle this for them. I still have to check a few commands now and then.
Though ideally interviewers should appreciate this - unless its a hard requirement you do it by hand day to day - the rest of us can look this up quick enough.
At previous jobs, I was the one coworkers would come to when they had messy git problems and needed help cleaning them up. I've put in the hours in the past to learn how to do all of that, and then later forgotten it because it's just not worth it anymore. I switched to jj a few years ago and had the majority of the annoying rebase issues go away, and whatever's left goes into my LLM to spit out a potential solution that I can then manually tweak if the result isn't perfect.
My OS professor in college once told us about what he considered the difference between "knowledge" and "information", with "knowledge" being the underlying facts about how something works and "information" being the terminology/labeling/bucketing/etc. of how to refer to it. The point he made was that knowledge was more important than information, and that he would try to test us on knowledge rather than information. To me, knowing how the underlying version control model works and what "shapes" you might want to make with it is useful knowledge. The exact set of commands, interactions with an IDE, or specific prompts you can use to ask an LLM to produce them is information. Arguably the entire benefit of LLMs is that you can ask them to do things even if you don't have the exact information memorized; if you can describe it in a rigorous way, and recognize whether what it gives you as an output fits that or not, you don't need to know any of the actual information of how to do it manually.
> but like, if someone doesn't know how to manually configure their git remotes and what exact command to use to amend/squash their commits into the shape needed and instead has an agent prepare all that and use the GitHub CLI to open the PR, why should I care?
Because LLMs aren't a reason to not learn your tools. A determinist CLI command vs using a statistical machine for it. It's just a waste of tokens at the very least.
No, the reason not to learn your tools is if they're not your tools anymore, and something else is. I don't spend time trying to manually invoke filesystem APIs to create files in my work projects and instead will often just have my LSP do it when I declare a module and the file isn't found. I could memorize the exact sequence of system calls needed, but my employer would prefer I spend time on things that are more worthwhile to them.
I don't disagree that having a deterministic CLI is useful, but I'd argue that's not the question here, because the CLI is what the statistical machine will be using. The question is whether the time spent doing it manually is worthwhile compared to the tokens spent on it. I'd further argue that if you instead learn how to pick the right model for the right job so that you don't use something way more expensive than needed for the task at hand, the token overhead will be extremely minimal for stuff like git operations; knowing that you can use something cheaper than like, Astra or Opus if all you want to do is a quick git cleanup and push is going to save your employer a lot more money in the long run than if you insist on doing every messy rebase by hand.
While using LLMs is a great idea, it has become crucial to put safeguards in place to ensure that their use doesn't deviate from team practices or compromise security.
I'd argue that these are not really specific to git (or even LLMs honestly); in terms of security, don't put company data into anything that your company hasn't given you explicit permission to put it into.
In terms of team practices, that basically seems like a code review thing. If my team has conventions around git, and a PR doesn't fit them, that's something I would point out regardless of how the PR was generated. If a team member is repeatedly not meeting the expectations we've all agreed upon, I would deal with it in the same way I always have; reach out and offer guidance for how to do things the way they're supposed to, notify my manager if they continue having trouble with it, and eventually just not bother looking at their PRs if they absolutely refuse to do things the way everyone else on the team has agreed they should be done.
In the before time, this is the sort of thing people would just google.
One time setup commands are the sort of thing people do once when setting up the repo, but dont use day to day. its understandable that people dont have that memorized and will reach for a man page, google or an AI.
I happen to have memorised how to add new remotes a long time ago, but I would 100% not care if someone I worked with googled it every time. That's how it was for me for several years. I don't think that has anything to do with "learning the tools". And getting claude to do it is not that much different from copy-pasting from google.
TBH I usually just search my shell history for the last time I added a remote and edit it.
It's also not particularly hard to write a shell function to avoid needing to care about the syntax, e.g.:
> It's just a waste of tokens at the very least.
Some 6-figure per year developer spending a quarter’s worth of tokens to do something they do once a month or so is not something I’ll ever care to optimize away…
That's pretty much where I'm at, so long as they're not filling the code with "///CLAUDE ADDITION" type guards (ie noise).
Personally I ask the LLM to summarise what the commit does and explain it to me, make sure I understand it, then review the PR. I'm getting half the speed the High Speed Sloperators are getting but I was the only person submitting PRs the other day when the LLM service was down.
For nasty multi-way git merges and rebases, it's been a game changer. And of course that's reviewable by doing a delta on the final rebase branch vs. the original branch.
With all that said... having to use LLMs at work is making me want to use them less on my own projects.
Oh, I was not even attempting to discuss using them for the code itself in my above comment. Code that's checked into a repo has a much more complex set of tradeoffs that I'm much less convinced have a one-size-fits-all answer. My point was more that even if reasonable people can disagree on how much you need to care about the code itself being LLM generated, I can't wrap my head around why anyone should care whether an LLM happened to execute the `git commit` and `git push` shell commands!
A candidate may be able to open a PR and not be able to make a commit without an IDE.
Another candidate might know plenty of git, but haven't worked with Github.
But, like... wouldn't you want them to at least know the steps of `git add` -> `git commit` -> `git push` and then click the button on Github? And Gitlab has basically the same web UI.
I have no problem with letting an IDE or LLM handle those details in practice... but I don't think I'd want to work with someone who doesn't understand the very basics of what's going on under the hood.
> might know plenty of git, but haven't worked with Github
That seems very unlikely. Github is the entire reason git is so popular, vs. any of the other distributed VC systems.
Edit: I'll refine that, after a moment of thought. Git is popular because of Github. But, I guess that now maybe there are people who are using git because it's the popular/default version control choice, but they might not be using Github. They might be using another forge, something homegrown, or just manual builds.
You got dinged but it's a learning opportunity:
Github was like Yahoo's directory, a way to share content in a searchable place and as a backup/bounce point. In the early days you could also upload to 'downloads' so it was a quick share host. Before that we had email, exposed ssh and cgit/gitweb but Github gave us `PR` to promote social interactions with forking. So it could be argued that Github tainted the spirit of git.
Having personally evolved from making date stamped zip files, to subversion and then to git, it earned its place quite quickly for myself and my roaming nature, didn't hurt who hacked it together either. When Linux adopted it from Bitkeeper, it became the way for many.
Git is a simple tool. I expect any engineer can learn to use it. While git is common, I would not expect an engineer who worked at a company using a different version control system to know how to use git (which is a really awful - I still miss mercurial). I expect you to know the general concept of version control, but the specific on is a tool I expect you can learn quickly.
I run a live coding challenge on a rather benign coding problem with the explicit expectation that candidates will use an LLM.
Interestingly, an LLM involved feels like it’s made it easier to assess candidates. Senior candidates know exactly what they’re doing and strongly driving the LLM. They pre-communicating design decisions, gotchas, and requirements. They also ask a lot of clarifying questions and dial in the scope (after all not building something is better than building it).
Less experienced candidates tend to jump right in, build way too much, and stumble because they delegated all of the critical thinking to the agent. They often end up in a place where the agent doesn’t align with their vision and they can’t really reign it back in.
> we also ask the candidate to open a PR against the repo just to see if they know the basics of git
I've heard this multiple times now and it still boggles my mind that git is something you have to test for.
At one job I had, we used git extensively, but not GitHub. We had internal systems for review and branch management. I could tell you all the gory details about various workflows and landmines in git. Is the test here really about git, or git+GitHub?
I rarely use anything beyond checkout, clone, pull, commit, cherry-pick, revert, and push in a job. If I have to, I'm probably asking the AI what to do by giving it my situation. And hopefully the AI can read about whatever git standards the company would like to be enforced so the engineer doesn't have to interrupt someone for that.
This is more about opportunity cost because instead of asking about git, you could ask about other valuable skills in your limited time with the interviewee, but I guess if git is really that important, then it's justified.
Well, I've been using git at work for 6 or 7 years, but I can't out of hand open a PR; at work we very rarely use different branches and the last time I touched Github I was a student.
Do you mean specifically Github, or any code forge at all? When you say "we rarely use different branches", what do you mean - you're all pushing to master, or you have branches for each team or something? I would regard "code forge" and "separate branch per reviewable unit of work" as extremely normal, nearly universal.
it's incredibly sad but it's real -- so many senior candidates have problems with commit messages, opening PRs.
not even joking: i've seen people with like 10y of experience trying to push to main :(
PRs are not only not a basic feature of git - it's not a git feature at all. Though button clicking on GitHub is anyway a crazy thing to test
How would you prepare for the coding problem as a senior? What are the assumptions that underpin this?
> (we also ask the candidate to open a PR against the repo just to see if they know the basics of git -- you would be surprise how many people cannot do it).
How does that work? Git has no concept of pull requests.
Something similar for senior devs: code reviews. Reading and understanding code has always been important. I find offering simple code reviews very telling. In a way, your LLM approach matches that. It's a way to do a code review. It's a test of understanding, and not just memorization.
Does it work? How do they know it works?
There are a lot of people telling you how they interview and why. Almost none of them have shown even the slightly indication that they are aware there there is scientific research on what works for an interview, much less that they apply it. They also are not showing any indication that they have done any testing - to see if their questions help hire better people.
If I said they could get equal results by picking resumes at random and hiring them without any other screening could they refute that? If so have they justified every part of their process or just one step that is useful and the rest they don't know?
> Almost none of them have shown even the slightly indication that they are aware there there is scientific research on what works for an interview,
The topic of the article is about adapting interviews in the age of LLMs.
Scientific research on interview techniques requires years of retrospective analysis after the hired employees have been evaluated in their roles for a long time.
That research does not exist on this topic. It's too new. I don't think this is a valid criticism of the actual article.
They do say "Not every onsite includes these new rounds yet, and when you come on-site we’ll give you a heads-up about what to expect."
So that implies that they are testing this, trying to determine if it works better than the current process. Whether they are doing this in a scientifically rigorous way is unclear, however.
I never see this question being asked enough.
In my experience (both as interviewer and interviewee), interviews primarily serve to satisfy the ego of the interviewer.
Even Steve Yegge got selected (or maybe nearly selected) out by his own process (unwittingly, mind you)
> One day, the recruiters gave us a special round of packets to review. In these special packets, we were able to read the interviewer notes and candidate responses. All personal details were stripped out, and we were told it was a “calibration exercise.” We had to do our regular voting job with these special packets, and see how it went. I think we may have assumed they were from another site, since cross-site calibration was common.
> Our group did our job, and voted not to hire about 2/3 of the packets. This was about par for the course.
> But surprise surprise, this time, those were our own packets from when we had all interviewed at Google. The recruiters had tricked us into reviewing our own interview packets, and we had voted not to hire most of our own group.
From https://yegge.ai/essays/the-last-technical-interview/ (May 2026)
This is the third Jane Street-related thing I've seen on here this week after not seeing much about them that I can remember any time recently beforehand I'm aware of their use of OCaml and probably do other things that might be of interest to the HN community, but it seems like a lot in a very short time out of nowhere. Is there some sort of marketing push or something going on?
According to algolia, there were 57 posts with jane street somewhere in the title or url in the last year, so a bit more than one per week. For a Poisson distribution with rate = 57/52, P(X >= 4) ~= 2.5%. So there should on average be ~5 weeks with 4 or more jane street related posts at that rate.
Probably just random fluctuation.
This is the kind of pedantry I come into HN for. Poisson is such an under-utilized distribution for these kinds of phenomena.
I appreciate a data-focused response here! What I'm more curious about is how many of these reached the front page. My impression is that the rate of how often they reach the front page is probably a good amount lower than once a week, which I think makes the question of whether this is a coincidence or not more reasonable.
Probably a self fulfilling prophecy.
Jane street news made it to the front page a couple times and got a lot of attention.
Now more people are recognizing the name and upvoting other Jane Street posts.
They’re pretty techy, idk why they’re showing up recently though.
Also one of my absolute favorite programming talks ever was hosted by Jane street:
https://www.janestreet.com/tech-talks/algorithm-for-precisio...
It’s like half talk, half story. Got me super interested in logic programming, and minikanren in particular.
I'd lean towards no on that. Might be a bit of a Baader-Meinhof thing. They've been mentioned/discussed on HN pretty regularly for years:
https://hn.algolia.com/?q=jane+street
People like to talk about Jane Street because it is this Very High IQ™ company that pays people astronomical salaries and is extremely hard to get into.
They don't have to do marketing, though. It's not like they sell anything to Hacker News readers, they make their money trading finantial assets
They indeed do marketing. I see their ads on lots of podcasts like dwarkesh.
They sell employment to HN, is the parent comment's point.
You don't think that companies who want to hire engineers ever try to post stuff to Hacker News as a way to market themselves as a potential employer? Where did you get this impression of "Very High IQ" and "astronomical salaries"? I'm guessing at least part of it is from reading stuff from them or from talking to other people who read stuff from them.
The fact that you seem to adamantly disagree that there's any plausible angle here doesn't mean it's not marketing, but it might mean that it is marketing and that it's working on you.
> you seem to adamantly disagree
Such strong wording, you got that from me saying "They don't have to do marketing"?
> where did you get this impression of [...] "astronomical salaries"?
From the real world fact that the base salary is US$300k/yr, and often said that the total compensation for the first year ends up being US$700k+. Even for Manhattan + SWE jobs, surely that merits "astronomical". Other devs making that much are usually working at Anthropic or OpenAI, aren't they?
> where did you get this impression of "Very High IQ"?
You didn't copy my ™ there, which was meant to be snarky.
In any case, what I was trying to say is that they don't have to do marketing in the usual sense. They don't have to get the Jane Street logo in your subconscious so you buy a Jane St. product when you go to Kroger's, and you can't sign a Jane St. subscription plan.
People in this thread seem to be implying that the company is botting/astroturfing, but for what? To maintain the image that they're a highly sought after employer?
Anything Paul Graham posts gets upvoted here instantly, because it's Paul Graham who posted it. For Jane Street there's the same halo effect, because many believe Jane Street's work is impressive. Is it really easier to believe the idea of botting to get an even longer list of candidates to interview, than it is to believe people just like to hear what this company has to say?
I don't ever see anyone saying Paul Graham is botting posts about his "essays"
> Such strong wording, you got that from me saying "They don't have to do marketing"?
The only alternative interpretation I can think of for what you said is "they waste resources on marketing they don't need to do". I didn't think that was more likely to be your intended meaning, but you're welcome to correct me on it.
> From the real world fact that the base salary is US$300k/yr, and often said that the total compensation for the first year ends up being US$700k+.
Can you clarify where these numbers are coming from? Real world facts tend to have sources that can verify them.
> In any case, what I was trying to say is that they don't have to do marketing in the usual sense. They don't have to get the Jane Street logo in your subconscious so you buy a Jane St. product when you go to Kroger's, and you can't sign a Jane St. subscription plan.
> People in this thread seem to be implying that the company is botting/astroturfing, but for what? To maintain the image that they're a highly sought after employer?
Yes, that's exactly what I'm implying. I honestly would have stated it explicitly in the first place, but I made the incorrect assumption that it was not controversial to claim that this phenomenon exists at least for some companies and that it can be described as a form of marketing.
> Anything Paul Graham posts gets upvoted here instantly, because it's Paul Graham who posted it. For Jane Street there's the same halo effect, because many believe Jane Street's work is impressive. Is it really easier to believe the idea of botting to get an even longer list of candidates to interview, than it is to believe people just like to hear what this company has to say?
> I don't ever see anyone saying Paul Graham is botting posts about his "essays"
If we were discussing this on a website originally created by Jane Street, I would find this a more compelling counterargument. That said, I also don't bother trying to discuss his writing much because I mostly find it insufferable. I find the motives of Jane Street to be more interesting precisely because my opinion on them is more malleable.
> Real world facts tend to have sources that can verify them.
Sure. What I said is a real world fact is the base salary, which can be verified by any of their job postings, e.g. www.janestreet.com/join-jane-street/position/4274288002, where it says "Base salary is $300,000. Base salary is only one part of Jane Street total compensation, which includes an annual discretionary bonus".
The claim that has less direct sources is how much the TC ends up being. The figure I said is the one I've heard multiple times over, sometimes by JS employees themselves, so I assume it to be true
> If we were discussing this on a website originally created by Jane Street, I would find this a more compelling counterargument.
That's fair, but I used Graham just as an example of source that always gets upvotes here. Uncle Bob hasn't posted anything in a while, but if he did, it'd certainly trend here, so that might be a better example
> I find the motives of Jane Street to be more interesting precisely because my opinion on them is more malleable.
Yes, that's fair. I don't think it's impossible that JS would bot/astroturf like you're implying, I just don't think it's the case. By Occam's razor I find it's more likely that people do care for what they have to say, similar to P. Graham, Uncle Bob, or any sort of blogpost from Anthropic/OpenAI, etc. It's quite possible that they got to this stage due to intentional marketing, though, so I'll give you that
> We know this sounds vague,
ok thanks for this slop then. Dont see why this stupid article is on frontpage.
They seem to belive in 'organic' marketing like doing a fake podcasts on dwarkesh. So maybe they have some bots upvoting their name.
Pretty vague blogpost tbh. Apart from the fact that it's changing, it doesn't really describe much
I had lunch with a couple friends this week, and we each work in different tech environments. Most of the conversation was about the workflows we're each using, and seeing our colleagues use.
It's a really interesting time to work in this field. People who are paying attention to workflows are using a range of tools, and constantly refining their own workflow. For example a whole team might use Claude, but one person collects data about their own usage on an ongoing basis and develops more advanced workflows than everyone else on the team. Their focus isn't just about working faster, but about doing better work.
I don't think the post is vague; I think we're at a time where you need flexibility in your interview process to find candidates who are doing the best work these days.
Thanks, that certainly clears up the doubts
Use AI or not, quite being half in half out.
Back then, people who were bad at interviews were often undervalued. I think interview culture itself will soon be devalued and eventually become obsolete. People who build real technology and solve real problems will be unaffected, while the glorified Valley slop built around interview performance will become obsolete.
My optimism comes from AI's ability to solve genuinely hard mathematical problems this year. September and October could go down as two of the most remarkable months in the history of AI If, and only if, those proofs are correct and independently verified by real experts. Even if the proofs have been formally verified in Lean, expert scrutiny still matters.
What's up with the obsession with Jane Street today ?
Money.
The linked article has almost no info to take away besides being so wordy.
"interviews in our onsites for campus candidates."
ie. Not actually interviewing software engineers.
I see much buzz lately about Jane Street. Probably they had a good year and now they’re looking for fresh meat, trying to expand even more.
employing humans? wow
This sort of announcement has made me very happy I left the software world. I still code as part of my job, but it's not my main part and luckily I don't have to use LLMs are part of my job. I still code 100% by hand.
In some ways, although I detest AI, it has clarified the sort of people and organizations I want to associate with. Any latent characteristics that I abhor have been made obvious with the existence of AI and of course, I would want nothing to do with Jane Street.
Upvoted this!
did you get paid for that slop?