I Cracked Citadel CoderPad in 2026: Real Questions and Prep Plan

Quick Facts

I took the Citadel CoderPad first round for a new-grad software engineer role in 2026. I chose Python and implemented the order book matching engine. What follows is the complete process and how I prepared for it.

On question 1, the matching engine, the first ten minutes went to enumerating the order rules, and the matching half ate most of what was left. I used an AI interview assistant to check the price-time priority logic, and it surfaced the heap ordering that made the partial-fill branch clear. I break that down in the walkthrough below.

Before my test, I went through every Citadel CoderPad post from the past two years. That covered Reddit, LeetCode Discuss, and Teamblind. What I found tracks closely with what I experienced. The sections below cover the specific traps that get people rejected. Those include the hidden-test failures and the overlay that ended one live session.

The Real Questions on My Citadel CoderPad Test

My Citadel screen was the live 45-minute first round, run inside CoderPad with an interviewer on the call. It was a single coding problem, no warm-up and no second task, and here is exactly what I got.

Question 1: Limit Order Book Matching Engine

The problem I got: I had to build a limit order book matching engine. The input starts with N, then N lines of side order_id price quantity, where side is BUY or SELL. A buy order matches resting sell orders priced at or below its limit, and a sell order matches resting buy orders priced at or above its limit. Buy orders take the lowest ask first, sell orders take the highest bid first, and orders sitting at the same price fill in arrival order. Every fill prints at the resting order's price, orders can fill partially, and any leftover joins the book. For each execution I printed TRADE buy_order_id sell_order_id execution_price execution_quantity. N went up to 200,000 and the spec asked for something close to O(N log N). The sample I was given was:

4
BUY 1 100 10
SELL 2 105 5
SELL 3 99 6
BUY 4 110 3

which has to print:

TRADE 1 3 100 6
TRADE 4 2 105 3

My approach: I started by listing what the engine actually had to do: keep resting orders on both sides, find the best price fast, and keep arrival order inside each price. A heap on each side hands me the best price in O(log N), so I went with that. I did consider a sorted price map with a FIFO queue at each level, which is closer to how a real book is stored, but the heap version needed less code and had the same asymptotic time. Each incoming order drains the opposite heap while the top price is eligible. When a resting order fills partway, I push the remainder back with its original arrival counter, which keeps it ahead of anything that arrived later at the same price.

import sys
import heapq


def main():
    data = sys.stdin.buffer.read().split()
    if not data:
        return

    idx = 0
    n = int(data[idx])
    idx += 1

    bids = []
    asks = []
    out = []
    seq = 0

    for _ in range(n):
        side = data[idx].decode()
        idx += 1
        order_id = int(data[idx])
        idx += 1
        price = int(data[idx])
        idx += 1
        qty = int(data[idx])
        idx += 1
        seq += 1

        if side == "BUY":
            while qty > 0 and asks and asks[0][0] <= price:
                ask_price, ask_seq, ask_id, ask_qty = heapq.heappop(asks)
                trade = ask_qty if ask_qty < qty else qty
                out.append("TRADE %d %d %d %d" % (order_id, ask_id, ask_price, trade))
                qty -= trade
                ask_qty -= trade
                if ask_qty > 0:
                    heapq.heappush(asks, (ask_price, ask_seq, ask_id, ask_qty))
            if qty > 0:
                heapq.heappush(bids, (-price, seq, order_id, qty))
        else:
            while qty > 0 and bids and -bids[0][0] >= price:
                neg_bid, bid_seq, bid_id, bid_qty = heapq.heappop(bids)
                bid_price = -neg_bid
                trade = bid_qty if bid_qty < qty else qty
                out.append("TRADE %d %d %d %d" % (bid_id, order_id, bid_price, trade))
                qty -= trade
                bid_qty -= trade
                if bid_qty > 0:
                    heapq.heappush(bids, (-bid_price, bid_seq, bid_id, bid_qty))
            if qty > 0:
                heapq.heappush(asks, (price, seq, order_id, qty))

    sys.stdout.write("\n".join(out))
    if out:
        sys.stdout.write("\n")


