Câu này hay xuất hiện khi tuyển từ mid-level trở lên, vì công ty muốn biết bạn có nhân rộng được năng lực hay chỉ làm tốt phần của mình.
Kế hoạch tháng đầu nên nói được:
- Tuần 1 — chạy được và có kết quả nhỏ. Mục tiêu là bạn đó tự dựng được môi trường và merge được một pull request nhỏ (sửa chữ, sửa lỗi nhỏ). Cảm giác hoàn thành sớm quan trọng hơn hiểu hết kiến trúc.
- Tuần 2-3 — task thật, có ranh giới rõ. Giao task đã chia nhỏ, kèm tiêu chí hoàn thành và một mốc kiểm tra giữa chừng để bạn đó không đi sai hướng cả tuần.
- Tuần 4 — tăng độ khó, giảm mức can thiệp. Để bạn đó tự thiết kế phần nhỏ và trình bày lại trước khi code.
- Xuyên suốt: một buổi 1:1 mỗi tuần khoảng 30 phút, và quy tắc chặn: kẹt quá 60-90 phút thì phải hỏi, kèm phần đã thử.
Cách review code cho junior: phân biệt rõ bắt buộc sửa với góp ý tuỳ chọn. Giải thích lý do đằng sau chứ không chỉ ra lệnh. Đừng viết lại code của họ trong comment — đó là cách nhanh nhất khiến người mới ngừng suy nghĩ.
Ví dụ mẫu: "Em kèm một bạn fresher. Ngày đầu em ngồi cùng dựng môi trường và ghi lại vào README vì chính em cũng phát hiện tài liệu thiếu 2 bước. Em cắt task đầu tiên thành 3 phần nhỏ. Đến tháng thứ hai bạn ấy tự nhận task cỡ vừa và bắt đầu review PR cho người khác."
Lỗi hay mắc:
- "Em sẽ bảo bạn ấy tự đọc code cho quen" — không phải hướng dẫn.
- Giao task quá khó tuần đầu, hoặc ngược lại chỉ giao việc lặt vặt suốt hai tháng.
- Sửa hộ mọi lỗi vì làm hộ nhanh hơn giải thích — người mới không tiến bộ và bạn thành nút thắt.