Tuyển dụng và onboarding engineer: loop, JD, ramp-up

Tuyển dụng là quyết định có chi phí cao nhất mà một tech lead phải đưa ra. Tuyển sai sẽ tốn 6-12 tháng đau đớn cộng thêm chi phí thay người; tuyển đúng thì ship giá trị nhiều năm liền. Chương này giới thiệu một hiring loop có khả năng phân biệt được hai phía, kèm plan onboarding biến nhân viên mới thành người đóng góp thật sự trong vòng 90 ngày.

Khi nào một quy trình tuyển dụng chính thức bắt đầu trả lại giá trị?

Có ba tín hiệu chính.

Team đang lớn dần. Vài hire đầu tiên sẽ đặt bar; những hire sau hoặc nâng bar lên hoặc kéo bar xuống. Quy trình tồn tại để bảo vệ cái bar đó.

Rủi ro bias là có thật. Việc tuyển không có rubric thường dẫn tới xu hướng chọn quá nhiều người trông giống team hiện tại. Một loop có cấu trúc kèm rubric viết ra chính là công cụ debias mạnh nhất.

Time-to-productivity quan trọng. Khi team cần nhân viên mới ship được trong vòng 6 tuần, chính plan onboard mới là thứ tạo ra điều đó trong thực tế.

Nếu bạn ở trong một team 2 người và rất ít khi tuyển, một quy trình nhẹ vẫn chạy được. Kỷ luật chỉ thật sự trả lại khi việc tuyển trở nên lặp đi lặp lại.

Cái giá khi tuyển dụng yếu là gì?

Có ba kiểu lỗi thường gặp.

Hire sai người. Sáu tháng output không đạt kỳ vọng, rồi đi tới một cuộc trò chuyện đau cho cả hai phía. Việc thay người sẽ khởi động lại toàn bộ chu kỳ từ đầu.

Ramp chậm. Đúng người đã tuyển nhưng phải mất 4 tháng họ mới đóng góp đáng kể. Ba tháng trong số đó có thể tránh được nếu onboarding tốt hơn.

Trôi bias. Team dần hội tụ về một loại engineer duy nhất. Đa dạng tư duy giảm xuống; điểm mù tăng lên.

Một hiring loop tối thiểu trông thế nào?

# Hiring Loop Engineer — {{ Tên vai trò }}

## Vòng 1: Phone screen (30 phút, recruiter hoặc hiring manager)
- Đi qua resume
- Vì sao quan tâm đến vai trò này
- Kỳ vọng lương
- Tiêu chí pass: kinh nghiệm khớp JD; ở trong timezone đích

## Vòng 2: Technical screen (60 phút, một engineer)
- 45 phút code (live hoặc review take-home)
- 15 phút thảo luận về cách tiếp cận
- Rubric: phân rã vấn đề, chất lượng code, giao tiếp
- Tiêu chí pass: 2 trong 3 chiều đạt mức "mạnh"

## Vòng 3: System design / kiến trúc (60 phút, engineer senior)
- 45 phút trên một hệ thống mà team đang thật sự xử lý
- 15 phút về một quyết định kiến trúc cũ ứng viên đã làm
- Rubric: nghĩ về đánh đổi, hỏi câu làm rõ, biết failure mode
- Tiêu chí pass: xem [khung system design](/system-design/how-to-answer)

## Vòng 4: Team fit (60 phút, hiring manager + 1 peer)
- 30 phút về giá trị và cách làm việc của team
- 30 phút về mục tiêu sự nghiệp ứng viên và feedback cho team
- Rubric: khớp phong cách cộng tác, khớp kỳ vọng phát triển
- Tiêu chí pass: chủ quan, nhưng phải tài liệu hoá

## Quyết định (trong 24 giờ sau vòng cuối)
- Cả 4 interviewer gửi feedback viết trước buổi debrief
- Debrief thảo luận; hiring manager là người quyết
- Từ chối ứng viên trong 1 tuần, kèm feedback nếu được hỏi

Hai chi tiết quan trọng. Một là mỗi vòng đều có rubric viết và tiêu chí pass cụ thể. Hai là feedback phải được gửi trước buổi debrief để giọng nói chi phối không lay được người khác.

Plan onboard 30-60-90 trông thế nào?

# Onboarding: {{ Tên nhân viên mới }}

## Mục tiêu: đóng góp được vào ngày 90.

