Citadel Software Engineer Interview Experience (2026) - HackerRank OA with Server Upgrade & MEX, Rejected

Problem 1: Minimum Total Time to Upgrade Two Servers

Problem: Two servers need to be upgraded. Server 1 needs T1 seconds of upgrade work, server 2 needs T2 seconds. At every integer second, at most one server can be upgraded. Server 1 receives requests at every second that is a multiple of Req1 (upgrades are forbidden at those seconds). Server 2 receives requests at every multiple of Req2 . Return the minimum total elapsed seconds to finish both upgrades. Idle seconds are allowed.

I parsed this as a binary-search-on-answer problem. For a candidate elapsed time x , the set of seconds from 1 to x splits into four buckets: usable only by server 1, usable only by server 2, usable by either, and usable by neither. Count each bucket using x // Req k style inclusion-exclusion, then check whether the single-server buckets each cover their target and the shared bucket is large enough to fill the rest. Binary search the smallest feasible x .

That works, and I got full credit on the visible tests. The hidden tests that I suspect tripped me up were the cases where Req1 == Req2 : in that case there is no shared-usable bucket and the two servers contend for exactly the non-multiple seconds. My code handled this case, but my inclusion-exclusion set up gcd(Req1, Req2) as a straight gcd call without checking for the degenerate case Req1 == 1 , which would mean no seconds are usable at all for server 1. If the grader tested Req1 = 1 , I returned a feasible x when the correct answer is "impossible." That is a plausible hidden-test failure.

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

Problem 2: Memory Block MEX After At Most One Increment

Problem: You have N memory blocks, with the i -th block of size MemoryBlocks[i] . You can do at most one operation: pick an index x and increment MemoryBlocks[x] by one, provided MemoryBlocks[x] < N - 1 . After the operation, the MEX (minimum non-negative integer missing from the array) is the "effective size." Return all possible effective sizes in ascending order.

My approach: count the frequency of each value from 0 to N-1, then scan from value 0 upward. Track how many "operation credits" I have (starts at 1). Whenever the count of value v is zero but the count of value v-1 is at least 2, I can spend my one operation to bump a v-1 up to v and continue. Record v as an achievable MEX whenever the scan reaches v having used at most one operation. Also record the current MEX without using any operation.

I think I got this one roughly right and I am fairly sure all test cases passed. But here is what I am less sure about: the spec says "at most one operation," which means "zero or one." I only recorded the zero-operation MEX and one-operation MEX cases. I never considered that operating on a specific index could produce a MEX that is lower than the no-op MEX, which is counterintuitive but possible if the increment creates a duplicate that crowds out a previously-unique small value. I did not enumerate the MEX that results from every individual index choice. That could have been a coverage gap on a tricky hidden test.

Result

Rejection email, no interviewer feedback. Standard Citadel boilerplate. Looking at my notes again, I think the binary-search setup on problem 1 had an edge case failure and my MEX enumeration on problem 2 was not exhaustive. Citadel OA grades on "hidden tests passed," and missing a single tricky case drops your score below the onsite cutoff even if your visible tests all pass.

Tips

1. On the server upgrade problem, test `Req1 == 1` and `Req2 == 1` explicitly. If a server gets a request every second, it can never be upgraded. Your solution must detect and return the correct "impossible" sentinel or propagate infeasibility to the binary-search upper bound. This is the most likely hidden test.
2. For the MEX problem, enumerate operation targets, do not just toggle the credit. The cleanest solve treats each possible operation index (or each possible value-to-bump) as a case and unions all resulting MEX values with the no-op MEX. A greedy single-credit scan misses cases where the operation actually hurts the MEX.
3. On Citadel's 75-minute OA, do not be fooled by finishing in 10 minutes. Citadel grades on hidden tests, and easy-looking problems are easy because the grading is hiding in the edge cases. Spend the remaining time stress testing with tiny randomized inputs and the boundary values of the constraints. I did not, and that is probably why I got cut.
4. Write your own test cases targeting stated constraint bounds. The problem specs say things like `1 <= Req <= N`. That means Req could be exactly 1 or exactly N. Run your solution on those boundary values before submitting. Hidden tests at Citadel specifically target the exact boundaries.
5. The HackerRank variant and the CodeSignal variant have different pools. If your invite is for HackerRank, drill server-scheduling, MEX, and interval-merge problems. If it is CodeSignal, drill tree DP and array partition. Ask your recruiter which platform you will be tested on.
6. Do not assume problem 2 is always "at most one operation means zero or one." Read carefully. Some variants allow up to `k` operations. My OA was "at most one," but a friend's was "at most two," and the friend who assumed the solution template was the same as mine ate a failed submission. Re-read the constraints every time.

Citadel's HackerRank OA is the kind where finishing fast can actually hurt you. The grader is looking for candidates who stress-test their own work. If I had used my last thirty minutes to stress test instead of scrolling my phone, I might be writing a different post right now.