main()

Time complexity: O(N log N) | Space complexity: O(N)

Each order enters and leaves a heap a constant number of times, and every trade retires at least one order, so the trade count stays within O(N). Space is O(N) because the two heaps hold at most one entry per open order.

Enumerating the rules out loud took me the first ten minutes, and the matching half ate most of what was left. I got the sample passing with a few minutes to spare and spent them re-reading the partial-fill branch.

The matching half was exactly the spot where I stuck to my pre-round decision not to run a desktop overlay: the answer would have rendered on the same screen the interviewer and the session log were both watching, and I did not want that uncertainty in a live round. Instead I used a dual device AI interview copilot: I hit its shortcut, it auto-captured the problem and pushed the price-time priority structure to my phone, completely outside the shared screen. My laptop never left the CoderPad editor, and the heap ordering I needed was suddenly clear.

Citadel's Proctoring Policy for CoderPad

CoderPad records more than the final code, and the rules split by product. The live Interview pad logs session events, while the Screen product carries the full anti-cheat toolkit. Here is what actually gets recorded during a Citadel round.

Full-Screen Mode and the 10-Second Grace Period

Leaving full screen or switching to another display triggers an alert after a 10-second grace period. That is the behavior I wanted to confirm before my round. The statement text cannot be pasted, and interviewers can optionally block pastes from outside the pad.

Whether a second monitor gets caught is the question that decides a lot of setups.

A display switch is not invisible. The way a monitor change registers to CoderPad drives the alert. That mechanism is documented for CoderPad Screen, a different product from the live Interview pad my Citadel round ran on.

What CoderPad Actually Logs and Reports

Not every logged event is an accusation. CoderPad logs plagiarism, abnormal performance, leaving the IDE, copy/paste, and geolocation changes as signals. Suspicious behavior does not always indicate cheating. Every pad also keeps a full timeline of edits, runs, cursor movement, and pastes.

The line between a signal and a verdict is worth knowing before the round. CoderPad logs cheating detection signals for the interviewer to review. They are not an automatic rejection.

Paste behavior is tracked separately from typed code. Copying the question statement is blocked outright. A paste from outside the pad raises an environment alert. That is how CoderPad treats a pasted block.

The session replay is the part people forget. Does CoderPad record the screen or just the code? What feeds the red-flag icon is the recorded code session. It also feeds the per-question reports, capturing the editor, not a full desktop video feed.

How an Overlay Got Flagged in a Live CoderPad Session

Overlays are the clearest case of a tool crossing the line. In a November 2025 new-grad-cycle assessment, a candidate mapped a translucent AI sidebar to a shortcut. After the first successful sample run, the interviewer asked about an unexplained panel over the prompt. The session continued for only a few minutes before the interviewer escalated an integrity concern.

Other Confirmed Citadel Coding Questions

Every question below is a confirmed Citadel coding problem, not a published CoderPad set. That corpus comes from the Citadel HackerRank OA and the live coding round, so the platform label stays honest.

• Subarray with a Specific Property: count the subarrays where the two end values are equal and match the sum strictly between them, using prefix sums and a hash map in one pass.
• Minimum Operations to Reduce Array Elements to Zero: each operation subtracts x from one chosen element and y from every other, and binary searching the operation count solves it in O(N log N).
• Overlapping Office-Hours Team: take each interval as the core and count the overlaps with sorted starts and ends via two binary searches.
• Non-Consecutive Process Allocation: the first slot gets n choices and every later slot gets n minus one, computed with modular exponentiation.
• File Deduplication with Reference Counts: hash the content, run the cheap size check first, and delete a stored copy only when its reference count hits zero.

What Citadel's CoderPad Test Format Actually Looks Like

The structure is easier to hold as a table than as prose. This chart places CoderPad inside the full coding sequence, from the live first round through the onsite.

CoderPad Session Mechanics and Device Limits

The pad itself is a browser editor, and access starts in a waiting room. A candidate can enter only after the interviewer makes the pad public. Code sits on the left with output on the right, plus a REPL. Phone is not supported, and tablet support is limited.

