Didi SDE onboarding and first 90 days tips 2026

TL;DR

The first 90 days for a new SDE at Didi are judged by how quickly you internalize the platform stack, deliver a tangible feature, and align with team OKRs, not by how much code you write in isolation. Success depends on proactive communication with your buddy, mentor, and manager; treating onboarding as a checklist leads to missed cultural signals that affect promotion decisions. Those who focus on learning the internal tooling hierarchy and asking precise questions outperform peers who rely solely on prior experience.

Who This Is For

This guide is for newly hired SDE L3 or L4 engineers joining Didi’s Beijing or Shanghai offices in Q1 2026, with zero to two years of professional experience, who need concrete, day‑by‑day actions to navigate the first three months. It assumes you have completed the offer process and are preparing for day‑one logistics, not for the interview itself.

How long does Didi SDE onboarding typically take and what are the key milestones?

Onboarding at Didi is structured as a 90‑day program with three formal checkpoints: day 7 orientation completion, day 30 buddy sign‑off, and day 60 feature‑delivery review. The final day 90 meeting evaluates impact against agreed OKRs and determines whether you proceed to the next level or require an extended plan. In a Q3 2025 debrief, the hiring manager noted that engineers who missed the day 30 buddy checkpoint often struggled to locate internal libraries, causing delays in their first project. The problem isn’t the length of the program — it’s the timing of when you seek help; waiting until day 45 to ask about the code‑review toolchain wastes the early‑access window that the buddy system provides.

What specific internal tools and platforms should a new SDE learn in the first 30 days?

During the first month you must become proficient with Didi’s internal CI/CD pipeline (named Atlas), the monorepo navigation tool (CodeBase), and the feature‑flag service (Flip). Mastery of these three reduces reliance on external documentation and lets you push changes to staging within a day of writing code. In a Q4 2024 HC discussion, a senior SDE explained that new hires who spent week 2 only reading the Atlas wiki without running a local build took twice as long to deploy their first bug fix compared to peers who paired with their buddy on a dummy commit. The problem isn’t reading the manual — it’s executing a full build‑test‑deploy cycle early; doing so surfaces configuration gaps that documentation never mentions.

How should I set goals with my manager during the first 60 days at Didi?

Goal‑setting at Didi follows the OKR framework with a emphasis on measurable output: you should propose one concrete feature or improvement that can be shipped to production by day 60, aligned with the team’s quarterly OKR, and define success metrics such as latency reduction or error‑rate decrease. Your manager will then break that into weekly milestones and review progress in the day 30 and day 60 one‑on‑ones. In a Q2 2025 debrief, a manager recalled that an SDE who framed their goal as “learn the stack” received vague feedback, while another who committed to “reduce the image‑upload latency by 15 % through a new caching layer” received specific guidance on which services to touch. The problem isn’t ambition — it’s specificity; vague learning goals create ambiguity that makes it impossible to assess impact at the 90‑day review.

What are the common pitfalls new SDEs encounter in their first 90 days at Didi and how to avoid them?

Three recurring pitfalls appear in debrief notes: (1) over‑reliance on legacy code without checking for newer internal libraries, (2) skipping the mandatory security‑training module before touching user‑data services, and (3) treating the day 90 review as a formality rather than a data‑driven conversation. To avoid the first, allocate time in week 3 to search the internal library catalog for alternatives before copying snippets from old services. To avoid the second, complete the security e‑learning within the first week and attach the completion certificate to your first pull request. To avoid the third, prepare a one‑page summary of your day 60 feature’s metrics, the OKR contribution, and three concrete learning points before the review meeting. In a Q1 2026 debrief, a manager rejected an SDE’s promotion request because the engineer could not cite any metric from their shipped feature, despite having written clean code. The problem isn’t effort — it’s evidence; Didi’s promotion criteria require quantifiable impact, not just activity.

How does the 90‑day performance review work at Didi and what metrics matter most?

The day 90 review consists of a self‑assessment, peer feedback from your buddy and two teammates, and a manager‑led calibration meeting where your OKR achievement is scored on a 0‑2 scale (0 = not met, 1 = partially met, 2 = exceeded). Metrics that carry weight include feature‑lead time, defect‑escape rate, and participation in code‑review throughput (measured as reviews per week). In a Q4 2025 calibration session, a manager explained that an SDE who scored 2 on feature‑lead time but 0 on defect‑escape rate received a “needs improvement” rating because the team’s reliability OKR could not be compromised. The problem isn’t speed alone — it’s balance; Didi values reliable delivery over rapid but buggy output, and the review reflects that trade‑off.

Preparation Checklist

Complete the pre‑onboarding paperwork and set up your Didi corporate email and VPN access before day 1.
Schedule a 30‑minute introductory call with your assigned buddy to clarify the Atlas workflow and request a sandbox repository.
Run a full build‑test‑deploy cycle on a dummy change by the end of week 2 to validate your local environment.
Enroll in the mandatory security‑training module and download the completion certificate for your first PR.
Draft a day 60 feature proposal with clear success metrics and review it with your manager during the day 30 one‑on‑one.
Work through a structured preparation system (the PM Interview Playbook covers effective onboarding goal‑setting with real debrief examples) to refine your OKR writing skills.
Allocate two hours each week to explore the internal library catalog and bookmark at least two reusable components relevant to your stack.

Mistakes to Avoid

BAD: Waiting until day 45 to ask your buddy how to run the Atlas pipeline because you assume the wiki is sufficient.

GOOD: Pairing with your buddy on day 3 to run a failing build, observe the error logs, and fix the configuration together, then documenting the steps for future reference.

BAD: Setting a vague goal like “improve the recommendation system” without defining scope or metrics for the day 90 review.

GOOD: Proposing to “reduce the recommendation‑service latency from 120 ms to 90 ms for the top‑5 % of requests by implementing a caching layer, measured via the internal latency dashboard.”

BAD: Treating the day 90 review as a casual chat and arriving without any data or preparation.

GOOD: Preparing a one‑page slide that shows your feature’s lead time, defect count, and OKR contribution, then walking the manager through each number and asking for specific feedback on next steps.

FAQ

What salary range can I expect for an SDE L3 at Didi in 2026?

Base salary for an SDE L3 in Beijing or Shanghai typically falls between ¥320,000 and ¥480,000 per year, with an annual bonus target of 10‑20 % based on individual and company performance. Equity refreshers are granted after the first year and are subject to vesting over four years.

How many interview rounds are there for an SDE role at Didi, and what do they assess?

The standard loop consists of four rounds: a coding interview focused on algorithmic problem‑solving, a system‑design interview evaluating scalability and trade‑offs, a behavioral interview assessing collaboration and ownership, and a bar‑raiser interview that checks cultural fit and long‑term potential. Each round is scored independently, and a strong performance in the system‑design round does not compensate for a weak bar‑raiser result.

Is it necessary to know Didi’s specific tech stack before day 1?

Prior familiarity with Didi’s internal tools is not required; the onboarding plan assumes you will learn Atlas, CodeBase, and Flip during the first month. However, experience with similar CI/CD pipelines, monorepos, and feature‑flag systems will shorten the ramp‑up time, as shown in multiple debriefs where candidates with comparable background shipped their first feature two weeks earlier than those without.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.