Kể dự án khi phỏng vấn FDE: cách trả lời câu hỏi “bạn đã đánh đổi gì?”

Bạn vừa kể xong dự án tâm đắc nhất: một hệ thống xử lý dữ liệu cho khách hàng, có queue, có dashboard, deploy trơn tru. Người phỏng vấn gật đầu rồi hỏi: “Bạn đã đánh đổi gì?” Đến đây, câu trả lời của nhiều ứng viên bắt đầu trôi về một danh sách công nghệ.

Đó là khoảnh khắc nhiều kỹ sư giỏi đánh rơi vòng phỏng vấn FDE, vì họ coi câu hỏi về đánh đổi là câu phụ. Thực ra nó là câu chính. Hướng dẫn của Fonzi mô tả rằng người phỏng vấn chấm quy trình của bạn: câu hỏi làm rõ, việc xác định stakeholder, triển khai theo giai đoạn và những đánh đổi được nói ra rõ ràng.

Lý do nằm ở bản chất công việc. Palantir tuyển người biết phán đoán khi mọi thứ còn mơ hồ, vì đó chính là công việc thật. Khi hỏi về đánh đổi, người phỏng vấn đang xem cách bạn ra quyết định trong tình huống phức tạp, nên câu trả lời của bạn là một bản demo thu nhỏ của việc bạn sẽ làm ở hiện trường khách hàng.

Một đánh đổi kể tốt có năm phần

Hãy hình dung mỗi quyết định trong dự án là một nút. Mỗi nút quyết định có năm phần, và thiếu phần nào thì người nghe sẽ hỏi vặn đúng chỗ đó.

Phần một là ràng buộc: thời hạn, dữ liệu, ngân sách hay một người duyệt khó tính, tức là những gì khiến bạn không thể làm mọi thứ cùng lúc. Phần hai là các phương án. FDE Academy khuyên trình bày cách làm của mình như một lựa chọn giữa nhiều lựa chọn, đừng kể nó như con đường duy nhất.

Phần ba là lựa chọn và lý do. Bài phân tích vòng phỏng vấn Palantir trên techinterview.org viết rằng khi gặp ngã rẽ, hãy nói vì sao bạn đi nhánh này. Phần bốn là cái phải trả, và đây là phần ứng viên hay né nhất, dù FDE Academy dặn phải chỉ rõ mình mất gì với mỗi lựa chọn.

Phần năm là nói cho khách hàng: bạn giải thích đánh đổi đó cho người không làm kỹ thuật như thế nào. FDE Academy ghi nhận rằng ở các vòng kiểu Palantir, ứng viên code được nhưng không giải thích được suy nghĩ của mình cho người ngoài ngành sẽ gặp rất nhiều khó khăn.

Nút quyết định nằm ở đâu trong STAR?

Phần lớn ứng viên đã quen khung STAR, nên đừng bỏ nó. Chỉ cần biết nút quyết định nằm ở chữ nào.

Ở Task, FDE Academy nhắc bạn nói rõ phần việc của riêng bạn chứ không phải của cả team. Câu “team em quyết định dùng X” không cho người hỏi biết bạn có phán đoán gì. Ở Action, phần cần nặng ký nhất, bạn nói cụ thể về quyết định kỹ thuật và những lần làm việc với khách hàng. Nút quyết định năm phần nằm trọn ở đây.

Ở Result, hãy kể cả kết quả kỹ thuật lẫn tác động lên khách hàng, có số liệu nếu được. Codemia khuyên thêm một câu về điều bạn học được và cách bạn đã đổi cách làm sau đó. Câu ấy cho người hỏi thấy bạn đã nhìn lại quyết định của mình và biết lần sau sẽ làm khác ở đâu.

Thử một ví dụ: rule-based trước, AI sau

Fonzi gợi ý một kiểu đánh đổi rất dễ kể: làm bản rule-based trước, đưa AI vào sau. Dưới đây là một tình huống giả định để bạn thấy năm phần ráp vào nhau thế nào. Mọi con số trong đó đều là giả định, khi kể bạn thay bằng số thật của mình.

Thử hình dung bạn làm cho một công ty giao hàng muốn tự động phân loại ticket khiếu nại. Bản kể có thể như sau:

“Phần việc của em là luồng phân loại ticket. Khách cần có thứ chạy được trong bốn tuần vì sắp vào mùa cao điểm. Dữ liệu gán nhãn thì gần như chưa có. Em cân nhắc hai hướng: train một model phân loại, hoặc viết rule theo từ khóa cho năm loại khiếu nại phổ biến nhất.”

“Em chọn rule vì nó chạy được trong tuần đầu và đội vận hành đọc hiểu được logic.

