70+ câu hỏi phỏng vấn Fullstack từ cơ bản đến nâng cao (Phần 1)

Khi tham gia phỏng vấn Fullstack thường cảm thấy bế tắc khi câu hỏi thì không quá đánh đố, nhưng càng trả lời càng thấy mình nói thiếu, nói lệch hoặc không chạm đúng điều nhà tuyển dụng đang tìm. 

Vấn đề không nằm ở việc bạn biết bao nhiêu framework, mà ở chỗ bạn có thể kết nối các mảnh ghép frontend, backend và dữ liệu thành một bức tranh thống nhất hay không.

Bài viết này sẽ là “bí kíp” giúp bạn tự tin hơn với những câu hỏi tập trung vào những mảng dễ xuất hiện nhất ở vòng technical: tư duy nền tảng, frontend, backend và database. Mỗi câu hỏi đi kèm gợi ý trả lời ngắn gọn, giúp bạn trả lời đúng trọng tâm và phù hợp với trải nghiệm của chính mình thay vì học thuộc câu trả lời mẫu.

Vì sao nhiều người biết code nhưng vẫn rớt phỏng vấn Fullstack

Rất nhiều ứng viên Fullstack bước vào phòng phỏng vấn với tâm thế khá tự tin vì họ đã từng làm dự án, từng code frontend lẫn backend, thậm chí deploy sản phẩm thật. Tuy nhiên, khi buổi phỏng vấn đi sâu hơn một chút, sự tự tin đó nhanh chóng biến thành cảm giác lúng túng. Nguyên nhân phổ biến không phải vì thiếu kiến thức, mà vì cách trình bày tư duy chưa đúng trọng tâm.

Phỏng vấn Fullstack hiếm khi yêu cầu bạn chứng minh mình biết “tất cả mọi thứ”. Thay vào đó, nhà tuyển dụng muốn thấy bạn hiểu mối liên hệ giữa các phần trong hệ thống và biết mình đang đứng ở đâu trong toàn bộ dòng chảy đó. Khi câu trả lời chỉ dừng ở mức liệt kê công nghệ, nói rời rạc từng mảng hoặc quá sa đà vào chi tiết kỹ thuật, interviewer sẽ rất khó đánh giá năng lực thực sự của bạn.

Một điểm nữa khiến nhiều người rớt oan là không phân biệt được đâu là vấn đề kỹ thuật, đâu là vấn đề tư duy giải quyết vấn đề. Fullstack không chỉ là “code cho chạy”, mà còn là khả năng lựa chọn giải pháp phù hợp, xử lý tình huống khi mọi thứ không như mong đợi và chịu trách nhiệm cho feature từ đầu đến cuối.

Bộ câu hỏi phỏng vấn từ kỹ thuật nền tảng đến UI và dữ liệu

Phần này tập trung vào những nhóm câu hỏi gần như chắc chắn sẽ xuất hiện ở vòng technical. Bạn không cần trả lời hoàn hảo tất cả, nhưng nên chọn lọc những câu phù hợp với kinh nghiệm của mình và luyện cách diễn đạt sao cho rõ ràng, mạch lạc.

Câu hỏi về nền tảng tư duy Fullstack

Những câu hỏi trong nhóm này thường xuất hiện rất sớm, đôi khi ngay từ đầu buổi phỏng vấn. Chúng không nhằm kiểm tra kiến thức chi tiết, mà để interviewer hiểu cách bạn nhìn một hệ thống và vai trò của mình trong đó. Nếu trả lời tốt nhóm này, bạn thường tạo được cảm giác “nói chuyện cùng tần” với người phỏng vấn, thay vì chỉ là người trả lời từng câu hỏi rời rạc.

1. Thế nào là một lập trình viên Fullstack “đúng nghĩa” trong dự án thật?

Câu hỏi này nhằm đánh giá bạn có tư duy end-to-end và hiểu rõ phạm vi trách nhiệm của mình trong một feature hay không.

• Thể hiện cách bạn nhìn một tính năng từ giao diện người dùng cho tới xử lý phía server và lưu trữ dữ liệu.
• Cho thấy bạn hiểu sự phụ thuộc giữa frontend, backend và database, thay vì coi chúng là các phần tách rời.
• Nhấn mạnh vai trò chịu trách nhiệm cho chất lượng feature, không chỉ viết code xong là xong.

2. Bạn mô tả flow của một request từ UI tới database và phản hồi ngược lại như thế nào?

