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

Nếu phần 1 giúp bạn vững vàng ở các mảng kỹ thuật cốt lõi như frontend, backend và database, thì phần 2 là nơi các vòng phỏng vấn bắt đầu phân hoá rõ rệt. Ở đây, nhà tuyển dụng thường không chỉ hỏi bạn biết làm gì, mà quan tâm nhiều hơn tới cách bạn thiết kế hệ thống, triển khai an toàn và phản ứng ra sao khi mọi thứ gặp sự cố trong môi trường thật.

Bài viết này tập trung vào những nhóm câu hỏi thường xuất hiện ở các vòng sâu hơn như system design, devops, testing, security và các tình huống production. 

Vì sao phần system và production là nơi phân hoá mạnh nhất?

Ở các vòng phỏng vấn sâu, câu hỏi thường không còn “đúng – sai” rõ ràng như các câu hỏi kiến thức. Thay vào đó, interviewer muốn nghe cách bạn ưu tiên cân nhắc trade-off và mức độ chắc tay khi đưa hệ thống vào vận hành. Những câu trả lời tốt thường không cần quá nhiều thuật ngữ, nhưng sẽ thể hiện được bạn biết điều gì quan trọng, điều gì có thể chấp nhận và điều gì phải tránh bằng mọi giá.

Ngoài ra, system và production cũng là nơi ứng viên dễ lộ ra khoảng trống trải nghiệm. Bạn có thể code một feature chạy được trên local, nhưng việc deploy, theo dõi, xử lý lỗi, rollback hay bảo vệ hệ thống trước các tình huống xấu lại là câu chuyện khác. Vì vậy, nếu bạn muốn thể hiện mình là một Fullstack “làm được việc”, đây là phần bạn nên luyện kỹ nhất.

👉 Tham khảo bộ câu hỏi dành cho lập trình viên Fullstack phần 1 tại đây.

Bộ câu hỏi phỏng vấn các kỹ năng thực chiến

Câu hỏi về System design

Nhóm câu hỏi này kiểm tra cách bạn nghĩ về kiến trúc ở mức tổng quan và cách bạn biến yêu cầu sản phẩm thành một hệ thống chạy ổn. Interviewer thường không đòi bạn vẽ hệ thống kiểu Big Tech, nhưng họ muốn thấy bạn hiểu các thành phần chính, các điểm rủi ro và lý do vì sao bạn chọn hướng thiết kế đó.

1. Thiết kế login và refresh token ở mức tổng quan như thế nào?

Câu này đánh giá bạn có hiểu luồng xác thực và các điểm dễ sai khi hệ thống có nhiều phiên đăng nhập.

• Nêu luồng đăng nhập, phát hành token và cơ chế làm mới token.
• Thể hiện bạn nghĩ tới thời hạn token, cách logout và thu hồi khi cần.
• Nhắc tới bảo mật cơ bản: lưu token ở đâu và tránh lộ token ra sao.

2. Thiết kế tính năng upload file lớn kèm quyền truy cập public/private như thế nào?

Interviewer hỏi để xem bạn hiểu vấn đề thực tế: file nặng, timeout, lưu trữ và phân quyền.

• Nêu cách xử lý upload để không làm API “đuối” (chia nhỏ, upload trực tiếp, xử lý nền nếu cần).
• Thể hiện cách quản lý quyền truy cập: public link, private link, link hết hạn.
• Nhắc tới kiểm soát loại file, dung lượng và audit cơ bản.

3. Thiết kế hệ thống notification (email/in-app) theo hướng nào khi số lượng tăng?

Câu này kiểm tra khả năng tách xử lý bất đồng bộ và đảm bảo hệ thống không nghẽn.

• Nêu lý do nên dùng queue/background job thay vì gửi trực tiếp trong request.
• Thể hiện bạn nghĩ tới retry, dead-letter, và theo dõi job lỗi.
• Nhắc tới việc người dùng có thể tắt/bật nhận thông báo và xử lý duplicate.

