Luyện vòng onsite AI-native của Sierra: buổi luyện 90 phút dựng một tính năng cùng coding agent

Ở vòng onsite AI-native của Sierra, đến một lúc người phỏng vấn đứng dậy và rời phòng. Từ lúc đó, bạn có 2 giờ để biến ý tưởng hai bên vừa định nghĩa thành một sản phẩm chạy được. Bạn được đổi hướng hoặc thu hẹp phạm vi bất cứ lúc nào.

Sierra cho biết cách tổ chức này giúp họ dễ thấy ứng viên có agency hay không, chẳng hạn khi bị kẹt thì bạn có đổi hướng không. Với một FDE, đây cũng là kỹ năng của tuần đầu tiên ở chỗ khách hàng: yêu cầu còn mơ hồ, thời gian thì ngắn, và lần cắt bớt nào cũng phải giải thích được với người khác.

Bài này hướng dẫn bạn tự dựng một buổi luyện 90 phút trên laptop. Vòng thật không ngắn như vậy: riêng pha Build của Sierra đã dài 2 giờ, chưa tính Plan và Review. Việc nén cả ba pha vào 90 phút là có chủ đích, để bạn quen quyết định cắt phạm vi khi áp lực thời gian còn lớn hơn vòng thật.

Vòng thật diễn ra thế nào?

Sierra chia vòng này thành ba phần. Trong phần Plan, bạn và người phỏng vấn cùng làm việc để định nghĩa sản phẩm sẽ dựng. Sang phần Build, người phỏng vấn ra ngoài và bạn tự dựng sản phẩm trong 2 giờ.

Đến phần Review, hai bên tranh luận về các luồng sản phẩm chính và những lựa chọn bạn đã đưa ra. Sau đó người phỏng vấn đọc code để đánh giá phán đoán kỹ thuật của bạn.

Khi lên kế hoạch, hãy nhớ điều Sierra đã nói rõ: bạn được cắt phạm vi trong lúc làm và được bỏ qua boilerplate như CRUD hay auth để dồn sức vào phần làm nên khác biệt của sản phẩm. Khi chỉ có vài giờ, quyền này rất đáng giá.

Đừng mặc định vòng nào cũng như vậy. Theo hướng dẫn của Aced (trước đây là Exponent), quy trình tuyển agent engineer có một vòng debug onsite 60 phút bằng TypeScript và React.

Aced cũng ghi nhận Sierra đã công bố thay đổi ở một số vòng. Một hướng dẫn khác trên PracHub lưu ý rằng mỗi vòng có thể có luật dùng AI riêng, và thư mời bạn nhận được là căn cứ cuối cùng.

Chuẩn bị gì trước khi bấm giờ?

Bạn cần một laptop đã cài coding agent bạn dùng hằng ngày, một repo trống, một đồng hồ đếm giờ và một người đóng vai phỏng vấn. Nếu luyện một mình, hãy viết sẵn năm câu hỏi chất vấn để tự trả lời ở cuối buổi. Theo Aced, cả quy trình tuyển dụng thường kéo dài 2-5 tuần.

Bảng dưới đây gợi ý cách chia 90 phút cho buổi luyện. Đây không phải lịch của Sierra:

Pha	Thời lượng luyện	Đầu ra phải có
Plan	10 phút	PLAN.md có luồng chính và đường cắt
Build	65 phút	Luồng chính chạy được, có kiểm tra, có xử lý lỗi
Review	15 phút	Demo và nhật ký quyết định

Bước 1: Plan trong 10 phút, viết đường cắt ra giấy

Thử hình dung người đóng vai phỏng vấn đưa ra bài toán: đội hỗ trợ khách hàng cần một màn hình cho biết cuộc hội thoại nào phải chuyển sang người thật, kèm lý do. Đề bài như vậy còn mơ hồ. Trong 10 phút này, bạn phải hỏi đủ để thu hẹp nó, rồi ghi lại:

# PLAN.md
Người dùng: trưởng ca hỗ trợ, xem đầu giờ
Luồng chính: nạp danh sách hội thoại mẫu -> gắn cờ "cần người" + lý do -> lọc theo cờ
Dữ liệu: file JSON mẫu, 20 hội thoại (bỏ CRUD: dữ liệu tĩnh đủ để chứng minh luồng)
Bỏ qua: đăng nhập (bỏ auth: một người dùng, chạy local)
Đường cắt: khi luồng chính chạy -> dừng thêm tính năng, chuyển sang kiểm tra, lỗi, demo
Phương án dự phòng: nếu phần gắn cờ kẹt quá 15 phút -> dùng luật từ khóa đơn giản

Cả hai dòng “bỏ” đều kèm lý do, và đó là chủ ý. Hướng dẫn trên PracHub khuyên chỉ bỏ boilerplate khi giải thích được rõ ràng, đồng thời đặt sẵn đường cắt: luồng chính chạy rồi thì chuyển sang kiểm tra, xử lý lỗi và demo.

Một phép thử nhanh: nếu người đóng vai phỏng vấn đọc PLAN.md mà không biết bạn sẽ dừng ở đâu, bản kế hoạch chưa đạt.

Bước 2: Cho agent biết những gì nó không nhìn thấy

Tài liệu best practices của Claude Code gói cách làm việc với agent trong ba ý: cho agent biết những gì nó không thấy, đưa cho nó một phép kiểm tra để tự chạy, và áp dụng những luật không có ngoại lệ.

Nguyên tắc này dùng được với mọi coding agent. Trước khi viết dòng code đầu tiên, hãy biến nó thành một file brief ngắn:

# AGENT.md (bản rút gọn)
Bối cảnh: công cụ nội bộ cho trưởng ca hỗ trợ; chỉ chạy local.
Không làm: đăng nhập, cơ sở dữ liệu, trang quản trị.
Kiểm tra bắt buộc sau mỗi thay đổi: chạy bộ test; 3 hội thoại mẫu
  có kết quả biết trước phải ra đúng cờ.
Luật cứng: không thêm thư viện mới khi chưa hỏi; mỗi lần chỉ sửa một phần.

Phần quan trọng nhất là ba hội thoại đã biết trước đáp án. Agent dùng chúng làm phép kiểm tra, còn bạn dùng chúng làm bằng chứng ở phần Review. Đây là bản đơn giản hóa: ở vòng thật, hãy viết phép kiểm tra bằng framework test bạn thạo nhất.

Bước 3: Build đến đường cắt rồi thôi đánh bóng

Hãy giữ vòng lặp ngắn: giao cho agent một việc nhỏ, chạy phép kiểm tra, đọc diff, rồi mới giao việc tiếp theo.

Hướng dẫn trên PracHub phân vai rất rõ: agent là công cụ tăng tốc phần triển khai, còn bạn là người làm chủ sản phẩm.

Khi bạn chấp nhận một diff mà chính mình không giải thích được, bạn đã giao quyền làm chủ sản phẩm cho agent.

Mỗi lần rẽ hướng, hãy ghi một dòng vào nhật ký quyết định. Việc này mất chưa tới một phút nhưng sẽ giúp bạn rất nhiều ở phần Review:

# DECISIONS.md
[phút 32] Gắn cờ bằng mô hình cho kết quả không ổn định trên 3 mẫu kiểm tra
  -> chuyển sang luật từ khóa + ngưỡng độ dài. Lý do: cần luồng chạy chắc trước.
[phút 51] Luồng chính chạy. Chạm đường cắt -> dừng thêm bộ lọc theo ngày.
[phút 55] Thêm xử lý file JSON hỏng: hiện thông báo thay vì trắng màn hình.

Dòng ở phút 32 chính là điều Sierra muốn thấy: bị kẹt thì đổi hướng thay vì cố đào tiếp. Sierra cho phép đổi hướng và thu hẹp phạm vi trong lúc làm. Nhờ ngưỡng 15 phút viết sẵn trong PLAN.md, bạn đưa ra quyết định đó khi đầu còn tỉnh, chứ không phải lúc đã hoảng.

Bước 4: Tập Review như một buổi tranh luận thật

Phần Review của Sierra có hai lớp: tranh luận về luồng sản phẩm và đọc code để đánh giá phán đoán kỹ thuật. Người đóng vai phỏng vấn nên hỏi vặn thật sự. Vì sao trưởng ca cần lọc theo cờ trước? Vì sao bỏ bộ lọc theo ngày? Đoạn code xử lý file hỏng nằm ở đâu?

Với mỗi câu hỏi, bạn nên mở ra được hai thứ: một dòng trong DECISIONS.md và một đoạn code mà bạn giải thích được từng nhánh. Đoạn nào do agent viết thì cứ nói thẳng, rồi giải thích vì sao bạn giữ nó.

Hướng dẫn trên PracHub dặn đừng bao giờ dùng trợ lý để lách một quy định đã nêu, và cũng đừng giấu ai là người viết code.

Những lỗi khiến buổi luyện trở nên vô ích

Lỗi phổ biến nhất là để agent quyết định thay bạn. Bạn hỏi agent “nên làm gì tiếp” rồi làm theo, nên đến phần Review bạn không có câu chuyện nào của riêng mình để kể. Lỗi thứ hai là tiêu 20 phút đầu vào đăng nhập và cơ sở dữ liệu, dù Sierra đã cho phép bỏ qua chúng.

Lỗi thứ ba là chạm đường cắt mà không dừng. Một tính năng phụ thêm vào lúc phút 70 hầu như không bao giờ đáng giá bằng phần xử lý lỗi và một bản demo chạy trơn tru.

Lỗi cuối cùng là luyện vòng nào cũng như vòng nào. Vòng debug 60 phút bằng TypeScript và React mà Aced mô tả cần một kiểu chuẩn bị khác, và luật dùng AI ở đó cũng có thể khác.

Kỹ năng này xuất hiện ở đâu tại khách hàng?

Thay người phỏng vấn bằng trưởng nhóm vận hành của khách hàng, và thay 2 giờ bằng một sprint ngắn trước buổi demo. Các bước vẫn y nguyên: cùng họ định nghĩa luồng chính, ghi rõ phần nào bỏ và vì sao, dừng ở đường cắt, rồi bảo vệ từng lựa chọn trước những người không ngồi cạnh bạn lúc code.

Về hồ sơ xin việc, mỗi buổi luyện để lại ba thứ đáng đưa vào portfolio: PLAN.md, DECISIONS.md và một repo chạy được. Trong CV, một dòng như “dựng prototype trong 2 giờ cùng coding agent, ghi lại các quyết định cắt phạm vi và đổi hướng” thuyết phục hơn một danh sách công cụ.

Khi đọc mô tả công việc FDE, hãy để ý những cụm như scoping, prototyping hay working with ambiguity. Chúng thường cho thấy vị trí đó coi trọng đúng kiểu kỹ năng bạn vừa luyện, và đó là chỗ tốt để kể câu chuyện trong DECISIONS.md.

Trong vòng phỏng vấn kiểu này, coding agent ngồi trong phòng cùng bạn. Điều nhà tuyển dụng muốn thấy là những quyết định chỉ bạn mới đưa ra được.