Từ Mid lên Senior: Kỹ năng mềm – Mảnh ghép còn thiếu mà không ai nói cho bạn

Sau gần 10 năm ngồi ở vị trí review hồ sơ và phỏng vấn hàng trăm kỹ sư, tôi nhận ra một sự thật khó chịu: giỏi kỹ thuật không giúp bạn tự động trở thành Senior. Rất nhiều lập trình viên có năng lực chuyên môn mạnh – họ viết code rất tốt, thành thạo Java Spring, Kubernetes, thiết kế được những service phức tạp – nhưng họ cứ mắc kẹt mãi ở tầm Mid-level. Tại sao? Bởi vì họ chỉ tập trung vào một trụ cột duy nhất: chiều sâu kỹ thuật. Trong khi đó, để trở thành Senior thực sự, bạn cần bổ sung một mảnh ghép ít được nhắc đến hơn: kỹ năng mềm và chiến lược phát triển sự nghiệp.

Một câu chuyện quen thuộc: Long và cái bẫy “senior IC”

Long là một Java Backend Dev 4 năm kinh nghiệm ở một ngân hàng Việt Nam. Cậu ấy rất cứng về chuyên môn: Spring Boot chạy ngon lành, Kubernetes cũng ok, đã thiết kế được 2 service đang hoạt động trên production. Khi apply vào 3 vị trí Senior ở ba công ty khác nhau, Long tin rằng mình sẽ đỗ. Nhưng kết quả: trượt cả ba.

Phản hồi nhận về đại loại như sau:

Công ty A: “Kỹ thuật mạnh, nhưng thiếu ví dụ về khả năng lãnh đạo và cộng tác xuyên team.”
Công ty B: “Không thể hiện được tầm ảnh hưởng ra bên ngoài phạm vi công việc cá nhân. Trả lời câu hỏi hành vi toàn dùng ‘tụi em làm X’ thay vì ‘em chủ động dẫn dắt X’.”
Công ty C: “Xuất sắc phần coding, nhưng ở vòng System Design lại gặp khó khăn khi thảo luận về đánh đổi ở cấp độ tổ chức.”

Vấn đề của Long không phải là code. Vấn đề là cậu ấy không truyền đạt được tầm ảnh hưởng của mình, không dẫn dắt ai, không đọc được bối cảnh tổ chức, và không viết được những tài liệu quan trọng như RFC, postmortem hay kiến nghị kỹ thuật. Long rơi vào cái bẫy gọi là “senior IC trap”: làm rất tốt những task được giao, nhưng không nhân rộng được tác động của mình sang người khác. Và đây chính là điểm khác biệt cốt lõi giữa Mid và Senior.

Senior = “Multiplier” (Người nhân tác động)

Trước khi bàn về kỹ năng cụ thể, hãy hiểu rõ mô hình tư duy: cấp bậc không đo bằng lượng code bạn viết ra, mà bằng tầm tác động bạn tạo ra.

Junior (L3): Hoàn thành task được giao. Tác động = 1 người.
Mid-level (L4): Làm được task phức tạp, không cần giám sát nhiều. Tác động = 1 người, nhưng chất lượng tốt hơn.
Senior (L5): Làm tốt việc của mình, đồng thời nâng cao chất lượng cả team. Tác động = 3-5 người (mentor, định hướng, cải tiến quy trình).
Staff (L6): Định hướng kỹ thuật cho tổ chức, mentor Senior. Tác động = 10-20 người.
Principal (L7+): Tầm ảnh hưởng xuyên tổ chức, ra tới cấp độ ngành. Tác động = 50+ người.

Một Senior thực thụ không chỉ giỏi giải quyết bài toán khó, mà còn giỏi ở bốn chiều:

Phạm vi (Scope): Sở hữu một hệ thống lớn, không chỉ một tính năng.
Mơ hồ (Ambiguity): Xử lý được vấn đề không rõ ràng, không chỉ làm theo spec có sẵn.
Ảnh hưởng (Influence): Khiến người khác thay đổi hành vi mà không cần quyền ra lệnh.
Nhân rộng (Multiplier): Sản lượng của bạn × sản lượng của đội bạn, chứ không chỉ sản lượng của riêng bạn.

Vậy làm thế nào để “scale” bản thân từ 1 lên 3-5? Câu trả lời nằm ở các kỹ năng mềm dưới đây.

1. Giao tiếp hàng ngày – Nghệ thuật thể hiện sự chuyên nghiệp

