Tencent SDE onboarding and first 90 days tips 2026

The candidates who prepare the most often perform the worst

TL;DR

Tencent’s SDE onboarding is a structured 90‑day ramp that emphasizes early code contribution, buddy‑driven learning, and clear performance milestones; success hinges on showing judgment in ambiguous tasks rather than perfect syntax.

Who This Is For

This guide targets newly hired SDEs (levels I‑III) at Tencent’s Shenzhen, Beijing, or Guangzhou offices who have accepted an offer and want to know exactly what to prioritize in their first three months, based on real debrief observations from hiring committees at FAANG‑adjacent firms.

How should I set up my development environment in the first week at Tencent?

Your first‑week goal is to get a working build and run the unit test suite on your machine within two days; spending longer signals a mismatch between your setup habits and the team’s automation standards. In a Q3 debrief for a Guangzhou backend team, the hiring manager noted that a candidate who spent three days tweaking IDE themes was flagged for low “environmental fluency,” while another who accepted the default config and pushed a trivial change on day one earned immediate trust. The environment is deliberately minimal: you receive a pre‑configured VM with internal tooling, and the expectation is to learn the internal CLI (ti) and code search (grep‑internal) rather than customize aesthetics.

Not X, but Y: the problem isn’t your choice of editor — it’s your willingness to adopt the team’s standardized workflow without hesitation.

What are the expectations for my first code review?

Your first code review should demonstrate clear intent, minimal logical gaps, and responsiveness to feedback within 24 hours; reviewers prioritize your thought process over the number of lines changed. During an HC debate for a Shenzhen frontend squad, a senior engineer argued that a diff that refactored a poorly named helper function, even if it introduced a tiny style nit, was more valuable than a large feature addition that lacked test coverage because it showed judgment in code hygiene. The review checklist includes: (1) a concise description of the problem solved, (2) links to any relevant design docs, and (3) a test plan that matches the team’s coverage threshold (usually 80 % for new logic).

Not X, but Y: the problem isn’t whether your code passes lint — it’s whether you can articulate why the change matters to the product’s reliability.

How do I navigate the buddy system and mentorship?

You should treat your assigned buddy as a process coach, not a technical tutor, and schedule two 30‑minute syncs per week to discuss workflow blockers, not algorithmic details. In a HC conversation for an Beijing AI platform team, the hiring manager revealed that buddies are evaluated on how quickly they help new hires close their first internal ticket, not on how many coding challenges they solve together. The buddy’s role is to explain the internal release train, point you to the appropriate design doc repository, and clarify the “definition of done” for your squad.

Not X, but Y: the problem isn’t the depth of technical advice you receive — it’s how fast you can translate that advice into a tangible deliverable that moves the team’s sprint goal forward.

What metrics will my manager use to evaluate my performance in the first 90 days?

Your manager will judge you on three measurable outcomes: (1) the number of production‑ready changes you own by day 60, (2) the defect leakage rate of those changes (target < 5 % post‑release), and (3) your participation in team rituals measured by attendance and action‑item completion. In a Q4 debrief for a Guangzhou cloud services group, the hiring manager explained that a new SDE who shipped two small but critical bug fixes and maintained zero rollouts was rated higher than a peer who delivered a medium‑sized feature that caused two rollback incidents, because the former demonstrated ownership and risk awareness.

Not X, but Y: the problem isn’t the sheer volume of code you write — it’s the reliability and ownership signal you embed in each change.

How should I approach cross‑functional communication with product and QA?

You must adopt a “brief‑first, detail‑later” habit: share a one‑sentence impact statement before diving into technical specifics, and always copy the QA lead on test plan discussions. During an HC debrief for a Shenzhen mini‑program team, the product manager complained that engineers who dumped API specs without context caused unnecessary clarification loops, whereas those who opened with “this change reduces image load time by 30 % for the feed page” received faster sign‑off. The internal communication template encourages: impact → approach → open questions → next steps.

Not X, but Y: the problem isn’t how thoroughly you document your work — it’s whether you frame that work in terms of measurable user or business outcomes before the details.

Preparation Checklist

Read the internal onboarding portal (ti‑onboarding) and complete the mandatory security and data‑privacy modules within the first 48 hours.
Run the “hello‑world” service on your VM and push a trivial change to the sandbox repo by end of day 1 to confirm your CI/CD pipeline access.
Identify your squad’s definition of done and locate the corresponding checklist in the team’s Confluence space before your first planning meeting.
Schedule two recurring 30‑minute syncs with your buddy: one focused on workflow tooling, the other on sprint goals.
Work through a structured preparation system (the PM Interview Playbook covers effective communication with cross‑functional partners, with real debrief examples) to sharpen your impact‑first messaging style.
Review the last two sprint retrospectives of your team to understand recurring pain points and improvement themes.
Prepare a one‑paragraph “impact hypothesis” for your first assigned ticket and share it with your manager before you start coding.

Mistakes to Avoid

BAD: Spending the first week customizing your shell prompt, theme, and keybindings to match your personal setup.

GOOD: Accepting the default shell configuration, learning the internal alias shortcuts, and using the saved time to run the full test suite on the codebase.

BAD: Waiting for your buddy to schedule meetings and only responding when they reach out.

GOOD: Proposing a standing 30‑minute slot on your calendar each week, sending a brief agenda ahead of time, and following up with action items in a shared note.

BAD: Submitting a large pull request that touches multiple services without a clear breakdown of what each change solves.

GOOD: Splitting work into small, vertically sliced changes, each with its own test plan and a one‑sentence impact summary in the PR description.

FAQ

What is the typical timeline for receiving my first performance feedback?

You will receive informal feedback from your buddy after the first two weeks, followed by a formal check‑in with your manager at the end of month 1, and a comprehensive 90‑day review at the end of month 3 that includes the three metrics outlined above.

How much autonomy do I have to choose my first project?

Your manager will assign an initial ticket based on squad capacity; you can express interest in specific areas during your first one‑on‑one, but the final decision rests with the team’s priority queue, which is refreshed every sprint.

Is there a formal mentorship program beyond the buddy system?

Yes, after the 90‑day period you can opt into a six‑month mentorship circle that pairs you with a senior engineer from a different domain; participation is voluntary and requires a quarterly goal‑setting session with your mentor.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.