Bài take-home FDE: dựng ứng dụng chạy được, rồi bảo vệ từng quyết định trong walkthrough

Theo hướng dẫn phỏng vấn của Aced, vòng take-home cho vị trí Forward Deployed Engineer ở OpenAI cho ứng viên khoảng một tuần. Bạn phải nộp ba thứ: code chạy được, một ứng dụng đang chạy và một video walkthrough ghi hình sẵn. Slide là tùy chọn.

Một ứng viên từng làm bài này kể rằng đề yêu cầu dựng hệ thống semantic search trên dữ liệu sản phẩm Amazon cho ChatGPT. Điều người này rút ra lại nằm ở chỗ khác: phần lớn việc chấm điểm có vẻ xoay quanh chuyện có giải thích quyết định rõ ràng và gắn chúng lại với nhu cầu khách hàng hay không.

Vì thế, ứng dụng chạy được chỉ là điều kiện để bạn được xét tiếp. Bài hướng dẫn này đi qua cách chuẩn bị bài nộp sao cho quyết định nào bạn cũng có lý do để bảo vệ. Đề semantic search ở trên sẽ là ví dụ xuyên suốt.

Bạn sẽ dựng gì, và cần chuẩn bị gì?

Kết quả cuối cùng gồm bốn phần: một ứng dụng có link chạy được, một README có kèm decision log, một bộ eval nhỏ, và kịch bản cho video walkthrough.

Bạn cần một nền tảng deploy cho ra đường link công khai để người chấm mở được, cùng một công cụ quay màn hình. Ngay từ phút đầu, hãy tạo một file trống tên DECISIONS.md và mở nó cạnh cửa sổ code.

Một lời khuyên về thời gian: đừng dồn cả tuần vào việc đánh bóng code. Nếu nhận xét của ứng viên kể trên đúng, phần giải thích quyết định có sức nặng lớn, nên hãy chừa thời gian thật sự cho tài liệu, eval và luyện walkthrough.

Bước 1: viết lại đề thành nhu cầu của một người cụ thể

Palantir có hẳn một vòng decomposition để kiểm tra khả năng tách một bài toán thực tế mơ hồ thành những phần xây được. Kỹ năng đó cũng nên là việc đầu tiên bạn làm với bài take-home, trước khi viết dòng code nào.

Với đề semantic search, thử hình dung khách hàng là người mua sắm gõ những câu như “giày chạy bộ đi mưa không trơn”. Họ không biết tên sản phẩm, chỉ biết mình cần gì. Viết điều đó vào đầu README:

## Khách hàng cần gì
- Người dùng: người mua mô tả nhu cầu bằng lời, không biết tên sản phẩm
- Thành công nghĩa là: kết quả đúng nằm trong 5 kết quả đầu
- Ngoài phạm vi: thanh toán, cá nhân hóa, đa ngôn ngữ

Kiểm tra: nếu một người không làm kỹ thuật đọc ba dòng này mà hiểu bạn đang giải bài gì, bạn có thể sang bước tiếp theo.

Bước 2: dựng một lát cắt mỏng chạy trọn từ đầu đến cuối

Đừng tối ưu bước tạo embedding khi chưa có ô tìm kiếm. Hãy làm một lát cắt mỏng: nạp một phần dữ liệu, đánh chỉ mục, nhận câu truy vấn, trả kết quả lên giao diện, rồi deploy luôn. Đề yêu cầu một ứng dụng đang chạy, và link chạy được thì có giá trị hơn mười tính năng chỉ chạy trên máy bạn.

Kiểm tra: mở link trên một trình duyệt khác, gõ ba câu truy vấn và thấy kết quả. Chỉ khi đó mới quay lại cải thiện chất lượng.

Bước 3: ghi lại quyết định ngay lúc đưa ra

Mỗi khi phải chọn giữa hai hướng, ghi lại một mục. Hướng dẫn trên fde.academy cho rằng lỗi phổ biến nhất ở vòng take-home là code hoàn hảo nhưng không có tài liệu. Cũng trong bài đó, fde.academy dẫn lại một nhận định từ nguồn khác: lời giải 70% có tài liệu tốt thắng lời giải 100% không có tài liệu.

### Q3: Chỉ đánh chỉ mục tiêu đề + mô tả, bỏ qua review
- Vì sao: người mua tả nhu cầu về tính năng sản phẩm, đó là phần mô tả
- Đánh đổi: bỏ lỡ tín hiệu từ trải nghiệm thật trong review
- Nếu khách đổi ý: thêm review thành một trường riêng, có trọng số thấp hơn