Giao tiếp là “soft skill” căn bản nhất, nhưng nhiều người bỏ qua. Nó không chỉ là nói chuyện cho trôi, mà là cách bạn xây dựng thương hiệu cá nhân trong mắt đồng nghiệp và quản lý.

1-on-1 với quản lý: Đừng chỉ báo cáo, hãy chiến lược

Một sai lầm phổ biến của junior là dùng buổi gặp 1-1 hàng tuần để điểm danh công việc. Senior biến nó thành phiên trao đổi chiến lược:

10% cập nhật trạng thái (ngắn gọn).
30% thảo luận chiến lược (lộ trình, ưu tiên, trở ngại).
30% phát triển sự nghiệp (phản hồi hai chiều, lộ trình thăng tiến).
20% thông tin team/tổ chức (cross-team, chính trị nội bộ).
10% cá nhân (xây dựng quan hệ).

Bạn có thể dùng một template đơn giản (trên Notion, Google Docs) gửi trước buổi họp để cả hai cùng chuẩn bị:

Đã hoàn thành: tính năng X (link PR)
Đang làm: refactor Y (hoàn thành 60%)
Bị tắc: Đợi team infra cấp quyền cho Z
Thảo luận: Ưu tiên Q3? Có nên nhận migration auth không?
Phản hồi cho em: Em cần cải thiện gì không?

Nhờ sự chủ động này, quản lý sẽ thấy bạn là người suy nghĩ trước, biết tổ chức và sẵn sàng gánh vác.

Cập nhật standup: Thêm “phát hiện” và “cảnh báo”

Thay vì: “Hôm qua em làm ticket 123. Hôm nay em làm tiếp.”
Hãy thử: “Hôm qua em ship ticket 123, phát hiện một vấn đề test coverage ở module liên quan nên đã tạo issue #145. Hôm nay em pick task #146, dự kiến sẽ gặp blocker ở khâu phân quyền migration database.”
Bạn không chỉ báo cáo việc đã xong, mà còn phát hiện cải tiến và cảnh báo rủi ro cho team – đúng chất một senior.

Viết tin nhắn bất đồng bộ (Slack, email): Nguyên tắc BLUF

BLUF = Bottom Line Up Front (Đưa kết luận lên đầu). Người đọc luôn bận, đừng bắt họ phải đọc cả đoạn dài mới biết bạn cần gì. Ví dụ:

“Chúng ta cần rollback bản deploy. Tỉ lệ lỗi production đang là 5%. Chi tiết bên dưới…” thay vì kể lể dài dòng.
Khi hỏi, hãy đưa ra yêu cầu cụ thể: “Cần 15 phút gặp ai đã làm việc với auth flow gần đây để bàn về hướng tích hợp SSO.”

Và khi bất đồng, hãy dùng khuôn khổ “Không đồng ý nhưng cam kết”:

Nêu quan điểm trái chiều rõ ràng, kèm dữ liệu.
Lắng nghe phản biện.
Một khi quyết định đã được đưa ra, dù bạn vẫn còn lo ngại, hãy cam kết hết mình với quyết định đó.
Tuyệt đối không nửa vời hay ngấm ngầm phá hoại.

2. Code Review – Không chỉ là kiểm tra code

Code review nghe có vẻ rất kỹ thuật, nhưng cách bạn review thể hiện kỹ năng mềm đỉnh cao. Nó quyết định bạn là một người đồng nghiệp đáng mến hay khó ưa.

Năm nguyên tắc vàng khi đưa ra phản hồi

Nhận xét về code, không phải về người
- Tránh: “Bạn làm sai rồi.”
- Nên: “Cách này có vấn đề X – mình thử hướng Y xem sao?”
Phân biệt rõ ràng giữa blocking và non-blocking
- 🛑 Chặn lại: “Đoạn này sẽ gây mất dữ liệu, phải sửa trước khi merge.”
- 💭 Góp ý nhẹ (Nit): “Nhỏ thôi: tên biến có thể rõ hơn.” (tác giả có thể chọn sửa hoặc không)
- ❓ Câu hỏi: “Mình chưa rõ pattern này lắm, bạn giải thích thêm được không?” (tò mò thật sự, không phải “bắt lỗi”)
Đề xuất, không ra lệnh
- ”Dùng Stream ở đây có thể giúp code sạch hơn. Tùy bạn quyết định.”
Khen những code hay
- ”Abstract này thông minh đấy, sạch hơn hẳn cách cũ.”
- Khi nhận xét tiêu cực đi kèm với lời khen chân thành, đồng nghiệp sẽ cởi mở hơn với góp ý của bạn.
Giới hạn số lượng nhận xét
- Tối đa 3-5 ý kiến đáng kể mỗi review. Nếu có tới hơn 20 vấn đề, hãy hẹn gặp trao đổi trực tiếp thay vì “ném đá” trên PR.

