Phỏng vấn Forward Deployed Engineer: câu hỏi thường gặp và cách trả lời từng loại

Bạn bước vào vòng phỏng vấn cuối cho vị trí FDE, mở sẵn editor. Người phỏng vấn không đưa đề thuật toán mà nói: một bệnh viện có hồ sơ bệnh nhân nằm trong sáu hệ thống không kết nối với nhau, bạn sẽ làm gì?

Không có test case, không có input mẫu. Theo phân tích của techinterview về quy trình tuyển FDE, vòng quyết định offer thường không có dòng code nào. Vòng phỏng vấn đánh giá ba nhóm năng lực với trọng số gần ngang nhau, nên đừng dồn hết thời gian chuẩn bị cho riêng phần code.

Đây là chỗ nhiều kỹ sư giỏi trượt. Hướng dẫn chuẩn bị của fde.academy gọi thẳng tên lỗi phổ biến nhất khiến ứng viên bị loại: nhảy vào giải pháp trước khi xác định phạm vi. Phần dưới đây đi qua từng dạng câu hỏi bạn sẽ gặp và một cách trả lời dùng được cho tất cả.

Phỏng vấn mô phỏng đúng công việc

Muốn đoán đề thì hãy nhìn vào việc FDE làm hằng ngày. Tin tuyển dụng FDE của Google Cloud mô tả công việc là cùng khách hàng triển khai các giải pháp agentic làm riêng, ngay trong môi trường của khách hàng. Họ tìm “high-agency engineers with a founder’s mindset”, tức kỹ sư chủ động cao, nghĩ như người sáng lập.

Vì thế vòng kỹ thuật cũng khác vòng của kỹ sư sản phẩm. Theo fde.academy, trọng tâm không nằm ở tối ưu thuật toán mà ở tư duy tích hợp: dữ liệu đi từ đâu tới đâu, hệ thống nào là nguồn dữ liệu gốc, chỗ nào sẽ gãy.

Hướng dẫn của Aced về vòng decomposition (kiểu Palantir) nói rõ hơn: người phỏng vấn chấm cách bạn tiến tới lời giải, không chấm việc bạn có ra đúng một đáp án cụ thể hay không.

Dạng câu hỏi	Ví dụ đề	Đang kiểm tra	Việc làm đầu tiên
Chia nhỏ bài toán	Hồ sơ bệnh nhân nằm trong sáu hệ thống rời rạc	Xác định phạm vi, chia thành phần giải được	Hỏi ai dùng kết quả và để làm gì
System design	Traffic của khách hàng tăng 10 lần qua đêm, phải giữ latency và chi phí	Tư duy tích hợp, cân nhắc đánh đổi	Hỏi mục tiêu latency và trần chi phí cụ thể
Debug	Một hệ thống chạy sai trước mặt người phỏng vấn	Phương pháp, không đoán mò	Tái hiện lỗi, nêu giả thuyết
Mô phỏng khách hàng	Khách bực bội, scope creep, deadline phi thực tế	Giao tiếp, tinh thần chịu trách nhiệm	Thừa nhận vấn đề, nói bước tiếp theo
Hành vi	Giải thích khái niệm phức tạp cho người không chuyên	Tác động thật, có bằng chứng	Chọn câu chuyện có con số

Mười phút đầu quyết định kết quả

Techinterview mô tả ứng viên mạnh là người dành mười phút đầu để đặt câu hỏi. Lấy đúng đề bệnh viện để thấy mười phút đó trông thế nào. Đoạn dưới đây là kịch bản minh họa, không phải bản ghi một buổi phỏng vấn thật.

Câu đầu tiên nên là: “Ai sẽ dùng dữ liệu đã gộp, bác sĩ khi khám hay bộ phận tài chính khi đối soát?” Câu thứ hai: “Hôm nay việc đó tốn của họ bao nhiêu thời gian, hay đã gây ra sai sót nào?” Hai câu này biến “gộp sáu hệ thống” từ một dự án vô hạn thành một vấn đề có người chịu thiệt.

Sau đó mới tới câu hỏi tích hợp. Hệ thống nào đang là nguồn dữ liệu gốc cho danh tính bệnh nhân? Mỗi hệ có API hay chỉ xuất được file? Ràng buộc về quyền riêng tư và ai được xem gì? Sau 90 ngày, khách hàng sẽ nói “thành công” khi thấy điều gì?

Giả sử người phỏng vấn trả lời: bác sĩ cấp cứu cần xem lịch sử dị ứng và đơn thuốc, hiện phải mở ba màn hình.

Lúc này bạn chia bài toán thành năm phần: khớp danh tính một bệnh nhân giữa các hệ, connector đọc dữ liệu từng hệ, mô hình dữ liệu chung cho dị ứng và thuốc, một màn hình cho bác sĩ cấp cứu, và lớp phân quyền kèm nhật ký truy cập.

Rồi chọn lát cắt đầu tiên: hai hệ chứa dị ứng và đơn thuốc, một khoa, một màn hình. Bốn hệ còn lại để sau, và bạn nói rõ vì sao. Phần khớp danh tính là rủi ro lớn nhất, nên bạn đề xuất kiểm tra nó trên dữ liệu thật trước khi xây bất cứ thứ gì khác.

Trong lúc làm, hãy nói to. Fde.academy khuyên kể lại suy nghĩ khi thiết kế, vì im lặng bị hiểu là bạn đang bí. Một câu như “tôi tạm giả định có API cho hai hệ này, nếu sai thì phương án là đọc file xuất hằng đêm” cho người phỏng vấn thấy cả giả định lẫn đường lui.

Câu hỏi kỹ thuật: hỏi mục tiêu trước khi chọn công cụ

Đề system design mà Aced ghi lại cho quy trình OpenAI là một ví dụ tốt: traffic của khách hàng tăng 10 lần qua đêm, bạn giữ hệ thống trong mục tiêu latency và chi phí bằng cách nào? Phản xạ sai là liệt kê ngay autoscaling, cache, queue.

Phản xạ đúng vẫn là hỏi. Đợt tăng này tạm thời hay là mức mới? Latency đo ở p95 hay p99, cho endpoint nào? Khách hàng chấp nhận trả thêm bao nhiêu?

Mỗi câu trả lời loại bớt một nhánh: đợt tăng tạm thời có thể xử lý bằng hàng đợi và giới hạn tốc độ, còn mức mới buộc bạn bàn lại kiến trúc và chi phí với khách hàng.

Ở vòng debug, kỷ luật còn quan trọng hơn. Techinterview nhận xét rằng thay đổi từng dòng một cách ngẫu nhiên để xem cái nào ăn sẽ bị đánh giá kém. Hãy tái hiện lỗi, đọc log, nói giả thuyết thành lời, rồi mỗi lần chỉ đổi một thứ để kiểm chứng.

Một số công ty thêm bài take-home. Theo Aced, quy trình FDE của OpenAI có bài làm khoảng một tuần, nộp code chạy được kèm video walkthrough.

Đề mẫu là xây semantic search trên một danh mục sản phẩm để ChatGPT truy vấn được, rồi giải thích hệ thống. Video là nơi bạn chứng minh mình biết vì sao chọn từng thành phần, nên hãy dành thời gian cho nó như cho code.

Tình huống khách hàng: áp lực chính là đề bài

Theo fde.academy, vòng mô phỏng khách hàng kiểm tra giao tiếp và tinh thần chịu trách nhiệm. Đề được dựng quanh những áp lực có thật: khách hàng bực bội, scope creep, deadline phi thực tế, lãnh đạo khách hàng gây sức ép khi hệ thống đang sập.

Thử hình dung người phỏng vấn đóng vai giám đốc vận hành, giọng gắt vì pipeline ngừng chạy giữa giờ cao điểm. Một câu trả lời vững có bốn nhịp. Thừa nhận tác động: “Tôi hiểu đội anh đang không xử lý được đơn”. Nói điều đã biết và chưa biết. Nói việc đang làm ngay lúc này. Hẹn mốc cập nhật tiếp theo bằng giờ cụ thể.

Với scope creep, đừng nói “không” và cũng đừng gật đầu cho xong. Hãy nêu đánh đổi thành lời: thêm tính năng này thì mốc bàn giao lùi lại, hoặc bỏ bớt một hạng mục khác. Người phỏng vấn muốn thấy bạn bảo vệ được dự án mà vẫn giữ được quan hệ.

Hành vi: hai kết quả và một con số

Fde.academy khuyên mỗi câu trả lời hành vi nêu cả kết quả kỹ thuật lẫn tác động tới khách hàng, và dùng con số khi có thể. Đây là chỗ kỹ sư hay hụt: kể rất kỹ phần kiến trúc rồi dừng, không nói khách hàng được gì.

Lấy câu hỏi Aced ghi nhận ở OpenAI: kể về một lần bạn giải thích khái niệm kỹ thuật phức tạp cho khách hàng hoặc người không chuyên.

Khung trả lời: bối cảnh là ai, họ cần quyết định gì; bạn giải thích bằng hình ảnh nào và kiểm tra họ hiểu ra sao; kết quả kỹ thuật là [hệ thống đã chạy, độ chính xác hay độ trễ bao nhiêu]; tác động là [họ quyết định gì, tiết kiệm bao nhiêu giờ hay tiền].

Điền số thật của bạn vào ngoặc vuông, đừng ước lượng cho đẹp.

Khung này cũng là cách viết CV. Mỗi gạch đầu dòng nên có việc bạn làm, kết quả kỹ thuật và tác động tới người dùng. Khi đọc job description, nếu thấy cụm như “customer’s environment” hay “ship with customers”, hãy chuẩn bị ít nhất hai câu chuyện bạn từng làm việc trực tiếp với người dùng cuối.

Những lỗi làm ứng viên giỏi trượt

Lỗi đầu tiên là vội. Kỹ sư quen bài toán đã được định nghĩa sẵn nên thấy đề là vẽ kiến trúc ngay, trong khi đề FDE cố tình mơ hồ. Aced mô tả vòng decomposition là đưa ra một bài toán thực tế mơ hồ có chủ đích và yêu cầu bạn chia nhỏ, kèm lý giải.

Lỗi thứ hai là im lặng suy nghĩ rồi đưa ra kết luận hoàn chỉnh. Người phỏng vấn không chấm được quá trình mà họ không nghe thấy. Lỗi thứ ba là coi khách hàng trong vai diễn là người vô lý: khi bạn bắt đầu tranh luận đúng sai, bạn đã quên rằng việc của FDE là đưa dự án tới đích cùng họ.

Lỗi cuối cùng nằm ở khâu chuẩn bị: luyện thêm trăm bài thuật toán trong khi chưa từng tập nói to một lần. Vòng quyết định thường không có code và chấm cách bạn tiến tới lời giải, tức là chấm lập luận có cấu trúc và cách bạn truyền đạt nó. Cả hai chỉ lên tay khi bạn tập thành tiếng.

Bài tập tuần này: lấy đúng đề bệnh viện ở trên, bấm giờ, ghi âm chính mình. Nghe lại và đếm xem bạn đã hỏi bao nhiêu câu trước khi nói tới chữ “kiến trúc” đầu tiên.