Citadel HackerRank: SWE OA Preparation and Original Practice

To prepare for a Citadel HackerRank software engineering assessment, practice turning a precise problem statement into an efficient algorithm, then test the boundaries that sample cases miss. Start with your invitation: it determines your assessment's duration, question count, languages, and rules. Online reports can suggest useful practice, but they cannot specify your test.

This guide is for SWE internship and new-graduate applicants. It includes two original teaching exercises, complete Python solutions, and a study plan you can adapt to the time available. These exercises are independently created practice, not Citadel questions or predictions of your assessment.

Research note — October 23, 2026: This AI-assisted guide uses official engineering guidance, HackerRank documentation, and a labeled historical candidate report. The original practice code was checked against brute-force oracles; we did not take a Citadel assessment. SkillCopilotAI offers a preparation product and is not affiliated with Citadel or HackerRank. The cover is an AI-generated editorial illustration.

What is confirmed about the Citadel online assessment?

The useful distinction is between an employer's published interview guidance and a candidate's account of one assessment.

For historical context, an anonymous LeetCode account about a Summer 2025 software developer assessment describes two HackerRank problems involving prefix sums with hashing and a binary-search approach. It is one applicant's report from an earlier cycle, not an official syllabus or evidence that those prompts will recur.

HackerRank's candidate introduction explains where to review duration and the test format before starting, and provides a sample test. Use that sample to check the editor, input/output handling, and submission flow before your real sitting. Use the platform checklist first, then return to the employer-specific preparation below.

Before starting: check your invitation

Write down these details before beginning the timed assessment:

Use the instructions supplied for your assessment to complete this checklist. Resolve any ambiguity with the recruiting or support contact before starting.

Keep SWE preparation separate from quant preparation

A trading, quantitative research, or competition write-up may describe a different task and recruiting route. If your application says software engineer, prioritize coding preparation and the engineering expectations attached to that role. If it says quantitative researcher or trader, confirm the relevant materials with recruiting before borrowing a SWE timetable.

Citadel's engineering FAQ emphasizes data structures, algorithms, engineering judgment, and explaining trade-offs. Those are useful preparation goals. They do not establish a frequency ranking of OA topics.

How to choose useful practice

Build a small set of problems that forces you to explain four things: the input contract, the invariant or state, the complexity, and a counterexample to a tempting wrong solution.

Use this menu to identify your weakest reasoning step. The two worked exercises below focus on the algorithmic fundamentals and explanation of trade-offs emphasized in Citadel's engineering guidance:

• Request-pair counting tests whether you can turn a precise time boundary into a data structure and justify an efficient scan.
• Constrained sequences tests whether you can define a complete state, derive transitions, and check a counting argument independently.

These are transferable engineering skills, not measured Citadel topic frequencies. Include prefix-sum/hash-map and monotonic-feasibility practice alongside them if you want to explore the approaches mentioned in the historical candidate report.

Original exercise 1: count nearby requests by service

Task. You receive a list of (service, timestamp) events in nondecreasing timestamp order. Count pairs of distinct event positions (i, j) where i < j, the services match, and 0 <= timestamp[j] - timestamp[i] < W. Return the total across all services.

Assume 0 <= n <= 100,000, integer timestamps from 0 to 10^9, and integer W >= 1. Equal timestamps are allowed and represent separate requests. Events are already sorted globally; do not silently sort an unsorted variant without accounting for the extra cost.

For these events with W = 5:

(A, 1), (B, 2), (A, 4), (A, 6), (B, 6)

The answer is 3: the A pairs (1, 4) and (4, 6), and the B pair (2, 6). The A pair (1, 6) is excluded because its gap equals 5. We are counting request pairs, not accepting or dropping requests.

Original teaching diagram. At current time 6, earlier requests must lie in (1, 6]; the current event itself is not an earlier request.

Reasoning and reference solution

