Citadel SDE onboarding and first 90 days tips 2026

The first 90 days as a Citadel SDE are not about coding volume — they’re about judgment alignment. New hires who succeed fast don’t optimize for output; they optimize for visibility into decision-making hierarchies. The onboarding period is a stealth evaluation of risk calibration, not technical ram

Title: Citadel SDE Onboarding and First 90 Days Tips 2026

TL;DR

Who This Is For

This is for new graduate and mid-level software engineers who have accepted a full-time SDE role at Citadel LLC in Chicago, New York, or London in 2026. You’ve passed 3–5 interview rounds, including a system design deep dive and live coding with a trading desk engineer. You earn $180K–$320K total comp, depending on level and location. You need to survive — and signal competence during — the unspoken evaluation window embedded in onboarding.

What does the Citadel SDE onboarding process look like in 2026?

Onboarding lasts 21 business days and includes 12 required compliance trainings, 4 technical bootcamp sessions, and 3 desk rotations. The process is not designed to teach you to code — it’s designed to stress-test your risk threshold. In a Q3 2025 debrief, a hiring manager killed an offer after day 18 because the candidate asked “Can I push this to prod without review?” during a sandbox exercise.

Citadel’s onboarding is a filter. It rewards precision over speed. You’ll be assigned a shadowing schedule across three desks: equities, futures, and clearing. Each rotation lasts 3 days. You’re not expected to contribute code — you’re expected to ask questions that reveal your grasp of operational risk.

Not all training is technical. Six sessions are SEC, CFTC, and MiFID II compliance deep dives. Fail one quiz, and you trigger a compliance hold — which delays your system access by 5–7 days. That delay gets logged. It doesn’t kill your hire status, but it downgrades your “execution readiness” score in the HRIS.

One insight from a 2025 HC meeting: candidates who annotated their compliance materials with margin notes citing rule sections scored higher on “procedural diligence” than those who aced the quizzes but showed no evidence of engagement.

The technical bootcamp covers low-latency primitives, not frameworks. You’ll learn how Citadel’s in-house messaging layer handles 500K messages/sec with sub-5-microsecond end-to-end latency. You won’t touch Kafka or RabbitMQ. You’ll debug a simulated order routing failure in C++ and Python, but the grading rubric focuses on how you document the incident — not whether you fix it.

Judgment signal > technical signal. Always.

How should I prepare technically before my first day?

Master memory hierarchy behavior, not LeetCode patterns. Citadel’s production issues rarely stem from algorithmic inefficiency — they stem from cache misses, false sharing, and syscall overhead. In a 2024 incident review, a 17-microsecond latency spike on the options desk was traced to a single misaligned struct padding in a shared library.

You don’t need to know Citadel’s stack yet — but you must understand how latency propagates through layers. Study NUMA architecture, CPU affinity, and how the kernel handles interrupts. Read Intel’s optimization manuals. Work through at least one case study on false sharing — it came up in 3 separate onboarding assessments in 2025.

Not whiteboard practice, but systems intuition. Not clean code, but deterministic behavior.

One new hire in 2025 stood out not because they coded fast — but because they said, “This function calls gettimeofday() — is that synchronized across cores?” That question triggered a follow-up meeting with the infra lead. The hire was fast-tracked to a core latency team.

Prepare by running microbenchmarks on your laptop. Measure the cost of a mutex, a cache line bounce, a page fault. Learn to read perf output. Understand what “IPC” means in practice, not just acronym form.

Most new SDEs waste prep time grinding dynamic programming. The real test is whether you flinch when you see a memory barrier in code.

Work through a structured preparation system (the PM Interview Playbook covers low-latency systems with real debrief examples from Citadel and HRT).

How do Citadel teams evaluate new SDEs during the first 90 days?

Evaluation is continuous, silent, and multi-threaded. There is no formal probation period — but your first 90 days are a de facto trial. Risk, reliability, and judgment are scored weekly by your manager and two peers in the HRIS.

You are not evaluated on lines of code or tickets closed. In a 2024 HC review, a new hire who pushed 37 commits in week two was flagged for “operational impulsivity.” Another who made zero commits but wrote a 5-page postmortem on a staging incident was labeled “high signal.”

Three dimensions are tracked:

Risk containment: Did you escalate appropriately? One hire delayed a fix for 48 hours because they weren’t sure about the trade surveillance implications. That delay was praised in the debrief.
System understanding: Can you explain why a change might fail in prod — not just how it works in dev?
Communication fidelity: Are your runbooks, PR descriptions, and incident reports precise enough that someone else can act without talking to you?

Not productivity, but predictability. Not innovation, but adherence.

In a Q2 2025 debrief, a manager argued to terminate a hire who built an elegant config management tool — but bypassed the change approval board. The tool worked perfectly. The hire was still let go. The verdict: “We don’t need smart people who break protocol. We need reliable people who follow it.”

You will be given access to production-adjacent systems in week 3. Your first task will likely be to read logs, not write code. Do it slowly. Take notes. Ask for context. That behavior is scored.

> 📖 Related: Citadel TPM system design interview guide 2026

What cultural norms do I need to internalize as a new Citadel SDE?