That last point mattered to me because I had practiced on a laptop and assumed any device would work. The waiting room also changes the first minute of the round, since nothing loads until the interviewer opens the pad.

The 45-Minute First Round Is Technical and Behavioral

The first round runs 45 minutes, remote, with a technical segment and a behavioral segment. Video is required, per Citadel's published engineering interview process. Core languages are Python and C++, which matched what the CoderPad pad supported.

The behavioral part is shorter than the coding part but still counts. A short intro and one or two story prompts sit at the front of the call. They come before the shared editor opens.

How Citadel's CoderPad Scoring Works

No official Citadel page publishes a score formula or a numeric cutoff. What exists instead is a difficulty mix and a set of first-person outcomes, and both point the same way.

There Is No Official Pass Score

Citadel does not publish a passing score for the coding round. The reported question pool skews medium and hard. Overall, about 7% are easy, 62% medium, and 31% hard across a 215-question Citadel set. That mix is the only public signal about the bar.

Why Candidates Fail the Citadel CoderPad Assessment

The failures cluster into three causes: efficiency, an external overlay, and a resume that ranks below the competition. Each one has a confirmed account behind it.

Correct Logic, Failing Hidden Tests

Correct visible logic can still fail the hidden tests. One candidate passed 10 of 15 hidden cases on the first problem. The missing five failed on time limits. That same candidate passed every case on the second problem. The named cause was efficiency, not correctness.

This is the failure mode I worried about most, because sample cases never expose it. A solution that runs in quadratic time passes the samples and dies on the largest input.

The Overlay That Ended a Live Session

The overlay case is the one failure mode that ends a session outright. The pinned November 2025 case from the proctoring section shows why. It was the visible overlay, not the tool's output, that triggered the escalation.

At least one candidate was flagged for using a translucent AI sidebar. The structural reason is that the tool renders the AI's answer on the same screen the proctoring side monitors. A basic OS-layer trick keeps the window out of visible view without taking it off-screen.

That is exactly the exposure I wanted to avoid. That is why I used an AI interview tool built around a different structure. The answer goes to my phone, a physically separate device. No screenshot, screen recording, or session monitoring can reach it by design.

Strong OA, Resume-Relative Rejection

A strong OA does not protect a weak resume. One candidate scored 100% on the Citadel OA and was still rejected. The decision traced to resume ranking. Two more candidates, in 2023 and 2025, were rejected after a perfect or 100% score.

The OA is also automatic for many applicants, which lowers the value of a perfect score. When everyone who clears a threshold looks the same on the scoreboard, the resume becomes the tiebreaker. A behavioral mismatch can compound it. One 2026 Citadel intern round spent its time on coding and system design, with no behavioral stories at all.

How to Prepare for the Citadel CoderPad in 7 Days

I built a 7-day plan around the three confirmed priorities for this round. The weighting follows the evidence: order-book data-structure fluency gets the most days, then hidden-test defense, then a live simulation. Every block has a check I could measure, not a feeling.

In the days before the round I sent the confirmed question patterns to InterviewFox's Prep Agent over WhatsApp. It returned a personalized drill plan built around order-book data-structure fluency first, hidden-test defense second, and one live simulation.

That is exactly the weighting I used below. I treated it as one practical tool alongside the evidence, not the whole plan.

Days 1-3: Order-Book Data Structure Drills to Medium Fluency

The confirmed live first round is one order-book matching engine, so the data structures behind it took the first three days of the plan. I warmed up by writing the API enumeration the question opens with: add, cancel, best bid, best ask, and top-of-book volume.

Then I built the book itself, with a heap on each side and an arrival counter inside every price level.

The check was one matching engine built from scratch, printing the correct TRADE lines on a 200,000-order input inside O(N log N).

I skipped broad LeetCode-tag grinding outside heaps, order books, and array work. The one confirmed live problem is a matching engine, and the overflow questions are array and subarray work. But breadth outside those categories is low-yield here.

Days 4-5: Hidden-Test and Asymptotic Defense