4. Khi lượng request tăng 10x, bạn ưu tiên thay đổi gì trước?

Interviewer đánh giá khả năng ưu tiên và giữ hệ thống sống khi tải tăng.

• Nêu bước quan sát trước: bottleneck nằm ở app, DB hay external service.
• Thể hiện bạn ưu tiên giải pháp ít rủi ro trước (cache, scale ngang, tối ưu query).
• Nhắc tới giới hạn của từng hướng và khi nào cần thay đổi kiến trúc sâu hơn.

5. Khi database bắt đầu nghẽn, bạn thường xem xét những hướng nào?

Câu này nhằm xem bạn hiểu cách “đỡ DB” thay vì chỉ tăng máy.

• Nêu các hướng: tối ưu query/index, giảm query lặp, cache hợp lý.
• Thể hiện bạn biết tách đọc/ghi hoặc phân vùng dữ liệu khi phù hợp.
• Nhắc tới việc theo dõi query chậm và truy vấn hot path.

6. Bạn thiết kế cache và invalidation ở mức hệ thống ra sao?

Câu hỏi này đo tư duy về tính đúng đắn dữ liệu, vì cache sai còn nguy hiểm hơn chậm.

• Nêu rõ mục tiêu cache và loại dữ liệu phù hợp để cache.
• Thể hiện bạn nghĩ tới TTL, cache key, và khi nào phải invalidate.
• Nhắc tới cách tránh cache gây sai dữ liệu cho các nghiệp vụ nhạy cảm.

7. Bạn thiết kế logging, metrics, tracing thế nào để debug nhanh?

Interviewer dùng câu này để xem bạn có tư duy vận hành, không chỉ tư duy phát triển.

• Nêu tối thiểu cần có: log theo request/context, metrics cơ bản, tracing khi cần.
• Thể hiện bạn biết chọn điểm đo quan trọng, tránh “log mọi thứ”.
• Nhắc tới việc chuẩn hoá format log để truy vết dễ.

8. Bạn rollout tính năng an toàn bằng cách nào (canary/feature flag/rollback)?

Câu này đánh giá khả năng giảm rủi ro triển khai.

• Nêu cách giảm phạm vi ảnh hưởng khi phát hành: bật dần, theo nhóm user, theo môi trường.
• Thể hiện bạn chuẩn bị rollback nhanh và tiêu chí rollback rõ ràng.
• Nhắc tới việc theo dõi chỉ số sau rollout, không deploy xong là xong.

9. Ở mức khái niệm, bạn xử lý distributed transaction theo hướng nào?

Interviewer hỏi để xem bạn có biết vấn đề và cách tránh “đau đầu” khi hệ thống tách nhỏ.

• Nêu mục tiêu là hạn chế transaction xuyên service nếu không cần thiết.
• Thể hiện bạn biết các hướng tiếp cận phổ biến ở mức ý tưởng (event, outbox, idempotency).
• Nhắc tới việc đảm bảo hệ thống vẫn đúng dù xử lý bất đồng bộ.

Câu hỏi về DevOps và triển khai

Nhóm câu hỏi này thường xuất hiện khi nhà tuyển dụng muốn chắc một điều: bạn không chỉ làm được tính năng trên máy cá nhân, mà còn biết cách đưa ra môi trường thật một cách an toàn. Interviewer sẽ để ý cách bạn nói về môi trường, cấu hình, quan sát sau deploy và cách xử lý khi có sự cố, vì đây là những thứ quyết định hệ thống có chạy ổn lâu dài hay không.

10. Docker giúp giải quyết vấn đề gì trong dự án thực tế?

Câu này nhằm xem bạn hiểu Docker như một công cụ chuẩn hoá môi trường và quy trình chạy, chứ không chỉ biết viết Dockerfile.

