50+ câu hỏi phỏng vấn Backend Developer thường gặp

Phỏng vấn Backend Developer không chỉ là kiểm tra khả năng cũng như kinh nghiệm của bạn mà còn là bước để bạn tạo được ấn tượng với nhà tuyển dụng. Trên thực tế, nhiều ứng viên dù có nền tảng kỹ thuật tốt vẫn không vượt qua được vòng phỏng vấn vì trả lời lan man, thiếu trọng tâm hoặc không thể hiện được tư duy hệ thống.

Các nhà tuyển dụng hiện nay thường tập trung vào cách bạn thiết kế API, xử lý dữ liệu, tối ưu hiệu năng và giải quyết các tình huống thực tế trong quá trình phát triển phần mềm. Điều này đòi hỏi lập trình viên không chỉ hiểu lý thuyết mà còn phải biết cách áp dụng vào thực tế.

Trong bài viết này, bạn sẽ tìm thấy hơn 50 câu hỏi phỏng vấn Backend Developer được hệ thống theo từng nhóm kỹ năng quan trọng. Mỗi câu hỏi đi kèm với định hướng trả lời ngắn gọn, giúp bạn biết mình cần nói gì khi bước vào buổi phỏng vấn.

Phỏng vấn Backend đang được đánh giá như thế nào

Xu hướng tuyển dụng Backend trong giai đoạn 2025-2026 đang dịch chuyển rõ rệt theo hướng đánh giá tư duy hệ thống thay vì kiểm tra kiến thức đơn thuần. Các vòng phỏng vấn kỹ thuật tại nhiều công ty công nghệ lớn ở Việt Nam hiện nay thường bao gồm ít nhất một phần system design, nơi ứng viên phải vẽ và giải thích kiến trúc của một hệ thống thực tế trong khoảng 30 đến 45 phút.

Điều này phản ánh một thực tế trong thị trường là với sự hỗ trợ của AI coding assistant, việc viết code đúng cú pháp không còn là thách thức lớn nữa. Thứ nhà tuyển dụng thực sự muốn biết là liệu bạn có thể đưa ra quyết định kỹ thuật đúng đắn, hiểu được hệ quả của những quyết định đó và giao tiếp rõ ràng về chúng với cả team hay không.

Ngoài phần kỹ thuật, các câu hỏi tình huống và hành vi cũng ngày càng được chú trọng hơn, đặc biệt với các vị trí mid-level trở lên. Nhà tuyển dụng muốn thấy ứng viên có tư duy làm việc nhóm, biết xử lý bất đồng kỹ thuật và có khả năng tự quản lý tiến độ mà không cần giám sát chặt.

Ở các phần tiếp theo, bài viết sẽ đi vào từng nhóm câu hỏi phổ biến, giúp bạn chuẩn bị đúng trọng tâm và tránh những lỗi thường gặp khi tham gia phỏng vấn Backend Developer.

Bộ 50 câu hỏi đa dạng chủ đề cần chuẩn bị

Phỏng vấn Backend hiện nay không dừng lại ở một hoặc hai chủ đề kỹ thuật mà trải rộng qua nhiều lớp khác nhau của hệ thống, từ cách thiết kế API cho đến cách ứng phó khi hệ thống gặp sự cố lúc nửa đêm. Điều đó có nghĩa là một ứng viên chuẩn bị tốt cần có hiểu biết rộng nhưng đồng thời phải đủ sâu ở những chủ đề trọng tâm phù hợp với vị trí đang ứng tuyển.

Bộ 50 câu hỏi dưới đây được chia thành sáu nhóm chủ đề chính, phản ánh đúng cấu trúc mà hầu hết buổi phỏng vấn Backend tại các công ty công nghệ Việt Nam và quốc tế đang áp dụng. 

Câu hỏi về API và thiết kế RESTful

API là lớp giao tiếp trung tâm của mọi hệ thống backend hiện đại, và cũng là chủ đề xuất hiện gần như trong mọi buổi phỏng vấn bất kể cấp độ hay lĩnh vực. Nhóm câu hỏi này không chỉ kiểm tra kiến thức kỹ thuật mà còn đánh giá tư duy thiết kế, khả năng cân nhắc trade-off và ý thức về developer experience của người dùng API.

1. REST API và GraphQL khác nhau như thế nào, khi nào bạn chọn cái nào?

Interviewer muốn biết bạn hiểu trade-off thực tế chứ không chỉ biết định nghĩa.

