Hiring a Solana Infrastructure Engineer: What to Actually Look For
Most candidates can configure an RPC node but few understand shred propagation, geyser plugin internals, or NUMA-aware thread pinning — we outline the interview signals, take-home task design, and market-rate ranges for trading-focused infra engineers in 2025.
Hiring a Solana infrastructure engineer for a trading operation is nothing like hiring a backend generalist. The gap between someone who can configure an RPC node and someone who can wire a low-latency Geyser pipeline into a sniper with NUMA-aware thread pinning is enormous — and resumes rarely tell you which side of that gap you're looking at. After building and running Solana trading infrastructure across sniper bots, MEV engines, and copytrading systems, here is what we have learned to screen for.
What "Infrastructure" Actually Means on Solana
On Solana, infra is not DevOps. You are not managing CRUD backends with Kubernetes. The work is closer to HFT systems programming: the validator gossip protocol, shred propagation, the leader schedule, slot boundaries, and how all of that interacts with your latency budget. A candidate who cannot explain what a shred is — that 1,280-byte UDP packet that carries fragments of a block before it is finalized — is going to hit a wall the moment you try to tune transaction landing rates.
The core primitives your candidate must understand:
- Turbine — the block propagation protocol that fans out shreds from the leader to the rest of the network. Understanding retransmitter topology tells you where to colocate.
- Geyser plugins — the streaming account-update interface that makes real-time state subscription possible. Know the difference between
notify_transactionandnotify_slot_statuscallbacks, and why you never block the Geyser thread. - Leader schedule — slots are assigned to validators 2–3 epochs in advance. A serious bot routes its transactions 2–3 slots before its target leader. Anyone who does not know this is sending randomly.
Interview Signals That Actually Separate Candidates
Stop asking "have you worked with Solana?" and start asking questions with checkable answers.
Ask about Geyser internals. A strong candidate can describe the plugin lifecycle, explain that the plugin runs in the validator's own process space, and tell you why a slow notify_block_metadata call can stall the whole chain. A weaker candidate will say "it streams transactions" and stop there.
Ask about transaction confirmation latency. You want to hear: slot time (~400ms), preflight checks and when to disable them, priority fees vs. Jito bundles vs. both, and the difference between processed, confirmed, and finalized commitment levels. The right answer for a sniper is almost never finalized.
Ask about NUMA and CPU affinity. On a multi-socket server, crossing NUMA boundaries under load costs 20–30ns per cache miss — that adds up. A candidate who knows to pin the hot-path thread to a NUMA-local core and disable CPU frequency scaling is operating at the level you need. Someone who has never pinned a thread in production is not.
Ask about RPC vs. direct validator access. Public RPC has rate limits, unpredictable latency, and no Geyser access. A trading-grade setup either runs a dedicated validator node or colocates with a staked node that exposes a private Geyser endpoint. If your candidate has only ever used QuikNode or Helius and has never thought about why, that is a gap.
Take-Home Task Design
A good take-home for a Solana infra role is scoped to 4–6 hours and tests real production thinking, not just code that compiles.
The task we use: "Given a Geyser plugin connected to a local test validator, stream all token program account updates and compute the time delta between the slot being marked processed and your code receiving the account notification. Output p50, p95, and p99 latency. Then explain in writing what you would change to reduce that p99."
What you are looking for in the answer:
- Correct use of
crossbeamor async channels to avoid blocking the Geyser callback - Accurate timestamping (wall-clock vs. monotonic, and why it matters here)
- Written analysis that mentions serialization cost, thread scheduling, network stack, and colocated vs. remote validators as real variables
A candidate who submits a working implementation and a thoughtful written analysis — even if the p99 numbers are not great — is worth a second conversation. A candidate who submits working code with no written analysis has probably never thought about the system end to end.
Market Rates in 2025
For a trading-focused Solana infra engineer in 2025, expect:
- Junior (1–2 years, knows Rust and Solana basics, no production trading infra): $90K–$130K base, or $80–$120/hr contract
- Mid (2–4 years, has run a Geyser pipeline or validator, understands latency trade-offs): $140K–$190K base, or $130–$180/hr
- Senior (4+ years, built and operated competitive trading infra, knows the full stack from BIOS to bundle): $200K–$300K+ base, equity expected, or $200–$300+/hr
Remote-first Rust engineers with Solana validator experience are scarce. If you find one who also understands MEV — Jito block engine internals, bundle ordering, tip auction dynamics — pay the number. The market is thin and the operational leverage is massive.
A common mistake is hiring a strong Solana protocol developer (smart contracts, Anchor) for an infra role. The skill sets overlap in Rust but diverge everywhere else. Program developers optimize compute units; infra engineers optimize wall-clock latency and network topology. Screen separately.
Green Flags and Automatic Disqualifiers
Strong signals:
- Has run a Solana validator on mainnet-beta, even briefly
- Can describe a specific latency regression they debugged and what the root cause turned out to be
- Knows the Jito block engine architecture and can explain why bundle tip optimization is non-trivial
- Mentions
io_uring, kernel bypass, orSO_BUSY_POLLin the context of reducing syscall overhead — even if they have never implemented it, knowing it exists signals the right mental model
Immediate disqualifiers:
- Confuses Geyser with a websocket subscription (
getAccountInfopolling is not Geyser) - Claims sub-10ms Solana transaction confirmation "from a cloud server in Europe to mainnet validators in New York" — the physics do not work
- Has never profiled a Rust binary under load and cannot name a profiling tool (perf, flamegraph, tokio-console)
If you are building trading infrastructure on Solana and need help evaluating candidates, scoping an infra build, or just want a second opinion on your stack — get in touch.
Need a bot like this built?
We design, build and run trading bots on Solana, Hyperliquid and Polymarket.
Start a projectMore from the blog
Public vs Paid RPC: How to Run a Fair Benchmark
A fair comparison of public and paid RPC endpoints must account for quotas, workload, freshness and support guarantees.
Read articleRPC Benchmark Percentiles Explained: p50, p95 and p99
Why averages hide the latency spikes that break trading bots, wallets and production blockchain applications.
Read articleHyperliquid REST vs WebSocket Benchmark: What to Measure
A benchmark plan for Hyperliquid market data that separates request latency from streaming freshness and recovery.
Read article