Cái giá là rule bỏ sót những ticket viết lòng vòng, nên em để chúng rơi vào một hàng chờ xử lý thủ công.

Em nói với trưởng nhóm vận hành thế này: bản này tự xử lý phần dễ, phần khó anh chị vẫn xem tay, còn mỗi ticket xem tay sẽ thành dữ liệu để train model ở giai đoạn hai.”

“Kết quả: khoảng 60% ticket được phân loại tự động ngay tháng đầu, thời gian chờ của khách giảm rõ. Hàng chờ thủ công cho em một bộ dữ liệu có nhãn để làm model sau đó. Bài học là lần sau em sẽ thiết kế hàng chờ thủ công ngay từ ngày đầu, chứ không đợi đến khi rule bắt đầu bỏ sót.”

Đếm lại thì đủ năm phần: ràng buộc (bốn tuần, chưa có nhãn), hai phương án, lựa chọn kèm lý do, cái phải trả (bỏ sót ticket khó) và câu nói với khách hàng. Phần kết quả có cả số kỹ thuật, tác động lên khách và một bài học.

Vì sao bản kể này chịu được câu hỏi vặn?

Người phỏng vấn có thể hỏi tiếp: “Sao không làm model luôn?” Bạn đã có sẵn câu trả lời, vì ràng buộc nằm ngay câu đầu. Câu này khớp với một nguyên tắc trong bài phân tích vòng phỏng vấn Palantir: bản nhỏ mà chạy được thắng bản công phu mà đứng yên.

Bản kể này cũng tránh được một cái bẫy FDE Academy chỉ ra: ứng viên nhảy ngay vào kiến trúc production cho thấy họ dễ xây rất nhanh một thứ sai. Bạn bắt đầu từ vấn đề của khách và từ những gì họ đang có, sau đó mới nói đến kiến trúc.

Những lỗi hay gặp

FDE Academy liệt kê một lỗi phổ biến ở vòng hành vi của FDE: câu trả lời STAR chung chung, không có tình huống khách hàng cụ thể nào. Bảng dưới đây so sánh vài câu yếu với câu mạnh hơn.

Câu yếu	Câu mạnh hơn
“Team em chọn kiến trúc microservices.”	“Em đề xuất tách riêng module X vì khách cần deploy nó độc lập, đổi lại phải vận hành thêm một service.”
“Hệ thống chạy tốt hơn nhiều.”	“Độ trễ giảm từ A xuống B, nhờ đó đội của khách xử lý đơn trong ngày.”
“Không có đánh đổi gì lớn.”	“Em bỏ tính năng Y ở giai đoạn một và đã nói rõ với khách hàng lý do.”
“Em dùng công nghệ mới nhất.”	“Em chọn công cụ quen thuộc hơn vì đội của khách phải tự bảo trì sau khi bàn giao.”

Ba lỗi còn lại khó thấy hơn. Lỗi đầu là kể một đánh đổi không có cái giá, kiểu “em chọn A vì A tốt hơn”. Lỗi thứ hai là bỏ trống phần nói với khách hàng. Lỗi cuối là kết quả chỉ có số kỹ thuật mà thiếu câu kể kết quả cho phía khách.

Chuẩn bị thế nào từ dự án bạn đang có

Nhiều developer Việt Nam làm outsourcing hoặc product cho khách nước ngoài đang có sẵn chất liệu tốt: những lần bị cắt scope, đổi yêu cầu sát hạn, hay phải giải thích với PM phía khách vì sao chưa làm được một tính năng. Đó đều là các nút quyết định chưa được kể ra.

Hãy chọn hai đến ba dự án. Với mỗi dự án, viết một nút quyết định năm phần trong không quá một trang, rồi tự hỏi ba câu vặn: sao không chọn phương án kia, nếu làm lại thì đổi gì, khách hàng phản ứng ra sao.

Sau đó tập kể bản đó cho một người không làm kỹ thuật, vì đó là người sẽ cho bạn biết phần năm có hiệu quả hay không.

Trên CV, đừng chỉ ghi stack. Một dòng theo khuôn “chọn A thay vì B vì ràng buộc C, đổi lấy kết quả D” sẽ cho người lọc hồ sơ thấy ngay bạn có phán đoán. Nếu job description của vị trí bạn nhắm tới nhấn mạnh việc làm với khách hàng hay xử lý tình huống mơ hồ, nên dành nhiều thời gian luyện phần này nhất.

Câu hỏi “bạn đã đánh đổi gì?” thật ra là để kiểm tra xem bạn có thấy mình đã bỏ lại thứ gì không. Ứng viên trả lời được câu đó là người khách hàng có thể tin khi phải đối mặt với lần cắt scope tiếp theo.