The take-home is where most people wash out. Redpanda hands you a scoped project built on Seastar, its thread-per-core async framework, and gives you a few days. It is not a warm-up. Candidates who have done it describe burning real weekend hours fighting a programming model they had never touched, and that is the point. The company wants to watch you learn an unfamiliar C++ codebase fast, because that is the actual job.
Redpanda is a Kafka-compatible streaming platform written from scratch in C++. No JVM, no reliance on the OS page cache, no ZooKeeper. The storage engine talks to raw disk, each CPU core owns its own shard of state, and replication runs on Raft. That architecture shapes every technical round you sit in. If you prep for this the way you would prep for a generic FAANG loop, grinding LeetCode mediums and rehearsing system-design scripts, you are aimed at the wrong target.
Who Redpanda hires and why the bar sits where it does
The company raised a $100M Series D in April 2025 at roughly a $1B valuation, backed by Lightspeed and GV, with around $266M raised across its rounds. It stays deliberately small and remote-first, which means each engineer carries more surface area than they would on a big-company team. Core engineering roles show up as Core Replication, Connectors, Networking, and Storage, alongside Forward Deployed and Production Operations roles that sit closer to customers. The Core postings are the ones that want serious modern C++.
Because the team is lean and the codebase is dense systems C++, they build the loop around one question: can you reason about performance-sensitive code with no garbage collector holding your hand? A candidate who writes clean Python and hand-waves at memory will not clear the C++ round, no matter how strong the rest of the resume reads.
The loop, round by round
Candidate reports from 2024 and 2025 describe a process that runs about a month end to end, sometimes closer to two if the take-home scheduling drags. The exact shape shifts by team and seniority, but the pieces below are consistent.
| Stage | Format | What it actually tests |
|---|---|---|
| Recruiter screen | ~30 min call | Motivation, C++ background, comfort with remote autonomy |
| C++ technical | ~60 min live coding and code reading | Move semantics, RAII, ownership, allocator awareness |
| Seastar take-home | Multi-day project plus a presentation | Learning an unfamiliar async codebase, correctness under failure |
| Systems / hiring manager | ~60 min discussion | Raft, replicated logs, Kafka protocol, thread-per-core reasoning |
| Culture and values | ~30-45 min conversation | Written communication, self-direction, appetite for low-level work |
The C++ round is a memory-model round in disguise
Expect to share a screen and write or read real C++, not pseudocode. The questions cluster around ownership, moves, and what the compiler is actually doing. A few that come up in different phrasings:
- “What’s the difference between an lvalue and an rvalue reference, and when does the compiler pick a move over a copy?”
- “What does
std::moveactually do? Does it move anything?” - “You allocate a small buffer per request in a hot loop. How do you get the allocator off the critical path?”
- “Walk me through RAII for a file handle. What happens if the constructor throws partway?”
The move-semantics answer people fumble: std::move moves nothing. It is a cast to an rvalue reference that makes an object eligible for a move constructor or move assignment. If the type has no move operations, you silently get a copy. Interviewers here like to sit on that gap and see whether you know it is a cast, not an operation. The same goes for RAII with a throwing constructor: the object was never fully constructed, so its destructor does not run, and any resource the constructor already grabbed leaks unless a member’s own destructor owns it.
They also probe the thread-per-core mindset head on. A common one: why would pinning one shard of state to each core beat a shared thread pool guarded by locks? A good answer touches cache locality, the absence of lock contention, and the way cross-core work becomes explicit message passing instead of hidden synchronization. Seastar leans on exactly this, and Redpanda’s storage layer lives or dies on it.
The Seastar take-home
You get a scoped task on top of Seastar, futures-and-continuations async, and a short window. The framework is the difficulty. Seastar’s future and promise model, its seastar::future<> chaining, and its no-blocking-allowed rule trip up engineers who came up on threads and mutexes. Blocking a Seastar reactor thread is the cardinal sin, and reviewers look for whether you understood that.
Get something compiling and correct before you get it fast. Read the Seastar examples in the repo first, because the idioms are not guessable from a general C++ background. Handle the failure paths, since a streaming component that ignores partial writes and errors is worthless. When you present, be ready to say where you would take it next and what you would measure, because that follow-up conversation carries as much weight as the code. Candidates consistently call this the hardest and most interesting part of the loop, and both halves of that are true.
The systems and hiring-manager round
This is where Raft, the log, and the Kafka protocol come up. You will not be asked to design Twitter. You will talk about the guts of a replicated log. Questions run toward:
- “How does Raft elect a leader, and what happens when a partitioned leader rejoins with stale entries?”
- “Kafka uses in-sync replicas for durability. Redpanda uses Raft. What does that buy you, and what does it cost?”
- “A producer sends with acks=all. Trace everything that has to happen before it gets its ack.”
Strong answers name the mechanics: log matching, the commit index advancing only after a quorum persists an entry, term numbers letting a new leader reject a stale one’s writes. If you have read the Raft paper and can explain why Redpanda folds replication and consensus into one Raft group per partition rather than bolting a separate coordination service onto the side, you are speaking their language. That single design decision is a lot of what separates their architecture from a classic Kafka-plus-ZooKeeper stack.
Behavioral and culture
The non-technical round is lighter than the engineering ones but not a formality. Remote-first and small means they screen for people who operate without much process. Can you drive a project without a manager pinging you daily, can you write clearly since a lot of coordination happens in text, and do you get energy from low-level performance work rather than merely tolerating it. Bring a real story about a gnarly bug you chased into the weeds, ideally something you tracked down with a profiler or a flamegraph.
Compensation, with the usual caveats
Redpanda does not publish salary bands, and numbers move, so treat anything specific with suspicion and check it against levels.fyi and your own recruiter conversation. What is fair to say: a venture-funded infra company at this stage tends to pay competitive cash without matching top-of-market frontier offers, and it leans on equity to close the gap. That equity is private-company stock, illiquid until a liquidity event that may never land on your timeline. Before you weigh an offer, ask for the strike price, the current preferred valuation, the total shares outstanding, and the vesting schedule. Without those four numbers an equity grant is a lottery ticket with the odds hidden from you.
How to actually prep
Spend your time on C++ depth, not breadth of algorithms. Re-read the move-semantics and RAII material in whatever reference you trust, and be able to explain out loud what the compiler generates for each. Clone Seastar and build one of its example apps so the future and continuation model is not brand new when the take-home lands. Read the Raft paper end to end once, slowly. Skim Redpanda’s own architecture docs so you can talk about thread-per-core and its no-page-cache storage design with specifics instead of vibes.
The people who do well here are not the ones with the cleanest LeetCode heatmap. They are the ones who can open an unfamiliar systems codebase, work out its ownership model in an afternoon, and stay calm when the abstraction they leaned on their whole career is simply gone. That is the real test, and the take-home is just the most direct version of it.
Useful next steps:
