Bắt đầu với bối cảnh sản phẩm

Trước hết, hãy giải thích ứng dụng làm gì, ai sử dụng ứng dụng và ứng dụng giải quyết vấn đề kinh doanh nào. Một phần giới thiệu tốt có thể là: “Tôi đã xây dựng một sàn thương mại điện tử, nơi khách hàng có thể tìm kiếm sản phẩm, so sánh giá và hoàn tất thanh toán.” Cách mở đầu này giúp người phỏng vấn hiểu lý do cần quan tâm đến những quyết định kỹ thuật được trình bày sau đó.

Hãy giữ phần mở đầu này ngắn gọn, thường trong khoảng 30 đến 60 giây, sau đó liên hệ sản phẩm với trách nhiệm của bạn. Giải thích liệu bạn làm việc trên toàn bộ ứng dụng hay phụ trách các tính năng cụ thể như xác thực, tìm kiếm sản phẩm, thanh toán hoặc dashboard quản trị. Chỉ đề cập đến quy mô nhóm và thời gian thực hiện dự án khi những thông tin đó giúp làm rõ mức độ sở hữu và trách nhiệm của bạn.

Mô tả kiến trúc Next.js

Hãy giải thích các lớp chính của dự án theo một trình tự logic: giao diện người dùng, ứng dụng Next.js, các dịch vụ bên ngoài và lớp lưu trữ dữ liệu. Ví dụ, trình duyệt có thể gửi yêu cầu đến Next.js để lấy trang sản phẩm, máy chủ có thể lấy dữ liệu sản phẩm từ một API, rồi trang hiển thị kết quả bằng các component React có thể tái sử dụng. Việc mô tả luồng request này hữu ích hơn nhiều so với chỉ nói rằng dự án sử dụng Next.js.

Sau đó, hãy mô tả cách tổ chức codebase. Bạn có thể đề cập đến một thư mục app chứa các route segment, các component dùng chung cho phần điều hướng và biểu mẫu, các tiện ích phía server để truy cập dữ liệu, cùng các schema validation cho dữ liệu đầu vào của người dùng. Tránh liệt kê mọi thư mục; hãy tập trung vào cấu trúc đã giúp nhóm tách biệt phần trình bày, business logic và hạ tầng.

Giải thích các quyết định về cơ chế render

Chiến lược rendering là một trong những phần quan trọng nhất khi thảo luận phỏng vấn về Next.js. Hãy giải thích vì sao một số trang sử dụng server rendering hoặc static generation, trong khi các control tương tác vẫn là client component. Một trang chi tiết sản phẩm ít thay đổi có thể được generate hoặc render ở server, còn bộ lọc trực tiếp, giỏ hàng hoặc trình chỉnh sửa kéo-thả cần state phía trình duyệt.

Gắn mỗi lựa chọn với hành vi có thể đo lường hoặc nhu cầu của người dùng, thay vì lặp lại các thuật ngữ của framework. Server rendering có thể giảm lượng JavaScript cần tải trước khi nội dung xuất hiện, còn client rendering phù hợp với các tương tác phụ thuộc vào event, state cục bộ hoặc browser API. Đồng thời, hãy giải thích trade-off: dữ liệu được render ở server có thể trở nên lỗi thời nếu không được revalidate, còn quá nhiều client component có thể làm tăng JavaScript payload.

Phân tích quy trình lấy dữ liệu

Hãy chọn một hành trình người dùng quan trọng và lần theo dữ liệu từ request đến màn hình. Với một trang tìm kiếm, hãy mô tả cách query trên URL như “?q=keyboard&page=2” được đọc, kiểm tra tính hợp lệ, truyền đến API và chuyển đổi thành danh sách được page render. Điều này cho thấy bạn hiểu cả framework lẫn hành vi thực tế của ứng dụng.

Hãy thảo luận về các trạng thái loading, empty và error trong cùng phần giải thích. Một ví dụ hữu ích là hiển thị skeleton trong khi request đang chờ, hiển thị thông báo rõ ràng khi không có sản phẩm nào phù hợp và cung cấp thao tác thử lại sau một lỗi API tạm thời. Khi phù hợp, hãy đề cập đến các thiết lập caching hoặc revalidation, đặc biệt nếu dự án có yêu cầu như dữ liệu tồn kho luôn mới hoặc điều hướng lặp lại phải nhanh.

