Rendered at 05:00:02 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
janalsncm 5 hours ago [-]
Leetcode was stupid before LLMs and now it’s even less useful as a signal.
What I want to know is whether someone has basic DSA understanding. Is the person familiar with any programming language. Can they translate business requirements into code? Can they disambiguate weird things PMs say into a viable plan?
You do not get a better signal about that from asking harder leetcode problems.
Never once in my career has writing a tricky algorithm under time pressure been relevant. The closest thing I can think of is debugging complex systems in an outage, but then it’s more like familiarity with bash commands and general debug skills.
As for LLMs and coding, companies need to figure out how to differentiate good and bad outputs here and what lasting engineer inputs to select for. And I don’t have any idea about this.
monksy 1 hours ago [-]
> Leetcode was stupid before LLMs and now it’s even less useful as a signal.
You got my vote right there. I also find it funny that LLMs can easily do leetcode problems, because there were so many examples and easy test cases.
> You do not get a better signal about that from asking harder leetcode problems.
I think this is a thing that needs bigger formatting for this statement or a feature to vote twice.
---
Only response I have to this:
There are many different schools of thought on how to architect systems. In many cases these different opinions don't have a lot of solid backing on why you'd do this. On top of that there is level restrictions that prevent talented individuals from being more influential. I.e. an Architect is less about technical experience and excellence and more about the abiltiy to communciate to high level stakeholds and having systems that can solve the problem [some what].
WalterBright 3 hours ago [-]
To get into Marine boot camp, there's a minimum strength test.
To get into college, there's the SAT test with a minimum score.
To get a high paying software job, there's the leetcode test.
These are gates meant to filter out the obviously unqualified candidates. Unqualified candidates waste the time of the candidate and the company. The real interview comes after that.
batshit_beaver 19 minutes ago [-]
All of these filter for the amount of time the person spent _preparing for the test _.
And leetcode is not something you prep for once in your life, but every time you switch jobs.
threethirtytwo 3 hours ago [-]
You missed the point. I’m not saying I support dsa but you are arguing against the weakest version of the reasoning behind why companies use dsa. It’s used as an iq test. IQ is highly correlated with many things associated with intelligence yet even though we don’t take iq tests on a daily basis it still correlates.
The argument was dsa functions like an iq test. It’s not relevant to the job (in fact it’s harder than the job, far harder) such that if you do well on it companies can be confident you can do well on the job just like how scoring high on an iq test makes people confident you’re intelligent.
There are plenty of arguments against what I said above and going after this argument is the better target because the irrelevancy of dsa to the job is widely known and obvious.
noduerme 2 hours ago [-]
Is DSA knowledge really pointless or just a stand-in for an IQ test?
I've been engineering systems for 25 years. On a macro level, most of my time is spent considering the right tooling and stack for a job, balancing budget and time constraints and efficiency against how things may need to scale in the future. On a micro level, in the data model and in the code itself, choosing the best structures for a task is important for maintainability and overall coherence.
In my experience with LLMs, I often need to guide them toward choosing the right ways to model data on the code and database level. LLMs seem to prefer json blobs of unstructured data, naming conventions that drift over time, argument structure patterns that change from one piece of code to another. The net result is a lot of tables and code that an LLM needs to read back through, find all the linkages, and recommit to its window before any debugging can take place. It makes human debugging very difficult if, for example, an LLM decides to just store all the userdata in some json column and then decides to add some kind of stateful preferences to that, and other state to something in memory, and then parse the memory falling back to the database state. I've seen a ton of things like this where weird ways of handling state kinda work, until they don't, and it's extremely difficult to figure out what is taking precedence when or where a thread race is coming from.
All this is to say that DSA knowledge may be even more important when LLMs are writing most of the code, because an unguided LLM will write stuff that can practically only be maintained by an LLM, and make design decisions that don't cohere or scale. If that's not really a problem, and you're certain that the code you're investing in writing will never need human intervention, then I guess it doesn't matter. But with a large enough system designed that way, the boundaries and edges of poor DSA choices aren't going to be apparent until either something breaks or you need to grow.
cweld510 2 hours ago [-]
DSA is plenty relevant to the job. There’s lots of professional programming that’s heavy on DSA.
threethirtytwo 1 hours ago [-]
It’s very rare. And often people end up using libraries. All pointless now with LLMs
fernandotakai 14 hours ago [-]
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)
wavemode 4 hours ago [-]
> (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).
This doesn't really say anything about someone's familiarity with git, considering pull requests are not a feature of git.
When I worked at a FAANG we used git but had our own internal code forge that was nothing like GitHub.
cebert 3 hours ago [-]
Also, AI can do that well now too. I haven’t had to deal with merge conflicts for months.
2 hours ago [-]
nomel 3 hours ago [-]
If you're on the repos git page, it's a total of three clicks. It doesn't really require prior knowledge.
beebmam 9 minutes ago [-]
If you are asking any human to write code, you are effectively asking them to write byte code. Humans should not be writing code in this era, and only in rare circumstances should humans be reading code.
saghm 13 hours ago [-]
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.
syshyk 13 hours ago [-]
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.
saghm 13 hours ago [-]
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.
ozim 6 hours ago [-]
Problem for me is that unless I see someone being proficient at using git commands to rebase, merge etc.
…
I have hard time believing they understand underlying model. Even if someone knows all the right words.
There is no way to verify it just by talking.
8note 5 hours ago [-]
i guess your difficulty is that half the commands i can write off hand and the other half i cant, and i only really care to understand the parts of the data model that i actually touch.
like, i dont really need to know all the stash details when i only stash one thing at a time, very temporarily
i also dont really care to know all the origin and remote definitions stuff when i only touch it once per project or so.
i could certainly draw graphs of what different git repos look like, but what makes it salient to know the rest of the details unless im actually building git itself? if youre using every git feature regularly you're probably doing something wrong
ozim 33 minutes ago [-]
Your comment hits the nail on what I wrote.
I couldn’t care less about stashing commands.
I do care about … if someone understands origins and not by definition because developer needs to know what is his local version and what is on the server and how those two affect each other. Bonus points if they understand server is not special in Git and their colleagues copy on their laptop can be origin as well.
Drawing graphs of what different repos look like? That’s irrelevant.
Irrelevant if one understands that Git uses DAG and is content addressable store.
You see someone might know those hard words but when working daily with Git reasoning about rebase or merge, cleaning up their own work with interactive rebase, making pull/merge requests or resolving conflicts it is much easier if one knows what is local what is remote and how Git stores data.
You also learn it once. In my 15 years of using Git I basically didn’t learn much new commands but having mental model of how it works was my tool to fix any problems other people had. Knowing commands or definitions is secondary.
zahlman 2 hours ago [-]
> like, i dont really need to know all the stash details when i only stash one thing at a time, very temporarily
If I were hiring, I would care about whether you can `git help stash`, skim over it (bonus points for actually using the pager competently) and figure out what you need to do.
WalterBright 3 hours ago [-]
I used to go to stackoverflow to resolve issues with git. The trouble was, I'd get 15 answers, all different, all saying "this might work", "try this", "try that".
Now I just ask google, and I get a straightforward "do this", and it works.
zahlman 2 hours ago [-]
That's largely because the OP couldn't clearly describe a specific situation to ask about (the question underlying the problem, but also a clearly recognizable, reproducible example); and solving your problem might depend on things that are different in your setup vs. the OP's.
That's the thing, though. Stack Overflow is not and never was intended to solve your problem, nor to solve the OP's problem. It was intended to answer questions. It was your responsibility, both as someone posting a question and as someone reading the Q&A later, to adapt knowledge to your circumstances. That's why they're called questions and answers, and are not called problems and solutions.
People who use a web site to get a solution to a problem are looking for a help desk, or a forum. Stack Overflow was specifically created to be not that, and that choice was specifically motivated by the frustration people had with trying to search those kinds of sites for information, and the frustration that experts had with trying to help people (for free) in that kind of environment.
PorciiVorbesc 7 hours ago [-]
>I switched to jj a few years ago and had the majority of the annoying rebase issues go away
jj? what's that?
I wish better names would be chosen by the tech industry, that would make search engine discoverability easier.
filoeleven 5 hours ago [-]
I hadn't heard of this either, but they have an interesting reason for the name:
> The command-line tool is called jj for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj".
Jujutsu, another VCS. It is popular enough to not require introduction on HN, or so the parent must have thought.
PorciiVorbesc 6 hours ago [-]
>It is popular enough
Define popular. This is the first time I'm hearing about it.
>not require introduction on HN
It's not necessary to explain acronyms, but gawd damn, I wish these products had names that were easily googleable.
saghm 3 hours ago [-]
Based on "or so the parent must have thought", I don't think they were being fully serious when they said it was "popular enough". I've seen it brought up pretty much in every conversation around git on Hacker News for the past year or so, and I did make an assumption that most people reading several comments deep into a debate about how important it is to memorize the exact incantations of git commands would be familiar with it. It's largely not relevant to my overall point though; you could replace it with "a different git tool" and it would not really change what I was saying.
hatthew 6 hours ago [-]
I'm not deep in the VCS discourse but I've seen jj come up many times on HN. I don't think it need an introduction, but it's also think it's reasonable to request clarification because I agree the name is confusing.
Tangent, but when I was younger, my main programming language was Processing, and I bet you can imagine how difficult it was to google issues with it :)
gspetr 5 hours ago [-]
>I wish these products had names that were easily googleable.
You can't google for "X" like it's early stack overflow days, but adding the minimum context "X that has something to do with Y" works 99% of the time.
> 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.
saghm 13 hours ago [-]
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.
StrangeWill 7 hours ago [-]
The point of knowing your tools is to stop escalating to other people every time something doesn't work with them.
Even if an LLM can hold your hand through everything, the disruption I've had because people don't understand what the LLM tool is doing, and ultimately does damage (we've had repos corrupted, systems taken offline, systems brought their knees, numerous data security incidents... it's been a fucking nightmare) is immense.
saghm 3 hours ago [-]
Repos corrupted? From arbitrary usage of a git client? I feel like it's been generally a bad idea to allow arbitrary force pushes for anything shared for a while before LLMs entered the picture.
StrangeWill 1 hours ago [-]
Automation bias!
Even worse, it gave a developer a command to run that basically crushed all history across all branches, it was a mess to clean up and lost a significant amount of work. It wasn't Claude running it on its own, but was entirely driven by a mix of a developer's lack of understanding their tools, and trusting Claude's output too much.
This was also the dev trying to "remove a key he had accidentally committed" again, just letting Claude take the wheel.
Of course, the new team _also_ really loved leaning on AI so they were all behind his plan to "clean up the repo" and not just reset the key and move on.
It was a nightmare.
nightdeployboy 13 hours ago [-]
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.
saghm 12 hours ago [-]
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.
zahlman 2 hours ago [-]
The idea of saying the LLM is "my tool" as opposed to all the actual tools it calls, is about as appealing to me as saying the same about, say, Remote Desktop. "The statistical machine" is there to generate candidate actions, not to implement them.
bawolff 13 hours ago [-]
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.
tempfile 13 hours ago [-]
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.
wtetzner 13 hours ago [-]
TBH I usually just search my shell history for the last time I added a remote and edit it.
saghm 11 hours ago [-]
It's also not particularly hard to write a shell function to avoid needing to care about the syntax, e.g.:
Better yet, assign the positional arguments to named variables for documentation purposes; you can see them when you `type` the function. (Comments get stripped, unless you make an actual script.)
8note 5 hours ago [-]
thats just the same problem though, ig you arent using it regularly you are going to forget that part of your shell functions
zahlman 2 hours ago [-]
1. Develop the instinct of "I probably have a shell function for that, if it isn't already obvious; and if I don't, I need to fix that"
2. Give your shell functions a common prefix, and/or big-endian naming convention (e.g. things that help you with git start with `@git-`)
3. Tab completion is your friend.
saghm 3 hours ago [-]
I wholeheartedly agree that it's the same, but I fundamentally disagree about it being a "problem", or at least, one worth caring about. I don't honestly believe that typing out the extra 35 characters that are filled in by the helper function I gave here would solve anything that comes close to the convenience of not needing to memorize them.
sokoloff 13 hours ago [-]
> 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…
saghm 3 hours ago [-]
I misread this as a "quarter" as in "three month period of the calendar year" and was very confused until I remembered that was also the name of a coin
marssaxman 10 hours ago [-]
Tokens are cheaper than brain power. Why waste my time trying to recall the details of git's byzantine, ill-begotten command line interface when I can delegate that boring task to a robot?
SamuelAdams 5 hours ago [-]
Omzsh user checking in, I always stumble a little in interviews about this because they usually have a default git configured and commands like gco -b and gp don’t work, and I have to think about it for a second.
nunez 8 hours ago [-]
what happens when there's a massive merge conflict that requires human review?
Git is an essential tool; not knowing how a key tool works is dangerous IMO
saghm 8 hours ago [-]
I think that actual direct knowledge about how git merges things and what ends up surfacing as "conflicts" as a result of that is not particularly well understood by quite a large number of people who in practice do not have any trouble using git every day. Moreover, there's nothing specific to git in terms of reviewing code, which is fundamentally what you get from the result of fixing conflicts; once the conflicts are all resolved, there's a diff from the old state (pre-merge) to the new state, and you already should be reviewing it to see if it's what you want even if there were never any conflicts.
a34729t 8 hours ago [-]
Yeah, I feel like knowing how to use tools is one of the key smells for finding good engineers.
user43928 7 hours ago [-]
Nothing.
Should you resolve the conflicts in a bad way we're going to see the result in the MR, will we not?
I don't think git knowledge is essential anymore.
Back in the days of the crappy git GUIs this was a problem, because people would regularly misunderstand even the basics of what they were doing and managed to lose their local changes.
That shouldn't happen with LLMs.
jvidalv 8 hours ago [-]
LLMs solves them great. So who cares? At most it will ask for a few guidelines on what takes priority, but no one is using git directly anymore.
I have not run a single git command in like the entire 2026.
rsoto2 8 hours ago [-]
just ask the agent "no mistakes" /s
zahlman 2 hours ago [-]
> 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 someone who's familiar with those sorts of things can get the commands typed and running before someone who isn't has even figured out the prompt.
(Well, not so much if there's a need to identify the base commit for a squash, do some cherry-picking, etc. But in those cases I'd rather see direct human judgment of what to do than hoping the LLM understands a vague description.)
philpem 12 hours ago [-]
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.
curt15 7 hours ago [-]
> 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
For the more important changes, I find it easier to stay on my toes by taking a pass at the codebase before comparing notes with the LLM. Peeking at the answer key first makes it too easy to nod uncritically.
saghm 12 hours ago [-]
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!
ctkhn 8 hours ago [-]
I had a coworker a few years ago who was very stuck up and the first place I saw it was his opinions how people should use git. I use the terminal for some stuff and the gui for others, but he was weirdly judgemental about doing anything other than full terminal.
Insimwytim 13 hours ago [-]
we also ask the candidate to open a PR against the repo just to see if they know the basics of git
That's the basics of Github, not git.
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.
labcomputer 11 hours ago [-]
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.
pdonis 9 hours ago [-]
> wouldn't you want them to at least know the steps of `git add` -> `git commit` -> `git push`
The GP said "open a PR", not "make a commit and push it to a remote".
labcomputer 2 hours ago [-]
Well, I can't read the GP's mind, but I'm fairly certain they didn't literally mean "candidate knows how to click one button in the web UI for a specific proprietary developer platform and type some stuff into a text box".
When I tell my LLM to "open a PR for those changes" (which is how I do it nowadays), my LLM understands that what I mean is "make a commit, push it to a remote and raise a PR".
Does it mean we've reached AGI when machines understand what we mean better than some humans?
pdonis 2 hours ago [-]
> When I tell my LLM to "open a PR for those changes" (which is how I do it nowadays), my LLM understands that what I mean is "make a commit, push it to a remote and raise a PR".
This makes it seem like all of those things are part of a single operation to you. That doesn't make sense to me.
On the occasions where I've submitted a PR to a project (anywhere, not just on Github), making the commit was not part of the same operation. I'd already made the commit and satisfied myself that it captured everything I wanted, before making the PR. I don't see those things as part of a single operation. I don't think the poster you were responding to does either.
labcomputer 2 hours ago [-]
> That doesn't make sense to me.
So you think the OP is asking candidates a question, where the solution is:
1. Navigate your browser to GitHub.mycompany.example.com
2. Click the repo name
3. Click pull requests
4. Click the source branch[1] and destination branch
5. Click "create pull request"
???
I started out by assuming this was some kind of good-faith disagreement, but I guess you're just trying to be funny.
[1] Presumably already extant, because they never mentioned anything about committing code, nor pushing it to github (and that's not the same operation!).
pdonis 51 minutes ago [-]
> So you think
The OP said:
"we also ask the candidate to open a PR"
So I think the OP meant to have the candidate, um, open a PR. Which is not the same thing as making a commit and pushing it to a remote. Maybe you always conflate those operations, but that doesn't make them the same operation. If the OP actually meant that they ask the candidate to make a commit, push it to the remote, and then open a PR, I would have expected the OP to say, um, all of those things, instead of just the last one.
I couldn't say how the OP expected the candidate to open a PR, since I don't know what their standard workflow is. There are ways of doing it from the CLI, as well as through the web interface, as well as through various IDEs.
> I started out by assuming this was some kind of good-faith disagreement, but I guess you're just trying to be funny.
Please save your patronizing for another time. And stop trying to put words in my mouth.
medler 9 hours ago [-]
Years ago I was the “git expert” on my team, the person you went to when you got into trouble. But I have long since moved to jj, and I basically don’t remember git commands anymore. I also don’t use GitHub much, so when I need to open a PR I prompt an LLM to do it for me.
calculatte 6 hours ago [-]
Why should anyone care?
This is something that can be taught and learned in 2 minutes.
SoftTalker 12 hours ago [-]
> 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.
dearing 11 hours ago [-]
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.
user43928 7 hours ago [-]
It seems rather likely for people who use git at work only on GitLab or (god beware) Bitbucket.
Personally I prefer GitLab over GitHub. The CI is better, and it doesn't go down every other week unless you self host on Azure.
SkyPuncher 12 hours ago [-]
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.
bluGill 13 hours ago [-]
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.
gosub100 9 hours ago [-]
There is nothing simple about git. 'ls' is a simple tool. git is probably the most complicated console command (in widespread use) I have ever used, although I'm open to other examples
spacebanana7 7 hours ago [-]
Agreed, the amount of stuff checkout can do is crazy. And the concepts of hard and soft resets mixed with garbage collection make deletion non trivial to understand. Or using interactive rebase to variously remove, squash, and rewrite commits.
Fundamentally git is conceptually complex in a way that almost no other tool is. Others might have scarier syntax to newcomers but rarely expose the same level of underlying complexity.
nunez 8 hours ago [-]
not for 95% of what people will use it for IMO
initializing a repo, staging files, adding them to the changeset, commiting then pushing those changes are easy to do. solving merge conflicts is a little complicated but IDEs make that much easier to do.
6 hours ago [-]
fragmede 9 hours ago [-]
It is not simple like a hammer, but imo the bar for being a software engineer is being intelligent enough to be able to understand it well enough to do things with it, since it is a tool of the trade.
medler 9 hours ago [-]
jj is far simpler and more powerful at the same time. There is absolutely no reason anyone should waste time learning git in 2026
xeyownt 8 hours ago [-]
reason: not use a tool whose name collides with million things
medler 5 hours ago [-]
Not a reason to use git. Git has been a common word since long before the git version control system was created: https://en.wiktionary.org/wiki/git
xpct 14 hours ago [-]
> 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.
cbm-vic-20 14 hours ago [-]
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?
fsnovask 13 hours ago [-]
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.
baud147258 13 hours ago [-]
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.
tempfile 13 hours ago [-]
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.
baud147258 6 hours ago [-]
Yes, we're all pushing in the same branch (not called master, we have one branch per version (usually we have one branch that's the current version deployed in production and the development branch)). To group up commits for review, we add in the commit message the Jira issue number and Jira will keep a list of all commits through Bitbucket. Bitbucket supports PRs, but I don't think it's ever been used here.
I can gather that the way we're using is not the most usual ;).
fernandotakai 14 hours ago [-]
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 :(
gspetr 5 hours ago [-]
Dave Farley (of the 2010 "Continuous Delivery" book fame) explicitly recommends committing and pushing directly to main (or master), and he actively argues against using feature branches and blocking pull requests.
What's incredible is how set some people are in their ways that they can't conceive of alternatives.
kerenskiy 14 hours ago [-]
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
skinfaxi 12 hours ago [-]
> (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.
robkeane 9 hours ago [-]
Extremely funny for OP to advertise this gotcha style question that's built on a misunderstanding of the tools
Doesn't surprise me at all that many developers can't do this, most professional software development isn't happening on Gitub.
GuB-42 7 hours ago [-]
What I though of was to give candidates a not-so-smart LLM, one that is almost guaranteed to make mistakes.
The idea is to see how the candidates deals with it. Maybe he will just say "fuck it" and do it by hand, or patiently point out every mistake so that the LLM gets it right. Both indicate competence, what you don't want is someone who doesn't see the mistakes and hand you slop.
NorthSouthNorth 9 hours ago [-]
> (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).
Worked with a "super senior", lead architect. Management was raving about the guy before he joined. Insane resume. Skipped the regular interview process because of this.
Had to show him how to open a PR and setup his git config so his commits are linked to his account. And then his PR's failed the automated ci checks for descriptions and titles, and he came to me to ask how to fix it. The failing gh action literally says what was broken.
This is all with Claude available btw, so one could literally just ask.
I guess it's a bit of a modern fizzbuzz. Where it's so simple but still manages to stump a lot of candidates.
throwaway2037 5 hours ago [-]
> 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
This part seems weird. "[B]asics of git"? You can Google for that and find a fossilized answer on StackOverflow. Do you really have candidates who cannot do git commit/push? Also, if you allow LLMs, then any idiot LLM will also know git basics.
vehementi 3 hours ago [-]
Funny that about 80% of the replies to you comment are about your git sidebar. Bikeshedding indeed
ItsYan 13 hours ago [-]
How would you prepare for the coding problem as a senior? What are the assumptions that underpin this?
skydhash 9 hours ago [-]
Not GP.
The trick is to get a good sense of the algorithms associated with basic data structures (list, stack, queue, graph, hashmap,...). They are primitives and almost any standard problem can be solved with those.
What you need to train most is the capability to break down problems: Like I have this input (and associated metadata), I have this context (may be null), I have those constraints (values, ranges, memory space, time, both, or neither), and I need these outputs. Then it's just a puzzle.
I no longer prepare for coding problems other than a quick refresh of the syntax of the main language. And if it's a whiteboard type of things, I go with pseudocode.
fernandotakai 10 hours ago [-]
honestly, for a senior, the coding challenge is just a checkbox -- because they can use llms, the main thing is making sure whatever code they accept, they can explain from top to bottom.
the coding challenge itself is just a way to make sure that people can understand a request within an existing codebase. as an example, i pay attention to the questions the candidate asks -- questions asked always mean something.
my general assumption with seniors are "they can think high level", which means i "mark them" with that assumption, so for me, the architecture talk is much more important.
at the end of the day, you need to understand what your org needs and adapt.
bismanawaz 6 hours ago [-]
how do they grade a right answer, suggested by the agent itself??
bismanawaz 6 hours ago [-]
my suggestion is one should ask the agent to go through series of research, analyse its own proposed solutions/fixes, then a human verify the plan, refine it further, instead of relying blindly on the agent.
That's how I do coding with agents.
jasonlotito 14 hours ago [-]
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.
BeetleB 5 hours ago [-]
> 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
Will you allow jj instead. I switched to jj 1.5 years ago (as many others have), and my git is now rusty.
I mean sure, I can do add, commit, basic diff, etc. But rebase/merge - oh dear, I forget which one is source/target (jj made the infinite design choice that the ordering doesn't matter - you have two parents making a child - it's symmetric).
sick_of_slop 13 hours ago [-]
[dead]
wewewedxfgdf 6 hours ago [-]
>>> the bar is super raised and now you need to explain in details everything the LLM wrote as if you wrote it yourself.
You have missed the point entirely.
bluGill 13 hours ago [-]
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?
Aurornis 11 hours ago [-]
> 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.
mjdiloreto 6 hours ago [-]
I'd add that even those years of retrospective analysis will be insufficient, because "hiring successfully" is fundamentally about measuring membership in a particular social group. You can never pick the right observable dimensions to measure in your analysis, it will ALWAYS be lacking. Sure, you can measure work done, tenure, etc, etc, but that does not mean a hire was successful.
You might have 2 people with opposite personality traits ace the interview then get put on a team together, now all of a sudden your whole team is worse overall. That's a massive effect but your study will just see it as noise.
The reality is your best hires will just be intelligent people who belong in the group and who push the mission forward.
SoftTalker 12 hours ago [-]
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.
viklove 11 hours ago [-]
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.
rsoto2 8 hours ago [-]
I used to interview people and would generally just have a chat with them about previous problems, projects, or experience at school. I would work out a pseudocode problem with them (designing an elevator). From what I can tell everyone I said yes to has had a fruitful career.
The idea of forcing a candidate to give a third party access to their screen, transcribing AI notes, and forcing them to do 3+ leetcode, and an architecture round, and a behavioral round while I watch over them for hours on end sounds completely idiotic and antisocial. This entire industry is high on its own supply when it comes to interviews.
julianlam 12 hours ago [-]
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.
its not like they instantly reviewed their own docs; the hiring bar and comparisons changed
northpine_team 12 hours ago [-]
[flagged]
saghm 14 hours ago [-]
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?
spongebobism 13 hours ago [-]
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.
stuxnet79 11 hours ago [-]
This is the kind of pedantry I come into HN for. Poisson is such an under-utilized distribution for these kinds of phenomena.
tmoertel 8 hours ago [-]
> Poisson is such an under-utilized distribution for these kinds of phenomena.
Yeah, Poisson distributions show up everywhere if you are paying attention. You can even use the theory as the basis for a fast, elegant algorithm to take parallel, weighted random samples. You can even do it in SQL!:
SELECT *
FROM Population
WHERE weight > 0
ORDER BY -LN(1.0 - RANDOM()) / weight
LIMIT 100 -- Sample size.
Isn't it a natural modeling choice? If your events arrive on exponentially distributed deltas, you end up having poisson arrival counts.
8note 5 hours ago [-]
possion distribution is what i learned in university for describing this kind of event?
the book is underutilized?
stuxnet79 5 hours ago [-]
No I learned it in university like most of us did but 10+ years in tech I have never once seen somebody reach out for it in situations like this one where it is a natural fit.
Few people understand it well, even though it's effectively a binomial distribution (easy to grok) but with special constraints.
saghm 13 hours ago [-]
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.
fantasticsid 3 hours ago [-]
where does ~5 weeks come from?
Rexxar 51 minutes ago [-]
I don't understand either. I would have said 1.3 (52 * 2.5%).
seizethecheese 10 hours ago [-]
Except I'm pretty sure there are three from the last 24 hours. Two live on the front page right now and one about some almost flooding just dropped off.
MeetingsBrowser 14 hours ago [-]
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.
chamomeal 14 hours ago [-]
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:
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
mancerayder 13 hours ago [-]
They sell employment to HN, is the parent comment's point.
dominotw 11 hours ago [-]
They indeed do marketing. I see their ads on lots of podcasts like dwarkesh.
saghm 14 hours ago [-]
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.
vrmiguel 13 hours ago [-]
> 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"
saghm 13 hours ago [-]
> 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.
vrmiguel 13 hours ago [-]
> 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
14 hours ago [-]
dominotw 14 hours ago [-]
> 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.
sashank_1509 6 minutes ago [-]
I remember Anthropic back in 2023, rethinking their coding interview and not using leetcode lol. They created some elaborate system design interview where you solve a question and then new questions are asked and you need to check if the abstractions you used at first were good enough to deal with the new questions and on and on. Leetcode was useless well before LLM’s.
floathub 13 hours ago [-]
This is a completely side comment, but I don't understand why stories about Jane Street keep making the front page day after day:
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...
OkayPhysicist 6 hours ago [-]
Their ban from India isn't particularly sinister. What they did would have been perfectly legal here in the US as "supplying liquidity". They just successfully arbitraged the liquidity gap between the Indian options market and the long position stock market.
verteu 2 hours ago [-]
No, this type of "liquidity arbitrage" is market manipulation, and illegal in the US.
> The cross-market manipulation involves buying and selling stocks at a loss, allegedly for the purpose of moving the prices of corresponding options, so that Avalon could make a profit by trading those options at artificial prices.
> The Court found that the two alleged manipulative trading schemes-if proven-would violate Sections 10(b) and 9(a)(2) of the Exchange Act and Section 17(a)(1) of the Securities Act.
> 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.
kevstev 11 hours ago [-]
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.
11 hours ago [-]
dogmayor 11 hours ago [-]
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.
koolba 11 hours ago [-]
> 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”.
tasuki 9 hours ago [-]
They provide liquidity!
vonneumannstan 12 hours ago [-]
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.
floathub 12 hours ago [-]
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.
Avicebron 11 hours ago [-]
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.
anonu 4 hours ago [-]
they spend a lot of time recruiting. this post is more of that kind of outreach
RetardedBastard 8 hours ago [-]
[dead]
uptrails 12 hours ago [-]
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.
efnx 11 hours ago [-]
What are some of the other aggregators?
uptrails 10 hours ago [-]
The closest to "HN lite" is probably lobste.rs. There's a fair amount of overlap, but it's closer to 20% AI than 80% AI.
Reddit? General-interest subreddits such as /r/technology are mostly mainstream news, but there's plenty of specialized ones, such as /r/math, /r/programming, /r/c_programming, /r/rust, etc. Most of these have relatively little AI, some explicitly contain all AI content to weekly threads.
Many of the aggregators "killed" by HN are still alive, just not as popular. For example, boingboing.net is up and running. Also, places like Ars Technica have RSS feeds, so it's easy to construct your own, you just lose the social aspect.
red-iron-pine 11 hours ago [-]
in other words, someone who works at Jane Street or use to posts on HN a lot
LPisGood 13 hours ago [-]
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.
locknitpicker 13 hours ago [-]
> 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.
LPisGood 12 hours ago [-]
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.
buriram 7 hours ago [-]
They are unknown because they choose to be unknown. The first rule of finance is that, you never tell anyone how you make money. Even more so if you make billions of dollars annually.
malfist 12 hours ago [-]
Your ignorance of something does not mean the thing you are ignorant of is inconsequential
wmchen 13 hours ago [-]
I am particularly fond of the assessment that Jane Street is a federation of anarcho-capitalist syndicates disguised as a quantitative trading firm.
Aurornis 12 hours ago [-]
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.
janalsncm 5 hours ago [-]
I think Jane Street has gained prestige and notoriety in the last few years. For people like Math majors who are split between tech and finance, it’s the most famous I think.
6 hours ago [-]
Grimburger 13 hours ago [-]
Noticing a bit too much
What is the deal with it though? Daily front page content in various forms starts to raise eyebrows.
pessimizer 12 hours ago [-]
That may or may not be suspicious, but Jane Street has been posted here a lot since forever, mostly because of ocaml.
keithnz 3 hours ago [-]
If you are employing someone to build software with AI, then interview that way.
I think what I'm looking for these days is people with a technical mindset and also can think strategically. So its not Yolo prompting, but creating an engineered environment for creating software for a particular purpose.
So if you want a good AI Engineer you want to test that can address the following things (not exactly, or everything, but they should be covering a lot of these things in some form) :-
- Define goals
- Distributing/Managing work in a team
- Establish guardrails
- Build feedback loops
- Use multiple agents, spanning out AI then recombining
- Setting up Verification
- Evaluating Engineering (Security, Architecture, Code, Performance, Deployment, Monitoring )
- Set it up that the whole process improves itself
- Understanding Domains
- Mitigations for an AI outage.
zerop 10 hours ago [-]
A friend recently got through Google after getting interviewed in Meta and several other companies. He said interview styles are changing in most places but there is no common pattern. Every company is taking their own custom approach. Some are giving open access to AI IDE, some are asking to not ask everything and monitoring what you ask. One company give access to LLM (probably custom) that would provide wrong code intentionally and candidate has to correct it.
joshdavham 8 hours ago [-]
> One company give access to LLM (probably custom) that would provide wrong code intentionally and candidate has to correct it.
How ‘wrong’ are we talking? Like the code is correct, but slow? Fails easy-to-spot edge cases? Uses poor taste in variables names?
This is probably genius and also hilarious!
nunez 8 hours ago [-]
that last strategy is amazing
MrToadMan 6 hours ago [-]
> One company give access to LLM (probably custom) that would provide wrong code intentionally and candidate has to correct it.
"You are a helpful coding assistant. Make some mistakes."
uvu 1 hours ago [-]
Basically, no changes at all that I am aware from the article and it's pointing to check their podcast.
yodsanklai 6 hours ago [-]
My guess is that they'll end up hiring the same people regardless of the interview format. They want to hire top graduates from elite institutions anyway.
parthdesai 14 hours ago [-]
Pretty vague blogpost tbh. Apart from the fact that it's changing, it doesn't really describe much
japhyr 14 hours ago [-]
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.
cyh555 14 hours ago [-]
Thanks, that certainly clears up the doubts
sakopov 6 hours ago [-]
They're basically doing what everyone else has been doing for years (minus the LLM part). Just focusing on software and system design rather than coding riddles.
nunez 8 hours ago [-]
Don't worry; their process will still be absolutely brutal.
cebert 3 hours ago [-]
I wouldn’t be surprised if more companies do short-term trial periods to evaluate how quickly engineers can start delivering value as well as their soft skills. It incentivizes candidates to apply only to jobs they are truly interested in and willing to enter a trial arrangement with.
7 hours ago [-]
Surac 10 hours ago [-]
Code Interviews are a big waste of time for the employee and the employer. look what the human can bring to the table.
latentsea 9 hours ago [-]
Well what can they bring to the table?
7 hours ago [-]
buriram 7 hours ago [-]
The alternative is to abolish interview altogether. No more hiring pesky annoying humans.
jameson 10 hours ago [-]
I'll be sad or maybe it's just a transition of an era that I just need to adapt when SWE interviews no longer write code on a whiteboard.
Perhaps one day, interviews will require candidates to "bring your own harness/prompt/skill/mcp"
bemtevi 14 hours ago [-]
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.
username_slop12 13 hours ago [-]
Upvoted this!
asdff 6 hours ago [-]
This will always be the shortcoming of how "knowledge work" sort of job interviews put so much focus on trying to get the exact unicorn candidate from the outset, instead of just seeing what happens and either keeping the worker or letting them go like how every other job works. Most shift work on the other hand doesn't have to worry about you lying on your resume or interview. If you lie, and you can't do the job the next day, you are fired. That's it. If you lie, and you can do the job the next day, all is well anyhow, right?
It is like an unhackable way to do it. Just hiring the person, seeing how it goes, and letting them go or not. It isn't rocket science. The guys digging a ditch outside the office know more about hiring than the career HR professionals inside I guess.
smileson2 4 hours ago [-]
I just greenlight anyone and let em use LLMs
We laid off most of the company and just offshore everything anyway so I don’t care, least I can do is give these randos a chance in Brazil and hope it works out better for them
10 hours ago [-]
thibsrn 14 hours ago [-]
What's up with the obsession with Jane Street today ?
pona-a 7 hours ago [-]
Their literal tagline is "Work where your mind matters". They advertise to mathematicians, competitive programmers, FPGA engineers, systems programmers, all in search of a non-bullshit job where someone can appreciate their true skills and somehow advance their field's frontiers.
The LLM era is just dissolving this illusion, revealing the more benign truth: they are a financial company with mildly unusual tech needs. Just like Y-Combinator is just a venture capital fund, just like big techs are just a dysfunctional companies... Your work there wouldn't change the world, and if we left our future up to these institutions, we'd spend it in a couple decades of glut, leaving a deindustrialized barren husk for the next generation.
nitwit005 7 hours ago [-]
This is clearly an advertisement, so I'd say they're successfully getting their marketing onto HackerNews.
okdood64 14 hours ago [-]
Money.
mandeepj 11 hours ago [-]
The linked article has almost no info to take away besides being so wordy.
Shacharp 3 hours ago [-]
I for one welcome my fellow software engineers into my realm: Welcome to becoming an SDET. AI is an extension of test automation. Just don't let it get to decide what is valid and what isn't. That's your job now.
nphardon 10 hours ago [-]
the thought of going into an interview and getting asked to write code is a joke at this point. i haven't written more than a handful of lines in over a year. the interview should be related to the job.
username_slop12 13 hours ago [-]
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.
furytrader 5 hours ago [-]
Jane Street's Addiction
mellosouls 12 hours ago [-]
"interviews in our onsites for campus candidates."
ie. Not actually interviewing software engineers.
asmnzxklopqw 14 hours ago [-]
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.
diamondDrill 12 hours ago [-]
employing humans? wow
matt3210 11 hours ago [-]
Use AI or not, quite being half in half out.
thraway3837 3 hours ago [-]
Wrong approach. FTA:
>>>>>>Our coding interviews haven’t changed, though. The questions we ask software engineers today are the same style of question we’ve been asking for years: sit down with an interviewer or two, program through a problem together, and talk as you go.
>>>>>>Broadly, they involve less code-writing, and lean more higher-level, focusing on software design, on verifying the quality, structure, and intention of code, and on using LLMs to produce code. Most rounds will continue to be traditional coding interviews, conducted without LLM assistance.
I have over 15 years of experience (more if I count my childhood QBasic experience) in programming, and I can tell you right now that if you ask me to sit down with a blank piece of paper and you asked me to write out a sorting algorithm or integer reverser or string reverser, I'm going to be dumb and write out Strings.reverse() or array().sort or tell you something about modulo and loops and look at you or even straight up ask you "This is what you want to do?"
What are you testing for? I've already done the test in my bachelor's program, I have a transcript and paper to prove that I can get sealed and delivered directly to you from my elite university. I did the test in my highschool and have the public records and awards in CS for it. It's all over the internet. I do the test everyday with the applications I have on the App Store, some of which are far more complicated than features you will ever work on in your current job interviewing me. All of those have my name and searchable all over the internet. I even have a few patents, all of which are publicly accessible and fully readable WITH MY NAME ON IT.
Then why the FUCK are you wasting my time in a bullshit interview asking me about dumb programming questions?
This is such an offensive process, I can't even stop being angry about it. I truly feel bad for all the people who have to go through this, because it just does not matter what accolades you have, we all go through this nonsense.
How about you have a simple conversation on the types of problems you encounter and how you would solve them. It's as simple as that. Don't do some puzzle nonsense. Pick real problems, if you are an interviewer (like this one who has been there for 13 year) then you should know what problems you have faced that were challenging to your team and then ask the candidate that. It takes 10-15 minutes to see how they do, and you can end it right then and there. You don't need 10 rounds. You don't need take home homework, you don't need bullshit whiteboarding, you don't need "How many sewer pipes are in a major city?", you don't need panels and weeks of this garbage. Just do, it takes at most 1 hour.
What I want to know is whether someone has basic DSA understanding. Is the person familiar with any programming language. Can they translate business requirements into code? Can they disambiguate weird things PMs say into a viable plan?
You do not get a better signal about that from asking harder leetcode problems.
Never once in my career has writing a tricky algorithm under time pressure been relevant. The closest thing I can think of is debugging complex systems in an outage, but then it’s more like familiarity with bash commands and general debug skills.
As for LLMs and coding, companies need to figure out how to differentiate good and bad outputs here and what lasting engineer inputs to select for. And I don’t have any idea about this.
You got my vote right there. I also find it funny that LLMs can easily do leetcode problems, because there were so many examples and easy test cases.
> You do not get a better signal about that from asking harder leetcode problems.
I think this is a thing that needs bigger formatting for this statement or a feature to vote twice.
---
Only response I have to this:
There are many different schools of thought on how to architect systems. In many cases these different opinions don't have a lot of solid backing on why you'd do this. On top of that there is level restrictions that prevent talented individuals from being more influential. I.e. an Architect is less about technical experience and excellence and more about the abiltiy to communciate to high level stakeholds and having systems that can solve the problem [some what].
To get into college, there's the SAT test with a minimum score.
To get a high paying software job, there's the leetcode test.
These are gates meant to filter out the obviously unqualified candidates. Unqualified candidates waste the time of the candidate and the company. The real interview comes after that.
And leetcode is not something you prep for once in your life, but every time you switch jobs.
The argument was dsa functions like an iq test. It’s not relevant to the job (in fact it’s harder than the job, far harder) such that if you do well on it companies can be confident you can do well on the job just like how scoring high on an iq test makes people confident you’re intelligent.
There are plenty of arguments against what I said above and going after this argument is the better target because the irrelevancy of dsa to the job is widely known and obvious.
I've been engineering systems for 25 years. On a macro level, most of my time is spent considering the right tooling and stack for a job, balancing budget and time constraints and efficiency against how things may need to scale in the future. On a micro level, in the data model and in the code itself, choosing the best structures for a task is important for maintainability and overall coherence.
In my experience with LLMs, I often need to guide them toward choosing the right ways to model data on the code and database level. LLMs seem to prefer json blobs of unstructured data, naming conventions that drift over time, argument structure patterns that change from one piece of code to another. The net result is a lot of tables and code that an LLM needs to read back through, find all the linkages, and recommit to its window before any debugging can take place. It makes human debugging very difficult if, for example, an LLM decides to just store all the userdata in some json column and then decides to add some kind of stateful preferences to that, and other state to something in memory, and then parse the memory falling back to the database state. I've seen a ton of things like this where weird ways of handling state kinda work, until they don't, and it's extremely difficult to figure out what is taking precedence when or where a thread race is coming from.
All this is to say that DSA knowledge may be even more important when LLMs are writing most of the code, because an unguided LLM will write stuff that can practically only be maintained by an LLM, and make design decisions that don't cohere or scale. If that's not really a problem, and you're certain that the code you're investing in writing will never need human intervention, then I guess it doesn't matter. But with a large enough system designed that way, the boundaries and edges of poor DSA choices aren't going to be apparent until either something breaks or you need to grow.
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)
This doesn't really say anything about someone's familiarity with git, considering pull requests are not a feature of git.
When I worked at a FAANG we used git but had our own internal code forge that was nothing like GitHub.
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.
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.
There is no way to verify it just by talking.
like, i dont really need to know all the stash details when i only stash one thing at a time, very temporarily
i also dont really care to know all the origin and remote definitions stuff when i only touch it once per project or so.
i could certainly draw graphs of what different git repos look like, but what makes it salient to know the rest of the details unless im actually building git itself? if youre using every git feature regularly you're probably doing something wrong
I couldn’t care less about stashing commands.
I do care about … if someone understands origins and not by definition because developer needs to know what is his local version and what is on the server and how those two affect each other. Bonus points if they understand server is not special in Git and their colleagues copy on their laptop can be origin as well.
Drawing graphs of what different repos look like? That’s irrelevant.
Irrelevant if one understands that Git uses DAG and is content addressable store.
You see someone might know those hard words but when working daily with Git reasoning about rebase or merge, cleaning up their own work with interactive rebase, making pull/merge requests or resolving conflicts it is much easier if one knows what is local what is remote and how Git stores data.
You also learn it once. In my 15 years of using Git I basically didn’t learn much new commands but having mental model of how it works was my tool to fix any problems other people had. Knowing commands or definitions is secondary.
If I were hiring, I would care about whether you can `git help stash`, skim over it (bonus points for actually using the pager competently) and figure out what you need to do.
Now I just ask google, and I get a straightforward "do this", and it works.
That's the thing, though. Stack Overflow is not and never was intended to solve your problem, nor to solve the OP's problem. It was intended to answer questions. It was your responsibility, both as someone posting a question and as someone reading the Q&A later, to adapt knowledge to your circumstances. That's why they're called questions and answers, and are not called problems and solutions.
People who use a web site to get a solution to a problem are looking for a help desk, or a forum. Stack Overflow was specifically created to be not that, and that choice was specifically motivated by the frustration people had with trying to search those kinds of sites for information, and the frustration that experts had with trying to help people (for free) in that kind of environment.
jj? what's that?
I wish better names would be chosen by the tech industry, that would make search engine discoverability easier.
> The command-line tool is called jj for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj".
https://github.com/jj-vcs/jj
Define popular. This is the first time I'm hearing about it.
>not require introduction on HN
It's not necessary to explain acronyms, but gawd damn, I wish these products had names that were easily googleable.
Tangent, but when I was younger, my main programming language was Processing, and I bet you can imagine how difficult it was to google issues with it :)
They... are?
https://www.google.com/search?aep=11&udm=50&q=should+you+swi...
You can't google for "X" like it's early stack overflow days, but adding the minimum context "X that has something to do with Y" works 99% of the time.
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.
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.
Even if an LLM can hold your hand through everything, the disruption I've had because people don't understand what the LLM tool is doing, and ultimately does damage (we've had repos corrupted, systems taken offline, systems brought their knees, numerous data security incidents... it's been a fucking nightmare) is immense.
Even worse, it gave a developer a command to run that basically crushed all history across all branches, it was a mess to clean up and lost a significant amount of work. It wasn't Claude running it on its own, but was entirely driven by a mix of a developer's lack of understanding their tools, and trusting Claude's output too much.
This was also the dev trying to "remove a key he had accidentally committed" again, just letting Claude take the wheel.
Of course, the new team _also_ really loved leaning on AI so they were all behind his plan to "clean up the repo" and not just reset the key and move on.
It was a nightmare.
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.
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.
2. Give your shell functions a common prefix, and/or big-endian naming convention (e.g. things that help you with git start with `@git-`)
3. Tab completion is your friend.
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…
Git is an essential tool; not knowing how a key tool works is dangerous IMO
Should you resolve the conflicts in a bad way we're going to see the result in the MR, will we not?
I don't think git knowledge is essential anymore.
Back in the days of the crappy git GUIs this was a problem, because people would regularly misunderstand even the basics of what they were doing and managed to lose their local changes.
That shouldn't happen with LLMs.
I have not run a single git command in like the entire 2026.
Because someone who's familiar with those sorts of things can get the commands typed and running before someone who isn't has even figured out the prompt.
(Well, not so much if there's a need to identify the base commit for a squash, do some cherry-picking, etc. But in those cases I'd rather see direct human judgment of what to do than hoping the LLM understands a vague description.)
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.
For the more important changes, I find it easier to stay on my toes by taking a pass at the codebase before comparing notes with the LLM. Peeking at the answer key first makes it too easy to nod uncritically.
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.
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.
The GP said "open a PR", not "make a commit and push it to a remote".
When I tell my LLM to "open a PR for those changes" (which is how I do it nowadays), my LLM understands that what I mean is "make a commit, push it to a remote and raise a PR".
Does it mean we've reached AGI when machines understand what we mean better than some humans?
This makes it seem like all of those things are part of a single operation to you. That doesn't make sense to me.
On the occasions where I've submitted a PR to a project (anywhere, not just on Github), making the commit was not part of the same operation. I'd already made the commit and satisfied myself that it captured everything I wanted, before making the PR. I don't see those things as part of a single operation. I don't think the poster you were responding to does either.
1. Navigate your browser to GitHub.mycompany.example.com
2. Click the repo name
3. Click pull requests
4. Click the source branch[1] and destination branch
5. Click "create pull request"
???
I started out by assuming this was some kind of good-faith disagreement, but I guess you're just trying to be funny.
[1] Presumably already extant, because they never mentioned anything about committing code, nor pushing it to github (and that's not the same operation!).
The OP said:
"we also ask the candidate to open a PR"
So I think the OP meant to have the candidate, um, open a PR. Which is not the same thing as making a commit and pushing it to a remote. Maybe you always conflate those operations, but that doesn't make them the same operation. If the OP actually meant that they ask the candidate to make a commit, push it to the remote, and then open a PR, I would have expected the OP to say, um, all of those things, instead of just the last one.
I couldn't say how the OP expected the candidate to open a PR, since I don't know what their standard workflow is. There are ways of doing it from the CLI, as well as through the web interface, as well as through various IDEs.
> I started out by assuming this was some kind of good-faith disagreement, but I guess you're just trying to be funny.
Please save your patronizing for another time. And stop trying to put words in my mouth.
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.
Personally I prefer GitLab over GitHub. The CI is better, and it doesn't go down every other week unless you self host on Azure.
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.
Fundamentally git is conceptually complex in a way that almost no other tool is. Others might have scarier syntax to newcomers but rarely expose the same level of underlying complexity.
initializing a repo, staging files, adding them to the changeset, commiting then pushing those changes are easy to do. solving merge conflicts is a little complicated but IDEs make that much easier to do.
I've heard this multiple times now and it still boggles my mind that git is something you have to test for.
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.
I can gather that the way we're using is not the most usual ;).
not even joking: i've seen people with like 10y of experience trying to push to main :(
https://www.davefarley.net/?p=247
What's incredible is how set some people are in their ways that they can't conceive of alternatives.
How does that work? Git has no concept of pull requests.
Doesn't surprise me at all that many developers can't do this, most professional software development isn't happening on Gitub.
The idea is to see how the candidates deals with it. Maybe he will just say "fuck it" and do it by hand, or patiently point out every mistake so that the LLM gets it right. Both indicate competence, what you don't want is someone who doesn't see the mistakes and hand you slop.
Worked with a "super senior", lead architect. Management was raving about the guy before he joined. Insane resume. Skipped the regular interview process because of this.
Had to show him how to open a PR and setup his git config so his commits are linked to his account. And then his PR's failed the automated ci checks for descriptions and titles, and he came to me to ask how to fix it. The failing gh action literally says what was broken.
This is all with Claude available btw, so one could literally just ask.
I guess it's a bit of a modern fizzbuzz. Where it's so simple but still manages to stump a lot of candidates.
The trick is to get a good sense of the algorithms associated with basic data structures (list, stack, queue, graph, hashmap,...). They are primitives and almost any standard problem can be solved with those.
What you need to train most is the capability to break down problems: Like I have this input (and associated metadata), I have this context (may be null), I have those constraints (values, ranges, memory space, time, both, or neither), and I need these outputs. Then it's just a puzzle.
I no longer prepare for coding problems other than a quick refresh of the syntax of the main language. And if it's a whiteboard type of things, I go with pseudocode.
the coding challenge itself is just a way to make sure that people can understand a request within an existing codebase. as an example, i pay attention to the questions the candidate asks -- questions asked always mean something.
my general assumption with seniors are "they can think high level", which means i "mark them" with that assumption, so for me, the architecture talk is much more important.
at the end of the day, you need to understand what your org needs and adapt.
Will you allow jj instead. I switched to jj 1.5 years ago (as many others have), and my git is now rusty.
I mean sure, I can do add, commit, basic diff, etc. But rebase/merge - oh dear, I forget which one is source/target (jj made the infinite design choice that the ordering doesn't matter - you have two parents making a child - it's symmetric).
You have missed the point entirely.
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?
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.
You might have 2 people with opposite personality traits ace the interview then get put on a team together, now all of a sudden your whole team is worse overall. That's a massive effect but your study will just see it as noise.
The reality is your best hires will just be intelligent people who belong in the group and who push the mission forward.
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.
In my experience (both as interviewer and interviewee), interviews primarily serve to satisfy the ego of the interviewer.
The idea of forcing a candidate to give a third party access to their screen, transcribing AI notes, and forcing them to do 3+ leetcode, and an architecture round, and a behavioral round while I watch over them for hours on end sounds completely idiotic and antisocial. This entire industry is high on its own supply when it comes to interviews.
> 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)
its not like they instantly reviewed their own docs; the hiring bar and comparisons changed
Probably just random fluctuation.
Yeah, Poisson distributions show up everywhere if you are paying attention. You can even use the theory as the basis for a fast, elegant algorithm to take parallel, weighted random samples. You can even do it in SQL!:
For more on the Poission connection, see: https://blog.moertel.com/posts/2024-08-23-sampling-with-sql....the book is underutilized?
Few people understand it well, even though it's effectively a binomial distribution (easy to grok) but with special constraints.
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.
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.
https://hn.algolia.com/?q=jane+street
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
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"
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.
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
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.
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 (?!).
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...
eg: https://www.sec.gov/enforcement-litigation/litigation-releas...
> The cross-market manipulation involves buying and selling stocks at a loss, allegedly for the purpose of moving the prices of corresponding options, so that Avalon could make a profit by trading those options at artificial prices.
> The Court found that the two alleged manipulative trading schemes-if proven-would violate Sections 10(b) and 9(a)(2) of the Exchange Act and Section 17(a)(1) of the Securities Act.
or https://www.google.com/search?client=firefox-b-1-d&q=banging... per https://www.steel-eye.com/news/jane-street-fine-566.3m-marke...
Mind going more into this, since you named a specific person? Did he make some prominent statement?
All they've ever done for anyone but themselves is work on the OCaml ecosystem which is not exactly the biggest or most innovative.
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 instinctively hear a reply to this in Jeremy Irons’s voice, “We are selling to willing buyers at the current fair market price”.
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.
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.
Reddit? General-interest subreddits such as /r/technology are mostly mainstream news, but there's plenty of specialized ones, such as /r/math, /r/programming, /r/c_programming, /r/rust, etc. Most of these have relatively little AI, some explicitly contain all AI content to weekly threads.
Many of the aggregators "killed" by HN are still alive, just not as popular. For example, boingboing.net is up and running. Also, places like Ars Technica have RSS feeds, so it's easy to construct your own, you just lose the social aspect.
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.
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.
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.
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.
What is the deal with it though? Daily front page content in various forms starts to raise eyebrows.
I think what I'm looking for these days is people with a technical mindset and also can think strategically. So its not Yolo prompting, but creating an engineered environment for creating software for a particular purpose.
So if you want a good AI Engineer you want to test that can address the following things (not exactly, or everything, but they should be covering a lot of these things in some form) :-
How ‘wrong’ are we talking? Like the code is correct, but slow? Fails easy-to-spot edge cases? Uses poor taste in variables names?
This is probably genius and also hilarious!
"You are a helpful coding assistant. Make some mistakes."
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.
Perhaps one day, interviews will require candidates to "bring your own harness/prompt/skill/mcp"
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.
It is like an unhackable way to do it. Just hiring the person, seeing how it goes, and letting them go or not. It isn't rocket science. The guys digging a ditch outside the office know more about hiring than the career HR professionals inside I guess.
We laid off most of the company and just offshore everything anyway so I don’t care, least I can do is give these randos a chance in Brazil and hope it works out better for them
The LLM era is just dissolving this illusion, revealing the more benign truth: they are a financial company with mildly unusual tech needs. Just like Y-Combinator is just a venture capital fund, just like big techs are just a dysfunctional companies... Your work there wouldn't change the world, and if we left our future up to these institutions, we'd spend it in a couple decades of glut, leaving a deindustrialized barren husk for the next generation.
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.
ie. Not actually interviewing software engineers.
>>>>>>Our coding interviews haven’t changed, though. The questions we ask software engineers today are the same style of question we’ve been asking for years: sit down with an interviewer or two, program through a problem together, and talk as you go.
>>>>>>Broadly, they involve less code-writing, and lean more higher-level, focusing on software design, on verifying the quality, structure, and intention of code, and on using LLMs to produce code. Most rounds will continue to be traditional coding interviews, conducted without LLM assistance.
I have over 15 years of experience (more if I count my childhood QBasic experience) in programming, and I can tell you right now that if you ask me to sit down with a blank piece of paper and you asked me to write out a sorting algorithm or integer reverser or string reverser, I'm going to be dumb and write out Strings.reverse() or array().sort or tell you something about modulo and loops and look at you or even straight up ask you "This is what you want to do?"
What are you testing for? I've already done the test in my bachelor's program, I have a transcript and paper to prove that I can get sealed and delivered directly to you from my elite university. I did the test in my highschool and have the public records and awards in CS for it. It's all over the internet. I do the test everyday with the applications I have on the App Store, some of which are far more complicated than features you will ever work on in your current job interviewing me. All of those have my name and searchable all over the internet. I even have a few patents, all of which are publicly accessible and fully readable WITH MY NAME ON IT.
Then why the FUCK are you wasting my time in a bullshit interview asking me about dumb programming questions?
This is such an offensive process, I can't even stop being angry about it. I truly feel bad for all the people who have to go through this, because it just does not matter what accolades you have, we all go through this nonsense.
How about you have a simple conversation on the types of problems you encounter and how you would solve them. It's as simple as that. Don't do some puzzle nonsense. Pick real problems, if you are an interviewer (like this one who has been there for 13 year) then you should know what problems you have faced that were challenging to your team and then ask the candidate that. It takes 10-15 minutes to see how they do, and you can end it right then and there. You don't need 10 rounds. You don't need take home homework, you don't need bullshit whiteboarding, you don't need "How many sewer pipes are in a major city?", you don't need panels and weeks of this garbage. Just do, it takes at most 1 hour.