• Nêu vấn đề thường gặp trước khi có Docker: lệch môi trường, khó onboard, chạy không giống nhau giữa máy các thành viên.
• Thể hiện bạn dùng Docker để làm môi trường dev gần production hơn, giảm thời gian setup.
• Nhắc tới cách bạn tách dịch vụ theo container nếu dự án có nhiều thành phần như app, database, cache.

11. Bạn tách cấu hình dev, staging, prod như thế nào để tránh chạy nhầm?

Interviewer hỏi để đánh giá bạn có tư duy quản lý môi trường và giảm rủi ro vận hành.

• Nêu cách bạn phân tách biến môi trường, file cấu hình hoặc config service.
• Thể hiện bạn tránh hard-code các giá trị nhạy cảm và tránh để cấu hình prod nằm trong repo.
• Nhắc tới cách kiểm tra trước deploy để giảm khả năng dùng nhầm cấu hình.

12. CI là gì và bạn thường đưa những bước nào vào pipeline?

Câu này nhằm xem bạn hiểu CI như một hàng rào chất lượng, không phải chỉ là chạy cho có.

• Nêu các bước thường có: chạy test, lint/format, build, kiểm tra bảo mật cơ bản nếu có.
• Thể hiện bạn ưu tiên bước nào bắt lỗi sớm và nhanh nhất.
• Nhắc tới việc pipeline cần ổn định và đủ nhanh để team không ngại dùng.

13. CD và triển khai tự động khác nhau ở điểm nào trong thực tế?

Câu này kiểm tra bạn hiểu mức độ tự động hoá triển khai và rủi ro đi kèm.

• Nêu sự khác nhau giữa việc có thể deploy tự động và việc luôn deploy tự động sau mỗi thay đổi.
• Thể hiện bạn biết nhiều team chọn triển khai bán tự động để kiểm soát rủi ro.
• Nhắc tới tiêu chí chấp nhận triển khai tự động: test đủ tin cậy, rollback rõ ràng, quan sát tốt.

14. Bạn quản lý secret như API key, DB password theo hướng nào?

Câu này nhằm đánh giá bạn có ý thức bảo mật tối thiểu khi vận hành hệ thống.

• Nêu nguyên tắc: secret không nằm trong code và không commit lên git.
• Thể hiện bạn dùng biến môi trường hoặc secret manager tuỳ theo bối cảnh.
• Nhắc tới việc phân quyền truy cập secret và thay đổi secret khi nghi ngờ lộ.

15. Nếu deploy xong mà lỗi 500 tăng lên, bạn làm gì ngay lập tức?

Interviewer muốn thấy phản xạ ưu tiên đúng khi hệ thống gặp sự cố sau triển khai.

• Nêu bước đầu là xác định phạm vi ảnh hưởng và mức độ nghiêm trọng.
• Thể hiện bạn kiểm tra nhanh log, health check và thay đổi gần nhất.
• Nhắc tới phương án an toàn: rollback hoặc tắt tính năng nếu có cơ chế phù hợp.

16. Bạn theo dõi hệ thống sau deploy bằng cách nào để biết có vấn đề sớm?

Câu này kiểm tra bạn có thói quen quan sát sau triển khai hay không.

• Nêu các tín hiệu thường xem: tỷ lệ lỗi, latency, tài nguyên, các endpoint quan trọng.
• Thể hiện bạn đặt ngưỡng cảnh báo hợp lý để không bỏ sót nhưng cũng không bị nhiễu.
• Nhắc tới việc so sánh trước và sau deploy để phát hiện bất thường.

17. Health check, readiness và liveness bạn hiểu và áp dụng ra sao?

Câu này dùng để đánh giá bạn hiểu cách hệ thống tự bảo vệ khi có instance lỗi hoặc chưa sẵn sàng.

• Nêu mục tiêu của health check là phát hiện trạng thái không phục vụ được.
• Thể hiện bạn phân biệt trạng thái chưa sẵn sàng nhận traffic và trạng thái cần restart.
• Nhắc tới việc health check phải phản ánh đúng khả năng phục vụ thực tế, không chỉ trả 200 cho có.

