Ôn thuật toán chỉ chuẩn bị cho một vòng trong loop phỏng vấn FDE

Thử hình dung bạn đã giải vài trăm bài LeetCode rồi bước vào vòng phỏng vấn FDE. Người phỏng vấn nói: “Một chuỗi phòng khám muốn dùng AI để giảm thời gian chờ của bệnh nhân. Bạn bắt đầu từ đâu?” Đề không có input, không có output, cũng không có ràng buộc độ phức tạp nào.

Một bài hướng dẫn phỏng vấn FDE trên techinterview.org nói thẳng rằng nếu chỉ ôn thuật toán, bạn đang học cho phần ít quan trọng nhất của bài thi. Khóa học FDE trên Educative mô tả loop gồm bốn vòng: decomposition, mô phỏng khách hàng, vòng kỹ thuật và vòng hành vi hướng khách hàng.

Trong bốn vòng ấy, ôn thuật toán chủ yếu chỉ giúp bạn ở vòng kỹ thuật.

Databricks là ví dụ rõ nhất. Theo hướng dẫn của Aced cho vị trí FDE ở công ty này, vòng decomposition kéo dài khoảng 60 phút, ứng viên phải thiết kế một hệ thống từ một mục tiêu kinh doanh mơ hồ, và vòng này được xem là trọng tâm của cả loop. Coding chỉ là một vòng 60 phút riêng.

Nếu bạn muốn làm FDE, vòng decomposition là kỹ năng cần luyện nghiêm túc nhất.

Vì sao vòng phỏng vấn chủ yếu là trò chuyện?

Câu trả lời nằm trong chính công việc. Tin tuyển dụng FDE của Anthropic mô tả việc làm trực tiếp với khách hàng chiến lược và đi công tác thường xuyên, chiếm 25–50% thời gian, đến tận nơi khách hàng để cùng họ xây sản phẩm.

Tin này cũng đòi hỏi tinh thần tự chủ cao và khả năng xử lý sự mơ hồ trong những tổ chức phức tạp.

Không khách hàng nào đưa cho FDE một spec hoàn chỉnh. Vì vậy, bài viết trên techinterview.org giải thích rằng vòng phỏng vấn mô phỏng đúng tình huống đó, và đó là lý do phần lớn thời gian là hội thoại chứ không phải gõ phím.

Định dạng decomposition do Palantir tạo ra và phổ biến, nhằm xem ứng viên có tự tìm được đường đi khi chưa ai vẽ sẵn bản đồ hay không.

Người chấm thực sự đang nghe gì?

Người chấm có một bảng tiêu chí khá cụ thể. Theo techinterview.org, họ chấm bốn thứ: phân rã có cấu trúc, đồng cảm với người dùng cuối, lập luận về dữ liệu, và phán đoán phạm vi. Khóa học trên Educative tóm gọn mục đích của vòng này là kiểm tra xem bạn có xử lý một bài toán mơ hồ một cách có hệ thống hay không.

Bốn tiêu chí này cũng giải thích lỗi phổ biến nhất mà Aced ghi nhận: nhảy thẳng vào giải pháp. Ứng viên vừa nghe đề đã nói “mình sẽ dùng RAG với vector database”. Khi đó họ đã bỏ qua người dùng cuối, chưa hỏi dữ liệu nằm ở đâu và chưa cắt phạm vi. Ba trong bốn tiêu chí đã mất trước khi buổi phỏng vấn kịp bắt đầu.

Một buổi mẫu: từ “giảm thời gian chờ” đến bản thiết kế

Quay lại đề phòng khám ở trên. Hướng dẫn Databricks khuyên dành 5–15 phút đầu để làm rõ mục tiêu rồi mới chuyển sang thiết kế kỹ thuật. Dưới đây là một kịch bản giả định cho những phút đầu đó.

Ứng viên: “Trước khi thiết kế, cho em hỏi: ‘thời gian chờ’ ở đây là từ lúc đặt lịch tới lúc được khám, hay từ lúc bệnh nhân tới quầy tới lúc gặp bác sĩ?”

Người phỏng vấn: “Thời gian ngồi ở phòng chờ.”

Ứng viên: “Ai bị ảnh hưởng nhiều nhất vì chuyện này: bệnh nhân, lễ tân hay quản lý phòng khám? Và hôm nay lễ tân xếp thứ tự khám bằng cách nào?”

