Self-Assessment Framework — Bạn Thực Sự Đang Ở Level Nào?

"The first step to growth is an accurate assessment of where you are. Most engineers are either overconfident (Dunning-Kruger) or underconfident (impostor syndrome). Both are wrong — and both will slow you down."

Tài liệu này không phải career coaching generic. Đây là framework để tự đánh giá thật sự — không tự dối, không tự ti. Nó được viết cho engineer 3-10 năm kinh nghiệm, muốn biết họ thực sự đang ở đâu và cần làm gì tiếp theo.

1. Tổng Quan — Level System Hoạt Động Như Thế Nào?

1.1 Tại Sao Level System Tồn Tại?

Level không phải để phân cấp hay gatekeep. Level system tốt có mục đích:

• Alignment: "Kỳ vọng của công ty với bạn là gì?" — cụ thể hóa bằng behaviors
• Compensation fairness: Cùng contribution → cùng pay range
• Growth clarity: Biết phải phát triển theo hướng nào

Level system tệ (và phổ biến ở công ty nhỏ):

• Không có document, "bạn sẽ biết khi nào bạn lên level"
• Dựa vào thâm niên hơn là impact
• Promotion là phần thưởng cho trung thành, không phải contribution

1.2 Level Danh Nghĩa vs Level Thực Tế

Điều quan trọng nhất cần hiểu:
  Title (L5 Senior) ≠ Actual operating level

Có 4 khả năng:
  1. Title = Level: Bạn đang operate đúng kỳ vọng
  2. Title < Level: Bạn đang "overpay" — contribute nhiều hơn được trả
  3. Title > Level: Bạn đang "underpay contribution" — được trả nhiều hơn deliver
  4. Không biết mình ở đâu: Thường gặp nhất, và đáng lo nhất

Honest Test #1:

Nếu bạn join một công ty mới ngày mai với cùng title, liệu bạn có thể thuyết phục team rằng bạn deserve level đó chỉ bằng work output — trong 90 ngày đầu tiên — mà không cần dùng authority từ title cũ?

Nếu câu trả lời là "chắc là không" hoặc "không chắc" — đó là thông tin quan trọng.

2. Self-Assessment Theo Level và Dimension

2.1 Framework Overview

Đánh giá bản thân theo 8 dimensions, mỗi dimension có biểu hiện cụ thể ở từng level:

Dimensions:
  1. Technical Depth       — Code, systems, debugging, performance
  2. Technical Breadth     — Cross-domain knowledge, awareness
  3. Scope of Impact       — Task / Feature / System / Team / Org
  4. Autonomy              — Cần guide bao nhiêu?
  5. Ambiguity Tolerance   — Xử lý unclear requirements ra sao?
  6. Communication         — Code review, RFC, exec comms
  7. Mentorship            — Đóng góp vào growth của người khác
  8. Business Acumen       — Hiểu tại sao build cái này

Levels:
  Entry/Junior → Mid → Senior → Staff → Principal

Level 1: Entry / Junior Engineer

Scope: Task-level. Làm được ticket đã được breakdown rõ ràng.

Green flags (đang thực sự operate ở Junior):

• Deliver task trong sprint mà không cần rescope nhiều
• Hỏi câu hỏi tốt, không bị stuck im lặng
• Code review không phải sửa đi sửa lại 3 lần vì cùng loại lỗi

Red flags (over-claim Junior hoặc đang struggle):

• Estimate sai > 2x liên tục mà không cải thiện
• Cùng loại bug xuất hiện nhiều lần (không học từ lỗi)
• Defensive với feedback thay vì curious

Level 2: Mid-Level Engineer

Scope: Feature-level. Tự breakdown task và deliver feature end-to-end.

Green flags:

• Giao feature → deliver mà không cần hand-hold
• Review code của junior giúp họ improve, không chỉ approve/reject
• Suggest improvement khi thấy design có vấn đề

Red flags:

• Luôn cần break task rất nhỏ mới làm được
• Code works nhưng không ai muốn review vì quá phức tạp vô lý
• Không bao giờ push back requirements dù clearly infeasible

Level 3: Senior Engineer

Scope: System-level. Đảm bảo hệ thống được design đúng, không chỉ code đúng.

Sự khác biệt quan trọng nhất giữa Mid và Senior:

Mid: "Tôi implement cái feature này theo spec"
Senior: "Spec này có vấn đề ở chỗ X. Đây là cách tôi propose design khác để avoid tech debt. Tôi cần phê duyệt không?"

