Take-home FDE chấm việc bạn hiểu khách dùng sản phẩm thế nào
Ở Cognition gần như không cần code; ở OpenAI, mỗi quyết định phải gắn với một nhu cầu của khách.

Tóm tắt nhanh
- Bài take-home FDE ở Cognition chạy ngay trong Devin và gần như không cần code; ở OpenAI, bài nộp gồm app đang chạy và video walkthrough.
- Lý do nằm ở AI: khi sản phẩm nộp vào trông giống nhau, phần lý giải quyết định giúp tách ứng viên giỏi khỏi người giỏi viết prompt.
- Người chấm muốn thấy cách bạn phân rã vấn đề, đồng cảm với người dùng cuối, lập luận bằng dữ liệu và khoanh phạm vi hợp lý.
Theo hướng dẫn của Aced (trước đây là Exponent), bài take-home cho vị trí FDE tại Cognition diễn ra ngay trong Devin, và phần code chỉ chiếm rất ít. Bài không nhằm xem bạn viết thuật toán nhanh đến đâu. Nó kiểm tra xem bạn có hiểu khách hàng dùng sản phẩm thế nào hay không.
Cognition không phải trường hợp duy nhất. Bài case study take-home của OpenAI, cũng theo Aced, kéo dài khoảng một tuần. Bạn phải nộp code chạy được, một app đang chạy và một video walkthrough, còn slide thì tùy chọn. Lời khuyên dành cho ứng viên là trong video, mỗi quyết định thiết kế phải gắn với một nhu cầu cụ thể của khách.
Nếu bạn chuẩn bị phỏng vấn FDE chỉ bằng cách giải thêm LeetCode hay đánh bóng repo cho bài take-home, rất có thể bạn đang bỏ trống đúng phần quyết định offer.
Vòng quyết định offer thường không có code
Một bài phân tích trên techinterview.org viết rằng vòng có sức nặng nhất với offer FDE thường không có dòng code nào. Ví dụ quen thuộc là vòng decomposition của Palantir. Ở đó, ứng viên nhận một thách thức thực tế còn mơ hồ, chia nó thành các phần nhỏ rồi đề xuất giải pháp, gần như không phải code.
Tiêu chí chấm cũng được nêu rõ: phân rã có cấu trúc, đồng cảm với người dùng cuối, lập luận dựa trên dữ liệu và biết khoanh phạm vi. Cả bốn tiêu chí đều không nói gì đến cú pháp. Chúng mô tả đúng những việc một FDE làm trong tuần đầu ở chỗ khách, khi chưa ai biết hệ thống cuối cùng sẽ trông thế nào.
Bài take-home đang đi cùng hướng với vòng phân rã. Xếp ba định dạng vào một bảng sẽ thấy chúng hỏi gần như cùng một câu, chỉ khác cách hỏi.
| Vòng | Định dạng | Lượng code | Câu hỏi thật sự |
|---|---|---|---|
| Take-home Cognition | Bài thực hành trong Devin | Rất ít | Bạn có dựng được sản phẩm và chạy một quy trình như khách thật không? |
| Take-home OpenAI | Khoảng một tuần: code, app chạy được, video walkthrough | Có, chấm cùng với cách đặt vấn đề theo khách | Mỗi quyết định của bạn phục vụ nhu cầu nào của khách? |
| Decomposition Palantir | Phân rã một vấn đề thực tế mơ hồ | Ít hoặc không có | Bạn chia bài toán, chọn phạm vi và nghĩ về người dùng cuối ra sao? |
Cột cuối mới là điểm chính. Ba công ty dùng ba hình thức khác nhau, nhưng đều muốn biết bạn suy nghĩ thế nào khi đứng giữa khách hàng và sản phẩm.
Vì sao code không còn đủ làm tín hiệu?
Karat, một công ty cung cấp dịch vụ phỏng vấn kỹ thuật, cho rằng bài test code và take-home giờ cho tín hiệu tuyển dụng kém tin cậy hơn trước. Karat cũng khẳng định phỏng vấn trực tiếp có người và AI cùng tham gia cho tín hiệu mạnh nhất. Nên đọc nhận định này với chút dè dặt, vì đó chính là định dạng Karat bán.
Nhìn rộng ra tuyển dụng kỹ thuật nói chung, không riêng FDE, techinterview.org cũng đi đến cùng chẩn đoán. Khi AI làm ra được một bài take-home bóng bẩy, sản phẩm nộp vào không còn cho biết ai đã làm nó, và take-home mất luôn tác dụng duy nhất là tách ứng viên giỏi khỏi người giỏi viết prompt.
Vì thế nhiều đội giữ take-home nhưng thêm một buổi walkthrough trực tiếp để ứng viên bảo vệ các quyết định của mình.
Có một phần khó giao cho AI: biết vì sao một thứ cần được làm như vậy, và cho khách nào. Một mô hình có thể sinh ra app hoàn chỉnh, nhưng nó không biết người vận hành phía khách sẽ bỏ cuộc ở bước nào. Video walkthrough của OpenAI và bài thực hành trong Devin của Cognition đều kéo trọng tâm về đúng phần đó.
Cùng một app, hai cách kể
Thử hình dung đề bài yêu cầu xây công cụ phân loại ticket hỗ trợ cho một công ty logistics. Ứng viên A nộp kiến trúc gọn gàng, test đầy đủ, rồi dành video walkthrough để nói về framework, prompt và độ trễ. Mọi thứ đều chạy, và mọi thứ đều đúng.
Ứng viên B nộp một app gần như y hệt nhưng mở đầu theo cách khác. B nói rằng nhân viên trực ca đêm cần biết ticket nào phải xử lý trước khi ca sáng bắt đầu, và mọi quyết định sau đó đều xuất phát từ nhu cầu này.
B chỉ dùng bốn nhãn thay vì mười hai, vì khi máy phân loại sai thì người trực phải sửa tay, và ít nhãn thì sửa nhanh hơn. B giữ một nhãn “không chắc chắn” để ticket mơ hồ không lọt vào hàng ưu tiên thấp. B cũng chủ động bỏ phần dashboard, vì người dùng chính không cần nó trong ca trực.
Chấm hai bài theo bốn tiêu chí của vòng phân rã, B có điểm ở cả bốn: phân rã có cấu trúc, hiểu người trực ca đêm, lập luận về dữ liệu sai nhãn và cắt phạm vi có chủ đích. A chủ yếu chứng minh được chất lượng build, và trong ví dụ này, đó là phần mà một ứng viên dùng AI tốt cũng có thể tạo ra.
Điều đó không có nghĩa code của B được phép cẩu thả. Aced lưu ý rằng ở OpenAI, người phỏng vấn xem bản thiết kế có bắt đầu từ nhu cầu và use case của khách hay không, bên cạnh chất lượng build chứ không thay thế nó. Bài tốt nhất là bài có cả hai.
Việc nên làm đầu tiên khi nhận đề là mở một file decision log trước khi mở editor. Mỗi dòng gồm bốn ô: quyết định, nhu cầu của khách mà nó phục vụ, điều bạn đánh đổi, và câu bạn cần hỏi lại khách.
Đến lúc quay video, bạn chỉ cần đi lần lượt qua file này, và buổi bảo vệ trực tiếp sau đó sẽ khó làm bạn bất ngờ.
Ghi lại chỗ vướng như một khách hàng
Theo hướng dẫn của Aced, mục tiêu bài take-home ở Cognition là cho thấy bạn dựng được Devin và chạy một quy trình thực tế. Thông tin này do ứng viên kể lại, không phải mô tả chính thức của công ty, nhưng nó vẫn chỉ ra người chấm nhìn vào cách bạn setup và chạy quy trình.
Kỹ năng này giống hệt ngày đầu ở chỗ khách. Bạn cài đặt, kết nối với hệ thống sẵn có, chạy một luồng việc thật và ghi lại chỗ nào bị vướng. Người mới thường bỏ qua bước ghi lại, trong khi chính danh sách chỗ vướng đó cho thấy bạn nhìn sản phẩm bằng mắt của khách.
Vì thế, khi làm một bài kiểu này, hãy nộp kèm danh sách chỗ vướng và cách bạn sẽ giải thích từng chỗ cho khách. Sau buổi phỏng vấn, chính tài liệu đó cũng đáng được đưa vào portfolio.
CV nên nói cùng ngôn ngữ với vòng phân rã
Một CV chỉ liệt kê công nghệ cho người đọc biết bạn build được gì, nhưng không cho biết bạn build cho ai. Một dòng tốt hơn nêu bạn đã chọn gì, vì người dùng nào cần gì, và kết quả ra sao. Dù nộp đơn ở đâu, hãy đặt người dùng vào ít nhất một gạch đầu dòng cho mỗi dự án.
Tin tuyển dụng cũng cho bạn biết nên dồn sức vào đâu. Nếu nó nhấn mạnh việc làm trực tiếp với khách hay xử lý vấn đề mơ hồ, hãy dành cho phần phân rã và walkthrough nhiều thời gian chuẩn bị ngang với thuật toán.
Trong take-home FDE bây giờ, điều tạo khác biệt là bạn nói được ai sẽ dùng sản phẩm vào sáng thứ Hai, và vì sao họ cần nó đúng như vậy.
Bài này có hữu ích không?
Cảm ơn bạn đã góp ý!
5 nguồn
- Cognition Forward Deployed Engineer Interview Guide | Sample Questions (2026) - Aced (formerly Exponent)
- OpenAI Forward Deployed Engineer (FDE) Interview Guide | Sample Questions (2026) - Aced (formerly Exponent)
- What the forward deployed engineer interview really tests · 2026-08-05
- Technical Assessments in the Age of AI: Which Formats Still Work? · 2026-08-13
- Why live coding rounds are beating take-homes in 2026 · 2026-07-24