Citadel HackerRank OA Interview Experience (2026) - Server Upgrade Binary Search & MEX Valid Sizes, Offer

• Available for server 1: seconds that are not multiples of `req1`. Count = `x - x // req1`.
• Available for server 2: seconds that are not multiples of `req2`. Count = `x - x // req2`.
• Seconds usable for *either*: `x - gcd_only_count`, specifically, seconds that are not a multiple of both (multiples of `lcm(req1, req2)` are unusable for either). Count = `x - x // lcm(req1, req2)`.

So feasibility is: pick t1 slots from the server-1-eligible set, pick t2 slots from the server-2-eligible set, the picks are disjoint.

By Hall's condition the feasibility check reduces to three inequalities comparing t1 against server-1-only slots plus shared slots, t2 against server-2-only plus shared, and the total demand against total available slots. The "only-1", "only-2", and "both" counts in the window of length x all decompose through x//req1 , x//req2 , and x//lcm(req1, req2) via inclusion-exclusion.

Binary search x between max(t1, t2) and a safe upper bound like 4 (t1 + t2 + max(req1, req2)) . Logarithmic in the upper bound. Fast.

Ran on the provided sample: t1=3, r1=2, t2=1, r2=3 returns 5. Matches.

Practice it: [[problem/188?company=33|Process Scheduling (No Consecutive)]]

Problem 2: Memory Block Valid Sizes via MEX

Problem: You have n memory blocks. memoryBlocks[i] is the size of block i . You can perform at most one operation: pick an index x and increment memoryBlocks[x] by 1, but only if the current value is strictly less than n - 1 . After the optional operation, the "valid size" of the configuration is the MEX (minimum excludant) of the array. Return all possible valid sizes you can achieve, sorted ascending.

I want the set of all achievable MEX values across the choice of "do nothing" or "increment exactly one eligible index."

Observation 1: if I do nothing, the MEX is some fixed value m0 . That is one achievable value.

Observation 2: incrementing index x changes the multiset. Specifically, it removes one copy of memoryBlocks[x] and adds one copy of memoryBlocks[x] + 1 . The resulting MEX depends on whether the removed value was unique in the array and whether adding the new value fills the MEX gap.

The clean way to compute this: use a frequency map. Compute the baseline MEX. Then for each possible value v in the array (group indices by value), simulate removing one copy of v and adding one copy of v + 1 , and recompute the MEX. Collect all results in a set.

Naive MEX recomputation is O(n), so total work is O(n distinct values) worst case, which at n = 10^5 is fine. Walk the set of distinct values, skip any value at or above n - 1 , temporarily mutate the frequency map, recompute MEX, then restore. Collect all MEX values into a set and return them sorted.

For n=3, blocks=[0, 3, 4] : baseline MEX is 1 (0 present, 1 missing). Incrementing the 0 to 1 gives multiset {1, 3, 4}, MEX = 0. Result set is {0, 1} which matches the expected [0, 1].

For tighter runtime, maintain a pointer to the current MEX and update it lazily under each single mutation, bringing the inner work to amortized O(1) per try.

Practice it: [[problem/186?company=33|Knight Dialer]]

Why I Think the OA Felt Easy

Two hypotheses:

1. The pool rotates. The tree-DP flavored problems I saw other candidates post about last cycle (server-upgrade-in-a-tree, partition MEX over an array) are harder variants of the exact themes I got. Citadel may be draining easier pool items to fill in the season and saving the hard pool for mid-cycle.
2. The bar is on Super Day, not the OA. Citadel famously has a tough Super Day. The OA might be tuned to filter only the bottom tier (syntax errors, wrong algorithm entirely) while the real evaluation happens live.

Either way, do not coast. My Super Day had one problem that felt like a hard HackerRank problem squeezed into 25 minutes, and I had to code it cold without partial-credit feedback.

Result

Got a Citadel Securities SDE new-grad offer about 5 business days after Super Day. NYC. The comp was higher than any FAANG offer in my cycle, which is typical for them.

Tips

1. Binary-search-on-answer is Citadel's favorite pattern. If a problem asks "minimum time / minimum resource," try to phrase feasibility at a fixed answer first and binary search. Problem 1 here is a textbook instance; the scheduling-by-multiples twist is just flavor.
2. MEX problems reward clean frequency-map code. Do not try to avoid the Counter. Just use it, compute MEX by linear scan from 0, and the problem usually collapses.
3. Read HackerRank problem statements twice. Citadel's wording is dense because they want to see if you can strip out irrelevant flavor. The server problem spends three paragraphs on "request seconds" when the real constraint is just "certain seconds are unusable." Strip the noise first.
4. Keep the browser tab focused. HackerRank has proctoring signals that track tab switches. If you need to check LeetCode or Stack Overflow, flip your phone instead and keep the main browser untouched.
5. Budget 35 minutes per problem, not 37.5. The extra 5 minutes of buffer is for submission failures. I had a test case that timed out on the remote judge because my Python was 100ms too slow, and I had to switch to PyPy-style optimizations. That buffer saved me.
6. For Super Day prep, do not just practice more LeetCode. Do Codeforces Div 2 problems B, C, D. That difficulty curve is closer to the Super Day coding bar than LeetCode medium is. Also brush up on expected-value math because at least one problem tends to have a probability twist.

Citadel's OA this season was easy. Super Day was not. Make sure you put the time budget where it matters.