Đây là câu đo chủ động và khả năng bán ý tưởng — hai thứ phân biệt người làm hết task được giao với người làm hệ thống tốt lên.
Khung trả lời:
- Vấn đề bạn tự nhận ra — nêu bằng số liệu hoặc bằng đau đớn lặp lại: build mất 20 phút, mỗi lần phát hành mất 2 tiếng thao tác tay, cùng một loại bug xuất hiện 5 lần trong quý.
- Cách bạn chứng minh giá trị trước khi xin nguồn lực — làm bản thử nhỏ trong thời gian rảnh hoặc trong một task có sẵn, đo trước và sau.
- Cách bạn trình bày cho người ra quyết định — quy về thời gian tiết kiệm, rủi ro giảm, hoặc số sự cố giảm. Không trình bày bằng thuật ngữ công nghệ.
- Kết quả và mức lan toả — team có dùng tiếp không, có thành quy chuẩn không.
Ví dụ mẫu: "Em thấy mỗi lần phát hành mất khoảng 2 tiếng thao tác tay và đã hai lần sai bước. Em dựng thử một pipeline CI cho một service nhỏ trong 2 ngày, đo lại còn 12 phút và không cần thao tác tay. Em trình bày cho lead bằng đúng hai con số đó thay vì nói về công cụ. Sau đó bọn em áp cho cả 6 service, và việc phát hành từ chỗ một người biết làm thành ai trong team cũng làm được."
Lỗi hay mắc:
- Đề xuất đổi công nghệ vì thích ("nên chuyển hết sang framework X") mà không gắn với vấn đề đo được — người phỏng vấn xem đây là dấu hiệu rủi ro.
- Tự làm âm thầm rồi merge một thay đổi lớn, không ai đồng thuận.
- Kể ý tưởng nhưng không có kết quả — không chứng minh được bạn đưa nó tới đích.
Điểm cộng: nêu được cả cải tiến bạn đề xuất nhưng bị từ chối và lý do bạn thấy hợp lý khi nhìn lại. Điều đó cho thấy bạn hiểu chi phí cơ hội, không chỉ hào hứng với cái mới.