Interviewing with Jane Street for a Linux Engineer role

· linux, interviews, learning

In August I interviewed with Jane Street for a Linux Engineer role, and I didn’t get it. They asked me not to share anything about the interview itself, so this post doesn’t: no questions, no tasks, nothing from inside it. What I can share is the ground I made sure I had covered going in, because none of that is theirs. It’s the same ground any Linux, systems or infrastructure role expects you to know.

Email from Jane Street recruiting dated 12 August 2026 with the subject Jane Street - Linux Engineering Opportunity / Abdul - Interview, inviting me to interview for a 2027 new grad role with their Linux Engineering team in Hong Kong and asking for my availability. The recruiter's name is blacked out
The invite.
Email from careers@janestreet.com dated 26 August 2026 with the subject Thank you for interviewing with Jane Street, thanking me for interviewing and saying they decided not to move forward with my candidacy
And the email after it.

Before writing this, I asked if I could write about the interview, and whether they’d rather I didn’t name them. This was the reply, and it’s why there’s nothing from the interview itself in here.

My email of 31 August 2026 to Jane Street recruiting, asking whether I could write publicly about what I learned from preparing for and doing the interview, keeping to general Linux concepts rather than the specific tasks, and whether they'd prefer I not mention Jane Street by name. The recruiter's name is blacked out
What I asked.
Reply from Jane Street recruiting on 2 September 2026, asking that I not publicly share anything about my Jane Street interview experience, since they consider the interview process and content intellectual property and want the questions to stay useful for future candidates. The recruiter's name is blacked out
Their reply.

Most of my day-to-day work is kernel and data plane code. Before the interview I went over the fundamentals around it as well, from the kernel boundary outwards.

The basics

These are what any Linux, systems or infrastructure role expects you to know: syscalls and what strace shows, fork and exec, threads and processes, signals and process states (D state, orphans, zombies, PID 1), virtual memory, page faults and overcommit, inodes and permissions, file descriptors, pipes and redirection order, what the shell expands before a program runs, the boot path from firmware to systemd, load and iowait, and sockets and TCP states. I wanted to be able to explain each of them without looking anything up.

The deeper parts

Most of my own time goes into the areas below, and I’ve written about all of them here.

XDP and eBPF. In xdp-bfd, replies are built inside an XDP program by rewriting the incoming packet. That meant BPF timers, keeping BPF maps consistent with userspace, pinning maps and links so a new process can take over without dropping anything, and fitting SHA1 into the 512-byte BPF stack.

Scheduling. Part 1 of that series is about how the normal scheduler picks the next task and what SCHED_FIFO does to everything below it. Part 9 gets into real-time throttling, and why a SCHED_DEADLINE reservation is the only thing that outranks a priority-99 task.

The receive path. On real hardware I had to deal with NIC queues, flow control and moving work to other CPUs with a cpumap, and I found PCIe power saving showing up as reply latency. Those are in part 9 and part 10.

TCP and tunnels. My offsite backups were slow because cubic collapses on a small amount of loss over a long path, and switching to BBR with fq pacing fixed it. The same post covers why a WireGuard peer behind NAT needs a keepalive.

Routing daemons. I have eleven fixes merged in FRR’s BFD daemon, from its data plane protocol to authentication, and they’re all in the FRR post.

How it went

From my side, the interview went well. I got through everything within the hour, and it wrapped up around the 56th minute. I don’t know what Jane Street’s criteria are, so I can’t say what decided it. Better luck next time.

Back to writing