18. Kế hoạch rollback của bạn thường gồm những gì?

Câu này đánh giá khả năng giảm rủi ro triển khai và phục hồi nhanh khi có sự cố.

• Nêu bạn chuẩn bị rollback như một phần của kế hoạch deploy, không phải tới lúc lỗi mới nghĩ.
• Thể hiện bạn biết rollback có thể là quay phiên bản, tắt feature, hoặc chuyển traffic.
• Nhắc tới việc sau rollback vẫn cần theo dõi để chắc hệ thống ổn định trở lại.

Câu hỏi về Testing và quality

Nhóm câu hỏi này thường xuất hiện khi nhà tuyển dụng muốn biết bạn làm sản phẩm theo kiểu chắc tay hay chỉ chạy theo tiến độ. Một người Fullstack mạnh không nhất thiết phải viết test thật nhiều, nhưng họ thường biết chọn đúng thứ cần test, biết cách giữ chất lượng ở mức ổn định và tránh để bug lặp đi lặp lại vì thiếu quy trình.

19. Unit test, integration test và end-to-end test khác nhau ở mục tiêu nào?

Câu này nhằm xem bạn hiểu test là để giảm rủi ro theo từng tầng, chứ không phải chỉ là viết test cho đủ.

• Nêu mục tiêu chính của từng loại: kiểm tra logic nhỏ, kiểm tra tích hợp giữa các phần, kiểm tra hành vi như người dùng.
• Thể hiện bạn hiểu trade-off giữa tốc độ chạy test và mức độ bao phủ.
• Nhắc tới việc chọn loại test phù hợp với rủi ro của hệ thống.

20. Khi làm một feature mới, bạn ưu tiên test phần nào trước?

Interviewer hỏi để đánh giá khả năng nhận diện điểm rủi ro trong feature, thay vì test tràn lan.

• Nêu nguyên tắc ưu tiên: nơi dễ lỗi nhất, ảnh hưởng lớn nhất, thay đổi nhiều nhất.
• Thể hiện bạn chú ý tới các nhánh xử lý lỗi và dữ liệu biên, không chỉ happy path.
• Nhắc tới việc test giúp bạn tự tin refactor và deploy.

21. Bạn viết test case để bắt edge case như thế nào?

Câu này kiểm tra cách bạn nghĩ về những trường hợp hiếm nhưng gây lỗi nặng.

• Nêu cách liệt kê đầu vào xấu: null, rỗng, sai format, quá dài, vượt giới hạn.
• Thể hiện bạn nghĩ tới dữ liệu thực tế từ user và từ hệ thống bên ngoài.
• Nhắc tới việc test nên bám theo bug đã từng xảy ra để tránh tái diễn.

22. Làm sao tránh flaky test và test chạy chậm khiến team ngại chạy?

Interviewer muốn biết bạn có trải nghiệm thực tế với test trong team, vì flaky test làm mất niềm tin rất nhanh.

• Nêu các nguyên nhân hay gặp: phụ thuộc thời gian, phụ thuộc network, dữ liệu test không ổn định.
• Thể hiện bạn cô lập external dependency bằng mock hoặc environment riêng khi cần.
• Nhắc tới việc tách test nhanh và test nặng để pipeline không bị kéo dài vô lý.

23. Khi code review, bạn thường xem những điểm nào để chặn bug sớm?

Câu này đánh giá bạn có tư duy kiểm soát chất lượng qua quy trình, không đợi tới lúc QA mới phát hiện.

• Nêu những thứ dễ gây lỗi: xử lý null, validate đầu vào, lỗi logic ở nhánh ít gặp.
• Thể hiện bạn quan tâm tới readability và maintainability, không chỉ đúng output.
• Nhắc tới bảo mật và performance cơ bản nếu thay đổi chạm tới các phần nhạy cảm.