• Trình bày được điểm mạnh của REST trong các hệ thống đơn giản, ít thay đổi và dễ cache.
• Giải thích GraphQL phù hợp khi client cần linh hoạt trong việc lấy đúng dữ liệu mình cần.
• Đưa ví dụ thực tế từ dự án hoặc hệ thống bạn đã làm để minh họa lựa chọn của mình.

2. Bạn thiết kế API versioning như thế nào và tại sao cần làm vậy? 

Câu này đánh giá tư duy về khả năng bảo trì và backward compatibility trong dài hạn.

• Trình bày các cách versioning phổ biến như URI versioning, header versioning hoặc query param.
• Giải thích tại sao cần versioning để không làm vỡ client cũ khi API thay đổi.
• Nêu quan điểm về khi nào nên tạo version mới và khi nào chỉ cần deprecate dần.

3. Idempotency trong API là gì và tại sao quan trọng? 

Interviewer kiểm tra xem bạn có hiểu rõ hành vi của các HTTP method hay chỉ biết dùng chúng theo thói quen.

• Giải thích idempotency nghĩa là gọi nhiều lần vẫn cho kết quả như gọi một lần.
• Phân biệt các method idempotent như GET, PUT, DELETE với POST thường không idempotent.
• Nêu ứng dụng thực tế trong việc xử lý retry logic khi network gặp sự cố.

4. Làm thế nào để xử lý rate limiting trong API của bạn? 

Câu này đánh giá khả năng thiết kế API có tính ổn định và bảo vệ hệ thống trước tải cao bất thường.

• Trình bày các thuật toán rate limiting phổ biến như token bucket, sliding window hay fixed window.
• Giải thích cách trả về HTTP 429 và header thông báo để client biết khi nào thử lại.
• Đề cập đến việc lưu trạng thái rate limit ở đâu, ví dụ Redis, khi hệ thống có nhiều instance.

5. Sự khác nhau giữa authentication và authorization là gì? 

Câu mở đầu điển hình nhưng nhiều ứng viên vẫn trả lời lẫn lộn hoặc dừng ở mức định nghĩa.

• Giải thích rõ authentication xác nhận bạn là ai, authorization xác nhận bạn được làm gì.
• Đưa ví dụ cụ thể như JWT cho authentication và RBAC hay ABAC cho authorization.
• Nêu các lỗi phổ biến như chỉ kiểm tra authentication mà bỏ qua authorization ở một số endpoint.

6. Bạn xử lý lỗi trong API như thế nào để client dễ hiểu và dễ xử lý? 

Interviewer muốn biết bạn quan tâm đến developer experience của người dùng API.

• Trình bày cách dùng HTTP status code đúng ngữ nghĩa thay vì trả về 200 cho mọi trường hợp.
• Đề xuất format error response nhất quán với error code, message và có thể kèm field validation.
• Nêu tầm quan trọng của việc log lỗi phía server nhưng không lộ thông tin nhạy cảm ra response.

7. CORS là gì và bạn xử lý nó như thế nào trong backend? 

Câu này kiểm tra xem bạn hiểu vấn đề ở mức browser security hay chỉ biết thêm header cho qua.

• Giải thích CORS là cơ chế bảo mật của browser ngăn request từ origin khác không được phép.
• Trình bày cách cấu hình Access-Control headers đúng, bao gồm preflight request với OPTIONS.
• Nhấn mạnh việc không dùng wildcard cho production và chỉ whitelist những origin thực sự cần.

8. Bạn document API như thế nào và tại sao điều đó quan trọng? 

Câu này phản ánh thái độ của bạn với teamwork và khả năng bảo trì lâu dài.

• Đề cập đến OpenAPI hay Swagger như tiêu chuẩn phổ biến hiện nay cho API documentation.
• Nêu tầm quan trọng của việc giữ document đồng bộ với code, tránh doc bị lỗi thời.
• Chia sẻ kinh nghiệm về việc document tốt giúp giảm thời gian onboarding cho thành viên mới.

9. Webhook khác gì so với polling và khi nào dùng cái nào? 

Câu này đánh giá khả năng chọn đúng pattern cho bài toán tích hợp hệ thống.

• Giải thích polling là client chủ động hỏi định kỳ, webhook là server chủ động gửi khi có sự kiện.
• Trình bày polling phù hợp khi số lượng event thưa thớt, webhook hiệu quả hơn khi event nhiều và realtime.
• Nêu các lưu ý khi dùng webhook như cần xác thực nguồn gửi và xử lý retry khi endpoint không phản hồi.

10. Bạn thiết kế API để hỗ trợ pagination như thế nào? 

Câu này kiểm tra khả năng tư duy về hiệu suất và trải nghiệm khi làm việc với tập dữ liệu lớn.

• Trình bày sự khác nhau giữa offset-based pagination và cursor-based pagination.
• Giải thích cursor-based phù hợp hơn với dữ liệu thay đổi liên tục để tránh bỏ sót hay trùng lặp.
• Đề cập đến việc trả về metadata như total count, next cursor để client dễ xử lý.

Câu hỏi về cơ sở dữ liệu

Cơ sở dữ liệu là nơi mọi quyết định thiết kế sai lầm đều để lại hậu quả lâu dài và khó sửa nhất. Đây cũng là lý do nhà tuyển dụng dành nhiều thời gian cho nhóm câu hỏi này, đặc biệt với các vị trí cần xử lý dữ liệu ở quy mô lớn. Không chỉ kiểm tra kiến thức SQL hay NoSQL, interviewer muốn biết bạn có tư duy về performance, consistency và khả năng thiết kế schema phù hợp với yêu cầu nghiệp vụ thực tế hay không.

11. SQL và NoSQL khác nhau như thế nào, bạn chọn loại nào cho bài toán nào? 

Câu này không có đáp án đúng tuyệt đối, interviewer muốn nghe lý luận của bạn.

• Trình bày SQL phù hợp khi dữ liệu có cấu trúc rõ ràng, cần transaction và quan hệ phức tạp.
• Giải thích NoSQL phù hợp khi schema linh hoạt, cần scale ngang hoặc làm việc với dữ liệu phi cấu trúc.
• Đưa ví dụ thực tế về trường hợp bạn đã cân nhắc và chọn một trong hai, kèm lý do cụ thể.

12. Index trong database hoạt động như thế nào và khi nào không nên dùng? 

Nhiều developer biết index giúp query nhanh hơn nhưng ít ai biết mặt trái của nó.

• Giải thích index tạo cấu trúc dữ liệu phụ giúp tìm kiếm nhanh hơn nhưng tốn thêm storage và làm chậm write.
• Nêu các trường hợp không nên index như cột có cardinality thấp hoặc bảng thường xuyên được write nhiều.
• Đề cập đến composite index và thứ tự cột trong index ảnh hưởng đến hiệu quả query như thế nào.

13. Transaction là gì và các thuộc tính ACID có ý nghĩa gì trong thực tế? 

Câu này kiểm tra độ sâu hiểu biết về database, không chỉ dừng ở mức gọi được transaction.

• Giải thích bốn thuộc tính Atomicity, Consistency, Isolation và Durability bằng ví dụ cụ thể.
• Trình bày isolation level khác nhau như Read Committed, Repeatable Read ảnh hưởng đến performance và concurrency.
• Nêu ví dụ thực tế như chuyển tiền giữa hai tài khoản để minh họa tại sao transaction quan trọng.

14. N+1 query problem là gì và bạn xử lý như thế nào? 

Đây là vấn đề phổ biến mà nhiều developer gặp nhưng không nhận ra cho đến khi hệ thống chậm.

• Giải thích N+1 xảy ra khi một query gốc trả về N bản ghi và mỗi bản ghi lại trigger thêm một query.
• Trình bày cách khắc phục bằng eager loading, JOIN hoặc batch query tùy ORM và ngôn ngữ đang dùng.
• Đề cập đến việc dùng query profiler để phát hiện N+1 trước khi ảnh hưởng đến production.

15. Database sharding là gì và khi nào cần áp dụng? 

Câu này dành cho những vị trí mid đến senior, đánh giá tư duy về scalability ở tầng dữ liệu.

• Giải thích sharding là chia dữ liệu nằm trên nhiều database instance theo một sharding key.
• Nêu các thách thức của sharding như cross-shard query, rebalancing và distributed transaction.
• Trình bày khi nào nên cân nhắc sharding và các giải pháp thay thế nên thử trước như read replica hay caching.

16. Sự khác nhau giữa optimistic locking và pessimistic locking là gì? 

Câu này đánh giá hiểu biết về concurrency control trong môi trường nhiều user cùng thao tác dữ liệu.

• Giải thích pessimistic locking khóa record ngay khi đọc, optimistic locking chỉ kiểm tra xung đột khi ghi.
• Trình bày optimistic phù hợp với hệ thống ít xung đột, pessimistic phù hợp khi xung đột xảy ra thường xuyên.
• Nêu cách implement optimistic locking bằng version column hoặc timestamp trong thực tế.

17. Connection pooling hoạt động như thế nào và tại sao quan trọng? 

