Phỏng vấn FDE ở OpenAI: take-home semantic search, buổi review 60 phút và vòng code có AI

Bạn mở email của recruiter và đọc đề: dựng một hệ thống semantic search trên dữ liệu sản phẩm Amazon để ChatGPT dùng. Một ứng viên FDE ở OpenAI kể lại trên Aced rằng mình nhận đúng đề này và có một tuần để dựng một thứ chạy thật.

Đó là lời kể của một người, không phải đề chuẩn, và các nguồn mô tả quy trình không hoàn toàn giống nhau. Nhưng hướng dẫn của Aced (tên cũ là Exponent) chốt lại một điểm đáng giữ: hãy coi take-home như một sản phẩm giao cho khách hàng thật.

Đề bài là một hợp đồng nhỏ, không phải bài thi

Thời lượng là thứ đầu tiên bạn cần làm rõ, vì các nguồn nói khác nhau. Hướng dẫn của Aced cho biết bạn có khoảng một tuần để nộp code chạy được, một ứng dụng đang chạy và video walkthrough. Gaijineer và The Forward Deployed thì mô tả một take-home khoảng năm giờ, dựng một thứ thật trên API của OpenAI, kèm video.

Ngay trong Aced cũng có hai con số: bài tổng hợp về phỏng vấn FDE của Aced, nguồn mô tả buổi review 60 phút bên dưới, lại ghi take-home khoảng năm giờ, trong khi hướng dẫn riêng về OpenAI ghi khoảng một tuần. Có thể quy trình đã thay đổi, hoặc mỗi đội làm một kiểu, nên đừng lấy con số nào làm chuẩn.

Vì thế, lời khuyên thực tế là hỏi recruiter thật rõ thời hạn và những gì cần nộp, giống cách bạn chốt phạm vi với khách hàng trước khi bắt tay vào làm. Final Round AI mô tả phần video là trình bày ứng dụng như thể đang nói với một khách hàng.

Tiêu chí chấm quan trọng hơn mọi mẹo kỹ thuật. Ứng viên nhận đề Amazon kể rằng điểm số nghiêng về việc giải thích các quyết định và gắn chúng với nhu cầu khách hàng.

Final Round AI nói thẳng hơn: kỹ sư nào không trình bày rõ được bản dựng của mình thì không đi tiếp. Một mẹo retrieval ấn tượng sẽ không cứu được bài mà người chấm không chạy nổi hoặc không hiểu nổi.

Bắt đầu từ câu người dùng gõ, chưa vội vẽ kiến trúc

Perspective AI khuyên xuất phát từ job-to-be-done của khách hàng thay vì từ một kiến trúc mẫu. Thử hình dung bạn nhận đề Amazon. Đừng mở notebook ngay, hãy viết ra ba câu một người dùng ChatGPT có thể gõ: “tai nghe chống ồn dưới 100 đô cho người hay bay”, “quà cho bé 5 tuổi thích khủng long”, “ốp lưng iPhone 15 không bị ố vàng”.

Ba câu này lộ ra ngay hai loại tín hiệu. Phần ngữ nghĩa (“hay bay”, “thích khủng long”) hợp với embedding. Phần ràng buộc cứng (“dưới 100 đô”, “iPhone 15”) nên đi qua metadata filter, vì embedding so sánh con số rất kém, và đây là loại quyết định bạn sẽ phải giải thích sau này.

Tiếp theo là cách biểu diễn một sản phẩm. Một bản ghi thường có tiêu đề, thương hiệu, danh mục, vài dòng mô tả đặc điểm và có thể có review. Phương án đơn giản nhất mà vẫn bảo vệ được là mỗi sản phẩm một văn bản ngắn, còn giá và danh mục giữ làm trường lọc:

def product_to_text(p):
    # One document per product; price stays structured for filtering
    lines = [p["title"], f"Brand: {p['brand']}", f"Category: {p['category']}"]
    lines += p.get("bullets", [])[:5]
    return "\n".join(lines)

def search(query, max_price=None, k=5):
    q_vec = embed(query)
    candidates = [p for p in products if max_price is None or p["price"] <= max_price]
    return top_k_by_cosine(q_vec, candidates, k)

Chiến lược chunking xuất hiện đúng ở chỗ này. Nếu cắt mô tả dài thành nhiều đoạn, bạn phải gộp kết quả về lại từng sản phẩm. Không gộp thì cùng một món hàng có thể chiếm ba ô trong top 5.

Nếu đưa review vào, bạn có thêm ngôn ngữ đời thường như “đeo cả chuyến bay không đau tai”, nhưng cũng kéo theo nhiễu. Chọn cách nào cũng được, miễn là bạn nói được vì sao.

Cuối cùng, hãy đo. Giả sử bạn tự viết 30 truy vấn, mỗi truy vấn ghi sẵn những sản phẩm được coi là đúng. Nếu 21 truy vấn có ít nhất một sản phẩm đúng trong top 5 thì hit@5 là 70%, và đó là câu mở đầu tốt cho buổi review: “Bản đầu đạt 70%. Thêm bộ lọc giá thì lên bao nhiêu, và vì sao.”

