Từ Mid lên Senior: ownership, impact, influence

Câu hỏi rất đúng lúc. Ở vòng senior, kỹ thuật chỉ là điều kiện cần. Người phỏng vấn muốn biết phạm vi bạn chịu trách nhiệm và ảnh hưởng của bạn lên người khác. Cả chương này dùng một ví dụ: bạn dẫn một team nhỏ (3 dev, 1 QA, 1 PM) làm shop-app, gồm checkout, payment, các đợt migration database và vài sự cố production.

1. Bài toán: hai dev cùng nhận ticket "checkout chậm"

Ticket SHOP-412: "Checkout p95 = 3.2s, khách bỏ giỏ hàng"

Dev Mid:
  - Profile, thấy N+1 query ở OrderService
  - Thêm JOIN FETCH, p95 còn 900ms
  - Đóng ticket

Dev Senior:
  - Cũng sửa N+1 như trên
  - Hỏi: vì sao lọt ra production? → không có alert cho p95 checkout
  - Thêm dashboard + alert p95 > 1s
  - Viết 1 trang guideline "fetch strategy" cho team, review 3 PR tương tự
  - Báo PM: conversion tăng lại bao nhiêu sau 2 tuần

Cùng một bug. Mid giải quyết task. Senior giải quyết vấn đề và nguyên nhân để nó không lặp lại, rồi đo tác động lên business.

2. Vấn đề: vì sao "code giỏi" chưa đủ

• Team có 4 người. Bạn code nhanh gấp đôi thì team chỉ nhanh thêm ~25%.
• Nếu bạn giúp 3 người kia tránh được lỗi lớn, team nhanh hơn nhiều. Đó là multiplier.
• Không ai giao cho bạn "hãy cải thiện quy trình release". Senior tự thấy và tự nhận.
• Bạn thường không có quyền ra lệnh (không phải manager), nhưng vẫn phải kéo người khác đi theo.

3. Giải pháp: 4 trục thay đổi từ Mid sang Senior

4. Ví dụ cụ thể: senior signals trên shop-app

Ví dụ 1: Ownership. Bạn làm tính năng refund. Bạn không chỉ viết API mà còn:

[x] API POST /refunds + idempotency key
[x] Metric refund_failed_total + alert
[x] Runbook: "refund kẹt PENDING thì làm gì"
[x] Demo cho CS team cách tra trạng thái
[x] Sau 1 tuần: check log lỗi, sửa 2 edge case

Ví dụ 2: Influence without authority. Team payment (team khác) trả lỗi 500 khi timeout, làm checkout retry sai. Bạn không sửa được code của họ. Cách làm:

1. Thu dữ liệu: 2% đơn bị double charge trong tuần, kèm trace ID.
2. Viết đề xuất 1 trang: trả 503 + header Retry-After, hỗ trợ idempotency key.
3. Gặp tech lead bên đó 15 phút, hỏi ràng buộc của họ trước khi đề xuất.
4. Đề nghị tự viết PR cho họ review. Họ đồng ý.

Ví dụ 3: Impact có số. Viết lại câu trong CV/phỏng vấn:

Yếu : "Em đã tối ưu checkout."
Mạnh: "Em giảm p95 checkout từ 3.2s xuống 900ms bằng cách sửa N+1
       và thêm cache giá; conversion tăng ~4% trong 2 tuần sau đó."

Ví dụ 4: Multiplier. Bạn thấy 3 lần liền junior viết migration Flyway khóa bảng orders lâu. Thay vì sửa từng PR, bạn viết checklist "migration an toàn" và thêm vào PR template.

5. Cách hoạt động: vòng ảnh hưởng của senior

        Bản thân             Team                 Tổ chức
   +--------------+   +------------------+   +-------------------+
   | Code tốt     |-->| Review, mentor,  |-->| Chuẩn chung, ADR, |
   | Test, ship   |   | guideline, chia  |   | phối hợp team     |
   | đúng hạn     |   | việc, on-call    |   | khác, roadmap     |
   +--------------+   +------------------+   +-------------------+
        Mid ≈ đây          Senior ≈ đây           Staff ≈ đây

6. So sánh: câu trả lời phỏng vấn mid vs senior

7. Khi nào nên thể hiện / không nên

• Nên: dùng "em" khi nói phần mình làm, "team" khi nói kết quả chung. Người phỏng vấn cần biết bạn làm gì.
• Nên: luôn có một con số (latency, số incident, thời gian release, số người được mentor).
• Không nên: nhận hết công về mình, hoặc kể chuyện "em làm hết vì team yếu". Đó là tín hiệu đỏ.
• Không nên: tỏ ra senior bằng cách chê công nghệ cũ của công ty cũ.