Nhiều developer dùng connection pool mà không thực sự hiểu hoạt động ra sao.

• Giải thích connection pool tái sử dụng database connection thay vì tạo mới mỗi lần request đến.
• Trình bày các thông số quan trọng như pool size, timeout ảnh hưởng đến hiệu suất và độ ổn định.
• Đề cập đến triệu chứng của pool exhaustion và cách monitor để phát hiện sớm.

18. Bạn migrate database schema như thế nào mà không gây downtime? 

Câu này kiểm tra kinh nghiệm làm việc với hệ thống production thực tế.

• Trình bày các kỹ thuật như expand-contract pattern để thêm cột mới mà không ảnh hưởng code cũ.
• Nêu tầm quan trọng của việc tách migration thành nhiều bước nhỏ thay vì một thay đổi lớn.
• Đề cập đến việc rollback plan cần được chuẩn bị trước mỗi lần deploy schema thay đổi.

19. Read replica được dùng để làm gì và có những lưu ý gì khi sử dụng? 

Câu này đánh giá hiểu biết về cách scale database và những đánh đổi đi kèm.

• Giải thích read replica giúp phân tải read query sang instance phụ, giảm tải cho primary.
• Trình bày replication lag là vấn đề cần chú ý, đặc biệt với nghiệp vụ đòi hỏi dữ liệu nhất quán ngay lập tức.
• Nêu cách quyết định query nào nên đi đến replica và query nào cần đọc từ primary.

20. Bạn thiết kế schema cho hệ thống có dữ liệu lịch sử và audit log như thế nào?

Câu này đánh giá tư duy thiết kế khi yêu cầu lưu trữ không chỉ trạng thái hiện tại mà còn lịch sử thay đổi.

• Trình bày các pattern như soft delete, versioning table hoặc event sourcing tùy mức độ phức tạp.
• Giải thích audit log cần lưu ai thay đổi, thay đổi gì và lúc nào, không chỉ lưu trạng thái cuối.
• Nêu cân nhắc về storage và query performance khi dữ liệu lịch sử tích lũy theo thời gian.

Câu hỏi về hiệu suất và tối ưu hóa

Vấn đề hiệu suất thường chỉ lộ ra khi hệ thống đã có người dùng thực tế, lúc đó áp lực sửa chữa rất lớn và chi phí cũng cao hơn nhiều so với thiết kế đúng từ đầu. Nhóm câu hỏi này đánh giá khả năng tư duy có hệ thống về performance, từ cách phát hiện vấn đề, phân tích nguyên nhân đến áp dụng đúng giải pháp trong từng tình huống cụ thể, thay vì tối ưu ngẫu nhiên theo cảm tính.

21. Bạn xác định và xử lý bottleneck trong hệ thống như thế nào? 

Câu này đánh giá quy trình tư duy có hệ thống khi gặp vấn đề hiệu suất, không phải thử ngẫu nhiên.

• Trình bày cách dùng profiling và monitoring để xác định đúng vị trí bottleneck trước khi tối ưu.
• Nêu nguyên tắc không optimize sớm và phải đo đạc trước khi kết luận.
• Chia sẻ kinh nghiệm về một bottleneck thực tế bạn đã tìm ra và giải quyết như thế nào.

22. Caching hoạt động như thế nào và bạn quyết định cache gì, không cache gì?

Interviewer muốn thấy bạn cân nhắc thực tế chứ không cache mọi thứ một cách mù quáng.

• Giải thích các tầng cache phổ biến như in-memory, distributed cache với Redis và CDN cho static asset.
• Trình bày cache invalidation là vấn đề khó nhất, cần có chiến lược rõ ràng cho từng loại dữ liệu.
• Nêu các trường hợp không nên cache như dữ liệu thay đổi liên tục hoặc yêu cầu tính nhất quán cao.

23. Cache invalidation strategy nào bạn thường dùng và tại sao? 

Câu hỏi đào sâu vào điểm khó nhất của caching, đánh giá ứng viên có kinh nghiệm thực tế hay không.

• Trình bày các chiến lược như TTL-based expiry, event-driven invalidation và cache-aside pattern.
• Giải thích write-through và write-behind cache khác nhau về consistency và performance.
• Nêu kinh nghiệm xử lý cache stampede hoặc thundering herd khi cache hết hạn đồng loạt.

24. Bạn tối ưu hóa một query SQL chậm như thế nào? 

Câu này kiểm tra kỹ năng phân tích và debug database, không phải chỉ biết lý thuyết.

