Start with what Cornelis actually makes, because the whole interview falls out of it. Omni-Path is a lossless, high-bandwidth fabric: host adapters (they call them SuperNICs or HFAs), switches, cables, and the software to drive the whole thing. The company spun out of Intel’s Omni-Path business in 2020, and its current generation, CN5000, is shipping with the CN6000 sampling to customers in late 2026 and CN7000 on the roadmap for 2027. In September 2026 it raised $205 million led by IAG Capital Partners (valuation undisclosed) and announced a rack-scale collaboration with Qualcomm. The AI framing is real but worth reading precisely: Omni-Path grew up in MPI-era HPC, and the GPU-cluster story runs through libfabric’s device-memory support (FI_HMEM), which OPX exposes for NVIDIA and AMD, so the engineering is still the classic HPC-networking problem applied to GPU collectives.
That means Cornelis is not hiring for generic backend work. The listings that surface, like a Senior Software Engineer on the OPX libfabric provider based in Wayne, Pennsylvania, want people who are comfortable where software meets the wire. If your experience is RDMA, verbs, libfabric/OFI, the Linux networking stack, DMA, or MPI collective operations, you’re the target. If it isn’t, the technical rounds will expose that fast, so calibrate before you spend prep time.
The three software tracks, and how they diverge
Cornelis’s stack has a shape you can study. In user space sits OPX, the native libfabric provider for Omni-Path, open source and upstream in the OpenFabrics tree. Below it, the hfi1 kernel driver is in the mainline Linux tree and supports both the old OPA100 adapters and the new CN5000 HFIs. Around both sit the fabric manager, subnet management, and user tools like Fast Fabric. There’s also firmware and ASIC work, but that’s a separate hardware discipline and I’ll leave it out of scope here; the three tracks below are the software loops you’re most likely to land in.
Which track you interview for changes the middle rounds completely. The OPX track is C, and it’s about the transport: how a message gets from an application call to the hardware and back, correctly and fast. The kernel-driver track is hfi1 and the Linux networking and PCIe subsystems. The fabric-software track is the distributed-systems side, routing and management across a large fabric, where it starts to resemble the kind of problem the rest of this site’s system design material covers. Pin down with your recruiter which one you’re in before anything else.
| Round (reasoned from a real Cornelis OPX posting, the published stack, and HPC-networking peers, not a confirmed Cornelis loop) | Who runs it | What it likely screens for |
|---|---|---|
| Recruiter screen (30 min) | Recruiter | Track fit, low-level networking background, work authorization, comp expectations, Wayne PA onsite/hybrid expectations |
| Technical phone screen (45-60 min) | Engineer | Practical C and systems reasoning: pointers, memory, concurrency, and a probe on RDMA or kernel internals depending on track |
| Deep technical dive (60 min) | Senior engineer | OPX: RDMA transport, tag matching, eager vs. rendezvous. Driver: hfi1, DMA, interrupts. Fabric: routing, congestion, management at scale |
| Design or debugging round (60 min) | Senior/staff engineer | Walk through a data path end to end, or debug a hang/perf regression on a live fabric; failure modes matter more than the happy path |
| Behavioral / team fit (45 min) | Hiring manager | Ownership of a deep component, working upstream in open source, debugging under pressure on hardware you can’t fully see |
Four to five rounds is normal for a company this size hiring into specialized work. The reasonable inference from the posting and from how HPC-networking shops hire: because the surface is narrow and the talent pool small, the bar on your specific domain is high, and the general-algorithm bar is probably lower than at a big-tech loop. Probably, not certainly, so don’t skip coding prep on an unconfirmed guess. Lead with evidence that you’ve moved bytes across a wire, and treat a clean algorithm round as table stakes.
The OPX round: an RDMA write from the application to the wire
If you’re interviewing for the libfabric provider, expect to be walked down the data path. A clean prompt is “trace an MPI_Put or an fi_write from the application call to the bytes landing in remote memory.” A strong answer names the layers: MPI or a collective library on top, libfabric’s OFI API, the OPX provider translating that into hardware commands, the adapter doing the actual RDMA. Know why OPX exposes only the FI_EP_RDM endpoint type, a connectionless but reliable datagram model, and why that fits Omni-Path’s hardware better than the connection-oriented queue pairs you’d set up in classic InfiniBand verbs. That contrast is worth rehearsing, because it separates people who’ve used verbs from people who understand them.
Then the performance mechanics. Be ready on eager versus rendezvous protocols and where the crossover threshold sits: small messages get copied and fired off eagerly, large ones negotiate so the hardware can DMA straight out of registered memory with no extra copy. Expect memory-registration and pinning questions, since registering buffers is expensive and caching those registrations is where real throughput is won or lost. Tag matching, manual versus automatic progress, and completion-queue handling are all fair to expect, because they’re exactly the knobs an MPI implementation leans on. The candidates who do well connect a design choice to a number: this threshold trades latency for bandwidth, this registration cache saves microseconds per message, here’s how you’d measure it with a bandwidth and message-rate benchmark. For the GPU bridge, be ready on device-memory registration: an OPX presentation describes GPU support via FI_HMEM, and the same FI_EP_RDM tagged-messaging surface is what an NCCL-over-OFI plugin needs to carry GPU collectives over the fabric.
The driver round: hfi1, DMA, and interrupts
The kernel track lives in hfi1 and the Linux networking and PCIe subsystems. Fair game: how the driver sets up DMA and keeps the CPU out of the fast path, interrupt moderation and when you’d switch to polling to kill latency, the split between what runs in kernel space and what OPX does in user space, and how a user-space library gets a fast doorbell to the hardware without a syscall on every message. Memory barriers, cache coherence between the CPU and the device, and the lifecycle of a descriptor ring are all reasonable depth probes. This is C, kernel conventions, and a real feel for how a NIC and a CPU core actually coordinate, not Java-style abstractions.
Debugging is where senior candidates pull ahead. A likely scenario: a job hangs, or throughput drops off a cliff under load, and you talk through isolating it. Good instincts sound like checking whether a completion got lost, whether flow control stalled, whether a single flapping link is stalling a collective, and which counters and traces you’d read first.
The fabric round: lossless at scale
For the distributed and fabric-management track, the questions climb up to the network as a whole. Omni-Path is lossless by design, so understand link-level credit-based flow control and how it differs from the priority flow control (PFC) that RoCE uses over Ethernet, including why PFC is prone to head-of-line blocking and deadlock that a credit scheme avoids. Adaptive routing on fat-tree and dragonfly topologies comes up: spreading traffic across paths to dodge congestion, and the ordering headaches it creates. Congestion control on a lossless fabric, how a fabric manager discovers topology and programs routes, and how collective operations like all-reduce and all-to-all stress the network differently from point-to-point traffic are all live. The through-line is that a tiny per-message cost multiplies across thousands of GPUs, so this round rewards thinking about the aggregate, not one link.
A lot of the management and tooling glue is ordinary systems software, so keep general problem-solving sharp with the coding patterns catalog, but don’t expect a LeetCode-grind loop. The differentiator here is fabric judgment, not a clever one-liner.
Compensation: what’s grounded and what to ask for
Cornelis is private and headquartered in Wayne, Pennsylvania, which has no statewide pay-transparency law, so a posting carries a salary range only if the role is also open to a state that requires one (Colorado, New York, Washington, California). The one public, if thin, data point is Levels.fyi, where self-reported software-engineer total compensation sits in the mid-$100Ks on a tiny sample that shifts with every new submission, so read it as a rough signal, not a band, and check the live page. The trap: at a private company with no public share price, the equity inside a self-reported total-comp figure can’t be valued with any confidence, so treat that number as closer to base cash than to a fully-valued package, and anchor on a harder source. For base specifically, the most reliable public source is DOL H-1B/LCA disclosure data filed under the employer name, which lists the exact wage for sponsored roles by title and worksite.
Because you can’t value the equity from the outside, the move is to negotiate and verify the grant terms themselves rather than a headline number. Ask the recruiter for the number of shares, the strike price, the most recent preferred price per share, the fully diluted share count, and where you sit in the liquidation preference stack, then model the range with the total comp calculator and push on the grant and the base separately in any salary negotiation. A fabric company’s upside tracks how much of the AI-cluster buildout it captures against Nvidia’s InfiniBand and the Ethernet camp, so weigh that before you count paper you can’t price.
Two logistics worth settling in the recruiter screen. The roles that surface are tagged to Wayne, Pennsylvania, which reads as onsite or hybrid rather than remote-first, though that’s inferred from the posting, not a stated policy, so ask directly if you need remote. And confirm visa sponsorship early: that Cornelis files H-1B/LCA petitions at all means it happens for some roles, but whether a given opening is open to it is a recruiter-screen question, not a given.
Behavioral round and how to calibrate
The behavioral round is likely lighter than a big-tech loop but not a formality. Expect to defend a deep technical decision, describe a nasty bug you chased on hardware you couldn’t fully observe, and show you can work in the open given how much of Cornelis’s stack lives upstream. Keep the stories tight and specific with the STAR method, and to see how this loop compares to other infrastructure-startup interviews, the AI-native company interview guides hub and the full company guides index are the places to calibrate. The thing that most plausibly gets you hired at Cornelis is narrow and testable: you’ve moved bytes across a wire and you can explain, with numbers, exactly how.
Practice the behavioral round:
