Phỏng vấn FDE: vòng code chưa biến mất, nhưng không còn là bộ lọc chính

Theo hướng dẫn phỏng vấn của Exponent/aced.io, quy trình tuyển forward deployed engineer của Cognition bỏ hẳn hai vòng mà kỹ sư muốn vào big tech thường mất cả năm để ôn: coding và system design. Thay vào đó, các vòng cuối là mô phỏng khách hàng trực tiếp, chẳng hạn trình bày đề xuất trước một lãnh đạo hoặc một cuộc gọi phân tích tình huống.

Nhiều người sẽ đọc tin này thành “làm FDE không cần code giỏi”. Đọc vậy là sai. Ở Distyl AI và Databricks, vòng code vẫn còn, nhưng đã đổi bản chất và không còn là bộ lọc chính.

Vòng được coi trọng nhất là vòng người phỏng vấn đóng vai khách hàng và đưa ra một đề bài cố tình viết thiếu. Nếu bạn đã dồn hàng trăm giờ cho LeetCode để chuẩn bị chuyển sang FDE, số giờ ấy sẽ không mang lại nhiều điểm như bạn nghĩ.

Tin tốt là kỹ năng bị chấm kỹ nhất luyện được, chỉ là hiếm ai luyện nó có chủ đích.

Cognition là ngoại lệ, không phải quy luật

Distyl AI vẫn có vòng code. Một phân tích trên techinterview.org về cách công ty này tuyển FDE khuyên ứng viên chuẩn bị Python và lưu ý rằng đề bài sẽ sát với công việc hằng ngày. Vòng code ở đây kiểm tra xem bạn có làm được việc của một kỹ sư ngồi ở công ty khách hàng hay không, chứ không kiểm tra thuật toán.

Databricks cũng đi theo hướng đó. Theo hướng dẫn của Exponent/aced.io, những bài về đồ thị, thuật toán và concurrency vốn quen thuộc trong vòng phỏng vấn software engineer của Databricks hiếm khi xuất hiện ở vòng FDE. Đổi lại, quy trình có thêm một buổi phỏng vấn decomposition riêng.

Bài trên Substack AI Engineering Insider gói xu hướng này trong mấy chữ “ít LeetCode hơn, kỹ thuật thực tế hơn”, với đề code kiểu parse một file CSV lộn xộn hay viết một rate limiter.

Khóa học FDE của Educative thì xếp mô phỏng khách hàng vào một trong bốn dạng vòng xuất hiện nhất quán trong tuyển FDE, với quy trình thường gồm 4 đến 6 vòng trong 3 đến 5 tuần.

Như vậy, việc Cognition bỏ code là trường hợp cực đoan nhất của một xu hướng chung. Code vẫn được kiểm tra để biết bạn đủ chuẩn, nhưng phần quyết định bạn có được nhận hay không nằm ở một vòng khác.

Vòng lọc thật sự thường không có dòng code nào

Bài trên Substack gọi thẳng vòng decomposition là bộ lọc chính. Ứng viên nhận một bài toán doanh nghiệp mơ hồ, không có spec rõ ràng, làm trong 45 đến 60 phút và không có đáp án đúng duy nhất.

Theo techinterview.org, vòng này thường không có code: một khách hàng giả định đưa cho bạn một vấn đề còn lờ mờ, rồi chờ xem bạn xử lý thế nào.

Định dạng này không mới. Theo một hướng dẫn của aced.io về câu hỏi decomposition, Palantir là công ty nghĩ ra và phổ biến nó, và nhiều công ty tuyển FDE hiện chạy phiên bản riêng của mình.

Điểm khó của vòng này là đề bài được viết thiếu có chủ đích. Hướng dẫn của aced.io nói rõ rằng việc ứng viên tự tìm ra phạm vi, ràng buộc, dữ liệu và tiêu chí thành công đang bị thiếu cũng là một phần được chấm.

Ở Distyl, người phỏng vấn đóng vai khách hàng sẽ không tự đưa thêm chi tiết, nên ứng viên được chấm trên chính những câu hỏi họ đặt ra.

Người phỏng vấn chấm gì khi không có code?

Theo techinterview.org, người phỏng vấn chấm bốn kỹ năng: chia nhỏ vấn đề có cấu trúc, thấu hiểu người dùng cuối, lập luận dựa trên dữ liệu và phán đoán phạm vi. Không kỹ năng nào trong số đó lộ ra qua một hàm chạy đúng. Tất cả lộ ra trong cách bạn hỏi và thứ tự bạn hỏi.

Lỗi phổ biến nhất, cũng theo nguồn này, là vừa nghe đề xong đã đưa ra giải pháp, trước khi hỏi người dùng là ai và “xong” nghĩa là gì. Đây là phản xạ tự nhiên của kỹ sư giỏi. Nhiều năm được thưởng vì giải nhanh khiến bạn mặc định coi đề bài là đúng và đủ.

Thử hình dung một tình huống giả định. “Khách hàng” là một công ty logistics nói rằng họ muốn dùng AI để giảm số đơn giao trễ. Ứng viên thiếu kinh nghiệm sẽ nói ngay về mô hình dự đoán thời gian giao hàng, pipeline dữ liệu và cách deploy. Câu trả lời nghe rất kỹ thuật, nhưng có thể đang giải sai bài.

Ứng viên tốt sẽ hỏi trước. Ai đang chịu thiệt khi đơn trễ: khách hàng cuối, tài xế hay bộ phận chăm sóc khách hàng? Thế nào thì coi là trễ? Dữ liệu chuyến đi đang nằm ở đâu, sạch đến mức nào? Ba tháng nữa nhìn vào con số nào thì biết dự án đã thành công?

Có thể câu trả lời đúng chẳng cần AI, chỉ cần một cảnh báo sớm gửi cho điều phối viên.

Hướng dẫn cho vòng decomposition của Databricks đưa ra con số cụ thể: dùng 5 đến 15 phút đầu để làm rõ mục tiêu kinh doanh, sau đó mới vào thiết kế kỹ thuật. Bỏ qua chính bước hỏi này là lỗi mà techinterview.org gọi là phổ biến nhất.

Ba công ty, ba cách cân đo

Nhìn ba quy trình trong cùng một bảng sẽ thấy các công ty không bỏ kỹ năng kỹ thuật. Họ đang chuyển trọng số sang phán đoán.

	Cognition	Distyl AI	Databricks
Vòng code	Được cho là bỏ cả coding lẫn system design	Vẫn giữ, Python, giống công việc hằng ngày	Hiếm khi có bài đồ thị, thuật toán, concurrency
Vòng xoay quanh khách hàng	Các vòng cuối là mô phỏng khách hàng trực tiếp: pitch cho lãnh đạo, gọi phân tích tình huống	Decomposition, người phỏng vấn đóng vai khách hàng, được coi là vòng quan trọng	Thêm một buổi decomposition riêng, bắt đầu từ một mục tiêu kinh doanh
Điều cần chuẩn bị	Trình bày và xử lý tình huống trước khách hàng	Đặt câu hỏi, vì người phỏng vấn không tự đưa chi tiết	Dành 5 đến 15 phút đầu làm rõ mục tiêu rồi mới thiết kế

Cả ba đều đặt ứng viên trước một khách hàng chưa biết rõ mình cần gì. Khác biệt chỉ nằm ở chỗ họ còn muốn kiểm tra code đến mức nào bên cạnh đó.

Cách thiết kế này có logic. Một FDE viết code chậm hơn đồng nghiệp một chút vẫn có thể giao được dự án. Một FDE xây rất đẹp một hệ thống giải sai bài toán thì làm dự án thất bại, và thất bại đó xảy ra ngay trước mặt khách hàng. Vòng phỏng vấn đang tập trung vào loại rủi ro thứ hai.

Người chuyển nghề nên luyện gì?

Với nhiều developer Việt Nam, nhất là người làm outsourcing, yêu cầu thường đến qua BA hoặc PM dưới dạng ticket đã được viết sẵn. Bạn có thể rất giỏi biến spec thành code, nhưng hiếm khi phải tự hỏi khách hàng xem spec đó có đúng không. Vòng decomposition kiểm tra đúng kỹ năng bạn ít dùng nhất.

Kỹ năng này luyện được, và luyện theo cách bạn từng luyện LeetCode: có đề, có giờ, có người chấm. Nhờ một đồng nghiệp đóng vai khách hàng, yêu cầu họ chỉ trả lời khi được hỏi, rồi tự đánh giá theo bốn tiêu chí ở trên. Sau năm sáu buổi, bạn sẽ thấy phản xạ đưa giải pháp sớm của mình rõ đến mức nào.

Đừng bỏ code hoàn toàn: Distyl vẫn giữ vòng code bằng Python, và các mô tả về phỏng vấn FDE cho thấy đề code giờ là kỹ thuật thực tế chứ không phải LeetCode. Hãy đổi cách luyện: bớt bài thuật toán, thêm những bài như parse dữ liệu bẩn, viết rate limiter, gọi API có retry, và viết chúng như code sẽ chạy ở chỗ khách hàng.

Khi đọc job description, hãy tìm các từ như “decomposition”, “customer simulation” hay “case study”. Chúng cho bạn biết vòng nào sẽ được coi trọng. Trong CV, thay vì viết “phát triển module X bằng Python”, hãy kể lại một lần yêu cầu ban đầu còn mơ hồ, bạn đã hỏi những gì, phạm vi được chốt ra sao và kết quả là gì.

Một nhà tuyển dụng FDE đọc dòng đó sẽ thấy đúng kỹ năng mà vòng phỏng vấn của họ đang tìm.

Vòng code chưa biến mất, nhưng giờ nó chỉ cho biết bạn có đủ chuẩn để đi tiếp. Muốn được nhận, bạn cần thể hiện tốt trong buổi nói chuyện với vị khách hàng giả định chưa biết mình cần gì.