Speak less. Write more. Assume all verbal communication is lost. Assume all written communication is archived.

In a 2025 postmortem, a verbal handoff during a shift change led to a misrouted order batch. The engineer wasn’t fired — but a new policy was created: all shift handoffs require a written summary in Confluence with timestamps and checksums.

Not informality, but formality. Not agility, but auditability.

Hierarchy is rigid. You will not “skip levels” — and attempting to do so is a career-terminating move. If you have a concern about a production issue, go through your manager. One junior SDE in 2024 emailed a VP directly about a latency spike. The SDE was reassigned to a non-trading desk the next week. The VP never replied — but the manager was informed.

Titles matter. “Software Engineer” vs. “Quantitative Developer” vs. “Trading Strategist” — each has defined boundaries. Crossing them without approval is a red flag.

One unspoken norm: never imply that another desk is misusing resources. During a resource allocation meeting in 2025, a new hire suggested the energy futures desk was “over-provisioning.” The comment was logged. Two weeks later, the hire was moved to a back-office team.

Socializing is optional. Performance is mandatory. You don’t need to go to happy hours — but you must respond to pages within 90 seconds during on-call rotations, which start in week 6.

You are not here to “disrupt” or “innovate.” You are here to maintain and extend a system that moves billions daily. The culture rewards caution, not charisma.

How much time should I spend learning the business side?

Spend 30% of your first 30 days learning the financial context of your desk. Not finance theory — desk-specific mechanics.

If you’re on equities, understand order types: IOC, FOK, mid-point peg, hidden liquidity. Know what a “sweep” is and when it’s used. Know the difference between ATS and exchange liquidity.

If you’re on futures, learn contract rollover mechanics, mark-to-market settlement, and how margin calls propagate through clearinghouses.

One hire in 2025 impressed their manager not by optimizing a matching engine — but by asking, “Does this order have agency or principal risk?” That question signaled business-aware engineering.

Not abstract knowledge, but applied context.

In a Q1 2025 review, a new SDE fixed a data feed parser bug — but didn’t realize the feed was used for SEC reporting. The fix altered timestamp precision and created a regulatory gap. The SDE wasn’t fired — but was required to attend three compliance remediation sessions.

Another SDE, same month, asked during code review: “Is this field used in Form ATS reporting?” The answer was yes. The bug was caught pre-deploy. That SDE was given a high-visibility incident response role in week five.

You don’t need an MBA. You need to speak the language of risk, not returns.

Spending time on Investopedia or Khan Academy is a waste. Read internal wikis. Attend optional desk walkthroughs. Sit through pre-market briefings — even if they seem irrelevant.

The fastest way to build credibility is to understand why a system exists — not just how it works.

Preparation Checklist

Complete all pre-onboarding paperwork 7 days early to avoid access delays
Set up a second monitor and mechanical keyboard — latency awareness starts with ergonomics
Install and learn Citadel’s internal logging and monitoring tools (you’ll get access on day one)
Run latency microbenchmarks on your personal machine to internalize performance baselines
Review Intel’s Software Developer Manual Volume 3 (focus on memory ordering and cache control)
Work through a structured preparation system (the PM Interview Playbook covers low-latency systems with real debrief examples from Citadel and HRT)
Study your desk’s last three incident postmortems — they’re in the internal wiki

Mistakes to Avoid

BAD: Pushing code to staging without a peer review — even if it’s a one-line config change. In 2025, a new hire did this to “save time.” They were pulled from the trading desk rotation and assigned to document legacy systems for six weeks.

GOOD: Opening a draft PR with “Needs review before merge” in the title, even if you’re not ready. This signals process awareness. One hire did this on day four — their manager noted it in the first-week feedback.

BAD: Saying “This shouldn’t break anything” in a code review. At Citadel, that phrase is treated as a guarantee — and guarantees without proof are malpractice.

GOOD: Saying “I’ve tested this under load up to 10K RPS; beyond that, we’d need to validate memory pressure.” That’s specific, bounded, and responsible.

BAD: Asking “Why do we do it this way?” in a team meeting. It implies the process is flawed.

GOOD: Asking “Can you help me understand the history behind this decision?” That shows respect for institutional knowledge. One new hire used this exact phrasing in 2025 — it was cited in their positive 30-day review.

FAQ

What happens if I make a production mistake during onboarding?

You won’t be fired for honest errors — but only if you escalate immediately, document fully, and don’t speculate. In 2024, a new SDE introduced a memory leak in a non-critical service. They paged the on-call lead, wrote a root cause analysis within two hours, and proposed a fix. They passed onboarding. Concealment, not failure, is the firing offense.

Is on-call required in the first 90 days?

Yes. You’ll start shadowing on-call in week four and take primary rotation in week six. The first incident you handle will be low-severity — but your response time, communication clarity, and escalation judgment are scored. In 2025, one hire took 12 minutes to respond to a page. They were moved to a non-critical path team.

How much autonomy do new SDEs have?

Minimal. You don’t own services — you assist owners. You don’t design systems — you implement under close supervision. Autonomy is earned over 12–18 months, not given. In a 2025 HC meeting, a manager said, “We hire for judgment, not independence. Independence without judgment is catastrophic.”

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.