Khi bạn là người nhận review

Đừng phòng thủ: Thay vì “Nhưng em làm vậy là vì…”, hãy nói “Cảm ơn anh/chị. Em chọn A vì B, sẵn sàng đổi nếu anh/chị thấy C hợp lý hơn.”
Cảm ơn người review: Đặc biệt khi họ tìm ra lỗi thực sự.
Giải quyết từng comment: Sửa, hoặc phản biện kèm dữ liệu, hoặc dời lại và tạo ticket theo dõi.

Mô tả PR cũng cần chỉn chu. Một senior sẽ viết mô tả gồm: làm gì, tại sao, cách làm, kiểm tra thế nào, phương án rollback, rủi ro. Một junior thường chỉ viết vỏn vẹn “sửa bug”.

3. Mentoring – Force multiplier (Cấp số nhân sức mạnh)

Mentor 2-3 junior thực sự biến tác động của bạn thành gấp 3-5 lần. Đây là con đường nhanh nhất để chứng tỏ bạn không chỉ code giỏi, mà còn giúp cả team giỏi hơn.

Lộ trình mentoring một junior điển hình

Tuần 1-4 (Onboard): Pair program 50% thời gian, dẫn họ đi tham quan codebase, giao ticket nhỏ để họ có chiến thắng đầu tiên trong tuần đầu.
Tháng 2-3 (Tăng tốc): Junior bắt đầu sở hữu tính năng nhỏ, bạn review kỹ và dạy thông qua PR. Giới thiệu các quy ước của team.
Tháng 4-6 (Hiệu suất cao): Junior tự làm các tính năng vừa end-to-end. Bạn chuyển sang vai trò “cố vấn”. Thử thách họ bằng việc sở hữu một subsystem.
Tháng 7-12 (Tiệm cận senior): Junior dẫn dắt dự án nhỏ. Bạn lùi lại, chỉ can thiệp khi cần. Junior bắt đầu mentor thế hệ sau.

Dạy cách câu cá, đừng đưa con cá

Khi junior hỏi: “Làm sao để làm X?”
Thay vì code hộ và gửi cho họ, hãy hỏi ngược lại: “Bạn đã thử cách nào? Điều gì làm bạn bối rối? Bạn đã đọc tài liệu này chưa?”
Dẫn dắt quá trình tư duy. Sẽ khó chịu trong ngắn hạn vì mất thời gian, nhưng dài hạn đây là khoản đầu tư nhân rộng năng lực.

Tránh các lỗi thường gặp: micromanage từng dòng code (khiến junior không tự lập), bỏ rơi họ giữa biển lớn (mất tự tin), dành 80% thời gian cho một junior giỏi nhất mà bỏ quên người khác, hay tệ hơn là nhận công lao của junior trước mặt sếp.

4. Viết tài liệu kỹ thuật – “Vũ khí” thầm lặng của Senior

Nếu code là cách bạn nói chuyện với máy tính, thì tài liệu là cách bạn nói chuyện với tổ chức. Một senior thực thụ phải viết tốt ít nhất bốn loại văn bản.

RFC (Request for Comments)

RFC là bản đề xuất trước khi đưa ra các quyết định kỹ thuật lớn: chọn công nghệ, thiết kế lại hệ thống, migration. Một RFC tốt phải đủ sức thuyết phục người đọc bằng dữ liệu. Cấu trúc thường có:

Trạng thái (Draft / Reviewing / Approved)
Bối cảnh & vấn đề hiện tại
Giải pháp đề xuất
Các phương án thay thế đã cân nhắc (kèm ưu/nhược điểm)
Rủi ro và biện pháp giảm thiểu
Tiêu chí thành công
Người review

Ví dụ về một RFC: “Di cư Order Service từ MySQL sang PostgreSQL”. Nó dùng bảng rủi ro, so sánh phương án, dẫn chứng về kết thúc hỗ trợ MySQL 5.7 và nhu cầu tính năng JSON mạnh hơn. RFC tệ là một danh sách mong muốn. RFC tốt là một câu chuyện với số liệu rõ ràng.

