跪拜 Guibai
← All articles
Backend · Programmer · Java

The Promotion Metric That Isn't on Your Performance Review

By SamDeepThinking ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Promotion criteria in Chinese tech teams are often opaque to outsiders. This account makes the unwritten rule explicit: sustained delivery on tasks slightly above your current level, not tool-count or visibility, is what triggers a manager to fight for your raise.

Summary

A junior hire in 2024 started with a simple cancel-workflow feature. The code was structurally clean — validate, execute, sync, persist — and the developer could explain exactly why his DDD-style in-memory state change avoided a partial-failure scenario. That clarity, plus consistently low bug counts and fast incident response, earned him progressively larger assignments.

The turning point came during a third-party integration. The vendor proposed batch-syncing orders via scheduled jobs. The developer pushed back, arguing that a batch spike from multiple clients would destabilize the vendor's system and cascade to their own. He insisted on real-time, order-by-order sync with a cancel API. The lead backed him immediately.

By 2025 he was promoted to mid-level with a ¥2,500 raise and an A rating. By 2026 he owned entire modules — store scheduling, material estimation — from design through delivery. The through-line: he consistently delivered on work that sat just beyond his current job description.

Takeaways
Clean, readable code on a first small task — with the developer able to explain why in-memory state changes avoid partial-failure races — set the baseline for trust.
Consistently low bug counts, fast incident response, and stable production runs across multiple simple features signaled readiness for harder work.
During a third-party integration, the developer rejected the vendor's batch-sync design, arguing it would create a peak-load fragility that could cascade back to their own system.
The alternative was real-time, per-order sync with a cancel API — a system-stability argument that went beyond writing code.
Promotion to mid-level came with a ¥2,500 monthly raise and an A performance rating, followed by ownership of entire modules like store scheduling and material estimation.
The manager's explicit promotion rule: can you repeatedly handle work that is slightly beyond your current role's scope?
Conclusions

The developer's early DDD answer — that root.cancel() only mutates an in-memory object, so no partial-failure race exists — is technically correct but incomplete; the lead still pushed for a compensation mechanism, which is the real production-hardening step many juniors skip.

Pushing back on a vendor's architecture is a high-risk move for a junior. It worked here because the objection was grounded in a concrete failure mode (multi-tenant batch spikes), not in preference, and the lead was willing to absorb the political cost.

The promotion logic described — 'always handle things slightly beyond your current ability' — is effectively a continuous stretch-assignment filter. It selects for learning velocity, not for current competence, which is the opposite of how many Western performance-review grids are calibrated.

Concepts & terms
DDD (Domain-Driven Design) in-memory state change
A pattern where business logic mutates an in-memory aggregate root object without immediately persisting it. The database update happens in a separate step, which avoids a class of partial-failure races where business state is committed but the persistence layer hasn't caught up.
Compensation mechanism / retry tool
A fallback process that runs when an external call (like an inventory-center sync) fails after the local business logic succeeded. It typically includes a retry queue or a manual replay tool so operators can recover without digging through logs.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