24. Bạn dùng linting, formatting và quy ước code để hỗ trợ chất lượng ra sao?

Interviewer muốn biết bạn có thói quen giảm tranh cãi và giảm lỗi lặt vặt trong team.

• Nêu mục tiêu: thống nhất style, giảm lỗi ngớ ngẩn, giúp review tập trung vào logic.
• Thể hiện bạn coi công cụ như một phần của pipeline, không phải việc làm thủ công.
• Nhắc tới việc quy ước tốt giúp người mới vào dự án đọc code nhanh hơn.

25. Bạn làm gì để chất lượng không phụ thuộc vào một người, mà trở thành thói quen của cả team?

Câu này kiểm tra khả năng xây dựng quy trình bền vững, nhất là khi dự án lớn dần.

• Nêu cách thiết lập tiêu chuẩn tối thiểu: definition of done, checklist release, quy tắc review.
• Thể hiện bạn biết chọn mức vừa đủ để team theo được, tránh đặt chuẩn quá cao rồi bỏ.
• Nhắc tới việc đo lường đơn giản như tỷ lệ bug, thời gian fix, hoặc các lỗi lặp lại.

Câu hỏi về Security căn bản

Nhóm câu hỏi về security thường không đi quá sâu vào lý thuyết hàn lâm, nhưng lại rất dễ khiến ứng viên mất điểm nếu trả lời hời hợt. Interviewer không kỳ vọng bạn là chuyên gia bảo mật, họ chỉ muốn biết bạn nhận diện được rủi ro phổ biến và có những nguyên tắc cơ bản để không vô tình mở cửa cho lỗi nghiêm trọng.

26. JWT và session khác nhau ở điểm nào và bạn dùng khi nào?

Câu hỏi này nhằm đánh giá bạn hiểu cơ chế xác thực ở mức thực dụng, không chỉ biết dùng theo mặc định.

• Nêu sự khác nhau về cách lưu trạng thái và kiểm soát phiên đăng nhập.
• Thể hiện bạn cân nhắc giữa tính tiện lợi, khả năng scale và mức độ kiểm soát.
• Nhắc tới rủi ro phổ biến như token bị lộ hoặc session bị chiếm quyền.

27. CORS là gì và vì sao nhiều hệ thống hay cấu hình sai?

Interviewer dùng câu này để xem bạn có hiểu bản chất CORS hay chỉ làm theo hướng dẫn có sẵn.

• Nêu mục đích của CORS trong việc kiểm soát truy cập từ trình duyệt.
• Thể hiện bạn hiểu vì sao mở wildcard có thể gây rủi ro.
• Nhắc tới việc cấu hình CORS nên bám theo domain và nhu cầu thực tế.

28. Bạn phòng tránh XSS và CSRF ở mức ứng dụng như thế nào?

Câu hỏi này kiểm tra ý thức bảo mật ở những điểm rất dễ bị bỏ qua.

• Nêu nguyên tắc xử lý và hiển thị dữ liệu người dùng nhập vào.
• Thể hiện bạn biết tách vai trò của frontend và backend trong việc phòng tránh.
• Nhắc tới việc bảo vệ các request nhạy cảm bằng cơ chế phù hợp.

29. SQL Injection là gì và bạn tránh nó ra sao trong dự án thật?

Interviewer muốn biết bạn không viết code nguy hiểm dù vô tình.

• Nêu cách tấn công xảy ra khi ghép query trực tiếp từ input.
• Thể hiện bạn dùng cơ chế an toàn sẵn có thay vì tự xử lý chuỗi.
• Nhắc tới việc validate dữ liệu đầu vào như một lớp bảo vệ bổ sung.

30. Bạn lưu mật khẩu người dùng như thế nào để đảm bảo an toàn?

Câu hỏi này đánh giá hiểu biết tối thiểu về bảo vệ thông tin nhạy cảm.