Sổ quyết định là thứ bạn mang vào buổi review

Aced mô tả một buổi 60 phút, vừa trình bày bài làm vừa bị hỏi sâu về kỹ thuật. Bạn giải thích các lựa chọn thiết kế, rồi trả lời câu hỏi nối tiếp về RAG, về đánh đổi giữa fine-tuning và prompting, về guardrails và evals.

Hướng dẫn của Aced thêm rằng người phỏng vấn kiểm tra xem thiết kế có bắt đầu từ thứ khách hàng thực sự cần hay không.

Một câu hỏi thường gặp trong buổi này, theo Aced, là: vì sao bạn chọn cách này, và ở đâu bạn quyết định không đi hướng khác? Cách chuẩn bị tốt nhất là một sổ quyết định, ghi rõ mỗi lựa chọn kỹ thuật xuất phát từ nhu cầu nào của người dùng. Một mẫu có thể trông thế này:

Quyết định	Phương án bị loại	Lý do, theo nhu cầu người dùng	Khi nào đổi
Mỗi sản phẩm một document	Cắt mô tả thành nhiều chunk	Người dùng cần danh sách sản phẩm khác nhau, không phải đoạn văn	Khi mô tả dài làm loãng embedding
Giá là bộ lọc cứng	Đưa giá vào văn bản embedding	“Dưới 100 đô” là ràng buộc, không phải gợi ý	Gần như không đổi
Chưa dùng review	Ghép review vào document	Giữ bản đầu đơn giản, đo trước rồi mới thêm	Khi eval cho thấy hụt ở truy vấn kiểu đời thường

Cột cuối là cột đáng giá nhất. Khi bị hỏi “nếu khách hàng có mười triệu sản phẩm thì sao”, bạn không phải ứng biến vì đã ghi sẵn điều kiện khiến mình đổi ý. Hãy thêm vài dòng cho các chủ đề Aced liệt kê, chẳng hạn vì sao bạn chưa cần fine-tuning và guardrail nào chặn kết quả sai giá.

Vòng code có AI: thứ được chấm là cách bạn dùng công cụ

Ứng viên nhận đề Amazon chỉ nhắc ngắn gọn rằng ngay cả vòng coding screen cũng bật AI, không mô tả quy tắc chi tiết. Hướng dẫn của Aced nói rõ hơn: công cụ AI được phép dùng, nên bạn hãy chia sẻ màn hình và nói ra lập luận trong lúc làm.

Khi ứng viên nào cũng có công cụ như nhau, thứ duy nhất người phỏng vấn quan sát được là cách bạn nghĩ. Một đoạn vừa làm vừa nói có thể nghe thế này:

“Trước khi để AI viết, cần chốt một điều: input có thể là mảng rỗng không? Giờ nhờ nó viết bản đầu… Dòng này dùng sort, độ phức tạp n log n, với đề này chấp nhận được. Thêm một test cho trường hợp phần tử trùng, vì đây là chỗ dễ sót.”

Lời khuyên ở đây là để người phỏng vấn thấy bạn đọc kỹ code do AI sinh ra, tự đặt test và bắt lỗi trước khi chạy. Dán nguyên kết quả rồi im lặng chờ là bỏ phí cơ hội cho thấy bạn nghĩ thế nào.

Những lỗi khiến bài tốt vẫn trượt

Một lỗi dễ mắc là tối ưu nhầm chỗ: dành ba ngày thử reranker cầu kỳ nhưng không có README, không có lệnh chạy một dòng, không có bộ eval. Nếu coi đây là sản phẩm giao cho khách, như Aced khuyên, bài đó yếu hơn một hệ thống đơn giản có test và có số đo.

Một lỗi khác là video walkthrough mở đầu bằng sơ đồ kiến trúc. Hãy mở bằng truy vấn của người dùng, cho xem kết quả, rồi mới giải thích phần bên dưới. Cũng đừng trả lời câu “vì sao” bằng “vì tutorial làm vậy”, và sổ quyết định tồn tại để bạn không bao giờ phải nói câu đó.

Công sức chuẩn bị này không phí kể cả khi bạn không phỏng vấn OpenAI. Một bài search có eval, có sổ quyết định và có video 5 phút là dự án portfolio hợp với bất kỳ vị trí FDE nào.

Trên CV, hãy viết thành một dòng có con số và có khách hàng giả định, ví dụ “semantic search cho 200 sản phẩm, hit@5 từ 70% lên X% nhờ bộ lọc giá”, thay vì chỉ liệt kê “RAG, embeddings”.

Bài tập tuần này: làm lại đề Amazon trong khoảng năm giờ, mốc mà Gaijineer, The Forward Deployed và bài tổng hợp của Aced mô tả, thay vì một tuần như ứng viên kia được giao. Sau đó nhờ một người bạn đóng vai khách hàng hỏi bạn đúng 60 phút, và câu nào bạn không trả lời được thì ghi thẳng vào cột “khi nào đổi”.