Đề bài khách đưa hiếm khi là đề bài thật: cách FDE làm rõ yêu cầu trước khi viết code

Thử hình dung khách gửi bạn đúng một dòng: “Team cần một công cụ tự động review pull request.” Trong đầu bạn đã thấy luôn giải pháp: một agent đọc diff, để lại comment rồi chấm điểm rủi ro. Ba tuần sau bạn demo, khách khen hay, nhưng thời gian từ lúc mở PR đến lúc merge vẫn y như cũ.

Track phỏng vấn FDE của Learn Cursor mở đầu đúng bằng tình huống này. Engineer phía khách sẽ đưa bạn một problem statement, và theo họ thì nó gần như không bao giờ là vấn đề thật.

Nút thắt trong ví dụ đó không nằm ở chuyện thiếu tự động hoá: review mất bốn ngày vì chỉ có hai staff engineer được quyền approve, và cả hai đều đang ngập việc.

Với một developer muốn chuyển sang FDE, đây là kỹ năng tách người làm FDE khỏi người chỉ nhận ticket. Code bạn đã biết viết. Thứ cần học là biến một câu yêu cầu mơ hồ thành một kế hoạch mà cả khách lẫn đồng đội đều tin là đúng hướng.

Yêu cầu chỉ là giả thuyết

Playbook discovery cho FDE mà Perspective AI công bố tháng 7/2026 đặt ra một giả định nghe hơi phũ: yêu cầu khách nói ra không phải yêu cầu thật. Không phải vì khách nói dối. Họ mô tả giải pháp họ tưởng tượng được, theo những công cụ họ đã biết, chứ không mô tả chỗ công việc đang tắc.

Vì thế, câu “cần tự động review PR” nên được đọc thành “khách tin rằng tự động review sẽ làm mọi thứ nhanh hơn”. Đó là một giả thuyết, và việc đầu tiên của bạn là kiểm chứng nó. Giả thuyết đúng thì bạn build tự tin hơn, còn sai thì bạn vừa tiết kiệm được ba tuần.

Câu hỏi nào lật được đề bài?

Sai lầm phổ biến là hỏi khách “anh muốn tính năng gì?”. Câu đó chỉ khiến họ nhắc lại yêu cầu ban đầu. Câu hỏi Learn Cursor đưa ra đi theo hướng khác: nhờ khách kể lại thay đổi gần nhất họ đã ship, và chỉ ra nó phải chờ lâu nhất ở đâu.

Câu hỏi này hiệu quả vì nó kéo cuộc nói chuyện về một sự việc đã xảy ra, có ngày giờ và có người thật. Dưới đây là một đoạn hội thoại giả định để bạn thấy nó diễn ra thế nào:

FDE: Anh kể lại giúp thay đổi gần nhất team mình ship nhé. Từ lúc mở PR đến lúc lên production, nó nằm chờ lâu nhất ở đâu?

Khách: Chắc ở khâu review. PR mở xong phải mất khoảng bốn ngày mới có người duyệt.

FDE: Trong bốn ngày đó ai là người duyệt? Họ đang chờ gì?

Khách: Chỉ có hai anh staff engineer được approve thôi. Họ còn lo on-call với thiết kế hệ thống nên lúc nào cũng tồn cả chục PR.

Đến đây đề bài đã đổi. Một agent comment tự động vẫn để PR nằm trong hàng đợi của đúng hai người đó. Kế hoạch hợp lý hơn có thể là giúp hai người này duyệt nhanh hơn, hoặc làm rõ loại thay đổi nào cần đến họ và loại nào không, nhưng bạn chỉ nên chọn sau khi đã kiểm chứng với khách.

Năm pha, mỗi pha cần một dấu hiệu “đã xong”

Một câu hỏi hay chưa đủ để thành phương pháp. Playbook của Perspective AI chia discovery thành năm pha nối tiếp nhau: Scope, Interview, Synthesize, Validate và Spec. Mỗi pha có một điều kiện để biết khi nào được chuyển sang pha sau.

Scope xong khi bạn vẽ được bản đồ người liên quan và hệ thống trên một trang giấy. Với ví dụ PR, trang đó có người viết code, hai approver, hệ thống CI và repo. Pha này kết thúc bằng việc gọi tên điểm ra quyết định, tức là hệ thống sẽ giúp ai thực hiện hành động gì. Nếu không nói được câu đó, bạn chưa sẵn sàng phỏng vấn.

Interview là lúc dùng những câu hỏi dựa trên sự việc như ở trên, với những người thật sự làm việc hằng ngày chứ không chỉ người gửi yêu cầu. Synthesize là gom những gì nghe được thành các cơ hội và xếp hạng chúng. Một nút thắt nhiều người cùng nhắc tới thường đáng chú ý hơn một lời phàn nàn chỉ một người nêu.

Validate là lúc bạn quay lại gặp các chuyên gia nghiệp vụ phía khách để xác nhận cơ hội đứng đầu danh sách đúng là thứ giá trị nhất nên build. Khi đã cầm bảng xếp hạng trong tay, bạn sẽ rất muốn bỏ qua bước này, và đó chính là lý do nên giữ nó. Cuối cùng, Spec được chấm bằng “bài kiểm tra bàn giao”: một đồng đội cầm spec phải build được mà không cần thêm buổi họp nào.

Những lỗi khiến discovery thất bại

Lỗi đầu tiên và phổ biến nhất là nhảy ngay vào giải pháp. Bài phân tích của techinterview.org về phỏng vấn FDE mô tả chính hiện tượng này: ứng viên vừa nghe vấn đề đã lao ngay vào giải pháp. Ngoài đời, lỗi này biến thành một bản demo đẹp không ai dùng.

Lỗi thứ hai là chỉ nói chuyện với người đưa yêu cầu. Engineer gửi ticket nhìn thấy triệu chứng, còn hai approver mới biết vì sao hàng đợi dài. Nếu bản đồ một trang của bạn chỉ có một cái tên, gần như chắc chắn bạn đang thiếu người.

Lỗi thứ ba là viết spec mà phải kèm thêm một buổi giải thích. Khi đồng đội cần họp để hiểu spec, nghĩa là các quyết định vẫn nằm trong đầu bạn. Quay lại kiểm tra xem bạn đã ghi rõ điểm ra quyết định và lý do chọn cơ hội này chưa.

Phỏng vấn đang chấm đúng kỹ năng này

Đây không chỉ là kỹ năng dùng sau khi được tuyển. Vòng decomposition của Palantir, theo techinterview.org, đánh giá khả năng tách một thách thức thực tế mơ hồ thành các phần nhỏ rồi đề xuất giải pháp. Ứng viên mạnh dành mười phút đầu để đặt câu hỏi.

Vì thế khi luyện phỏng vấn, bạn hãy tập kiềm chế phản xạ vẽ kiến trúc ngay. Hỏi ai đang dùng, việc bị kẹt ở đâu, quyết định nào đang chờ, rồi nói to bản đồ người và hệ thống trước khi đề xuất bất cứ thứ gì.

Trong CV, thay vì ghi “xây dựng công cụ X”, hãy viết một dòng kể lúc bạn phát hiện yêu cầu ban đầu sai và đã đổi hướng ra sao. Một dòng như vậy cho thấy đúng kỹ năng mà vòng decomposition chấm điểm.

Lần tới khi nhận một yêu cầu một dòng, đừng mở editor vội mà hãy mở một trang giấy trắng. Nếu chưa vẽ được ai đang chờ ai trên trang đó, bạn vẫn chưa biết mình cần build gì.