• Nêu nguyên tắc không lưu mật khẩu dạng rõ ràng hoặc mã hoá tự chế.
• Thể hiện bạn hiểu việc băm kèm yếu tố ngẫu nhiên để giảm rủi ro lộ dữ liệu.
• Nhắc tới việc xử lý reset mật khẩu và giới hạn thử sai.

31. Bạn thiết kế phân quyền theo role hoặc permission như thế nào để dễ mở rộng?

Câu hỏi này nhằm xem bạn nghĩ xa hơn một vài vai trò cố định ban đầu.

• Nêu cách tách quyền khỏi logic nghiệp vụ cụ thể.
• Thể hiện bạn tránh hard-code quyền trong code xử lý.
• Nhắc tới việc kiểm tra quyền ở backend thay vì chỉ dựa vào frontend.

Câu hỏi về tình huống production thực tế

Đây là nhóm câu hỏi thường xuất hiện ở các vòng sâu hoặc khi phỏng vấn ứng viên đã có kinh nghiệm đi làm. Interviwer dùng những tình huống này để xem bạn phản xạ ra sao khi hệ thống gặp sự cố, cách bạn ưu tiên xử lý, và khả năng giữ hệ thống ổn định dưới áp lực, chứ không chỉ kiểm tra kiến thức kỹ thuật.

32. Sau khi deploy, số lượng lỗi 500 tăng đột biến, bạn làm gì ngay lập tức?

Câu hỏi này kiểm tra phản xạ ưu tiên trong tình huống khẩn cấp.

• Xác định nhanh phạm vi ảnh hưởng và mức độ nghiêm trọng.
• Kiểm tra thay đổi vừa deploy và các tín hiệu bất thường trong log, monitoring.
• Ưu tiên rollback hoặc tắt tính năng gây lỗi nếu có cơ chế phù hợp.

33. Lỗi không tái hiện được trên local nhưng lại xảy ra ở production, bạn xử lý thế nào?

Interviewer muốn biết bạn có biết dựa vào dữ liệu thực tế thay vì cố đoán mò.

• Thu thập thông tin từ log, request, môi trường production.
• So sánh khác biệt giữa local, staging và production.
• Tạo điều kiện tái hiện gần nhất có thể để xác định nguyên nhân.

34. Latency tăng rõ rệt sau một lần release, bạn khoanh vùng nguyên nhân ra sao?

Câu này đánh giá khả năng phân tích theo từng lớp, không tối ưu mù.

• So sánh số liệu trước và sau release để tìm điểm thay đổi.
• Kiểm tra lần lượt app, database và các service phụ thuộc.
• Tránh kết luận sớm khi chưa có đủ dấu hiệu.

35. Bộ nhớ của service tăng dần theo thời gian, bạn nghi ngờ nguyên nhân gì trước?

Interviewer muốn xem bạn có hiểu các dấu hiệu memory issue thường gặp.

• Nêu khả năng giữ reference không cần thiết hoặc cache không kiểm soát.
• Thể hiện bạn theo dõi hành vi tăng bộ nhớ theo thời gian.
• Nhắc tới việc dùng công cụ quan sát để xác nhận giả thuyết.

36. CPU hoặc load database tăng cao bất thường, bạn ưu tiên kiểm tra gì?

Câu hỏi này kiểm tra tư duy bảo vệ thành phần lõi của hệ thống.

• Kiểm tra query chậm hoặc query lặp lại nhiều lần.
• Xem có thay đổi nào ở code hoặc traffic pattern gần đây.
• Thể hiện bạn tìm cách giảm tải tạm thời trước khi tối ưu sâu.

37. Retry bị cấu hình sai gây ra thác request, bạn nhận ra và xử lý thế nào?

Interviewer dùng câu này để đánh giá hiểu biết về rủi ro của retry.

• Nhận diện dấu hiệu: số request tăng theo cấp số nhân khi upstream chậm.
• Thể hiện bạn biết giới hạn retry và kết hợp backoff.
• Nhắc tới việc bảo vệ hệ thống bằng circuit breaker hoặc cơ chế tương tự.