ADR (Architecture Decision Record)

Nhẹ ký hơn RFC, được lưu ngay trong repo (/docs/adr/) như một cuốn nhật ký quyết định kiến trúc. Mỗi ADR ghi lại: ngày, trạng thái, quyết định gì, hậu quả ra sao, các phương án thay thế. Người đi sau sẽ biết ơn bạn vì không phải “đoán mò” lý do của những quyết định kỹ thuật cũ.

Postmortem (Phân tích sau sự cố)

Đây là bản phân tích không đổ lỗi (blameless) sau mỗi lần hệ thống gặp vấn đề. Mục tiêu không phải tìm ra “ai làm sai”, mà là “hệ thống của chúng ta đã sai ở đâu để lỗi lọt tới production, và làm sao để nó không lặp lại?” Một postmortem mẫu mực gồm: dòng thời gian (timeline), nguyên nhân gốc rễ, bài học rút ra, và danh sách hành động cụ thể có chủ sở hữu và deadline.

Blog kỹ thuật – Hiện diện bên ngoài

Đây không còn là tài liệu nội bộ nữa, nhưng là cấp độ cao hơn khi bạn muốn xây dựng thương hiệu cá nhân. Viết về cách team bạn migration zero-downtime, bài học sau 6 tháng chạy một giải pháp mới, hay so sánh các cách tiếp cận – tất cả đều là tư liệu cho thấy bạn là người có tư duy dẫn dắt.

5. Ảnh hưởng mà không cần quyền lực (Influence without Authority)

Là một IC (Individual Contributor – nhân viên không quản lý), bạn không có quyền ra lệnh cho ai làm gì, nhưng bạn vẫn phải thúc đẩy sự thay đổi. Đây là kỹ năng tinh tế nhất mà bất cứ Senior nào cũng cần rèn luyện.

Ba nguồn sức mạnh ảnh hưởng của một IC:

Chuyên môn (Expertise): Mọi người nghe vì bạn am hiểu sâu nhất một lĩnh vực.
Quan hệ (Relationships): Bạn đã từng giúp đỡ họ, họ tin tưởng bạn.
Uy tín (Credibility): Bạn đã nhiều lần triển khai thành công, cách làm của bạn hiệu quả.

Lộ trình tạo ra thay đổi

Xác định thay đổi cụ thể: Không mơ hồ như “team nên test tốt hơn”, mà là “Đến Q3, thêm một stage integration test vào CI pipeline, target 70% coverage cho các service”.
Xây dựng liên minh: Tìm 1-2 senior khác ủng hộ, nói chuyện với quản lý để được chấp thuận, xác định những đồng nghiệp có thể phản đối và chủ động giải tỏa lo ngại cho họ.
Trình bày luận cứ thuyết phục: Viết bản đề xuất 1 trang (kiểu RFC thu nhỏ), kèm dữ liệu (tỉ lệ lỗi hiện tại, case study ở công ty tương tự), ước lượng công sức và lợi ích (ROI).
Thí điểm nhỏ (Pilot): Làm thử trên 1 service, ghi nhận kết quả, rồi mở rộng dần.
Biến nó thành chuẩn mực: Cập nhật convention, tài liệu onboarding, tổ chức họp rút kinh nghiệm.

Điều tối kỵ: “Senior ý kiến mạnh nhưng bằng chứng yếu”. Đừng nói “Theo anh, microservices là chân lý, monolith là rác rưởi”. Hãy nói “Service X hiện có 3 team cùng đụng vào, tần suất deploy giảm 50% trong 6 tháng. Việc tách thành 2 service cho phép team A iterate nhanh hơn. Chi phí: 2 sprint. Rủi ro: độ phức tạp distributed transaction.” Chính dữ liệu biến bạn từ một người nhiều ý kiến thành một người có tầm nhìn.

6. IC hay Manager? – Ngã rẽ sự nghiệp

Từ cấp Senior (L5) trở đi, bạn sẽ có hai con đường:

IC track (Technical Leadership): Đi sâu vào chuyên môn, kiến trúc, giải những bài toán siêu khó, mentor không chính thức. Bạn vẫn code hàng ngày. Thang bậc: Senior → Staff → Principal → Distinguished.
Manager track (People Leadership): Quản lý con người, tuyển dụng, đánh giá hiệu suất, phân bổ nguồn lực. Thời gian code giảm dần. Thang bậc: Engineering Manager → Senior Manager → Director → VP.