Câu này giúp interviewer đánh giá mức độ hiểu biết của bạn về luồng xử lý cơ bản trong một ứng dụng web.

• Trình bày các bước chính từ khi người dùng thao tác đến khi nhận được kết quả.
• Nhắc tới các điểm dễ phát sinh lỗi như validate dữ liệu, xử lý lỗi hoặc timeout.
• Cho thấy bạn hiểu rõ vai trò của từng tầng trong hệ thống.

3. Khi xảy ra bug “mất dữ liệu”, bạn thường khoanh vùng và kiểm tra từ đâu trước?

Đây là câu hỏi kiểm tra khả năng debug và tư duy ưu tiên.

• Nêu cách bạn xác định phạm vi ảnh hưởng của bug trước khi đi sâu.
• Giải thích thứ tự kiểm tra giữa frontend, backend và database.
• Thể hiện bạn không vội kết luận mà dựa trên dấu hiệu thực tế.

4. Khi làm MVP, bạn ưu tiên tốc độ hay chất lượng? Vì sao?

Câu hỏi này nhằm xem bạn có hiểu trade-off trong phát triển sản phẩm hay không.

• Nêu rõ tiêu chí ưu tiên trong từng giai đoạn.
• Giải thích rủi ro nếu nghiêng hẳn về một phía.
• Cho thấy bạn biết điều chỉnh cách làm theo mục tiêu sản phẩm.

5. Khi nào bạn quyết định tách module hoặc service, và khi nào thì không cần?

Interviewer dùng câu này để đánh giá khả năng thiết kế và giữ hệ thống ở mức vừa đủ.

• Trình bày các dấu hiệu cho thấy code bắt đầu khó maintain.
• Nhấn mạnh việc tránh tách quá sớm khi chưa có nhu cầu rõ ràng.
• Cho thấy bạn cân nhắc chi phí kỹ thuật khi thay đổi kiến trúc.

6. Bạn xử lý thay đổi requirement giữa chừng như thế nào để không làm vỡ kế hoạch?

Câu hỏi này kiểm tra khả năng thích nghi và giao tiếp trong dự án thật.

• Nêu cách bạn làm rõ lại yêu cầu trước khi chỉnh sửa.
• Thể hiện việc đánh giá ảnh hưởng tới các phần khác của hệ thống.
• Cho thấy bạn chủ động trao đổi thay vì âm thầm sửa code.

7. Khi debug, bạn thường dựa vào những nguồn thông tin nào?

Câu này giúp interviewer hiểu cách bạn tiếp cận vấn đề.

• Nhắc tới việc đọc log, kiểm tra dữ liệu đầu vào/đầu ra.
• Cho thấy bạn không phụ thuộc hoàn toàn vào cảm giác hay đoán mò.
• Thể hiện tư duy kiểm chứng trước khi kết luận.

8. Hãy kể một quyết định kỹ thuật bạn từng đưa ra vì lý do trade-off

Đây là câu hỏi để đánh giá kinh nghiệm và mức độ chín trong tư duy.

• Nêu bối cảnh khiến bạn phải chọn giữa các phương án.
• Giải thích tiêu chí bạn dùng để quyết định.
• Nhấn mạnh bài học rút ra sau khi triển khai.

9. Bạn hiểu thế nào về “end-to-end ownership” trong một feature?

Câu hỏi này dùng để phân biệt người “làm theo task” và người chịu trách nhiệm thực sự.

• Trình bày cách bạn theo dõi feature từ lúc bắt đầu đến khi chạy ổn.
• Nhắc tới việc kiểm tra sau deploy và xử lý phản hồi.
• Cho thấy bạn không chỉ dừng lại ở việc hoàn thành code.

👉 Khám phá thêm 100 câu hỏi phỏng vấn cho lập trình viên Java tại đây!

Câu hỏi về Frontend

Ở nhóm câu hỏi frontend, interviewer thường không quá quan tâm bạn dùng framework nào, mà muốn biết bạn xử lý các vấn đề giao diện và trải nghiệm người dùng trong dự án thật ra sao. Cách bạn nói về state, render, performance hay lỗi UI sẽ cho thấy bạn có thực sự làm frontend hay chỉ “đụng tới cho có”.

10. Bạn tổ chức component như thế nào để dễ maintain khi ứng dụng lớn dần?

Câu hỏi này nhằm đánh giá cách bạn kiểm soát độ phức tạp của UI theo thời gian.

