Câu hỏi phỏng vấn Full Stack Developer

Bạn có thể lo lắng rằng một vòng phỏng vấn full stack nghĩa là phải chuẩn bị hai buổi phỏng vấn hoàn chỉnh, frontend và backend, trong khoảng thời gian mà hầu hết ứng viên chỉ dành cho một buổi. Nỗi lo đó là hợp lý, và phần này sẽ cho thấy tại sao công việc thực ra nhỏ hơn vẻ ngoài của nó. Người phỏng vấn hiếm khi chạy lại nguyên một vòng chuyên sâu về frontend hoặc backend; họ dò tìm những chỗ các lớp gặp nhau, vì đó chính là nơi kỹ sư full stack chứng minh giá trị của danh xưng.

Hầu hết các quy trình kết hợp bốn loại vòng:

• Code: một bài toán cấu trúc dữ liệu, hoặc một nhiệm vụ thực tế như phân tích, gom nhóm, hay phân trang bản ghi, thường bằng JavaScript, TypeScript, Python, hoặc Java.
• Xây dựng tính năng: một nhiệm vụ end-to-end nhỏ, chẳng hạn một form lưu dữ liệu qua API và hiển thị lỗi kiểm tra hợp lệ, trong một trình soạn thảo dùng chung hoặc một repository làm tại nhà.
• Thiết kế xuyên suốt stack: phác thảo một tính năng như bình luận hoặc thông báo, bao gồm schema, API, trạng thái phía client, và điều gì xảy ra khi mạng gặp sự cố.
• Hành vi: kể về việc bạn phụ trách một tính năng từ ticket đến khi lên production, và một lỗi bạn đã truy vết xuyên suốt nhiều lớp.

Các câu hỏi chuyên sâu theo từng lớp vẫn xuất hiện, và các bộ câu hỏi riêng, bao gồm các trang riêng cho developer frontend và backend, nằm trong trung tâm câu hỏi phỏng vấn. Trang này tập trung vào phần nằm giữa hai lớp đó.

API là hợp đồng giữa hai nửa công việc của bạn, nên người phỏng vấn sẽ hỏi từ cả hai phía:

• Bạn sẽ thiết kế các endpoint cho một tính năng như thế nào, và mỗi endpoint trả về gì khi thành công và khi thất bại?
• Bạn thay đổi một API như thế nào mà không làm hỏng các client đã chạy trên production? (Quản lý phiên bản, thay đổi bổ sung, khoảng thời gian ngừng hỗ trợ.)
• Phân trang offset hay phân trang cursor: bạn sẽ dùng loại nào cho một activity feed, và tại sao?
• Làm sao để một POST có thể thử lại an toàn nếu client bị timeout? (Idempotency key.)
• REST, GraphQL, hay RPC cho một client cụ thể: điều gì thay đổi trong caching, over-fetching, và xử lý lỗi?
• Việc kiểm tra hợp lệ nên nằm ở đâu, phía client, phía server, hay cả hai, và bên nào là chuẩn cuối cùng?
• Làm sao để tránh truy vấn N+1 khi một endpoint danh sách trả về dữ liệu lồng nhau?

Một câu trả lời tốt nêu rõ sự đánh đổi, chứ không chỉ nêu lựa chọn. "Phân trang cursor, vì các hàng được chèn thêm trong khi người dùng cuộn sẽ làm lệch offset và gây trùng lặp mục" là câu trả lời tốt hơn việc chỉ liệt kê cả hai lựa chọn rồi dừng lại.

Có hai dạng câu hỏi phân biệt ứng viên full stack với người chuyên sâu một mảng. Dạng đầu tiên là xác thực end-to-end: hãy trình bày điều gì xảy ra từ lúc người dùng gửi form đăng nhập cho đến lúc một lệnh gọi API đã xác thực thành công. Người phỏng vấn muốn nghe xem thông tin đăng nhập được lưu ở đâu (cookie hay bộ nhớ phía client), server kiểm tra nó như thế nào, tại sao cookie HttpOnly chống lại được truy cập từ script, session dựa trên cookie cần loại bảo vệ CSRF nào, CORS ảnh hưởng ra sao đến một frontend ở origin khác, và logout cùng việc token hết hạn được xử lý như thế nào.

Dạng thứ hai là câu hỏi truy vết: "Người dùng bấm Lưu và không có gì xảy ra. Hãy trình bày cách bạn sẽ gỡ lỗi việc này." Một câu trả lời tốt sẽ đi qua từng lớp một, từ console trình duyệt và tab network, đến request và response, đến log server, rồi đến thao tác ghi vào cơ sở dữ liệu, thay vì đoán mò.

Một nữ full stack developer đang phỏng vấn tại một công ty SaaS quy mô vừa là một ví dụ điển hình. Khi được hỏi một tính năng bình luận sẽ hoạt động ra sao, cô bắt đầu từ bảng dữ liệu (bình luận có post ID, author ID, và timestamp, được đánh index theo bài viết), sau đó định nghĩa endpoint danh sách dùng phân trang cursor, mô tả việc render lạc quan (optimistic rendering) phía client kèm rollback nếu POST thất bại, và kết thúc bằng cách cô sẽ ngăn việc double-click đăng bài hai lần như thế nào. Cô giữ mỗi lớp thật ngắn gọn, và các câu hỏi tiếp theo của người phỏng vấn đi thẳng vào đúng những mối nối cô đã nêu tên.

Hãy luyện tập truy vết bằng cách nói to. Chọn một tính năng trong một ứng dụng bạn dùng hằng ngày và giải thích nó từ schema đến màn hình, rồi làm lại một lần nữa với một lỗi được cố tình đưa vào: API bị chậm, thao tác ghi chỉ thành công một phần, người dùng bị đăng xuất giữa chừng request. Hãy tự ghi âm lại, hoặc luyện tập các câu hỏi trong một buổi phỏng vấn thử bằng AI, nơi hệ thống đặt câu hỏi tiếp theo dựa trên câu trả lời bằng lời nói của bạn.

Trong các vòng phỏng vấn trực tiếp, ứng dụng desktop của SubcueAI cho macOS và Windows có thể phiên âm lời người phỏng vấn và gợi ý cấu trúc cho các câu trả lời thiết kế và hành vi ở những nơi quy định của buổi phỏng vấn cho phép hỗ trợ; tiện ích mở rộng Chrome/Edge xử lý các cuộc gọi trong tab trình duyệt, còn ứng dụng iPhone lắng nghe một cuộc gọi đang phát trên thiết bị khác. Giới hạn trung thực này quan trọng nhất trong các vòng full stack: xây dựng tính năng và các vòng code thường diễn ra trên màn hình chia sẻ, và mọi thứ trên màn hình chia sẻ đều hiển thị, nên sự hỗ trợ không áp dụng ở đó. Các bài đánh giá trực tuyến có giám sát và các thiết bị do công ty quản lý cũng nằm ngoài phạm vi hỗ trợ. Cách thiết lập nằm trong hướng dẫn.