Mid: Làm xong task → đợi task mới
Senior: Làm xong task → nhìn xung quanh → "Cái này có thể improve thế này..."

Mid code review comment: "Cần thêm null check"
Senior code review comment: "Null check này symptom của vấn đề deeper hơn — model của bạn không force invariant. Hãy xem xét thay đổi struct để null không thể tồn tại."

Green flags:

• Junior/Mid hỏi senior các câu hỏi design và senior có answer thuyết phục
• Senior review là signal quality — team muốn senior review PR quan trọng
• Khi senior nghỉ 2 tuần, team vẫn chạy tốt (không phải bottleneck)

Red flags:

• "Senior" nhưng tất cả code flow qua mình (bottleneck, không phải value)
• Design decision không có rationale — "tôi thấy thế là đúng"
• Mentoring = "đây là cách làm" mà không giải thích tại sao

Level 4: Staff Engineer

Scope: Multi-team / Organization. Đây là bước nhảy khác về chất, không chỉ hơn về lượng.

"Staff Engineer không phải Senior Engineer giỏi hơn. Staff Engineer là người giải quyết vấn đề mà không một Senior nào trong team có thể giải quyết một mình, và họ làm điều đó bằng cách kéo nhiều teams lại với nhau."

Sự khác biệt quan trọng nhất giữa Senior và Staff:

Senior nhìn thấy vấn đề trong team mình.
Staff nhìn thấy vấn đề nằm giữa các teams mà không ai trong team thấy.

Senior viết design doc cho feature của team.
Staff viết RFC ảnh hưởng đến cách 5 teams phối hợp — và get buy-in từ tất cả.

Senior: "Service A của team tôi có latency cao"
Staff: "Service A có latency cao vì B, C, D interconnect theo cách không ai design từ đầu.
        Đây là proposed architecture thay đổi cần 3 teams implement trong 2 quý.
        Trade-off là X và Y. Đây là migration path. Đây là rollback plan."

Senior ADR: "Chúng ta sẽ dùng Redis cho caching vì nó fast và team biết dùng"
Staff ADR:  "Chúng ta sẽ dùng Redis cho caching. Đây là 3 alternatives tôi đã evaluate.
            Redis wins vì [specific reasons với data]. Trade-off là operational overhead,
            và đây là plan để address nó. Decision này có thể revisit khi [condition X]."

Honest Test #2 — Bạn có thực sự operate ở Staff level không?

• Bạn có thể list 3 vấn đề lớn nhất của engineering org ngay bây giờ mà không ai assign cho bạn?
• Bạn đã từng thay đổi cách nhiều teams làm việc cùng nhau (không phải chỉ code của một team)?
• Senior engineers trong org có seek out ý kiến của bạn cho quyết định quan trọng?

Level 5: Principal Engineer

Scope: Organization / Industry. Đây là level mà rất ít người reach.

"Principal Engineers là người mà khi họ nói 'chúng ta nên làm X', cả công ty thay đổi hướng đi. Không phải vì authority, mà vì track record và reasoning của họ đủ mạnh để thuyết phục."

Honest Test #3 — Principal level:

• Quyết định kỹ thuật nào của bạn trong 2 năm qua có business impact đo được (revenue, cost, user metrics)?
• Có Staff engineers trong org học hỏi từ bạn không? Bạn có thể name họ?
• Engineering approach của công ty có gì khác biệt vì bạn ở đây?

3. Bẫy Phổ Biến Khi Tự Đánh Giá

3.1 Dunning-Kruger — Bạn Đang Ở Giai Đoạn Nào?

Confidence
    │
High│      /\
    │     /  \
    │    /    \       ___________
    │   /      \     /
    │  /        \___/