Câu hỏi thứ hai thể hiện sự đồng cảm với người dùng cuối. Bạn đang tìm người sẽ dùng hệ thống mỗi ngày, chứ không chỉ người ký hợp đồng. Tiếp theo là dữ liệu:

Ứng viên: “Phòng khám có lưu giờ check-in, giờ bắt đầu khám, loại dịch vụ không? Lưu ở phần mềm quản lý hay trên giấy?”

Nếu câu trả lời là “có, trong phần mềm quản lý, khoảng hai năm”, bạn đã có cơ sở để lập luận về một mô hình dự đoán thời lượng khám. Nếu là “trên giấy”, giai đoạn đầu của dự án phải là thu thập dữ liệu, và bạn cần nói rõ điều đó.

Cuối cùng là phạm vi, phần nhiều ứng viên quên nhất:

Ứng viên: “Em đề xuất giai đoạn một chỉ làm ở một phòng khám, chỉ dự đoán thời lượng khám để lễ tân báo giờ chờ cho bệnh nhân. Việc tự động xếp lịch lại để sang giai đoạn hai, khi đã đo được dự đoán có chính xác không. Anh thấy hợp lý chứ?”

Chỉ sau khoảng 10 phút như vậy, bạn mới vẽ kiến trúc: nguồn dữ liệu, pipeline, mô hình, giao diện cho lễ tân, cách đo thành công. Lúc này bản thiết kế có lý do đằng sau từng ô. Người chấm cũng đã nghe đủ cả bốn tiêu chí.

Tự luyện theo trình tự nào?

Hãy lặp lại một trình tự cố định cho tới khi nó thành phản xạ. Đầu tiên, nhắc lại mục tiêu bằng lời của chính bạn và hỏi xem “thành công” được đo bằng gì. Tiếp theo, xác định người dùng cuối và cách họ đang làm việc hôm nay. Sau đó, hỏi dữ liệu nằm ở đâu, chất lượng ra sao, ai sở hữu.

Khi đã có ba mảnh đó, đề xuất một phạm vi nhỏ có thể giao trong vài tuần và nói rõ bạn cố ý bỏ lại phần nào. Chỉ đến lúc này mới vẽ kiến trúc, rồi kết thúc bằng cách đo kết quả.

Trong suốt buổi, hãy liên tục hỏi người phỏng vấn xem bạn có đang đi đúng hướng không, vì vòng này được thiết kế để cộng tác chứ không phải độc thoại.

Nếu tiếng Anh nói chưa phải thế mạnh của bạn, đừng chỉ luyện bằng cách viết ra giấy. Hãy luyện nói to, có bấm giờ, vì vòng thi đòi hỏi bạn suy nghĩ thành tiếng chứ không chấm bản nháp.

Một lời khuyên khi đọc job description: nếu tin tuyển dụng nhấn mạnh việc xử lý sự mơ hồ và làm việc trực tiếp với khách hàng, như tin của Anthropic, cứ chuẩn bị tinh thần rằng phần hội thoại sẽ nặng và dành nhiều giờ luyện decomposition hơn.

Những cái bẫy quen thuộc

Bẫy đầu tiên là coi các câu hỏi làm rõ như thủ tục: hỏi ba câu cho có rồi vẫn trình bày kiến trúc đã nghĩ sẵn từ đầu. Người chấm nhận ra ngay khi câu trả lời của họ không làm thay đổi thiết kế của bạn.

Bẫy thứ hai là ôm hết phạm vi. Cố giải toàn bộ bài toán trong 60 phút đồng nghĩa với bỏ trắng tiêu chí phán đoán phạm vi trong bảng chấm mà techinterview.org mô tả. Bẫy thứ ba là im lặng suy nghĩ.

Vòng này yêu cầu nói to, nên một phút im lặng là một phút người chấm không có gì để chấm.

Vòng coding vẫn cần ôn, nhưng nó chỉ chứng minh bạn viết được code. Vòng decomposition cho thấy bạn có biết nên viết code gì, cho ai hay không, và với một công việc phải tự tìm đường giữa sự mơ hồ của khách hàng, đó là thứ đáng để bạn dồn nhiều giờ luyện nhất.