JPMorgan SDE onboarding and first 90 days tips 2026

JPMorgan SDE Onboarding and First 90 Days Tips 2026

TL;DR

JPMorgan’s SDE onboarding is structured but inconsistent across teams—your success depends on proactive mapping of stakeholders, not waiting for assigned training. The first 90 days are a shadow evaluation period, not a grace period. Technical output matters less than visibility into decision-making and demonstrating risk-aware engineering judgment.

Who This Is For

This is for new SDE hires at JPMorgan who passed the technical screen but lack internal context on how engineering credibility is earned in a regulated financial environment. It’s not for interns or lateral hires with banking experience. If you’re joining a tech-forward group like Athena, Payments, or DORA but came from Big Tech, you’re in a high-risk transition zone.

What happens during JPMorgan SDE onboarding?

Onboarding lasts 2–4 weeks and is mostly administrative, not technical. You’ll complete compliance training, get system access, and attend mandatory HR sessions. The first 3 days are spent in virtual classrooms with 50 other hires, covering data privacy, SOX compliance, and code of conduct. One session includes real forensic examples of how developers triggered SEC investigations by mishandling audit logs.

The actual engineering integration begins only in week 3, when you’re assigned a buddy—usually a mid-level engineer pulled from delivery work. Most buddies are disengaged because there’s no incentive or time allocated for mentoring. In one Q2 2025 HC meeting, a hiring manager admitted 60% of new SDEs hadn’t committed code by day 15 because their buddies hadn’t set up repo access.

Not a learning journey, but a compliance gauntlet.

Not mentorship, but peer shadowing with zero accountability.

Not technical ramp-up, but access negotiation.

The deeper problem isn’t inefficiency—it’s that JPMorgan treats onboarding as risk containment, not talent acceleration. Engineering managers don’t see onboarding success as their KPI. Your first task should be to bypass the script and identify who controls code review gates, test environments, and CI/CD pipelines—even if that person isn’t your buddy.

How should I structure my first 90 days as a new SDE?

Your first 90 days are a proxy evaluation of judgment, not coding speed. Managers watch for whether you escalate appropriately, question requirements in regulated contexts, and avoid solo decisions on data access or logging. In a Q3 2025 debrief, a new SDE was flagged for “over-delivery” after shipping a feature without involving Compliance—a classic Big Tech instinct that backfires here.

Week 1: Map the stakeholder web. Identify the tech lead, product manager, QA lead, and compliance liaison. Attend every meeting you’re invited to, even if silent. Take notes in Confluence, tag them correctly—this is your first signal of diligence.

Weeks 2–4: Ship one small, auditable change. Pick a bug fix or log enhancement. The goal isn’t impact—it’s to complete the full SDLC loop: PR, review, security scan, regression test, sign-off. In one team, a new hire delayed their first PR for 10 days because they didn’t know the internal SonarQube instance required manual approval. Visibility into process friction is more valuable than clean code.

Weeks 5–12: Own a component, not a ticket. Move from task execution to ownership—volunteer for on-call, investigate a recurring alert, document a service boundary. At JPMorgan, ownership is proven through operational stamina, not design docs.

Not velocity, but audit readiness.

Not innovation, but compliance adjacency.

Not autonomy, but escalation precision.

The 90-day review isn’t formal. Your manager updates your performance tracker in Workday based on informal feedback from QA, security, and your tech lead. There’s no panel, no presentation—just a 10-minute HC slot where your name is mentioned or skipped.

What technical systems will I work with as a JPMorgan SDE?

You’ll work in a hybrid cloud environment split between on-prem data centers and AWS GovCloud, governed by internal platforms like Conductor (workflow orchestration), DORA (resilience testing), and Athena (pricing and risk). Most backend services are Java 11+ on Spring Boot, with gRPC for inter-service communication. Frontend stacks vary—some teams use React, others still maintain AngularJS.

CI/CD is managed through Jenkins and internal tooling. Every PR triggers a security scan via SourceClear and a compliance check against internal policy tags. One engineer in Payments got blocked for 3 days because their PR included Lombok—an approved library, but not tagged correctly in the internal artifact registry.

Access to production data requires Data Classification Approval (DCA), which can take 5–7 business days. You cannot self-serve logs—Splunk access is tiered, and raw log export requires manager + security sign-off. In 2025, a new SDE on the Fraud team was reprimanded for downloading transaction logs to their local machine, even though encrypted.

Not modern DevOps, but governed delivery.

Not full stack freedom, but policy-bound development.

Not open tooling, but internal gatekeeping.

The real test isn’t mastering the stack—it’s navigating the approval chains. Engineers who survive long-term aren’t the fastest coders—they’re the ones who learn which forms to submit, which Slack channels to monitor, and which leads respond to urgency versus protocol.

How do performance reviews work for SDEs in the first 90 days?

There is no official performance review at 90 days, but your reputation is already set by then. Feedback flows informally through tech leads and QA leads into the manager’s Workday tracker. In a hiring committee conversation last year, a director said, “If a new hire hasn’t been mentioned in a risk meeting by day 60, they’re likely invisible—and that’s a red flag.”