Một lời khuyên quan trọng: đừng chọn Manager track chỉ vì tiền hay chức danh. Rất nhiều kỹ sư giỏi nhảy sang làm quản lý, rồi kiệt sức vì thực ra họ không thích công việc với con người. Lý tưởng nhất là bạn nên thử cả hai (nhiều công ty có vị trí Tech Lead, khoảng 50/50), để cảm nhận xem công việc nào mang lại năng lượng cho bạn, thay vì rút cạn nó.

7. Performance Review & Lộ trình thăng tiến

Việc đánh giá hiệu suất không phải là bài “ứng biến”. Senior luôn chủ động thu thập bằng chứng từ trước.

”Brag doc” – Cuốn sổ ghi chiến công

Hãy tạo một file riêng (gọi là Brag Doc), cập nhật hàng tuần những gì bạn đã đạt được:

Dự án đã ship, số người dùng ảnh hưởng.
Chỉ số cải thiện (độ trễ API giảm 40%, tiết kiệm chi phí $X/tháng).
Junior bạn đã mentor và kết quả của họ.
Lời khen nhận được (email, tin nhắn Slack).
Các tín hiệu cho thấy bạn xứng đáng level tiếp theo (ví dụ: tự chủ dự án mà không cần quản lý can thiệp, hợp tác cross-team thành công).

Nhờ brag doc, khi tới kỳ review, bạn sẽ không bao giờ rơi vào cảnh “chết não” không nhớ nổi mình đã làm gì trong 6 tháng qua.

Promotion playbook (Chiến lược xin thăng chức)

Khoảng 6-12 tháng trước đợt promotion, bạn cần:

Nói thẳng với quản lý: “Em muốn đạt level X trong kỳ review tới. Anh/chị thấy em còn thiếu gì?”
Yêu cầu tiêu chí rõ ràng (hầu hết công ty lớn đều có rubric).
Với mỗi lỗ hổng, lên kế hoạch nhận project thể hiện “tín hiệu” đó. Ví dụ: còn thiếu “kinh nghiệm cross-team” → chủ động dẫn dắt tích hợp với team data trong quý tới.
Theo dõi bằng chứng qua brag doc.
Làm cho quản lý biết về công việc của bạn – đừng là người hùng thầm lặng.

Sự thật đau lòng: Chỉ làm tốt công việc thôi là chưa đủ. Bạn còn cần độ nhận diện (visibility), người bảo trợ (advocacy) và chứng minh rõ ràng rằng bạn đáp ứng đúng tiêu chí.

8. Đàm phán lương – “Lãi kép” cho cả sự nghiệp

Junior thường nhận ngay offer đầu tiên. Senior biết cách đàm phán – chỉ cần thêm 10-30% mỗi lần nhảy việc, tính theo cả sự nghiệp, con số khác biệt là khổng lồ.

Một vài nguyên tắc:

Luôn có đòn bẩy: Tốt nhất là có 2 offer cạnh tranh. Nếu chỉ có 1, hãy dùng dữ liệu thị trường (levels.fyi, Blind) để hỗ trợ.
Neo giá cao nhưng hợp lý: Khi nhà tuyển dụng hỏi kỳ vọng, đừng trả lời “Em linh hoạt, khoảng range thế nào ạ?” – hãy nói “Dựa trên mặt bằng thị trường và kinh nghiệm, em đang nhắm mức tổng thu nhập khoảng $X.” (nên đặt X ở phân vị 80 của range).
Đàm phán tổng gói (Total Comp): Lương cứng, thưởng, cổ phiếu, sign-on, phúc lợi – đều có thể thương lượng. Đôi khi công ty dễ tăng sign-on hoặc cổ phiếu hơn là lương cứng.
Yêu cầu văn bản chính thức: Những lời hứa miệng thường không đáng tin.

Một kịch bản mẫu: Offer: $80K base, $5K sign-on, $50K stock vest 4 năm. Phản hồi: “Cảm ơn anh/chị. Em rất hào hứng với cơ hội này. Dựa trên dữ liệu thị trường và một offer khác ở mức $X, em hy vọng mình có thể đạt gần mức $90K base và $20K sign-on. Liệu có linh động thêm được không ạ?” Sau đó, giữ im lặng – đừng lấp chỗ trống. Thường bạn sẽ được tăng thêm một chút. Hãy giữ thái độ tích cực, không nói dối về offer khác, và biết ơn dù kết quả ra sao.

9. Xây dựng sự hiện diện bên ngoài – Đòn bẩy dài hạn