• Nêu nguyên tắc chia component theo trách nhiệm, tránh component “ôm đồm”.
• Cho thấy bạn quan tâm tới khả năng tái sử dụng và khả năng đọc hiểu code.
• Nhắc tới việc tách logic và phần hiển thị để dễ chỉnh sửa, test.

11. Khi nào state nên nằm ở local component, và khi nào cần đưa lên global?

Interviewer muốn xem bạn hiểu bản chất của state, không chỉ dùng theo thói quen.

• Phân biệt state chỉ phục vụ một component với state dùng chung cho nhiều nơi.
• Nêu rủi ro khi lạm dụng global state khiến code khó theo dõi.
• Cho thấy bạn cân nhắc phạm vi ảnh hưởng trước khi quyết định.

12. Bạn xử lý form phức tạp (validation, submit bất đồng bộ) như thế nào?

Câu hỏi này đánh giá khả năng xử lý các tình huống rất thường gặp trong sản phẩm thật.

• Nêu cách kiểm soát dữ liệu đầu vào và phản hồi lỗi cho người dùng.
• Thể hiện việc tách validation phía frontend và backend.
• Cho thấy bạn quan tâm tới trải nghiệm khi submit thất bại hoặc chậm.

13. Bạn quản lý loading, error và empty state ra sao để UX không bị tệ?

Câu hỏi nhằm kiểm tra tư duy trải nghiệm người dùng, không chỉ code cho chạy.

• Nhắc tới việc hiển thị trạng thái rõ ràng trong từng tình huống.
• Tránh để giao diện “đứng im” khiến người dùng không hiểu chuyện gì đang xảy ra.
• Cho thấy bạn suy nghĩ về các trường hợp biên, không chỉ happy path.

14. Khi UI bị re-render nhiều lần, bạn phát hiện và xử lý như thế nào?

Interviewer dùng câu này để xem bạn có hiểu cơ chế render và hiệu năng cơ bản hay không.

• Nêu cách quan sát hành vi re-render trong quá trình phát triển.
• Cho thấy bạn biết khoanh vùng component gây vấn đề trước khi tối ưu.
• Tránh tối ưu sớm khi chưa có dấu hiệu rõ ràng.

15. Trong những trường hợp nào bạn sử dụng debounce hoặc throttle?

Câu hỏi này kiểm tra khả năng tối ưu tương tác người dùng.

• Nêu các tình huống phổ biến như search, scroll hoặc resize.
• Giải thích ngắn gọn sự khác nhau giữa debounce và throttle.
• Cho thấy bạn dùng đúng chỗ, không áp dụng tràn lan.

16. Khi xây dựng danh sách dài, bạn chọn pagination hay infinite scroll? Vì sao?

Câu hỏi nhằm đánh giá khả năng cân nhắc giữa kỹ thuật và trải nghiệm.

• So sánh ưu và nhược điểm của từng cách tiếp cận.
• Nhắc tới yếu tố hiệu năng và khả năng sử dụng.
• Cho thấy bạn chọn giải pháp theo ngữ cảnh sản phẩm, không theo sở thích cá nhân.

17. Bạn cache dữ liệu phía client như thế nào để vừa nhanh vừa tránh sai dữ liệu?

Câu hỏi này kiểm tra tư duy về tính nhất quán dữ liệu.

• Nêu mục tiêu của cache là giảm request và cải thiện tốc độ.
• Nhắc tới việc làm mới dữ liệu khi có thay đổi quan trọng.
• Cho thấy bạn hiểu rủi ro của cache stale.

18. Khi UI chạy chậm trên thiết bị yếu, bạn đo và cải thiện theo thứ tự nào?

Interviewer muốn biết bạn có biết bắt đầu từ đâu khi gặp vấn đề hiệu năng.

• Nêu cách quan sát thực tế thay vì tối ưu theo cảm giác.
• Ưu tiên tìm điểm nghẽn lớn trước khi chỉnh chi tiết nhỏ.
• Cho thấy bạn không đổ lỗi ngay cho backend hay framework.

19. Bạn đảm bảo giao diện hoạt động ổn trên nhiều trình duyệt và thiết bị như thế nào?

Câu hỏi này nhằm đánh giá mức độ “làm sản phẩm thật” của bạn.