• Trình bày quy trình dùng EXPLAIN hoặc EXPLAIN ANALYZE để hiểu query execution plan.
• Nêu các dấu hiệu cần chú ý như full table scan, temporary table hoặc filesort trong execution plan.
• Chia sẻ ví dụ cụ thể về một query bạn đã tối ưu và kết quả cải thiện đo được như thế nào.

25. Message queue được dùng để giải quyết vấn đề gì và bạn đã dùng trong trường hợp nào? 

Câu này đánh giá khả năng thiết kế hệ thống xử lý bất đồng bộ và tăng khả năng chịu tải.

• Giải thích message queue giúp decoupling producer và consumer, xử lý tải không đều và tăng fault tolerance.
• Trình bày sự khác nhau giữa Kafka và RabbitMQ trong cách tiếp cận và trường hợp phù hợp.
• Nêu các vấn đề cần xử lý như at-least-once delivery, message ordering và dead letter queue.

26. Horizontal scaling và vertical scaling khác nhau thế nào, khi nào dùng cái nào?

Câu hỏi cơ bản nhưng interviewer muốn nghe tư duy thực tế chứ không phải định nghĩa đơn thuần.

• Giải thích vertical scaling tăng resource cho một server, horizontal scaling thêm nhiều server vào cluster.
• Trình bày horizontal scaling phức tạp hơn vì cần xử lý stateless, session sharing và load balancing.
• Nêu khi nào nên scale vertical trước và khi nào cần thiết kế từ đầu để scale horizontal.

27. Làm thế nào bạn giảm latency cho một API endpoint đang chậm? 

Câu này đánh giá khả năng tiếp cận vấn đề hiệu suất một cách có hệ thống từ nhiều góc độ khác nhau.

• Trình bày quy trình từ đo đạc và xác định nguồn gốc latency trước khi áp dụng bất kỳ giải pháp nào.
• Nêu các hướng tối ưu như tối ưu query, thêm cache, giảm số lượng external call hoặc dùng async processing.
• Đề cập đến async và background job cho các tác vụ không cần trả kết quả ngay trong cùng request.

28. Bạn theo dõi và đo lường hiệu suất hệ thống backend như thế nào? 

Câu này đánh giá tư duy về observability, điều ngày càng được coi trọng trong môi trường production hiện đại.

• Trình bày bộ ba trụ cột của observability gồm metrics, logs và traces với vai trò của từng loại.
• Nêu các chỉ số quan trọng cần theo dõi như response time, error rate, throughput và resource utilization.
• Đề cập đến các công cụ phổ biến như Prometheus, Grafana, Datadog hoặc OpenTelemetry trong thực tế.

Câu hỏi về bảo mật

Bảo mật không phải là tính năng có thể thêm vào sau khi hệ thống đã xây xong. Đây là thứ cần được tư duy từ giai đoạn thiết kế và duy trì liên tục trong suốt vòng đời của sản phẩm. Nhóm câu hỏi này kiểm tra không chỉ kiến thức kỹ thuật về các lỗ hổng phổ biến mà còn đánh giá ý thức bảo mật chủ động, tức là liệu bạn có thói quen nghĩ đến rủi ro trước khi vấn đề xảy ra hay không.

29. SQL injection là gì và bạn phòng chống như thế nào? 

Câu kinh điển nhưng interviewer muốn biết bạn hiểu bản chất chứ không chỉ biết dùng ORM.

• Giải thích SQL injection xảy ra khi input của user được đưa trực tiếp vào câu query mà không được sanitize.
• Trình bày parameterized query và prepared statement là cách phòng chống hiệu quả nhất ở tầng code.
• Nêu thêm các lớp bảo vệ bổ sung như WAF và principle of least privilege cho database user.

30. JWT hoạt động như thế nào và có những rủi ro bảo mật nào cần lưu ý? 

Câu này phổ biến trong phỏng vấn vì JWT được dùng rộng rãi nhưng cũng hay bị implement sai.

• Giải thích cấu trúc JWT gồm header, payload và signature, và ai có thể đọc được phần nào.
• Trình bày các lỗi phổ biến như lưu JWT trong localStorage, không kiểm tra expiry hoặc dùng algorithm none.
• Nêu cách xử lý token revocation vì JWT stateless không thể invalidate trước khi hết hạn một cách đơn giản.

31. HTTPS hoạt động như thế nào và tại sao không đủ để bảo mật hoàn toàn? 

Câu này kiểm tra xem bạn hiểu HTTPS ở mức nào và biết những gì nằm ngoài phạm vi bảo vệ của nó.

• Giải thích HTTPS mã hóa dữ liệu trong transit bằng TLS, bảo vệ khỏi man-in-the-middle attack.
• Trình bày HTTPS không bảo vệ được dữ liệu sau khi đến server và không ngăn được logic lỗi trong ứng dụng.
• Nêu các lớp bảo mật bổ sung cần có như input validation, authentication, authorization và data encryption at rest.

32. Bạn lưu trữ và xử lý thông tin nhạy cảm của người dùng như thế nào? 

Câu này đánh giá ý thức về data protection và hiểu biết về các thực hành tốt trong bảo mật dữ liệu.

• Trình bày password phải được hash với algorithm chậm như bcrypt, không được lưu dạng plain text hay MD5.
• Nêu nguyên tắc data minimization, chỉ thu thập và lưu trữ những gì thực sự cần thiết.
• Đề cập đến encryption at rest cho dữ liệu nhạy cảm và kiểm soát ai trong team được quyền truy cập vào production data.

33. OWASP Top 10 là gì và bạn phòng chống những lỗ hổng phổ biến nhất như thế nào? 

Câu này đánh giá ý thức bảo mật chủ động, không phải chỉ biết fix lỗi khi bị báo cáo.

• Trình bày một số lỗ hổng quan trọng trong OWASP Top 10 mà bạn thực sự hiểu và đã xử lý.
• Nêu cách tích hợp security check vào quy trình phát triển như SAST, dependency scanning trong CI/CD.
• Chia sẻ kinh nghiệm về lần bạn phát hiện hoặc xử lý một lỗ hổng bảo mật trong dự án thực tế.

34. API key và OAuth 2.0 khác nhau như thế nào và khi nào dùng cái nào? 

Câu này kiểm tra hiểu biết về authentication mechanism phù hợp cho từng loại client và use case.

• Giải thích API key đơn giản hơn nhưng không có cơ chế revoke granular và thường có quyền truy cập rộng.
• Trình bày OAuth 2.0 phù hợp khi cần delegate quyền truy cập với scope giới hạn và có thể revoke.
• Nêu khi nào API key đủ dùng như internal service-to-service và khi nào cần OAuth như third-party integration.

35. Bạn xử lý secret và config nhạy cảm như database credential như thế nào trong môi trường thực tế? 

Câu này đánh giá thói quen làm việc an toàn với thông tin nhạy cảm trong quá trình phát triển và vận hành.

• Trình bày không được hardcode secret vào code hay commit vào git repository dù là private repo.
• Nêu các giải pháp như environment variable, secret manager như AWS Secrets Manager hay HashiCorp Vault.
• Đề cập đến việc rotate secret định kỳ và có cơ chế phát hiện khi secret bị lộ ra ngoài.

Câu hỏi về kiến trúc hệ thống và Microservices

Kiến trúc hệ thống là chủ đề phân hóa rõ nhất giữa ứng viên junior và mid đến senior. Nhóm câu hỏi này không có đáp án đúng duy nhất mà đánh giá khả năng phân tích vấn đề, hiểu rõ trade-off giữa các lựa chọn kiến trúc và khả năng bảo vệ quan điểm kỹ thuật của mình bằng lý luận có căn cứ. Đây cũng là phần nhiều ứng viên chuẩn bị thiếu nhất dù lại là phần interviewer dành nhiều thời gian nhất.

36. Monolithic và Microservices khác nhau thế nào và bạn chọn cái nào cho dự án mới? 

Câu này không có đáp án đúng duy nhất, interviewer muốn thấy bạn hiểu trade-off của từng hướng.

• Trình bày monolithic đơn giản hơn để bắt đầu, dễ debug và phù hợp với team nhỏ hoặc dự án còn thăm dò.
• Giải thích microservices phù hợp khi cần scale độc lập từng phần, có nhiều team làm việc song song.
• Nêu quan điểm về việc bắt đầu từ monolith và tách dần khi đã hiểu rõ domain thay vì microservices ngay từ đầu.

37. 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ư coupling cao, deploy ảnh hưởng lẫn nhau.
• Nhấn mạnh việc tránh tách quá sớm khi chưa có nhu cầu rõ ràng vì tăng độ phức tạp vận hành.
• Cho thấy bạn cân nhắc chi phí kỹ thuật và operational overhead khi thay đổi kiến trúc.

38. Các service trong hệ thống microservices giao tiếp với nhau như thế nào? 

Câu này kiểm tra hiểu biết về các pattern giao tiếp và khi nào dùng synchronous hay asynchronous.