## Tuần 1
- [ ] Ngày 1: laptop, account, access repo; ăn trưa intro với team
- [ ] Ngày 2: đọc handbook của team, [decision log](/tech-pm/decision-logs-and-adrs), ADR gần đây
- [ ] Ngày 3: pair cùng buddy; khám phá codebase
- [ ] Ngày 5: ship một PR nhỏ (sửa typo, cập nhật doc, bug nhỏ)

## Tuần 2-4
- [ ] Lấy ticket tính năng nhỏ đầu tiên
- [ ] Tham dự đầy đủ standup, các sự kiện sprint, retro
- [ ] Shadow một ca on-call
- [ ] [1-on-1](/tech-pm/one-on-ones) đầu với manager: mọi thứ đang ra sao

## Tuần 5-8
- [ ] Sở hữu một tính năng nhỏ đầu-cuối (thiết kế, code, test, ship)
- [ ] Tham gia rotation on-call ở slot nhỏ, có backup
- [ ] Dự một buổi sync xuyên team với vai quan sát viên

## Tuần 9-12
- [ ] Lead một dự án nhỏ (scope khoảng 2 tuần)
- [ ] Chạy một buổi sprint planning với vai người dẫn dắt
- [ ] Check-in 90 ngày: cái gì đang chạy, cái gì còn thiếu

## Buddy: {{ Tên engineer senior }}
## Check-in manager: hàng tuần qua 1-on-1

Việc gán buddy quan trọng. Manager xử lý các quyết định lớn; nhưng buddy mới là người trả lời các câu kiểu "push lên production thế nào", "hỏi ai về service auth", "channel Slack này có đáng mute không" - những ma sát nhỏ làm chậm ramp.

Tuyển dụng scale lên đa team như thế nào?

flowchart TB
    Need[Nhu cầu tuyển xác định] --> Loop[Loop chuẩn<br/>4 vòng]
    Loop --> Cross[Feedback xuyên team<br/>1 interviewer team partner]
    Cross --> Decision[Hiring manager + peer review]
    Decision --> Onboard[Plan onboard 90 ngày]
    Onboard --> Buddy[Buddy trong team]
    Onboard --> CrossBuddy[Buddy xuyên team<br/>cho ngữ cảnh hệ thống]

Ở quy mô lớn hơn, có hai thay đổi. Một là thêm feedback xuyên team vào loop để bắt được những hire có thể va chạm với team kế cạnh. Hai là thêm buddy xuyên team trong giai đoạn onboard, để nhân viên mới có ngữ cảnh vượt ra ngoài góc nhìn của một team.

Quy trình tuyển dụng có thể tự tạo ra những lỗi nào?

• Trôi rubric. Cùng một vai trò mà rubric khác nhau ở mỗi vòng và không khớp với nhau. Cách phòng: hiring manager sở hữu rubric, và review nó sau mỗi loop.
• Take-home quá dài. Yêu cầu 8 giờ việc không trả tiền trước cả khi vào loop. Cách phòng: cap take-home ở 90 phút nếu dùng; coding live thường thắng take-home dài.
• Plan onboard bị bỏ quên. Một file PDF được gửi ngày đầu rồi không bao giờ mở lại. Cách phòng: check-in hàng tuần trên plan ngay trong 1-on-1; buddy review vào tuần 2 và tuần 6.
• Một interviewer veto. Một người chặn hire mà không có lý do viết ra. Cách phòng: feedback phải được viết trước debrief; veto cần đi kèm một lỗi rubric được nói thành lời.

Khi nào quy trình tuyển dụng chính thức là quá liều?

Có hai trường hợp.

Tuyển một peer đã biết. Khi đưa một cựu đồng nghiệp đã từng ship cùng vào team, có thể bỏ vòng 3 và 4 nếu phù hợp. Loop chỉ thật sự cần thiết khi sàng lọc người chưa biết.

Contractor / hợp đồng có thời hạn. Một contractor 6 tuần cho một deliverable rõ ràng không cần phỏng vấn team-fit đầy đủ. Một buổi technical screen cộng với check reference là đủ.

Đi tiếp từ đây như thế nào?

Chương tiếp theo: hiệu suất và feedback - các cuộc trò chuyện có cấu trúc đi sau khi hire đã vào team. Sau đó, các chương về artifact (bắt đầu với status report) sẽ lo phần deliverable thể hiện tiến độ ra ngoài.