• Nhắc tới việc kiểm tra trên các môi trường phổ biến.
• Cho thấy bạn ý thức được sự khác biệt giữa các trình duyệt.
• Tránh trả lời theo kiểu “chạy được trên máy tôi là đủ”.

20. Khi gọi nhiều API song song, bạn xử lý race condition ở frontend ra sao?

Câu hỏi này kiểm tra khả năng kiểm soát trạng thái bất đồng bộ.

• Nêu cách bạn đảm bảo dữ liệu hiển thị là dữ liệu mới nhất.
• Nhắc tới việc hủy request cũ hoặc kiểm soát thứ tự phản hồi.
• Cho thấy bạn đã từng gặp và xử lý tình huống này.

👉 Tham khảo thêm phần 2 tại đây để nắm trọn bộ câu hỏi chinh phục nhà tuyển dụng!

Câu hỏi về Backend & API

Nhóm câu hỏi backend giúp phân biệt rõ giữa người chỉ viết API cho chạy và người hiểu cách thiết kế một backend ổn định, dễ mở rộng. Interviewer thường lắng nghe cách bạn nói về error handling, hiệu năng, retry hay logging để đánh giá mức độ “chín” khi làm việc với hệ thống phía server.

21. Bạn thiết kế REST API như thế nào để dễ dùng và dễ mở rộng?

Câu hỏi này nhằm xem bạn hiểu cách “đóng gói” logic backend thành API rõ ràng, nhất quán, không gây khó cho frontend về sau.

• Nêu cách đặt resource/endpoint có ý nghĩa, nhất quán theo hành vi.
• Thể hiện bạn quan tâm tới chuẩn trả về (status code, payload, thông báo lỗi).
• Nhắc tới versioning/pagination/filters nếu hệ thống có khả năng mở rộng.

22. Bạn thiết kế error response ra sao để frontend debug dễ hơn?

Interviewer muốn biết bạn có tư duy “làm sản phẩm cùng nhau” thay vì backend trả gì cũng được.

• Cho thấy bạn phân biệt lỗi do client (validation) và lỗi do server.
• Nêu cách trả về message/field lỗi đủ rõ để UI hiển thị đúng.
• Tránh trả lời kiểu “quăng stacktrace ra cho nhanh”.

23. Khi API chậm, bạn kiểm tra theo thứ tự nào?

Câu này kiểm tra khả năng khoanh vùng và ưu tiên, nhất là khi bạn không có thời gian “đào tất cả”.

• Nêu cách xác định API nào chậm, chậm tới mức nào (so với bình thường).
• Thể hiện bạn chia lớp kiểm tra: network → app → database → external service.
• Cho thấy bạn tìm bằng chứng trước khi tối ưu, tránh tối ưu theo cảm giác.

24. Bạn phân biệt bottleneck CPU-bound và IO-bound như thế nào?

Câu hỏi nhằm đánh giá bạn có hiểu nguyên nhân gốc của chậm, từ đó chọn cách tối ưu phù hợp.

• Nêu dấu hiệu nhận biết qua hành vi (CPU cao, chờ DB, chờ network…).
• Thể hiện cách bạn chọn hướng tối ưu khác nhau cho từng loại.
• Tránh trả lời chung chung kiểu “tối ưu code là xong”.

25. Khi nào bạn dùng background job hoặc queue thay vì xử lý ngay trong request?

Interviewer muốn biết bạn hiểu cách giữ request nhanh và hệ thống ổn định khi workload tăng.

• Nêu các tình huống phù hợp: gửi email, xử lý file, tính toán nặng, đồng bộ dữ liệu.
• Thể hiện bạn hiểu trade-off: nhanh hơn cho user nhưng tăng độ phức tạp vận hành.
• Nhắc tới cách bạn theo dõi job thất bại và retry.

26. Idempotency là gì và bạn áp dụng nó cho endpoint quan trọng ra sao?

Câu hỏi này thường xuất hiện khi sản phẩm có thanh toán, đặt hàng, tạo đơn… nơi “bấm hai lần” có thể gây hậu quả.

• Giải thích ngắn gọn idempotency giúp tránh tạo dữ liệu trùng khi retry/multi-click.
• Nêu cách bạn thiết kế key hoặc cơ chế kiểm tra trùng.
• Thể hiện bạn nghĩ tới retry, timeout, và việc client gửi lại request.

27. Bạn xử lý rate limiting hoặc throttling như thế nào khi traffic tăng?

Interviewer kiểm tra tư duy bảo vệ hệ thống, không để một nhóm request làm sập toàn bộ.