38. Cache gây ra dữ liệu sai hoặc không đồng nhất, bạn phát hiện và xử lý ra sao?

Câu hỏi này kiểm tra khả năng cân bằng giữa hiệu năng và tính đúng đắn.

• Nêu cách phát hiện thông qua phản hồi người dùng hoặc log bất thường.
• Thể hiện bạn biết tạm thời tắt cache hoặc giảm TTL khi cần.
• Nhắc tới việc xem lại chiến lược invalidation sau khi sự cố qua đi.

39. Một endpoint bị abuse hoặc bị gọi quá mức, bạn xử lý thế nào?

Interviewer đánh giá khả năng bảo vệ hệ thống trước hành vi xấu hoặc lỗi client.

• Nêu cách phát hiện qua log, metrics hoặc alert.
• Thể hiện bạn biết áp dụng rate limit hoặc chặn tạm thời.
• Nhắc tới việc phân biệt lỗi vô tình và hành vi cố ý.

40. Queue bị backlog lớn và job xử lý chậm, bạn ưu tiên xử lý theo hướng nào?

Câu hỏi này kiểm tra tư duy xử lý bất đồng bộ khi hệ thống chịu tải.

• Xác định nguyên nhân: job chậm, worker ít, hoặc job lỗi retry liên tục.
• Thể hiện bạn ưu tiên xử lý job quan trọng trước nếu có phân loại.
• Nhắc tới việc dọn dẹp hoặc tạm ngừng job không cần thiết.

41. Khi upstream service timeout hoặc không ổn định, bạn làm gì để hệ thống không bị kéo sập?

Interviewer muốn biết bạn biết cách cô lập sự cố.

• Nêu cách giới hạn thời gian chờ và số lần gọi.
• Thể hiện bạn tránh để request bị treo lâu.
• Nhắc tới việc trả về phản hồi hợp lý cho client trong thời gian sự cố.

42. Bug liên quan tới timezone hoặc định dạng thời gian, bạn debug theo hướng nào?

Câu này thường dùng để kiểm tra kinh nghiệm với những lỗi rất khó chịu.

• Nêu cách xác định timezone của server, database và client.
• Thể hiện bạn kiểm tra dữ liệu gốc thay vì chỉ nhìn giao diện.
• Nhắc tới việc chuẩn hoá cách lưu và hiển thị thời gian.

43. Deploy nhầm cấu hình môi trường, bạn xử lý và phòng tránh thế nào?

Interviewer muốn xem bạn có học được bài học từ lỗi vận hành hay không.

• Xử lý nhanh để đưa hệ thống về trạng thái an toàn.
• Thể hiện bạn kiểm tra lại pipeline và quy trình deploy.
• Nhắc tới việc thêm bước kiểm tra để tránh lặp lại lỗi tương tự.

44. Khi xảy ra incident vào giờ cao điểm, bạn ưu tiên phục hồi hay tìm root cause?

Câu hỏi này kiểm tra khả năng ưu tiên và giao tiếp dưới áp lực.

• Nêu rõ ưu tiên khôi phục dịch vụ cho người dùng trước.
• Thể hiện bạn tách thời điểm xử lý sự cố và thời điểm phân tích nguyên nhân.
• Nhắc tới việc thông báo tình trạng cho các bên liên quan.

45. Bạn viết postmortem sau sự cố như thế nào để tránh lặp lại?

Interviewer muốn thấy bạn biến sự cố thành bài học.

• Nêu cách ghi lại bối cảnh, nguyên nhân và tác động.
• Thể hiện bạn đề xuất hành động cải thiện cụ thể.
• Nhắc tới việc chia sẻ bài học cho team, không đổ lỗi cá nhân.

46. Khi phải chỉnh sửa legacy code ngay trong lúc incident, bạn làm thế nào để giảm rủi ro?

Câu hỏi này đánh giá khả năng làm việc trong điều kiện không lý tưởng.