Promotions and bonuses are decided in semi-annual cycles, but early signals matter. One SDE on the Clearing team was fast-tracked to L5 after identifying a race condition in settlement logic during week 6—because it was flagged in a control review, not because the code was elegant.

You’re assessed on three silent dimensions:

Risk containment – Did you raise flags on data handling or edge cases?
Process adherence – Did you follow code review, testing, and documentation steps?
Stakeholder awareness – Did product, QA, and compliance feel looped in?

Not output volume, but signal density.

Not bug fixes shipped, but near-misses flagged.

Not code quality, but audit trail completeness.

In regulated tech at JPMorgan, silence is interpreted as disengagement. If you don’t speak up in design reviews about compliance gaps, you’re assumed to be unaware—not cautious. Speak early, even if partially wrong. The cost of silence exceeds the cost of correction.

How can I stand out as a new SDE at JPMorgan?

You stand out by demonstrating engineering judgment in regulated contexts, not by shipping fast or optimizing algorithms. In a Q4 2025 hiring committee, a new SDE was praised not for building a scalable service, but for refusing to proceed on a PR until the data lineage was documented—even though it delayed the sprint.

Start by auditing the test coverage of your component. Most legacy services have 40–60% coverage. Write integration tests that include negative paths—especially around money movement or user identity. One engineer gained visibility by creating a test suite that caught a rounding error in cross-currency settlement.

Volunteer for on-call in month two. Incident response is where reputations form. During a 2026 outage in the Card Authorization system, a new SDE who correctly identified a cache poisoning issue in the failover logic was mentioned in the post-mortem—and fast-tracked for a stretch assignment.

Contribute to internal tech forums. JPMorgan runs internal engineering guilds—Security Guild, Resilience Guild, Data Guild. Present a 10-minute lightning talk on a lesson from your first sprint. Not a deep dive—just a “here’s what surprised me” reflection.

Not technical complexity, but risk transparency.

Not solo heroics, but controlled escalation.

Not speed, but durability focus.

The engineers who rise aren’t the ones who write the most code—they’re the ones who make others feel safer. In banking, safety signals competence.

Preparation Checklist

Complete all pre-onboarding compliance modules early—delays in background checks can push start dates by 2–3 weeks.
Install and test JPMorgan’s VPN and remote access tools before Day 1. Many new hires waste 2–3 days on connectivity issues.
Review the internal engineering principles document—it’s not public, but available on the internal wiki. Know the difference between “customer-facing” and “market-sensitive” systems.
Set up your Confluence and Jira access immediately. Use consistent tagging and update your status daily—even if no one reads it.
Work through a structured preparation system (the PM Interview Playbook covers financial tech onboarding with real debrief examples from JPMorgan, Goldman, and Citigroup).
Identify your tech lead and QA lead in your first week—schedule 1:1s, even if they’re 15 minutes.
Document every dependency and approval step in your first PR—this becomes your process map for future onboarding.

Mistakes to Avoid

BAD: Waiting for someone to assign you work after onboarding ends.

One SDE in Treasury Systems attended training, then waited 10 days for a ticket. Their manager noted “lack of initiative” in the 90-day feedback.

GOOD: Scour Jira for unassigned bugs or tech debt tickets. Pick one, write a proposal, and tag the tech lead. Shows ownership.

BAD: Making direct changes to production configs without a change advisory board (CAB) ticket.

A new hire in Equities tried to “fix” a log level in prod and triggered a compliance alert. The incident went to risk governance.

GOOD: Submit a CAB request with rollback plan and stakeholder tags—even for small changes. Process over urgency.

BAD: Building a feature without consulting the data classification team.

One engineer used PII in staging without DCA approval. The entire sprint was rolled back, and the team faced an audit.

GOOD: Flag data usage early in design—ask, “Is this classified? Where does it flow?” Shows risk awareness.

FAQ

Does JPMorgan provide housing or relocation for new SDEs?

No formal housing is provided, but relocation is reimbursed up to $10,000 with receipts. The process takes 45–60 days to process. Most delays come from missing tax forms or unapproved vendors. Do not assume it’s automatic—track every receipt and submit within 30 days of start.

What is the typical salary for a new SDE at JPMorgan in 2026?

L3 SDEs earn $110K–$130K base, $10K–$15K sign-on, and 10–15% annual bonus. L4s earn $140K–$160K base, $20K–$30K sign-on, 15–20% bonus. Salaries are lower than Big Tech, but total comp is competitive when factoring in bonus and stock. Location adjustments are minimal—even NYC and SF roles are within $10K of base.

Are there promotion opportunities for SDEs in the first year?

Promotions in year one are rare but possible for L3 to L4 if you own a critical component and deliver through full SDLC under scrutiny. It requires visibility in risk reviews, not just delivery. One SDE on the DORA team was promoted at 10 months after leading a resilience test that uncovered a cross-region failover flaw.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.