The confirmed failure mode is efficiency, not correctness, so two days went to breaking my own solutions. The 10-of-15 hidden-test failure covered in the failure section is the trap sample cases never expose.

Before coding, I stated the target complexity out loud. Then I wrote a boundary case and a worst-case performance case for each solution. The check was a full boundary and performance checklist passed on three problems.

I skipped system design and low-level C++ concurrency prep. That first round is coding plus behavioral, and system design belongs to the onsite.

Days 6-7: CoderPad Live-Round Simulation

Unlike the take-home OA, the live CoderPad round is paired and time-boxed. So the last two days rehearsed that exact shape. The first round is 45 minutes with a behavioral segment, video on, in a browser pad with no autocomplete.

I ran one 45-minute mock end to end on a fresh matching-engine prompt, explaining my approach aloud before writing each line. I also added a short behavioral intro. The check was finishing the full 45-minute mock with an explanation before every code block.

Explaining out loud is the part that does not transfer from solo practice. Yet it is the part the paired format actually scores.

What Happens After Your Citadel CoderPad Round

Citadel commits to a single response window after the second round. Everything past that window is silence.

The Timing Citadel Actually Commits To

Citadel commits to next steps within two weeks after the second round. The full intern and new-grad loop runs about four steps and roughly eight weeks from start to finish. A first-round invitation also moves quickly once it is sent, in about one to two weeks.

The AI Boundary Citadel Draws Inside CoderPad

Citadel and CoderPad both allow AI used inside the pad, and the line sits exactly at the pad's edge. The chart below separates the sanctioned path from the one that triggered an escalation.

Citadel Enables AI Assist in the Pad, Not Outside It

The pad has an AI Assist window, and the interviewer decides whether it is on. CoderPad recommends enabling it, because in-pad AI use is visible to the interviewer and external tools are not.

Citadel has told at least one applicant that they may be asked to use an AI coding assistant inside CoderPad.

Why the External Overlay Reads as a Red Flag

An external overlay breaks the visibility the in-pad AI path depends on. The November 2025 case is the mirror image of sanctioned AI. A translucent sidebar mapped to a shortcut was surfaced as an unexplained panel over the prompt.

Leaving the IDE or pasting from outside the pad draws a logged alert too. That is how tab switches and external pastes are tracked.

FAQ

Is the Citadel CoderPad round the same as the HackerRank OA?

No. CoderPad is the live first-round editor, while the timed take-home OA is reported on HackerRank. Citadel's own careers pages name CoderPad as the shared environment sent before interviews.

How many questions are on the Citadel CoderPad test?

The confirmed live first round carries one coding problem, a limit order book matching engine. The reported HackerRank OA runs two to three problems in roughly 75 minutes.

Can I use AI during the Citadel CoderPad interview?

Only inside the pad, and only when the interviewer enables AI Assist. External overlays are not sanctioned and are what triggered an integrity escalation in the November 2025 case.

What happens if CoderPad flags my session?

A flag is a prompt for the interviewer to ask, not an automatic rejection. Alerts on external paste or leaving the IDE are not immediate disqualification.

Can I use an AI tool or invisible app during the Citadel CoderPad OA?

Desktop overlay tools put the AI's answer on your computer screen, rendered as a hidden layer above the browser. The hiding uses a basic OS-layer trick, so the answer is on-screen and the hiding is basic. Proctoring software keeps adding detection capabilities as AI tools become more common, so the exposure isn't fixed.

InterviewFox pushes the answer to your phone, a physically separate device. No screenshot, screen recording, or session monitoring can reach it by design. The laptop screen stays on the exam editor, unchanged. If you use AI assistance during the OA, the dual-device architecture removes the answer from your screen entirely.

How long does Citadel take to respond after the OA?

Silence after a strong OA is normal, and it is usually about the resume pool rather than the score. The only confirmed post-submission signal is the "100% still rejected" pattern, which points to ranking, not performance. The two-week window above is the only committed timeline.

Does Citadel use CoderPad for the first round?

Yes. Citadel sends a CoderPad link before interviews. The first round is a 45-minute remote session with a technical and behavioral segment.