Career & Non-TechĐiều được đánh giá là bạn có tách được nội dung góp ý khỏi giọng điệu hay không. Code review gắt là chuyện thường ở team có tiêu chuẩn cao.
Cách trả lời theo STAR: - Situation — một PR bị reviewer để lại nhiều nhận xét, có nhận xét viết cộc lốc. - Action — ba việc cụ thể:
- đọc lại phần bị góp ý và kiểm chứng bằng code
- hỏi lại rõ ràng khi chưa hiểu lý do ("anh muốn tách hàm này vì lý do test hay vì tái sử dụng?")
- sửa và ghi lại nguyên tắc đó để lần sau không lặp. - Result — PR merge được, và bạn nêu một thay đổi lâu dài: thêm quy ước vào checklist, hoặc từ đó tự review trước khi mở PR
Ví dụ mẫu: "Reviewer viết 'query này chắc chắn N+1, đọc lại đi'. Em hơi tự ái nhưng bật log SQL lên thì đúng là 1 + 50 truy vấn. Em sửa bằng eager loading, và sau đó thêm bước bật log truy vấn vào thói quen tự kiểm tra trước khi mở PR."
Lỗi hay mắc:
- Kể theo hướng đổ lỗi reviewer thiếu lịch sự — bạn sẽ bị nhìn nhận là khó làm việc chung.
- "Em luôn tiếp thu 100%" mà không có ví dụ nào bạn phản biện lại — nghe thụ động.
- Sửa cho xong mà không hiểu lý do; lần sau vẫn sai chỗ đó.
Có thể nói thêm ranh giới: nếu nhận xét công kích cá nhân chứ không nói về code, cách xử lý là trao đổi riêng hoặc nhờ lead, không đôi co trong comment PR.