Bạn hiểu gần đúng, chỉ cần chỉnh một điểm: ảnh hưởng không đến từ chức danh mà từ uy tín (credibility). Uy tín xây bằng 3 thứ:

• Dữ liệu: "2% đơn bị double charge" thuyết phục hơn "em thấy nên sửa".
• Hiểu ràng buộc của người khác: hỏi trước "bên anh đang vướng gì?" rồi mới đề xuất.
• Giảm chi phí cho họ: "em viết PR, anh chỉ cần review" dễ được gật đầu hơn "anh sửa đi".

Mẫu câu dùng được ngay:

"Em thấy [vấn đề + số liệu]. Em hiểu bên anh đang ưu tiên [X].
 Em đề xuất [phương án nhỏ], em có thể [làm phần lớn việc].
 Anh thấy có rủi ro gì em chưa tính không?"

Câu cuối quan trọng nhất: mời họ góp ý, biến đề xuất của bạn thành quyết định chung.

Đúng rồi, ownership có phần đó. Nhưng owner tốt không phải người duy nhất biết sửa. Owner tốt làm cho việc 2 giờ sáng hiếm và ai on-call cũng xử lý được:

Owner checkout làm:
  - Alert có ý nghĩa (không spam)      → bài observability
  - Runbook cho 5 lỗi hay gặp
  - Ít nhất 2 người khác hiểu service  → giảm "bus factor"
  - Postmortem sau mỗi incident         → xem bài Incident & postmortem

Nếu chỉ một mình bạn biết service, đó là rủi ro cho team, không phải thành tích. Xem lại quy trình sự cố ở bài Incident & postmortem.

Q1. Theo bạn senior khác mid ở đâu?

🇻🇳 Tiếng Việt:

Em nghĩ khác biệt chính là phạm vi trách nhiệm và ảnh hưởng. Mid hoàn thành tốt task được giao. Senior chịu trách nhiệm cả kết quả: từ làm rõ yêu cầu, chọn trade-off, đến khi chạy ổn trên production và đo được tác động. Senior cũng làm team tốt lên qua review, mentor và chuẩn chung, chứ không chỉ tự mình code nhanh.

🇬🇧 English:

For me the main difference is scope of ownership and influence. A mid-level engineer delivers assigned tasks well. A senior owns the outcome: clarifying requirements, choosing trade-offs, running it reliably in production and measuring the impact. A senior also makes the team better through reviews, mentoring and shared standards, not just by coding faster alone.

Q2. Kể lần bạn ảnh hưởng một quyết định mà không có quyền.

🇻🇳 Tiếng Việt:

Ở shop-app, payment service của team khác trả 500 khi timeout, làm checkout retry và khoảng 2% đơn bị trừ tiền hai lần. Em không sở hữu service đó. Em gom trace ID và số liệu, hỏi tech lead bên đó về ràng buộc, rồi đề xuất trả 503 kèm idempotency key và nhận viết PR cho họ review. Sau hai tuần, double charge về 0 và hai team dùng chung chuẩn retry đó.

🇬🇧 English:

In shop-app, another team's payment service returned 500 on timeouts, our checkout retried, and about 2% of orders were charged twice. I didn't own that service. I collected trace IDs and numbers, asked their tech lead about their constraints, then proposed returning 503 with idempotency keys and offered to write the PR for them to review. Within two weeks double charges dropped to zero and both teams adopted the same retry standard.

Q3. Bạn hiểu "ownership" là gì?

🇻🇳 Tiếng Việt:

Ownership là coi kết quả là việc của mình, không chỉ code. Em lo cả monitoring, runbook, chia sẻ kiến thức để người khác on-call được, và quay lại kiểm tra sau khi release. Nếu có lỗi, em nhận trước rồi tìm cách sửa quy trình.

🇬🇧 English:

Ownership means treating the outcome as mine, not just the code. I take care of monitoring, runbooks and knowledge sharing so others can be on call, and I check back after release. When something breaks, I own it first and then fix the process.

Cách nhớ ngắn gọn

• Mid giải task, Senior giải vấn đề và nguyên nhân.
• Impact phải có số.
• Influence = dữ liệu + hiểu ràng buộc + giảm chi phí cho người khác.
• Owner tốt làm cho mình không còn là người duy nhất biết sửa.