Keep a timestamp list and a left pointer for each service. At current time t, discard earlier timestamps at or before t - W. Every remaining earlier timestamp for that service forms exactly one pair with the current event. Count them before appending the current event.

from collections import defaultdict


def request_pairs(events, window):
    recent = defaultdict(list)
    left = defaultdict(int)
    pairs = 0

    for service, timestamp in events:
        times = recent[service]
        i = left[service]
        while i < len(times) and times[i] <= timestamp - window:
            i += 1
        left[service] = i
        pairs += len(times) - i
        times.append(timestamp)

    return pairs

Why it works: sorted input makes each service's timestamp list sorted. Once an old event fails the window boundary, it cannot become eligible for a later event. Each valid pair is counted exactly once, when its later position is processed. Interleaving services does not change that invariant.

Complexity: expected O(n) time with hash-map operations and amortized list appends, and O(n) space. Although there is a nested while, each left pointer advances over each stored event at most once. This implementation retains expired entries; it does not claim memory is bounded by the active window.

Try to break it

For C++ or Java, use a sufficiently wide type for the total. A useful follow-up is to replace retained lists with active queues, then explain how space depends on the number of retained events and service keys. Another is to remove the sorted-input guarantee and identify what must change.

Original exercise 2: count sequences that use a special label

Task. There are n labels numbered 0 through n-1. Count length-m sequences where adjacent labels differ and label 0 appears at least once. Return the result modulo 1,000,000,007.

Assume 2 <= n <= 100,000 and 0 <= m <= 100,000. The empty sequence has not used label 0, so its answer is 0. A label can reappear after a different label; adjacent inequality does not mean every label can appear only once.

For n=3, m=3, the answer is 10. There are 12 adjacent-distinct sequences in total. Exactly two, 121 and 212, never use label 0, leaving 10 valid sequences. For n=2, m=3, only 010 and 101 qualify, giving 2.

Original teaching diagram. State counts below aggregate whole groups of sequences, not individual final labels.

Derive the state before writing code

After building a nonempty prefix, maintain:

• unseen: prefixes that have never used 0.
• special: prefixes ending in 0.
• ordinary: prefixes that have used 0 and end in another label.

At length 1, these counts are n-1, 1, and 0. To append one label:

• An unseen prefix stays unseen in n-2 ways: exclude 0 and its current last label.
• A prefix ending in 0 can only follow an ordinary prefix or an unseen prefix. The unseen contribution must be included here.
• A seen prefix ending in an ordinary label comes from a special prefix in n-1 ways, or an ordinary prefix in n-2 ways.

That gives the following implementation:

MOD = 1_000_000_007


def special_sequences(n, m):
    if m == 0:
        return 0

    unseen, special, ordinary = n - 1, 1, 0
    for _ in range(1, m):
        unseen, special, ordinary = (
            unseen * (n - 2) % MOD,
            (ordinary + unseen) % MOD,
            (special * (n - 1) + ordinary * (n - 2)) % MOD,
        )
    return (special + ordinary) % MOD

Each new state uses the previous three values. Python's simultaneous assignment preserves this; sequentially overwriting them can corrupt the transition.

Why it works: the three groups are disjoint and cover every adjacent-distinct prefix. Each allowed appended label enters exactly one new group. Summing special and ordinary selects precisely the sequences that have used 0.

Complexity: O(m) time and O(1) auxiliary space for the stated bounds. As a follow-up, count all adjacent-distinct sequences and subtract those formed using only the other n-1 labels. Handle length 0 separately rather than relying on an ambiguous empty-sequence convention.

Test the recurrence

Check (n,m) = (3,0) -> 0, (3,1) -> 1, (2,2) -> 2, and (3,3) -> 10. For tiny inputs, enumerate every length-m sequence, reject equal adjacent labels, and check whether 0 appears. That independent oracle catches misplaced state contributions that a few ordinary examples may miss.

The reference implementations passed 2,532 small-case oracle comparisons, the examples, and 100,000-scale checks. To reproduce the sequence-checking method, compare special_sequences(n, m) with this exhaustive version for tiny inputs such as n=2..4, m=0..6:

from itertools import product


def brute_special_sequences(n, m):
    return sum(
        0 in seq and all(a != b for a, b in zip(seq, seq[1:]))
        for seq in product(range(n), repeat=m)
    )

Enumeration grows exponentially, so use it only as a small-input oracle. For request pairs, the corresponding oracle checks every earlier/later position pair directly against the service and time-gap rules.

A focused five-session preparation plan

Use these sessions as a sequence, adjusting their length to your deadline and baseline ability.

1. Diagnose. Attempt two unseen algorithm problems under one timer. Record whether lost time came from reading, finding the approach, coding, or debugging.
2. Repair window and counting mistakes. Solve exercise 1 without the reference. Change the boundary from < W to <= W, then explain the one condition that changes.
3. Practice state design. Solve exercise 2 from the state definitions. Compare it with the subtraction approach and test both on tiny inputs.
4. Broaden one weak area. Choose a graph, interval, or binary-search problem. Write its invariant and complexity before implementation; avoid spending the session only rereading solutions.
5. Simulate and explain. Use unseen questions with the duration and rules shown in your invitation. Afterward, explain one solution aloud and revisit every failed case.

For an illustrative 75-minute practice session, reserve 5 minutes to scan both problems, 25 for a first complete solution, 30 for the other problem, and 15 for tests and submission checks. This is a suggested training budget, not a Citadel assessment specification. Scale it to the actual timer and reconsider the order if a problem is consuming time without a workable approach.

Before submitting, check output format, boundary equality, duplicates, integer range, memory, and the largest source of repeated work. Passing samples should trigger a search for counterexamples, not an assumption that all hidden tests pass.

Prepare for the engineering interviews after the OA

Citadel's published campus engineering process describes a 45-minute first interview combining technical and behavioral discussion, usually three 45-minute second-round interviews, and later team or leadership consideration. This is published campus guidance, not a promise about your route or an OA response deadline.

Alongside algorithms, prepare a project explanation: what you built, a design trade-off, how you found a bug, and what you would change. Practice asking a clarifying question and explaining a failed approach constructively. Follow the next steps in recruiting communications rather than treating a forum's timeline as a deadline.

Frequently asked questions

How hard is the Citadel HackerRank?

Difficulty varies by role, cycle, and individual strengths. Public reports describe algorithmic problems under time pressure, but no uniform official difficulty scale was established here. A useful readiness check is whether you can derive an efficient solution to an unseen problem and defend its edge cases without hints.

What should I do if I only have one day to prepare?

First complete the invitation checklist and try the platform's sample test. Use one short diagnostic to identify whether reading, algorithm choice, or implementation is your main bottleneck. Work on that weakness, then attempt unseen problems under your actual assessment's timer. Finish by reviewing failed cases and checking your equipment; avoid spending the whole day memorizing solutions.

Why do samples pass while hidden tests fail?

Look for a mismatch between the specification and your assumptions. Check equal values, exact window boundaries, empty or minimal inputs, integer range, and maximum-size performance. In exercise 1, a gap equal to W must be excluded. In exercise 2, using a newly updated state too early changes the recurrence. Build a tiny counterexample or compare against a brute-force oracle before changing the algorithm.

Can I use AI during the assessment?

Read the rules for that assessment and use only permitted resources. An assistant can help generate practice variants or critique explanations beforehand; that does not establish permission to use it during a timed employer test. Ask recruiting if the instructions are unclear.

Are these actual Citadel HackerRank questions?

No. They are original teaching exercises chosen to practice precise specifications, algorithm design, and adversarial testing. The candidate report linked above is labeled separately and does not establish future question reuse.

Continue preparing

Use the general HackerRank preparation guide for platform-wide question types and setup. If you are also interviewing elsewhere, our Microsoft HackerRank guide provides a separate employer context, while the CodeSignal OA guide covers a different assessment platform.