Trình bày các cải tiến hiệu năng

Hãy chuẩn bị một câu chuyện cải thiện hiệu năng cụ thể với phần so sánh trước và sau. Bạn có thể giải thích rằng một hero image lớn, chưa được tối ưu đã làm chậm Largest Contentful Paint, vì vậy đội ngũ đã thay đổi kích thước ảnh nguồn, sử dụng image component của Next.js và lazy-load các media nằm bên dưới màn hình đầu tiên. Nếu có số liệu thực tế, hãy đưa ra thay đổi cụ thể, chẳng hạn giảm từ 3,8 giây xuống 2,4 giây trên một trang kiểm thử được xác định rõ.

Hiệu năng cũng bao gồm bundle size, độ trễ cơ sở dữ liệu và các lần re-render không cần thiết. Hãy giải thích cách bạn xác định bottleneck bằng các công cụ hiệu năng của trình duyệt, phân tích bundle, server log hoặc Web Vitals thay vì phỏng đoán. Hãy nêu rõ giới hạn: một tối ưu hóa có ích cho landing page tĩnh có thể không giúp ích cho dashboard mà độ trễ đến từ các request API đã xác thực nhưng phản hồi chậm.

Thảo luận về kiểm thử và độ tin cậy

Giải thích chiến lược kiểm thử ở ba cấp độ khi dự án yêu cầu độ tin cậy cao. Kiểm thử đơn vị có thể bao phủ các hàm định dạng hoặc quy tắc xác thực, kiểm thử component có thể xác minh hành vi của biểu mẫu, còn kiểm thử end-to-end có thể xác nhận một quy trình hoàn chỉnh, chẳng hạn như đăng nhập, thêm một mặt hàng và hoàn tất thanh toán. Một ví dụ cụ thể thể hiện sự am hiểu tốt hơn so với việc chỉ nói rằng dự án có độ bao phủ kiểm thử tốt.

Đề cập đến các lỗi và trường hợp biên mà bạn đã cân nhắc. Chẳng hạn, một trang yêu cầu xác thực phải xử lý phiên đã hết hạn, một yêu cầu thanh toán phải ngăn việc gửi trùng lặp, và một biểu mẫu phải hiển thị lỗi xác thực từ máy chủ mà không làm mất dữ liệu người dùng đã nhập. Hãy nêu cách các bài kiểm thử được chạy trong CI và cho biết bạn đã sử dụng response được mock, cơ sở dữ liệu kiểm thử hay môi trường staging.

Giải thích về các đánh đổi và bài học

Các cuộc phỏng vấn kỹ thuật thường trở nên thuyết phục hơn khi bạn giải thích một quyết định chưa thật sự hoàn hảo. Bạn có thể nói rằng nhóm đã chọn một nhà cung cấp dịch vụ xác thực được quản lý để phát hành sản phẩm nhanh chóng, chấp nhận việc có ít quyền kiểm soát hơn đối với trải nghiệm đăng nhập, hoặc chọn một thư viện dữ liệu phía client vì nhu cầu cập nhật dashboard thường xuyên lớn hơn phần phức tạp phát sinh thêm. Hãy nêu các phương án bạn đã cân nhắc và ràng buộc đã tác động đến quyết định cuối cùng.

Kết thúc bằng những điều bạn sẽ cải thiện trong phiên bản thứ hai. Các cải tiến khả thi bao gồm ranh giới giữa server và client rõ ràng hơn, các hợp đồng API chặt chẽ hơn, khả năng giám sát tốt hơn đối với các request chậm, hoặc kiểm thử khả năng tiếp cận sớm hơn. Hãy gắn câu trả lời với dự án: mô tả một bài học, bằng chứng làm cơ sở cho bài học đó và cách bài học sẽ thay đổi việc triển khai của bạn, thay vì khẳng định rằng mọi phần của kiến trúc đều cần được viết lại.

Các bài viết liên quan

Đọc thêm

Next.js

React

Kết xuất phía máy chủ