This is a failure retrospective. I got Citadel's New Grad three-round back-to-back video interview, solved most of the problems, and still got rejected—not because of the algorithms, but because of communication. This article does not dwell on the problems (all three are covered briefly). Instead it zooms in on the round I blew: an unfamiliar original problem, a stone-cold interviewer, a tug-of-war over how the data should be represented, and 2h15m of nonstop rounds wearing down my judgment. If you are prepping for high-intensity back-to-back loops, I hope my mistakes save you one pitfall.
1. Interview Overview
| Dimension | Details |
|---|---|
| Entry | Cold apply, no referral, no OA; resume pulled straight into screening |
| Screening | 45 min, relaxed; project chat + a few behavioral questions + 1 backtracking problem |
| Main loop | Three rounds back-to-back, 2h15m total, no breaks in between |
| Round structure | Resume / behavioral first half, algorithm coding second half, ~45 min each |
| Platform | Citadel's own video + editor platform, clean UI, not HackerRank / CoderPad |
| Result | Rejection in 3-4 days |
Bottom line first: Citadel's process is fast, the technical bar is high, and the problems track real work (model design, system simulation, greedy). But what actually decides the outcome is whether you can pull an uncooperative interviewer into your line of reasoning under pressure.
2. The Three Problems (Briefly)
1. Screening: Permutation Equation (Backtracking)
Place digits 1-9 into three 3-digit numbers ABC, DEF, GHI with no repeats, and count how many satisfy ABC + DEF = GHI. Brute-forcing all 9! permutations is fine; passed easily, no need to expand.
2. Round 1: DMV Task Assignment (Load Balancing)
Each employee has a multiplier for speed (multiplier=2 means tasks take double time). Each task has a base duration (the standard time at multiplier=1). Employees work serially, tasks cannot be split, and you decide the assignment. Return the minimum total time to finish all tasks.
Classic load balancing: sort tasks by duration descending, keep a min-heap of each employee's accumulated finish time, and greedily hand the largest remaining task to the least-busy employee (multiplied by their multiplier). Got this one right.
import heapq
def min_time_to_finish(tasks, multipliers):
# tasks: list of base durations, one per task
# multipliers: speed multiplier per employee (larger = slower)
# heap holds (employee's accumulated finish time, that employee's multiplier), all start at 0
heap = [(0.0, m) for m in multipliers]
heapq.heapify(heap)
# Assign the largest tasks first so nothing gets stranded at the end
for dur in sorted(tasks, reverse=True):
finish, mult = heapq.heappop(heap)
finish += dur * mult # actual cost for this employee to do this task
heapq.heappush(heap, (finish, mult))
# The latest-finishing employee determines total completion time
return max(finish for finish, _ in heap)
if __name__ == "__main__":
# 3 tasks, 2 employees (multipliers 1 and 2)
print(min_time_to_finish([4, 2, 3], [1, 2])) # 6.0
Time complexity O(n log m) (n tasks, m employees); space complexity O(m).
3. Round 3: Character-Version Topological Sort
Given several character pairs (directed edges A->B) and a full character set, output any valid ordering that satisfies all precedence constraints (similar to Alien Dictionary).
Build the graph plus an in-degree table and run Kahn's algorithm (BFS). This interviewer was relaxed and we even discussed optimizations; a good experience.
from collections import deque, defaultdict
def valid_char_order(pairs, chars):
# pairs: [(a, b), ...] meaning a must come before b
# chars: the full character set
graph = defaultdict(list)
indeg = {c: 0 for c in chars}
for a, b in pairs: # a -> b
graph[a].append(b)
indeg[b] += 1
# Enqueue every character with in-degree 0 first
queue = deque(c for c in chars if indeg[c] == 0)
order = []
while queue:
c = queue.popleft()
order.append(c)
for nxt in graph[c]:
indeg[nxt] -= 1
if indeg[nxt] == 0:
queue.append(nxt)
# A short result means there is a cycle, so no valid ordering exists
return order if len(order) == len(chars) else []
if __name__ == "__main__":
pairs = [("a", "b"), ("b", "c"), ("a", "d")]
chars = ["a", "b", "c", "d"]
print(valid_char_order(pairs, chars)) # e.g. ['a', 'b', 'd', 'c']
Time complexity O(V+E); space complexity O(V+E).
3. The Round I Blew: What Actually Happened
Rounds 1 and 3 went smoothly; the problem was the middle one. On reflection, the failure was three things stacking up:
1) Unfamiliar problem, panic at the open. It was an original problem I had never seen, matching no familiar template. My mind went blank for a good half-minute—and by then over an hour of nonstop interviewing had passed, no break, so my judgment was already dulled. That opening fumble ate the time I would have needed later to debug.
2) Cold interviewer, zero cushion. The first two interviewers picked up on what I said and ran with it. This one was expressionless the whole time: no hints, no nudges. I would float an idea and get nothing back, so I could not tell whether my direction was right and had to power through alone.
3) A drawn-out standoff over data representation. My approach was actually viable—I wanted to store the state in one structure. But the interviewer insisted I switch to a different type. We went back and forth over the representation for a long time, and I finally caved to his type. After the switch, the type conversions got me tangled up, I introduced a logic bug, and by the time I spotted it there was no time left to debug.
Afterward I was nearly certain: my original approach would have run. The failure was not algorithmic ability; it was that I could not both hold onto a viable plan and get the interviewer willing to follow it.
4. Actionable Advice
Mapping each pitfall to a move you can use directly:
On an unfamiliar problem, think out loud—do not go silent. Half a minute of silence is a disaster with a cold interviewer; they just conclude you are stuck. Even restating the problem, listing inputs and outputs, or saying "let me get a brute force first, then optimize" keeps your thought process visible. Turn the panic into structured narration.
With a cold interviewer, manufacture your own feedback points. Do not wait for hints. After each step, pause and check: "I plan to store the state like this—does that direction seem OK to you?" Convert "he gives no feedback" into "I actively ask for it." An interviewer who volunteers nothing often gives a signal when you ask a direct question.
On a representation disagreement, ask for intent before deciding whether to switch. When the interviewer pushes a different type, do not rush to abandon your idea, but do not dig in either. Ask first: "What's driving your preference for this type—an extension you have in mind, or an interface constraint?" Once you understand the intent, either you realize he is right and switch with conviction, or you say "my structure can satisfy that too—can I write it my way, get it running, and then discuss?" The key is not to cave blindly before you understand the motivation. Switching blindly is more dangerous than holding your ground, because you end up writing logic against a representation you never thought through.
Reserve a debugging buffer. In a nonstop loop with tight timing, favor a plain solution and keep the last few minutes to run samples. A plain solution that actually runs beats an elegant one you never had time to verify.
One line to remember: in a loop like Citadel's, the algorithm is just the ticket in; whether you can walk an uncooperative person through your reasoning is the real dividing line.
5. Prep Advice for Back-to-Back Loops
- Simulate the real cadence. Get someone to run 2+ hours with you nonstop, no breaks, so you train judgment under fatigue instead of grinding each problem fresh and alert.
- Deliberately practice "cold interviewer + unseen problem." Have your partner withhold feedback on purpose and push back on your representation on purpose, so you build muscle memory for proactive check-ins and standing your ground.
- Prepare communication scripts. "Let me restate the problem," "I plan to store it like this—does the direction look OK?", "What's driving your preference for this type?"—drill these until they come out automatically, because that is the only way they show up under pressure.
- Do not wing the behaviorals. Every round opens with resume / behavioral questions; have "Why Citadel" and "which project taught you the most" ready in advance.
FAQ
Q1: Does Citadel New Grad always require an OA?
Not necessarily. Mine was a cold apply with no referral and no OA; my resume was pulled straight into a screening call. They seem to pick a batch off resumes and drop them directly into the pipeline, so resume quality matters a lot.
Q2: How draining is three rounds back-to-back?
Three rounds, 2h15m total, with zero breaks in between and ~45 min each (behavioral first half, coding second half). The hard part is not any single problem—it is the decline in judgment and communication patience by rounds two and three. The round I blew landed right when my energy and focus were starting to drop.
Q3: Why exactly did round two fail—was it that you could not do the algorithm?
No. I had the right overall direction, and I later confirmed the approach would run. The failure was: an unfamiliar problem caused an opening panic, the interviewer stayed cold and gave no feedback, and we stalled too long on data representation. After caving on the type, the conversions tangled me up, I introduced a logic bug, and ran out of time to debug. It was communication and in-the-moment handling, not algorithms.
Q4: What do you do when the interviewer insists on a different data representation?
Do not rush to abandon your own idea. Ask why they prefer that type (extensibility? interface constraint?), and once you understand the intent, decide: either switch with conviction, or explain that your structure also meets the need and ask to get it running your way first, then discuss. The worst move is caving blindly before you understand the motivation and then writing logic against a representation you never thought through.
Q5: What kinds of problems does Citadel lean toward?
Close to real work—model design, system simulation, greedy strategies, like the DMV task-assignment load balancing. There are also more standard ones like character-version topological sort and permutation backtracking. The technical bar is high overall, but the outcome often comes down to in-the-moment communication.
Prepping for a Citadel New Grad loop?
Citadel's three-round back-to-back is intense and fast-paced, and beyond the algorithms, the in-the-moment scenarios—cold interviewer, unseen-problem standoff, representation disagreement—are where people trip up. If you want a high-pressure mock run at the real loop cadence, and to drill proactive check-ins, standing your ground, and compromise scripts, let's talk: send the job JD, we predict the problem types first, then lay out a back-to-back practice plan.
Add WeChat Coding0201 now, get a Citadel loop practice plan.
Contact
- WeChat: Coding0201
- Email: [email protected]
- Telegram: @OAVOProxy