Dòng cuối là chỗ ghi điểm. Ứng viên kể trên cho biết mình chuẩn bị cả cách điều chỉnh hệ thống khi nhu cầu khách hàng thay đổi, chứ không chỉ lý do của thiết kế hiện tại.

Bước 4: chứng minh hệ thống chạy đúng bằng con số

Theo Aced, ứng viên OpenAI được chuẩn bị để trả lời câu hỏi đo thế nào thì biết một hệ thống AI đã triển khai đang chạy đúng. Vì vậy đừng nộp bài mà thiếu eval, dù nó nhỏ.

Đây là một ví dụ giả định, rút gọn cho dễ theo dõi. Bạn soạn 20 câu truy vấn, mỗi câu kèm sản phẩm mà bạn coi là đáp án đúng, rồi đếm số câu có đáp án lọt vào top 5. Nếu 14 trên 20 câu đạt, độ chính xác của bạn là 70%. Sáu câu trượt chính là phần đáng nói nhất trong video.

query, expected_product_id, in_top5
"giày chạy bộ đi mưa không trơn", P0123, yes
"tai nghe cho người đeo kính", P0456, no

Kiểm tra: bạn phải nói được vì sao từng câu trượt. Nếu nhiều câu trượt vì người dùng tả tình huống còn mô tả sản phẩm lại liệt kê thông số, bạn đã có sẵn một hướng cải tiến để trình bày.

Bước 5: nói tác động trong năm phút đầu

Hướng dẫn của Aced cho Cognition khuyên nói rõ vì sao dự án quan trọng ngay trong năm phút đầu, rồi mới đến cách xây. Áp dụng vào video: mở bằng nhu cầu của người mua và con số eval, sau đó mới mở code.

Nên nhớ người nghe có thể không cần chi tiết kỹ thuật. Một nhận định từ hướng dẫn Palantir của DataInterview, được fde.academy trích lại, cho rằng ứng viên biết code nhưng không giải thích được tư duy cho người không làm kỹ thuật sẽ gặp rất nhiều khó khăn.

Hướng dẫn của Aced cũng nói rõ walkthrough là để chứng minh bài làm đáp ứng nhu cầu khách hàng, chứ không phải để khoe code.

Bước 6: tập trước những câu hỏi “vì sao”

Sau video còn một buổi deep-dive trực tiếp. Theo Aced, buổi này xoay quanh nhu cầu khách hàng và người phỏng vấn sẽ hỏi dồn vì sao bạn chọn cách tiếp cận đó. Trước buổi này, hãy đọc lại decision log và tập trả lời mỗi mục trong ba câu.

Hãy tự đặt câu hỏi khó nhất: nếu khách hàng nói kết quả đúng nhưng chậm, bạn sẽ đổi gì trước? Nếu chưa có câu trả lời, hãy ghi thẳng nó vào mục “chưa làm được” trong README, đừng giấu đi.

Những lỗi khiến bài chạy được vẫn trượt

Kế đến là video đi qua từng file theo thứ tự thư mục. Tệ hơn cả là không có eval, nên khi bị hỏi “làm sao biết nó đúng”, bạn chỉ trả lời được “em đã thử vài câu”.

Cũng đừng mặc định công ty nào cũng ra đề giống nhau. Theo Aced, bài take-home của Cognition không phải code challenge truyền thống mà làm trong sản phẩm Devin, gần như không phải code, và ứng viên đóng vai khách hàng. Palantir thì cấm dùng AI trong suốt quá trình phỏng vấn. Hãy đọc kỹ luật chơi trước khi chọn cách làm.

Ở site khách hàng, bạn sẽ còn walkthrough nhiều lần

Bài take-home có thể xem như bản thu nhỏ của công việc. fde.academy cho rằng nhà tuyển dụng quan tâm cách bạn suy luận để xử lý vấn đề triển khai, không chỉ cách bạn viết code. PostHog cũng xếp kỹ năng giao tiếp để làm discovery với khách hàng và giải thích khái niệm kỹ thuật cho nhiều nhóm stakeholder vào năng lực cốt lõi của FDE.

Vì vậy, decision log và bộ eval không nên dừng ở bài nộp. Hãy đưa chúng vào portfolio và ghi trong CV theo dạng “định nghĩa tiêu chí thành công cùng khách hàng, đo bằng bộ eval 20 câu”. Nếu JD nhắc tới customer discovery hay làm việc với stakeholder, hãy mang sẵn decision log ấy làm ví dụ cụ thể khi được hỏi.

Kiến trúc nào rồi cũng sẽ thay đổi. Điều buổi walkthrough muốn biết là bạn có giải thích được với một khách hàng thật vì sao hệ thống chạy như vậy hay không.