• Trình bày hai hướng chính là synchronous qua REST hoặc gRPC và asynchronous qua message queue.
• Giải thích asynchronous phù hợp khi không cần kết quả ngay, giúp tăng resilience và giảm coupling.
• Nêu vấn đề của synchronous chain như latency cộng dồn và cascade failure khi một service chậm.

39. Circuit breaker pattern là gì và tại sao cần thiết trong microservices? 

Đây là câu hỏi về resilience pattern, đánh giá ứng viên có tư duy về hệ thống fault-tolerant hay không.

• Giải thích circuit breaker tự động ngừng gọi service bị lỗi để tránh làm hỏng lan rộng toàn hệ thống.
• Trình bày ba trạng thái closed, open và half-open của circuit breaker và cách chuyển đổi giữa chúng.
• Nêu ví dụ cụ thể về tình huống không có circuit breaker dẫn đến cascade failure như thế nào.

40. Distributed transaction trong microservices được xử lý như thế nào? 

Câu này đánh giá ứng viên hiểu rằng transaction kiểu truyền thống không dễ áp dụng trong môi trường phân tán.

• Giải thích tại sao không thể dùng ACID transaction thông thường khi dữ liệu nằm trên nhiều service.
• Trình bày Saga pattern như một giải pháp phổ biến với choreography và orchestration approach.
• Nêu tầm quan trọng của compensating transaction để rollback khi một bước trong saga thất bại.

41. Service discovery hoạt động như thế nào trong môi trường microservices? 

Câu này kiểm tra hiểu biết về cách các service tìm thấy nhau khi địa chỉ IP thay đổi liên tục.

• Giải thích client-side và server-side discovery là hai hướng tiếp cận chính với trade-off khác nhau.
• Trình bày các công cụ phổ biến như Consul, Eureka hoặc Kubernetes native service discovery.
• Nêu health check đóng vai trò quan trọng như thế nào để service registry luôn phản ánh đúng trạng thái.

42. API Gateway đóng vai trò gì trong kiến trúc microservices? 

Câu này đánh giá hiểu biết về single entry point pattern và những gì có thể delegate cho gateway.

• Giải thích API Gateway là điểm vào duy nhất cho client, xử lý routing, authentication và rate limiting tập trung.
• Trình bày các lợi ích như client không cần biết địa chỉ từng service và dễ áp dụng cross-cutting concerns.
• Nêu rủi ro của gateway như single point of failure và cách xử lý bằng redundancy và health check.

43. Bạn đảm bảo data consistency như thế nào trong hệ thống phân tán? 

Câu này kiểm tra hiểu biết về CAP theorem và sự đánh đổi giữa consistency và availability.

• Trình bày eventual consistency là gì và tại sao nhiều hệ thống chấp nhận để đổi lấy availability và performance.
• Giải thích strong consistency cần thiết ở đâu như thanh toán và cách đạt được với chi phí nào.
• Nêu kinh nghiệm thiết kế hệ thống chấp nhận được với eventual consistency và những trường hợp không chấp nhận được.

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

Ranh giới giữa Backend Developer và DevOps đang ngày càng mờ nhạt hơn trong các công ty công nghệ hiện đại. Developer được kỳ vọng hiểu đủ để tự deploy, tự debug môi trường và tự chịu trách nhiệm với hệ thống đang chạy, không phải chỉ viết code rồi đẩy sang cho bộ phận khác. Nhóm câu hỏi này đánh giá mức độ sẵn sàng của bạn với những trách nhiệm đó trong thực tế.

44. CI/CD pipeline của bạn thường được thiết lập như thế nào? 

Câu này đánh giá mức độ quen thuộc với quy trình phát triển hiện đại, không chỉ là viết code rồi đưa cho DevOps.

• Trình bày các giai đoạn cơ bản trong pipeline như build, test, static analysis, staging deploy và production deploy.
• Nêu tầm quan trọng của automated testing ở nhiều tầng để phát hiện lỗi sớm trước khi lên production.
• Chia sẻ kinh nghiệm về việc xử lý failed pipeline và quy trình rollback khi deploy có vấn đề.

45. Docker và container hóa mang lại lợi ích gì cho quy trình phát triển backend? 

Câu này kiểm tra hiểu biết thực tế về containerization, không phải chỉ biết dùng Docker run.

• Trình bày lợi ích về môi trường nhất quán giữa development, staging và production giúp giảm vấn đề môi trường.
• Nêu khả năng scale nhanh và deploy độc lập từng service trong kiến trúc microservices.
• Đề cập đến image size optimization và security best practices như không chạy container với root user.