• Nêu mục tiêu: bảo vệ tài nguyên và đảm bảo hệ thống vẫn phục vụ được phần còn lại.
• Thể hiện bạn biết rate limit theo IP/user/token tùy bối cảnh.
• Nhắc tới phản hồi phù hợp để client biết cần giảm tốc.

28. Bạn thiết kế logging như thế nào để truy vết lỗi nhanh?

Câu hỏi này đánh giá khả năng hỗ trợ vận hành, đặc biệt khi production có sự cố.

• Nêu cách bạn log theo request/context để lần theo luồng xử lý.
• Thể hiện bạn biết log đủ thông tin nhưng không lộ dữ liệu nhạy cảm.
• Nhắc tới việc phân biệt log info/warn/error để không bị “nhiễu”.

29. Bạn xử lý retry và backoff như thế nào để tránh “thác request” khi upstream chậm?

Câu này nhằm xem bạn hiểu rủi ro của retry, vì retry sai thường làm mọi thứ tệ hơn.

• Thể hiện bạn dùng retry có điều kiện, không retry mọi lỗi.
• Nhắc tới backoff và giới hạn số lần retry.
• Nêu cách bạn kết hợp timeout/circuit breaker ở mức tư duy.

30. Bạn xử lý upload/download file thế nào để vừa ổn định vừa an toàn?

Interviewer muốn biết bạn hiểu các vấn đề thực tế: size lớn, timeout, quyền truy cập, virus/file type…

• Nêu cách giới hạn dung lượng, loại file, và validate phía server.
• Thể hiện bạn biết tách xử lý nặng ra khỏi request nếu cần.
• Nhắc tới phân quyền truy cập (public/private) và link hết hạn nếu phù hợp.

31. Khi cần thay đổi API, bạn đảm bảo backward compatibility như thế nào?

Câu hỏi này kiểm tra khả năng phát triển lâu dài mà không “đập” frontend hoặc client cũ.

• Nêu cách thay đổi có kiểm soát: thêm field thay vì đổi field cũ, giữ default.
• Thể hiện bạn biết khi nào cần versioning.
• Nhắc tới việc thông báo/ghi chú thay đổi để team tích hợp không bị bất ngờ.

32. Bạn tổ chức cấu trúc project backend như thế nào để dễ maintain?

Interviewer muốn thấy bạn biết giữ codebase sạch, không để mọi thứ thành “một cục”.

• Nêu cách tách theo layer (controller/service/repo) hoặc theo module theo domain.
• Thể hiện bạn quan tâm tới boundaries và trách nhiệm rõ ràng.
• Tránh trả lời chỉ kể tên folder, tập trung vào nguyên tắc.

33. Bạn thiết kế API contract giữa frontend và backend như thế nào để tránh “vỡ tích hợp”?

Câu này kiểm tra khả năng phối hợp, vì nhiều dự án chết vì hai bên hiểu khác nhau.

• Nêu cách thống nhất payload, error format, và quy ước đặt tên.
• Thể hiện bạn có cách giảm mismatch: mock/contract test/document đơn giản.
• Nhắc tới việc cập nhật khi có thay đổi và kiểm tra lại các màn hình liên quan.

Câu hỏi về Database & Data layer

Nhóm câu hỏi về database thường khiến ứng viên hụt hơi không phải vì quá khó, mà vì nhiều người chỉ quen viết CRUD mà ít khi để ý vì sao hệ thống chậm hoặc dữ liệu sai. Interviewer hỏi phần này để xem bạn hiểu cách dữ liệu được lưu, được truy vấn và được bảo vệ như thế nào, đồng thời đánh giá khả năng xử lý các vấn đề performance cơ bản khi dữ liệu bắt đầu lớn lên.

34. Bạn chọn SQL hay NoSQL cho một sản phẩm mới dựa trên tiêu chí nào?

Câu hỏi này nhằm đánh giá bạn có hiểu nhu cầu dữ liệu và trade-off, thay vì chọn công nghệ theo xu hướng.

• Nêu loại dữ liệu và kiểu truy vấn chính (quan hệ chặt hay linh hoạt, join nhiều hay không).
• Thể hiện bạn cân nhắc tính nhất quán, transaction, và yêu cầu mở rộng.
• Nhắc tới khả năng vận hành và kỹ năng của team như một tiêu chí thực tế.

35. Index là gì và dấu hiệu nào cho thấy hệ thống đang thiếu index?