• Ưu tiên thay đổi nhỏ, dễ rollback.
• Thể hiện bạn hạn chế refactor lớn khi đang chữa cháy.
• Nhắc tới việc bổ sung test hoặc ghi chú sau khi hệ thống ổn định.

Lời khuyên để luyện phỏng vấn Fullstack hiệu quả hơn

Thay vì cố nhồi nhét toàn bộ kiến thức bạn hãy chọn lọc và luyện theo mục tiêu. Bạn chỉ cần tập trung vào những câu hỏi phù hợp với vị trí ứng tuyển và những phần bạn có khả năng gặp nhiều nhất, vì luyện dàn trải thường khiến bạn mệt nhưng không sâu.

Khi luyện trả lời, hãy ưu tiên sự rõ ràng. Một câu trả lời tốt thường đi theo trình tự đơn giản: bạn hiểu vấn đề gì, bạn sẽ làm gì trước, và bạn dựa vào dấu hiệu nào để kết luận. Nếu có thể nói thêm một điểm đánh đổi hoặc rủi ro cần tránh, câu trả lời sẽ chắc hơn rất nhiều mà không cần dùng nhiều thuật ngữ.

Bạn cũng nên chuẩn bị sẵn vài câu chuyện ngắn từ dự án thật, vì hầu hết câu hỏi Fullstack đều dễ ghi điểm hơn khi bạn nói bằng trải nghiệm của mình. Không cần câu chuyện hoành tráng, chỉ cần đúng tình huống, có bối cảnh rõ, có cách xử lý hợp lý và có một bài học rút ra là đủ để tạo cảm giác tin cậy.

Cuối cùng, đừng luyện theo kiểu cố có câu trả lời hoàn hảo. Điều nhà tuyển dụng muốn nghe thường là cách bạn suy nghĩ và cách bạn làm việc khi gặp vấn đề, vì đó mới là thứ họ sẽ thấy mỗi ngày nếu bạn vào team. Bạn càng luyện theo hướng thể hiện tư duy và quy trình làm việc, bạn càng bớt sợ phỏng vấn và càng dễ giữ bình tĩnh khi gặp câu hỏi khó.

Vì sao nhiều người chọn Onschool Bootcamp để chuẩn bị cho phỏng vấn Fullstack

Một trong những khó khăn lớn nhất khi chuẩn bị phỏng vấn Fullstack là biết nhiều kiến thức nhưng lại thiếu trải nghiệm để nói cho tròn câu, đúng trọng tâm. Đây cũng là lý do nhiều học viên tìm tới Onschool Bootcamp như một bước đệm trước khi bước vào thị trường tuyển dụng.

Điểm khác biệt của các chương trình Fullstack tại Onschool Bootcamp nằm ở cách học gắn chặt với dự án thực tế. Người học không chỉ viết code cho chạy, mà được hướng dẫn cách thiết kế API, xử lý dữ liệu, triển khai ứng dụng, theo dõi sau deploy và phản ứng khi hệ thống gặp sự cố ở mức vừa đủ để đi phỏng vấn. Nhờ đó, khi trả lời các câu hỏi về system, production hay trade-off, bạn có trải nghiệm thật để nói, thay vì chỉ nhắc lại lý thuyết.

Ngoài kiến thức kỹ thuật, lộ trình học còn giúp người học rèn tư duy làm việc của một Fullstack developer thực thụ: biết ưu tiên, biết đánh đổi, biết giữ hệ thống ổn định và biết trình bày vấn đề rõ ràng. Đây chính là những yếu tố thường quyết định việc bạn vượt qua vòng technical hay dừng lại ở mức tiềm năng.

Nếu bạn đang tìm một lộ trình học Fullstack bài bản, có dự án để làm và có mentor đồng hành để chuẩn bị cho phỏng vấn một cách tự tin hơn, Onschool Bootcamp là một lựa chọn đáng cân nhắc.