Low │ /
    └─────────────────────────────── Competence
       Beginner   Expert  True Expert
       (know nothing,  (know  (know how much
        think they  enough to  they still
        know all)  doubt)     don't know)

Khi mới học một technology, confidence cao vì không biết mình không biết gì. Sau đó confidence drop khi gặp real complexity. Rồi tăng dần khi thực sự master.

Self-check: Bạn đang ở giai đoạn "tôi đã học Redis 3 tháng và tôi biết Redis" hay "tôi đã dùng Redis production 2 năm và tôi biết những gì tôi chưa biết về Redis"?

3.2 "Biết" vs "Có Thể Dùng Để Giải Quyết Vấn Đề Thực"

Level 1 — Nhận ra: "Tôi đã nghe về Kafka"
Level 2 — Hiểu khái niệm: "Kafka là distributed streaming platform, dùng cho event-driven architecture"
Level 3 — Dùng được: "Tôi đã implement Kafka consumer trong project"
Level 4 — Problem-solve: "Khi nào nên dùng Kafka vs SQS, và tại sao với traffic pattern này thì chọn cái kia"
Level 5 — Teach: "Tôi có thể mentor người khác design Kafka topology đúng cho use case của họ"

Hầu hết engineer khi nói "tôi biết X" đang ở Level 2-3,
nhưng tự đánh giá mình ở Level 4.

Honest Test #4: Lấy một technology bạn nói "tôi biết" — bạn có thể giải thích khi nào không nên dùng nó không? Nếu không, bạn chưa thực sự biết nó.

3.3 Years of Experience ≠ Growth

Engineer A: 7 năm kinh nghiệm
  Year 1: Học React
  Year 2-7: Dùng React theo cùng pattern, không đặt câu hỏi

Engineer B: 3 năm kinh nghiệm
  Year 1: Học React + hiểu tại sao React design như vậy
  Year 2: Build complex state management, gặp limits → research alternatives
  Year 3: Contribute to team's frontend architecture, mentor junior

Engineer B operate ở level cao hơn dù ít năm hơn.

Phép đo thực tế: Trong 12 tháng qua, bạn đã gặp và giải quyết bao nhiêu vấn đề thực sự mới — không phải variation của cái bạn đã làm?

3.4 Impostor Syndrome — Khi Nào Nghe, Khi Nào Không

Impostor syndrome = cảm giác mình không deserve vị trí mình đang có, dù evidence nói khác.

Khi nên nghe impostor syndrome:

• Bạn thực sự không thể articulate tại sao decision của mình đúng
• Bạn consistently miss expectations và không biết tại sao
• Bạn learn chậm hơn peers ở cùng level

Khi nên ignore impostor syndrome:

• Bạn deliver được, team tin tưởng, nhưng bạn cảm thấy "luck"
• Bạn compare mình với người có 10 năm kinh nghiệm khi bạn chỉ có 3 năm
• Bạn là người duy nhất trong phòng không tin mình capable

Calibration test: Hỏi 2-3 người đã làm việc trực tiếp với bạn: "Tôi có perform đúng kỳ vọng ở level này không?" Nếu câu trả lời là Yes nhất quán — tin họ hơn là tin tiếng nói trong đầu bạn.

3.5 Over-index Technical, Under-index "Người Khác Có Thể Làm Việc Với Bạn Không"

Giỏi technical nhưng:

• Code reviews của bạn khiến người khác ngại submit PR
• Meeting với bạn thường kết thúc với mọi người confused hơn
• Junior engineers tránh hỏi bạn

→ Đây là career ceiling thực tế, dù technical skills rất tốt.

4. Self-Assessment Toolkit Thực Tế

4.1 Checklist Câu Hỏi Tự Đánh Giá

TECHNICAL EXECUTION:
  ☐ Tôi có thể estimate task với < 30% sai số không?
  ☐ Code của tôi có cần sửa nhiều lần sau code review không?
  ☐ Tôi debug được production issues độc lập không?
  ☐ Tôi có thể giải thích trade-off của design decision của mình không?

SCOPE & AUTONOMY:
  ☐ Last month, tôi làm task nào mà không có ai giao cho tôi?
  ☐ Khi bị block, tôi tự unblock được trước khi hỏi không?
  ☐ Tôi có biết team đang làm gì trong Q tiếp theo không? Tại sao?
  ☐ Ai đang bị ảnh hưởng bởi quyết định kỹ thuật của tôi?

COMMUNICATION:
  ☐ Khi tôi viết design doc, người khác hiểu rationale không?
  ☐ Tôi có thể explain technical concept cho PM/non-tech không?
  ☐ Code review của tôi giúp người khác grow, không chỉ nitpick?

GROWTH:
  ☐ Năm nay tôi làm gì mà tôi không thể làm năm ngoái?
  ☐ Tôi đang học gì right now? Tại sao?
  ☐ Ai tôi đã help grow trong 6 tháng qua?

4.2 Work Sample Approach

Thay vì tự đánh giá theo cảm tính, nhìn vào actual work:

Lấy 3 PR gần nhất của bạn:

• PR description có đủ context cho stranger hiểu không?
• Code có require nhiều clarification từ reviewer không?
• Test coverage có đủ không, hay chỉ happy path?

Lấy 1 design decision gần nhất:

• Bạn có document alternatives đã xem xét không?
• Trade-offs có được articulate rõ không?
• Bạn có data/evidence cho choice không, hay chỉ preference?

Nhìn vào tech debt bạn tạo ra:

• 3 tháng sau khi code được push, có ai phải sửa lại nhiều không?
• Tỉ lệ "tôi tạo ra tech debt" vs "tôi xử lý tech debt của người khác" là bao nhiêu?

4.3 Calibration Với Peers

Cách làm peer calibration đúng:

1. Tìm 2-3 người: một người bạn respect (peer hoặc senior), một người mà bạn
   sẽ surprised nếu họ có opinion khác bạn.

2. Hỏi specific questions, không phải "tôi giỏi không?":
   - "Trong project X, tôi handle Y như thế nào — bạn thấy có gì tôi có thể làm tốt hơn không?"
   - "Khi bạn cần ai đó review architecture decision, bạn có nghĩ đến tôi không? Tại sao / tại sao không?"

3. Listen without defending. Nếu bạn giải thích tại sao họ sai trước khi nghe xong —
   bạn đang waste cơ hội.

4. Triangulate: Nếu 3 người nói cùng một điều về bạn, tin nó.

4.4 Stretch Assignments — Evidence Bạn Đang Operate Ở Level Tiếp Theo

Muốn prove bạn deserve Senior? Hành động như Senior trước khi được promote:

Junior → Mid:
  - Tự breakdown task mà không cần ai hỏi
  - Review code của junior và có comment valuable
  - Propose improvement, không chỉ wait for assignment

Mid → Senior:
  - Write design doc cho feature mà không ai hỏi
  - Own một technical area của team
  - Unblock junior/mid từ mình mà không cần hỏi senior khác

Senior → Staff:
  - Identify problem mà không có team nào own nó → propose solution
  - Lead project có nhiều teams involved
  - RFC được adopted bởi teams ngoài team của bạn

Staff → Principal:
  - Propose và execute architectural change org-wide
  - Develop Staff engineer từ Senior
  - Technical strategy của bạn có measurable business impact

5. Roadmap Từng Level — Transition Points Quan Trọng

5.1 Entry → Mid: Bước Từ Dependency Vào Independence

Core shift: Từ "tôi cần được tell what to do" → "tôi figure out what to do trong scope đã define"

Concrete milestones:

• Deliver feature end-to-end mà không cần break task cho bạn
• Debug production issue mà không cần ai guide từng bước
• Write test tự động (không cần nhắc)
• Code review của bạn có comment mà reviewer không phải add thêm

Timeline: 1-2 năm là bình thường. Nếu sau 2 năm vẫn cần hand-hold nhiều → có vấn đề cần address.

5.2 Mid → Senior: Bước Mà Nhiều Người Stuck Nhất

Tại sao bước này khó?

Mid level, bạn được đánh giá tốt vì: Deliver ticket đúng hạn
Senior level, bạn được đánh giá vì: Quyết định kỹ thuật đúng, team output tốt

Transition gap:
  Bạn deliver tốt nhưng chưa "care" đủ về design quality, team health, tech debt
  → Bạn là mid-level performer tốt, không phải senior performer

Core shift: Từ "tôi responsible cho task của tôi" → "tôi responsible cho technical health của cái system / area mình own"

Concrete milestones:

• Mentor được junior/mid (không chỉ answer câu hỏi mà guide thinking)
• Write design doc mà team adopt
• Identify và propose fix cho tech debt (không ai hỏi)
• Technical decision của bạn không bị revisit trong 6 tháng

Red herring: "Tôi cần biết nhiều technology hơn". Không phải. Senior là về judgment, không phải knowledge surface. Biết ít mà judge đúng > biết nhiều mà judge sai.

5.3 Senior → Staff: Khác Về Chất, Không Phải Về Lượng

Đây là transition mà hầu hết mọi người không hiểu đúng.

Nhiều Senior nghĩ Staff = "Senior giỏi hơn, biết nhiều hơn, code tốt hơn"
Thực ra: Staff = "Scope khác hoàn toàn"

Senior: "Team tôi đang làm đúng không?"
Staff:  "Teams trong org đang align đúng không? Có friction nào tôi có thể remove?"

Senior: Solve problems được giao
Staff:  Find problems không ai thấy, prioritize chúng, align resources để solve

Core shift: Từ "team impact" → "organizational impact"

Concrete milestones:

• Lead cross-team initiative từ problem identification đến delivery
• RFC của bạn thay đổi cách multiple teams làm việc
• Senior engineers seek out bạn cho complex architectural questions
• Khi bạn raise concern, leadership listen

Warning: Nhiều Senior cố force Staff bằng cách "làm nhiều hơn" — code nhiều hơn, review nhiều hơn, attend nhiều meeting hơn. Đây là wrong approach. Staff không phải về quantity, về scope.

5.4 Staff → Principal: Narrow Path, High Stakes

Rất ít người reach level này — và đó không phải failure.

Core shift: Từ "org impact" → "org direction" và potentially "industry impact"

Principal không chỉ solve problems — họ change what problems are worth solving.

Concrete evidence:

• Technical decision của bạn alter business strategy (không phải ngược lại)
• Bạn develop Staff engineers (không chỉ Senior)
• Company technical reputation ảnh hưởng bởi work của bạn
• Industry biết về bạn hoặc approach của bạn (speaking, writing, OSS)

6. Honest Conversation Về Career Ceiling

6.1 Không Phải Ai Cũng Cần Lên Principal

Đây là điều industry ít nói thẳng: Career ceiling không phải failure. Hầu hết engineers có impact lớn nhất ở Senior hoặc Staff level — đủ technical depth, đủ broad view, không phải carry organizational weight của Principal.

Nếu bạn:
  - Deliver consistently ở Senior level
  - Được team respect
  - Vẫn thấy challenging và engaged
  - Được comp fair

→ Không cần phải "climb" thêm. Đây không phải stagnation, đây là mastery.

Nếu bạn:
  - Bored với current scope
  - Thấy bạn đang solve ở higher level than title
  - Muốn organizational impact lớn hơn

→ Đây là signal để grow, không phải discontent cần suppress.

6.2 Reality ở Vietnam/Southeast Asia

Điều khác biệt so với Mỹ:

1. Level system ít formal hơn — nhiều công ty không có clear leveling rubric
   → Bạn cần tự advocate nhiều hơn, không chờ được promote "tự nhiên"

2. "Principal" ở công ty VN thường = "Staff" ở US company
   → Đừng over-compare title, compare scope và impact

3. EM track thường được pay cao hơn IC track ở nhiều công ty VN
   → Nếu bạn muốn tối đa hóa TC và impact qua people, EM có thể là path tốt hơn

4. Remote work mở ra possibility join US/Singapore company ở level cao hơn
   → Nếu bạn thực sự operate ở Senior/Staff, international company có thể pay 3-5x

6.3 Depth vs Breadth vs Leadership — Choose Your Path

Path 1: Technical Depth (IC Track)
  → Expert trong specific domain (distributed systems, ML, security)
  → Consultant-able, high-value niche
  → Principal / Distinguished Engineer

Path 2: Technical Breadth (Platform / Architecture)
  → Generalist architect, cross-system thinker
  → Staff / Principal, often org-wide scope
  → CTO path trong smaller companies

Path 3: Technical Leadership (EM Track)
  → Team building, process, organization design
  → EM → Director → VP → CTO
  → Impact thông qua people, not code

Không có path nào "đúng hơn". Sai nhất là không chọn — drift theo mặc định.

7. Tổng Hợp: 8 Honest Tests

Những câu hỏi này khó trả lời một mình. Nhưng nếu bạn honest với chính mình:

1. "Nếu tôi join công ty mới ngày mai với cùng title, tôi có prove được mình 
    deserve level đó trong 90 ngày không?"

2. "Trong 12 tháng qua, tôi đã thay đổi cách team/org làm việc — không phải 
    chỉ làm tốt trong hệ thống hiện tại?"

3. "Khi tôi nói 'tôi biết X', tôi có thể nói khi nào KHÔNG dùng X không?"

4. "Khi 3 người có ý kiến khác nhau về kỹ thuật, team nhìn về tôi để quyết không?"

5. "Trong 6 tháng qua, ai đã grow vì tôi — có thể name cụ thể không?"

6. "Quyết định kỹ thuật nào của tôi năm nay có thể trace đến business outcome cụ thể?"

7. "Tôi có thể nhận feedback mà không defend, không explain — chỉ nghe và process?"

8. "Nếu tôi honest: tôi đang grow, hay tôi đang comfortable?"

Không có score. Không có passing threshold. Mục đích của những câu hỏi này là tạo ra rubs — điểm mà bạn không thoải mái. Đó chính xác là chỗ bạn cần focus vào.

Growth không phải là về reaching một level. Nó là về consistently operate ở edge của ability của bạn — uncomfortable đủ để learn, capable đủ để deliver.