Interviewer muốn biết bạn có tư duy hiệu năng cơ bản ở tầng dữ liệu, không chỉ viết query cho ra kết quả.

• Nêu dấu hiệu phổ biến: query chậm, scan nhiều, latency tăng khi data lớn.
• Thể hiện bạn biết index hỗ trợ truy vấn nhưng cũng có chi phí khi ghi.
• Nhắc tới việc ưu tiên index theo query thực tế, không index “cho vui”.

36. N+1 query là gì và bạn thường phát hiện nó bằng cách nào?

Câu này kiểm tra khả năng nhận diện một lỗi performance rất hay gặp khi có quan hệ dữ liệu.

• Giải thích ngắn gọn hiện tượng: một query chính kéo theo nhiều query phụ lặp lại.
• Nêu dấu hiệu: số query tăng bất thường khi danh sách lớn.
• Thể hiện bạn dựa vào log/query monitor để phát hiện, không chỉ đoán.

37. Khi gặp N+1 query, bạn xử lý theo hướng nào?

Interviewer muốn xem bạn hiểu nhiều cách xử lý và biết cân nhắc trade-off.

• Nêu các hướng tiếp cận: join/fetch/batch/điều chỉnh cách load dữ liệu.
• Thể hiện bạn quan tâm tới dữ liệu trả về có “phình” quá không.
• Nhắc tới việc kiểm tra lại số query và thời gian sau khi sửa.

38. Transaction là gì và bạn đặt transaction boundary thế nào cho hợp lý?

Câu hỏi nhằm đánh giá bạn hiểu tính nhất quán dữ liệu và biết giới hạn phạm vi “khóa” để tránh làm chậm hệ thống.

• Nêu mục tiêu: đảm bảo dữ liệu đúng khi có nhiều thao tác liên quan.
• Thể hiện bạn giữ transaction đủ nhỏ, tránh kéo dài do gọi external service.
• Nhắc tới các tình huống cần transaction rõ ràng: tạo đơn + trừ tồn kho, cập nhật nhiều bảng liên quan.

39. Khi migration database trên production, bạn làm thế nào để giảm rủi ro downtime?

Interviewer kiểm tra tư duy triển khai an toàn, vì đây là phần dễ gây sự cố nhất khi hệ thống đang chạy.

• Nêu cách làm theo bước: thêm cột mới trước, chuyển dần dữ liệu, rồi mới bỏ cột cũ.
• Thể hiện bạn quan tâm tới backward compatibility giữa code và schema.
• Nhắc tới kiểm tra trên staging và kế hoạch rollback khi có sự cố.

40. Bạn thiết kế schema cho các tính năng search/filter/sort như thế nào để không “đuối” về sau?

Câu hỏi này đánh giá khả năng nhìn xa, vì search/filter/sort thường phát sinh sau khi dữ liệu đã lớn.

• Nêu cách xác định trường nào sẽ được filter/sort thường xuyên.
• Thể hiện bạn cân nhắc index phù hợp cho kiểu truy vấn.
• Nhắc tới giới hạn thực tế: không phải filter nào cũng tối ưu bằng SQL thuần, đôi khi cần giải pháp khác khi dữ liệu lớn.

41. Khi hệ thống chậm, bạn quyết định tối ưu query, tối ưu code hay tối ưu cache dựa trên gì?

Interviewer muốn thấy bạn chọn đúng “điểm đập”, thay vì tối ưu ngẫu nhiên.

• Nêu tiêu chí dựa trên số liệu: query time, số lần gọi, tần suất request.
• Thể hiện bạn ưu tiên điểm nghẽn lớn trước, tránh tối ưu tiểu tiết.
• Nhắc tới việc tối ưu phải đi kèm kiểm tra lại, không sửa xong rồi “cầu may”.

42. Caching có thể đặt ở nhiều nơi: bạn chọn cache ở database, ứng dụng hay client?

Câu hỏi này đánh giá khả năng cân nhắc vị trí cache và rủi ro sai dữ liệu.

• Nêu mục tiêu: giảm tải nơi đang nghẽn và tăng tốc phần hay lặp lại.
• Thể hiện bạn hiểu cache luôn đi kèm bài toán invalidation, không có “cache miễn phí”.
• Nhắc tới việc chọn TTL và cách làm mới dữ liệu theo mức độ nhạy cảm.

