Fidelity SDE onboarding and first 90 days tips 2026

Fidelity SDE Onboarding and First 90 Days Tips 2026

Target keyword: Fidelity onboarding sde

TL;DR

The first 90 days at Fidelity for a Software Development Engineer are a sprint, not a marathon: hit the mandatory “Infrastructure Bootcamp” in the first two weeks, deliver a scoped “Impact Project” by day 45, and secure a cross‑team mentor by day 60. Judgment: treat the onboarding curriculum as a performance benchmark, not a courtesy tour.

Who This Is For

You are an incoming SDE—either a new graduate hired through Fidelity’s Campus program or a mid‑level hire from a competitor—who has accepted the offer and is staring at the onboarding portal. You have a technical background, understand Agile, and need concrete, battle‑tested tactics to convert Fidelity’s structured onboarding into early career momentum rather than a series of check‑boxes.

How long does the Fidelity SDE onboarding program actually last?

The official timeline is 90 calendar days, broken into three distinct phases. In the first 14 days you complete “Infrastructure Bootcamp,” a series‑controlled series of labs on mainframe connectivity, data‑mesh APIs, and internal CI/CD pipelines. Days 15‑45 are the “Impact Project” window, where you build a feature that ships to a production microservice. Days 46‑90 focus on “Deep‑Dive Ownership,” where you take over a legacy component and lead a sprint. Judgment: the program is not a vague orientation; each phase is a deliverable‑driven sprint that directly feeds your performance review.

Insider scene: During a Q2 debrief last year, the senior engineering manager halted the meeting to point out that a new hire had never pushed code to the internal Artifactory repository. The manager’s comment—“The problem isn’t the tool, it’s the signal you’re sending about your readiness”—set the tone for the rest of the cohort.

What should I prioritize on day 1 to day 14?

Prioritize credential provisioning, internal security training, and the “Infrastructure Bootcamp” labs over any “meet‑the‑team” coffee chats. The first two weeks are your only window to earn the “Trusted Builder” badge, which unlocks write access to the core trading‑engine repo. Judgment: early badge acquisition signals competence to both the security team and your future sprint lead, whereas casual networking does not move the needle on your ability to ship code.

Not X, but Y: Not “attend every welcome session,” but “complete the zero‑trust network labs and acquire the Trusted Builder badge.”

How do I choose a mentor, and why does it matter?

Select a mentor who has at least two “Impact Projects” under their belt and currently sits on a cross‑functional guild (e.g., Data‑Mesh Guild). Approach them with a one‑pager summarizing your background, the badge you earned, and a concrete question about the guild’s roadmap. Judgment: a mentor who is merely senior but not guild‑active will give you generic advice; a guild‑active mentor will embed you in the decision‑making loop, accelerating your visibility.

Not X, but Y: Not “pick the most senior engineer available,” but “pick a guild‑active engineer whose recent deliverables align with your Impact Project.”

What is the “Impact Project” and how do I guarantee it ships?

The Impact Project is a 30‑day, 10‑story‑point feature that must be merged into the production branch of the “FinData” microservice. Success requires three steps: (1) define a narrow scope with your sprint lead by day 20, (2) write unit‑test coverage of at least 85 % by day 30, and (3) obtain two independent code‑review approvals before the merge gate on day 45. Judgment: treat the Impact Project as a mini‑performance review, not an optional learning exercise.

Insider scene: In a July debrief, a cohort member’s project stalled because they waited for a “design clarification” that never arrived. The engineering director interrupted, “The problem isn’t the missing diagram—it’s your inability to make a decision with the data you have.” The lesson was clear: own the decision, document assumptions, and move forward.

How should I navigate Fidelity’s internal tooling ecosystem?

Fidelity runs a bespoke stack: Mainframe‑Bridge for legacy COBOL services, Data‑Mesh for real‑time market feeds, and the “Cobalt” CI platform for Go and Java services. Within the first 30 days, you must be able to spin up a local Cobalt pipeline, trigger a Data‑Mesh ingest, and debug a Mainframe‑Bridge RPC call. Judgment: proficiency in these three tools is the de‑facto technical barometer; anything less signals you are still in “new‑hire” mode.

Not X, but Y: Not “learn every internal tool superficially,” but “master the three core platforms to the point where you can troubleshoot a failed pipeline without escalating.”

When does my first performance review happen, and what does it evaluate?

The first formal review occurs at the end of day 90, but the informal “30‑day pulse” happens on day 30 and again on day 60. Review criteria are (1) delivery of the Impact Project, (2) badge acquisition (Trusted Builder, Data‑Mesh Contributor), (3) peer feedback on collaboration, and (4) alignment with the guild’s quarterly OKRs. Judgment: the 90‑day review is a gate—not a rubber‑stamp; failure to meet any two of the four criteria results in a performance‑plan extension.

Insider scene: During a Q4 debrief, a senior manager recounted a case where a new hire met the Impact Project deadline but missed the Trusted Builder badge; the manager said, “The problem isn’t the feature—it’s the missing security signal that kept the code in a sandbox.”

Preparation Checklist

Secure a corporate VPN credential and complete the MFA enrollment before your start date.
Finish the “Zero‑Trust Network” lab on the Fidelity onboarding portal; the badge unlocks source‑control write access.
Draft a one‑page mentor outreach memo that cites your badge, a concrete guild interest, and a targeted question.
Map the three core tooling platforms (Cobalt, Data‑Mesh, Mainframe‑Bridge) to a personal lab environment; verify you can trigger a CI build end‑to‑end.
Outline a 30‑point Impact Project scope with acceptance criteria; get sign‑off from your sprint lead by day 20.
Work through a structured preparation system (the PM Interview Playbook covers Fidelity’s guild‑based delivery model with real debrief examples).
Schedule a 15‑minute “pulse check” with your manager on day 30 and day 60 to surface blockers early.

Mistakes to Avoid

BAD: Treating the onboarding portal as optional reading material and only attending the social events. GOOD: Completing every mandatory lab, earning the Trusted Builder badge, and using the badge as proof of readiness in early sprint stand‑ups.

BAD: Selecting a mentor based solely on seniority, resulting in delayed feedback and vague guidance. GOOD: Choosing a guild‑active mentor whose recent code reviews align with your Impact Project, ensuring concrete, timely input.

BAD: Defining an Impact Project scope that is too ambitious, then missing the day 45 merge gate and receiving a performance‑plan extension. GOOD: Narrowing the scope to a single, testable endpoint, achieving 85 % unit‑test coverage, and securing two independent approvals before the merge deadline.

FAQ

How quickly do I get access to the production repo?

You receive write access only after earning the Trusted Builder badge, which is awarded at the end of the 14‑day Infrastructure Bootcamp. No other path bypasses this security gate.

What if my Impact Project is blocked by a missing design doc?

Document the assumption, notify the sprint lead, and proceed with a prototype. The debrief culture penalizes indecision, not premature commitment, so own the risk and iterate.

Can I switch guilds after the first 90 days?

Switching is possible but requires a formal transfer request, endorsement from both guild leads, and a demonstrated contribution record (at least two merged features) in your current guild. Without those, the request is denied.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.