Sự hiện diện bên ngoài không chỉ dành cho người hướng ngoại. Nó mang lại cho bạn:

Cơ hội việc làm tự tìm đến (không phải nộp đơn lạnh lùng).
Đòn bẩy đàm phán lương.
Mạng lưới quan hệ phát triển theo cấp số nhân.
Thu nhập phụ (tư vấn, khóa học).

Lộ trình với ~20 giờ mỗi tháng

Dễ (5h/tháng): Chỉnh chu hồ sơ LinkedIn, viết 1 bài/tháng về bài học kinh nghiệm, tương tác có chiều sâu vào bài người khác.
Trung bình (10h/tháng): Lập blog cá nhân trên Hashnode, Medium hoặc dev.to. Viết 1 bài chất lượng mỗi tháng (800-1500 từ) về case study, so sánh công nghệ, hoặc bài học thực tế.
Nâng cao (20h+/tháng): Phát biểu tại meetup, hội thảo, làm video YouTube, xây dựng khóa học.

Quan trọng: Đừng chờ tới khi rảnh mới làm. Chặn lịch 1 giờ mỗi tuần để viết. Sự tích lũy đều đặn qua nhiều năm mới tạo ra khác biệt, chứ không phải một bài viết hoàn hảo.

10. Tránh kiệt sức (Burnout) – Sự nghiệp là marathon

Sự nghiệp senior là một cuộc đua dài hơi, không phải chạy nước rút. Kiệt sức không chỉ giết chết sự nghiệp mà còn cả sức khỏe và cuộc sống cá nhân.

Dấu hiệu cảnh báo

Thường xuyên sợ sáng thứ Hai.
Mất ngủ vì nghĩ về công việc.
Bi quan, mỉa mai mọi dự án.
Triệu chứng thể chất: đau đầu, rối loạn tiêu hóa.
Mất hứng thú với sở thích cũ, cáu gắt với gia đình.

Cách phòng ngừa

Thiết lập ranh giới: Không Slack vào cuối tuần (trừ on-call), không làm việc sau 7 giờ tối, nghỉ phép là ngắt kết nối hoàn toàn.
Quản lý năng lượng: Nhận biết việc gì khiến bạn hứng khởi, việc gì rút cạn bạn; ưu tiên các dự án mang năng lượng.
Xoay tua sự nghiệp: Sau 2-3 năm, nếu thấy trì trệ, hãy đổi team hoặc công ty, chuyển lĩnh vực – việc thiết lập lại đường cong học tập sẽ hồi sinh động lực.
Tìm mentor và chuyên gia tâm lý: Mentor để định hướng công việc, therapist để chăm sóc sức khỏe tinh thần (đặc biệt trong ngành ngân hàng/công nghệ áp lực cao).
Có đam mê ngoài lề: Đừng để sự nghiệp là danh tính duy nhất của bạn.

Khi nào nên nghỉ việc?

Nếu bạn đã ngừng học hỏi 6 tháng, sếp/team độc hại không cải thiện, xuất hiện cơ hội tốt hơn, giá trị công ty không còn phù hợp, hoặc công việc gây tổn hại đến sức khỏe – trung thành với sự nghiệp và gia đình, đừng trung thành mù quáng với công ty.

Tổng kết: Con đường trở thành Senior thực sự

Bạn có thể sở hữu bộ kỹ năng kỹ thuật đáng nể – Java, Spring, Cloud, AI – nhưng chỉ riêng chúng sẽ đưa bạn tới ngưỡng Mid-level. Để bứt phá lên Senior và hơn thế nữa, hãy dành 10% thời gian mỗi tuần để phát triển kỹ năng mềm. 4 giờ mỗi tuần nhân với 50 tuần là 200 giờ mỗi năm, đủ để bạn thành thạo một mảng như viết lách, mentoring, đàm phán hay tạo ảnh hưởng.

Checklist thành thạo cho bạn:

Đích đến “Senior” không phải là một danh hiệu trên CV. Đó là khả năng tác động lớn hơn bản thân bạn, là lúc bạn không chỉ trả lời câu hỏi “làm thế nào?” mà còn là “tại sao?”, “có cách nào tốt hơn không?” và “làm sao để mọi người cùng tốt lên?“. Chúc bạn không chỉ là một lập trình viên giỏi, mà còn là một Senior thực thụ!

Từ Mid lên Senior: Kỹ năng mềm – Mảnh ghép còn thiếu mà không ai nói cho bạn