43. Bạn xử lý validation dữ liệu ở layer nào: frontend, backend hay database?

Interviewer muốn xem bạn hiểu “phòng tuyến” dữ liệu và không đặt niềm tin sai chỗ.

• Nêu rõ frontend giúp UX, nhưng backend mới là nơi bắt buộc phải validate.
• Thể hiện bạn dùng constraint/database validation cho các quy tắc cần đảm bảo tính toàn vẹn.
• Nhắc tới thông báo lỗi rõ ràng để client xử lý đúng.

44. Khi dữ liệu tăng nhanh theo thời gian, bạn thay đổi schema/index như thế nào để không phá hệ thống?

Câu hỏi này kiểm tra khả năng nâng cấp hệ thống dần dần, thay vì “đập đi làm lại”.

• Nêu cách dựa trên query thực tế và quan sát hệ thống trước khi thay đổi.
• Thể hiện bạn ưu tiên thay đổi an toàn: thêm mới, chuyển dần, theo dõi, rồi mới loại bỏ.
• Nhắc tới việc phối hợp deploy code và migrate theo trình tự để tránh mismatch.

Học Fullstack bài bản để trả lời phỏng vấn tốt hơn

Một điểm dễ thấy ở những ứng viên trả lời phỏng vấn Fullstack tốt là họ không nói kiến thức rời rạc, mà luôn gắn câu trả lời với trải nghiệm xây dựng và vận hành sản phẩm thật. Điều này không đến từ việc học thêm vài framework, mà đến từ một lộ trình học có hệ thống, nơi frontend, backend, database và tư duy hệ thống được kết nối ngay từ đầu.

Tại Onschool Bootcamp, các chương trình đào tạo Fullstack được thiết kế theo hướng learning by doing để người học tới đâu, làm sản phẩm tới đó. Thay vì chỉ dừng ở bài tập nhỏ lẻ, người học sẽ trực tiếp xây dựng các tính năng end-to-end, xử lý các tình huống gần với thực tế như thiết kế API, tối ưu dữ liệu, deploy và theo dõi ứng dụng sau khi chạy.

Chính cách học này giúp người học:

• Hiểu rõ mối liên hệ giữa frontend, backend và dữ liệu, thay vì học từng mảng riêng lẻ.
• Có “chất liệu thật” để trả lời các câu hỏi phỏng vấn về trade-off, debug và vận hành hệ thống.
• Tự tin hơn khi bước vào các vòng technical, vì câu trả lời xuất phát từ trải nghiệm, không phải học thuộc.

Bạn có thể tham khảo thêm lộ trình đào tạo Fullstack Web tại Onschool Bootcamp để hiểu rõ cách chương trình được xây dựng và những kỹ năng nào sẽ hỗ trợ trực tiếp cho quá trình đi phỏng vấn.

Kết luận

Phỏng vấn Fullstack ở vòng kỹ thuật hiếm khi đánh trượt ứng viên vì họ không biết code, mà thường vì cách họ trình bày tư duy chưa đủ rõ và chưa thể hiện được bức tranh tổng thể của một tính năng. Khi câu trả lời chỉ dừng lại ở từng mảnh frontend, backend hay database rời rạc, nhà tuyển dụng sẽ rất khó đánh giá khả năng làm việc thực tế của bạn.

Trong phần 1 của bài viết này, các nhóm câu hỏi tập trung vào nền tảng tư duy Fullstack, cách làm việc với frontend, backend và dữ liệu. Nếu bạn có thể trả lời tốt những câu hỏi này dựa trên trải nghiệm thật của mình, bạn đã có nền tảng khá vững để vượt qua vòng technical và tạo được sự tin cậy ban đầu với interviewer.

Tuy nhiên, Fullstack không chỉ dừng lại ở việc xây dựng tính năng cho chạy đúng. Khi đi sâu hơn, nhà tuyển dụng sẽ quan tâm tới cách bạn thiết kế hệ thống, triển khai ứng dụng, đảm bảo chất lượng, xử lý bảo mật và đặc biệt là phản ứng của bạn khi hệ thống gặp sự cố trong môi trường production.

Ở Phần 2, bài viết sẽ tiếp tục với các nhóm câu hỏi mang tính phân hoá mạnh hơn, xoay quanh system design, devops, testing, security và các tình huống production thực tế. Đây cũng là phần thường quyết định bạn dừng lại ở mức làm được hay tiến xa hơn trong các vòng phỏng vấn cuối.