46. Zero downtime deployment được thực hiện như thế nào? 

Câu này đánh giá kinh nghiệm làm việc với hệ thống production thực tế và ý thức về trải nghiệm người dùng.

• Trình bày các kỹ thuật như blue-green deployment, canary release và rolling update với ưu nhược điểm từng loại.
• Nêu database migration cần được tách riêng và backward compatible với code cũ trong quá trình chuyển đổi.
• Đề cập đến health check và automatic rollback trigger khi phát hiện error rate tăng sau deploy.

47. Bạn xử lý secret và environment configuration như thế nào khi deploy lên nhiều môi trường? 

Câu này đánh giá thực hành quản lý configuration an toàn và có tổ chức khi quy mô hệ thống tăng lên.

• Trình bày nguyên tắc tách configuration khỏi code và không commit secret vào repository.
• Nêu các giải pháp như environment variable qua CI/CD, secret manager hoặc Kubernetes secrets.
• Đề cập đến việc có strategy rõ ràng cho mỗi môi trường và audit trail khi secret được thay đổi.

48. Logging trong hệ thống phân tán cần được thiết lập như thế nào để có thể debug hiệu quả? 

Câu này kiểm tra ứng viên có hiểu thách thức của distributed tracing và structured logging hay không.

• Trình bày tầm quan trọng của correlation ID để trace một request đi qua nhiều service.
• Nêu structured logging với format JSON giúp dễ dàng query và phân tích hơn so với plain text log.
• Đề cập đến log aggregation tool như ELK stack hay Loki và cách thiết lập alert dựa trên log pattern.

49. Kubernetes giải quyết vấn đề gì và bạn đã làm việc với nó như thế nào? 

Câu này không bắt buộc ứng viên phải là Kubernetes expert, nhưng cần hiểu được bức tranh tổng thể.

• Giải thích Kubernetes giải quyết vấn đề orchestration container ở scale lớn, bao gồm scheduling, scaling và self-healing.
• Trình bày các khái niệm cơ bản như Pod, Deployment, Service và Ingress theo cách bạn thực sự hiểu chứ không phải đọc lại docs.
• Nêu kinh nghiệm thực tế kể cả nếu chỉ là dùng Kubernetes ở mức cơ bản, chia sẻ những gì bạn đã làm và học được.

50. Bạn xử lý incident trong production như thế nào khi hệ thống gặp sự cố? 

Câu hỏi cuối nhưng quan trọng, đánh giá khả năng giữ bình tĩnh và xử lý có hệ thống dưới áp lực.

• Trình bày quy trình phản ứng từ phát hiện sự cố, xác định phạm vi ảnh hưởng đến tìm nguyên nhân gốc rễ.
• Nêu tầm quan trọng của việc ưu tiên mitigate impact trước khi tìm root cause, tránh mất thời gian debug trong lúc user bị ảnh hưởng.
• Đề cập đến post-mortem sau khi giải quyết xong để rút kinh nghiệm và ngăn sự cố tương tự tái diễn.

Cách sử dụng bộ câu hỏi này hiệu quả

Cách tiếp cận hiệu quả hơn là đọc từng câu hỏi, tự thử trả lời trước khi đọc phần gợi ý, sau đó so sánh xem câu trả lời của mình đã chạm đúng vào những điểm mà interviewer đang muốn nghe hay chưa.

Với những câu hỏi mà bạn trả lời được nhưng không chắc chắn, hãy ghi chú lại và tìm hiểu sâu hơn về chủ đề đó thay vì chỉ ghi nhớ gợi ý. Mục tiêu là hiểu được bản chất của vấn đề để có thể diễn đạt theo cách của mình trong buổi phỏng vấn thực tế, chứ không phải học thuộc một câu trả lời mẫu cứng nhắc.

Kết luật

Hầu hết các câu hỏi trong thực tế đều xoay quanh những chủ đề đã được đề cập ở trên, chỉ khác nhau ở cách đặt vấn đề và mức độ đào sâu tùy vào vị trí và công ty.

Điều tạo ra sự khác biệt giữa ứng viên được chọn và ứng viên bị loại thường không phải là ai biết nhiều câu trả lời hơn, mà là ai thể hiện được tư duy rõ ràng, trung thực về giới hạn của mình và có khả năng suy luận khi gặp câu hỏi chưa từng chuẩn bị trước. Đó là thứ không thể học thuộc, nhưng có thể rèn luyện được qua thực hành và kinh nghiệm thực tế.