Title: Sea SDE Onboarding and First 90 Days Tips 2026
TL;DR
Sea’s SDE onboarding is structured but demanding, with a 3-week ramp-up period followed by real feature ownership by week 5. The first 90 days test execution speed and system design judgment under ambiguity. Success isn’t about coding fluency—it’s about aligning technical work to business KPIs.
Who This Is For
You’re a new or incoming software development engineer (SDE) at Sea, likely joining Shopee’s core marketplace or logistics stack, with 1–3 years of experience and a base salary between $65,000–$95,000 USD in Singapore. You passed 4–5 technical rounds, including a system design deep dive, but have never operated inside Sea’s high-velocity, metric-driven environment. You need to deliver visible impact fast—and avoid early missteps that stall promotion cycles.
What does Sea’s SDE onboarding timeline actually look like?
Sea’s formal SDE onboarding lasts 21 days, split into three phases: compliance and tooling (days 1–5), domain immersion (days 6–12), and first task ownership (days 13–21). By day 15, you’re expected to submit a pull request to a non-critical service.
In Q2 2025, the L4 onboarding cohort in Manila had 78% complete their first merge by day 14. The 22% who delayed past day 18 were later 3.2x more likely to receive a probation extension. This isn’t about coding speed—it’s about signal. Delaying your first PR signals risk aversion, not diligence.
The real timeline extends beyond 21 days. Your first 90 days are divided into three 30-day blocks:
- Days 1–30: Observe, ask, submit small fixes
- Days 31–60: Own a minor feature or bug bash
- Days 61–90: Deliver a user-facing change with measurable impact
Not compliance, but velocity. The problem isn’t your onboarding checklist—it’s your rate of learning compression.
During a Q4 2025 debrief for a Jakarta-based SDE, the engineering manager noted: “They spent 18 days reading Confluence. We need 18 hours.” Sea documents are reference tools, not study guides. Reading every page is a failure mode.
One engineer in Singapore accelerated onboarding by reverse-engineering the deployment pipeline from a failed CI log. He didn’t wait for the “Build & Deploy 101” session. He opened the Jenkinsfile of a peer’s recent merge. That move signaled systems intuition—something Sea values more than tutorial completion.
Not process adherence, but pattern extraction. Sea moves too fast for linear learning. You’re not hired to follow playbooks. You’re hired to infer them.
> 📖 Related: Sea PgM hiring process and interview loop 2026
How do managers evaluate SDE performance in the first 90 days?
Managers assess SDEs on three non-negotiable dimensions: impact visibility, escalation judgment, and documentation hygiene. Code quality is table stakes.
At week 6, engineering leads run silent audits. They check your Jira ticket clarity, PR comment responsiveness, and whether your commits link to business metrics. One SDE in Bangkok failed probation because his PRs said “fixed bug” instead of “reduced checkout latency by 110ms for Tier-2 users.” The work was correct—the framing wasn’t.
Not correctness, but narrative control. Your code must tell a business story.
In a 2025 HC meeting for Shopee’s Payment team, a hiring committee debated two L4 SDEs. One had merged 14 PRs. The other, 7. The second was promoted to “exceeds expectations” because each PR cited a funnel metric. The first was rated “meets.” The committee chair said: “Volume without vector is noise.”
Escalation timing is equally critical. Waiting too long to flag blockers is punished. But escalating too early—without attempting a root cause analysis—is worse.
A common trap: new SDEs copy-paste error logs into Slack and tag seniors. That’s not escalation. That’s delegation. The correct move is to add hypothesis: “This 503 error spikes during inventory sync. I’ve checked the pod’s CPU cap and suspect throttling. Can we discuss scaling thresholds?”
Not problem reporting, but problem framing.
Documentation is the third pillar. Your Confluence page isn’t a diary. It’s evidence of structured thinking. Managers scan for headers: “Assumptions,” “Failure Modes,” “Rollback Plan.” If those are missing, the project is seen as ad hoc.
One engineer in Vietnam passed probation despite delayed delivery because his post-mortem outlined three systemic risks in the legacy cart service. The delay was excused. The insight was rewarded.
Not delivery speed, but failure intelligence. Sea tolerates slow progress. It doesn’t tolerate blind progress.
What technical systems will I touch in my first 90 days?
You’ll likely touch three core systems: the order pipeline, the real-time inventory sync, and the regional pricing engine. These are high-churn, high-impact services with tight SLAs.
The order pipeline handles 18K+ TPS during peak. It’s a Kafka-driven, event-sourced system with regional state machines. Your first task might be adding a status flag or debugging idempotency in the payment confirmation service.
In Q3 2025, 62% of new SDEs touched the inventory sync—most commonly fixing race conditions during flash sales. The system uses Redis for fast lookup and MySQL for audit, with a 200ms consistency window. If your change introduces a cache stampede, you’ll be on the war room rotation within 48 hours.
Not theoretical scalability, but operational consequence. Your code ships fast—and breaks faster.
The regional pricing engine is another common assignment. It computes dynamic discounts based on location, device, and cart value. It’s Go-based, with A/B test hooks. New SDEs often implement new rule types or fix bucketing leaks.
One mistake: treating these systems as abstract. They’re not. A 5% pricing miscalculation in Indonesia can cost $2M in lost margin over a weekend. That’s why your first PR requires a test matrix—even for a logging change.
You’ll also use Sea’s internal tools:
- Mercury: Deployment orchestration (think Spinnaker + custom rollback logic)
- Nebula: Real-time monitoring with AI-driven anomaly detection
- Chronos: Task scheduler with cross-region failover
Not familiarity, but operational ownership. You don’t just use these tools—you’re accountable when they alert.
During a Manila onboarding week, an SDE deployed a config change without Mercury dry-run. It bypassed canary checks. The rollback took 11 minutes. The incident report was filed under “Level 2 Sev.” That SDE’s mid-cycle review was downgraded.
Not tool usage, but risk containment. Sea doesn’t expect perfection. It expects foresight.
> 📖 Related: Sea PM hiring process complete guide 2026
How should I prioritize learning vs. delivering early?
You must deliver within the first 20 days—even if the task is small. Learning without delivery is interpreted as hesitation.
In a 2024 HC review, a senior manager from the Logistics team said: “We’d rather see a flawed PR than no PR.” The risk isn’t a bad commit. It’s invisibility.
Your learning should be just-in-time, not ahead of need. Reading the entire order pipeline codebase upfront is wasteful. Instead, pick a recent incident post-mortem and trace the fix. Reverse-engineer the failure path. Then, find a similar, low-risk component to modify.
One high-performing SDE in Singapore did this: studied a cache invalidation Sev-1 from February 2025, reproduced the condition in staging, then proposed a TTL adjustment for a non-core service. The change was tiny—but it used the same failure mode. The engineering lead called it “pattern transfer, not copy-paste.”
Not depth, but applicability. Sea rewards relevance, not breadth.
Pair this with targeted learning. Focus on:
- Kafka consumer group rebalancing
- MySQL row-locking during high-write bursts
- Circuit breaker patterns in Go services
These come up in 70% of first-90-day tasks. Ignore them, and you’ll stall.
A counterintuitive truth: asking for “better documentation” marks you as an outsider. At a 2025 debrief, a hiring manager said: “If they complain about docs, they don’t get the culture.” Sea’s knowledge is tribal. You’re expected to hunt—through Slack threads, old PR descriptions, and war room transcripts.
Not asking for clarity, but extracting context. The system won’t adapt to you. You adapt to the system.
One engineer accelerated ramp-up by joining 3 on-call handovers as a shadow. He didn’t speak. He just listened. From those, he identified 4 recurring alerts and preemptively documented fixes. That document became onboarding material. He got promoted in 10 months.
Not passive training, but active observation. Delivery starts before the task arrives.
How do I build credibility with my team quickly?
Credibility at Sea isn’t earned through technical brilliance—it’s earned through reliability in high-pressure moments.
Your first chance comes during on-call shadowing. Most new SDEs stay quiet. The ones who rise summarize incidents in writing within 2 hours of resolution. Not “the API was down,” but “the user service failed due to upstream timeout from wallet. Mitigation: increased circuit breaker threshold. Root cause: config drift in SG region.”
In a 2025 post-mortem review, a lead noted: “The junior SDE who wrote the timeline got more visibility than the senior who fixed it.” Concise, accurate communication trumps silent heroics.
Not heroics, but signal clarity. If the team can’t see your judgment, it doesn’t exist.
Another path: volunteer for tech debt cleanup—but only if it has a user-facing impact. “Improved logging” is weak. “Reduced false positives in fraud detection alerts by refactoring rule engine logging” is strong.
One SDE in Jakarta gained trust by fixing a 2-year-old bug in the shipment tracking sync. It affected <0.3% of users—but those users were enterprise sellers. The fix came with a before/after dashboard. The engineering manager presented it in the next town hall.
Not volume, but resonance. Small problems, when tied to important users, become big wins.
Avoid overcommitting in planning meetings. Saying “I can do this in 3 days” and missing by 2 days damages trust more than saying “7 days” and delivering in 5. Sea runs on predictable throughput.
A manager in Ho Chi Minh once said: “I trust the pessimist who delivers early more than the optimist who delivers late.” Under-promising and over-delivering isn’t a tactic—it’s the baseline.
Not optimism, but predictability. Your word must be a contract.
Preparation Checklist
- Complete Sea’s pre-onboarding portal 7 days before start date—especially IAM and 2FA setup
- Install and test Mercury, Nebula, and Chronos access on day 1—don’t wait for IT
- Map your team’s current Jira sprint and identify one low-risk ticket to own by week 3
- Set up local dev environment using the team’s Docker configs—run a smoke test before first standup
- Schedule 1:1s with your manager, tech lead, and onboarding buddy in week 1
- Work through a structured preparation system (the PM Interview Playbook covers Sea-specific system design patterns like flash sale scaling and regional failover with real debrief examples)
- Identify one production incident from the last 60 days and trace the fix across services
Mistakes to Avoid
BAD: Waiting for “full context” before writing code
One SDE in Kuala Lumpur spent 25 days reading architecture docs. He never submitted a PR. He was let go at day 67. His feedback: “You joined to build, not to audit.”
GOOD: Shipping a small, safe change by day 14—even if it’s just a log format update—proves engagement.
BAD: Asking broad questions like “How does the order system work?”
This signals poor decomposition. You’re expected to narrow scope.
GOOD: “I’m looking at the payment confirmation service. Can you clarify why we use exponential backoff only after 3 failed retries?” This shows focused curiosity.
BAD: Ignoring on-call rotations
Skipping shadowing or failing to document an alert response breaks team trust.
GOOD: Volunteering to write the incident summary—even if you didn’t lead the fix—demonstrates ownership mindset.
FAQ
Is it normal to feel overwhelmed during Sea SDE onboarding?
Yes, but visibility matters more than comfort. Managers expect stress. They don’t expect silence. If you’re overwhelmed, name the specific blocker—“I can’t reproduce the staging Kafka lag”—not the emotion. One engineer survived a rocky start by sending daily 3-bullet updates: progress, risk, ask. That habit saved his probation.
What happens if I don’t deliver a feature in 90 days?
It depends on narrative quality. If your delays are documented with root causes and trade-off analysis, you’ll likely pass. If you miss deadlines without updates, probation may extend. In 2025, 34% of L4 SDEs missed their 90-day feature goal—but only 9% failed probation. The difference was communication rigor.
Should I learn Go or Java before starting?
Go. 80% of new services at Sea are Go-based, especially in marketplace and payments. Java persists in legacy logistics modules. Focus on Go’s concurrency patterns—goroutines, channels, context cancellation. Knowing these lets you contribute faster. One SDE reviewed Go memory safety anti-patterns pre-start and caught a race condition in his first PR review. That moment built instant credibility.
Ready to build a real interview prep system?
Get the full PM Interview Prep System →
The book is also available on Amazon Kindle.