100 câu hỏi kỹ năng phỏng vấn Java dev nào cũng nên biết (P1)

Trong thị trường công nghệ hiện nay, việc nắm vững kiến thức Java thôi là chưa đủ để đảm bảo bạn sẽ nhận được offer tốt. Để có thể thành công xin được vị trí công việc mong muốn thì kỹ năng phỏng vấn Java chính là yếu tố tạo ra khác biệt. Một buổi phỏng vấn không chỉ kiểm tra kiến thức, mà còn đánh giá tư duy, cách giao tiếp và khả năng giải quyết vấn đề của bạn. 

Bài viết này sẽ giúp bạn hiểu rõ cần chuẩn bị gì, thường gặp những dạng câu hỏi nào để từ đó nâng cao cơ hội đỗ phỏng vấn và đạt được công việc phù hợp với mục tiêu nghề nghiệp.

Bạn có thể xem thêm phần tiếp theo tại đây để biết những câu hỏi dành cho ứng viên khi phỏng vấn theo vị trí kinh nghiệm cũng như các tình huống mà nhà tuyển dụng quan tâm

Các bước trong quy trình phỏng vấn vị trí lập trình viên Java 

Khi tham gia phỏng vấn bên cạnh những câu hỏi khó thì đa số ứng viên thường cảm thấy áp lực vì không hình dung được quy trình của buổi phỏng vấn sẽ như thế nào. Trên thực tế, hầu hết các doanh nghiệp đều tổ chức phỏng vấn theo một quy trình tương đối rõ ràng nhưng tùy theo mỗi công ty mà sẽ khác nhau về độ sâu và cách triển khai. 

Thông thường, một buổi phỏng vấn lập trình viên Java sẽ bao gồm các bước sau:

1. Vòng trao đổi với nhân sự
   Đây là bước mở đầu nhằm xác nhận thông tin cơ bản về kinh nghiệm, định hướng nghề nghiệp và mức độ phù hợp của bạn với vị trí đang tuyển. Dù không đi sâu kỹ thuật, vòng này quyết định rất nhiều đến việc bạn có được bước tiếp vào phỏng vấn chuyên môn hay không.
2. Vòng phỏng vấn kỹ thuật Java
   Ở giai đoạn này, nhà tuyển dụng tập trung đánh giá trực tiếp kỹ năng phỏng vấn Java, bao gồm kiến thức nền tảng, framework, tư duy giải quyết vấn đề và khả năng giải thích giải pháp. Các câu hỏi có thể ở dạng lý thuyết, tình huống hoặc coding trực tiếp.
3. Bài test coding hoặc bài tập thực hành (nếu có)
   Một số công ty yêu cầu ứng viên giải bài toán logic, thuật toán hoặc xây dựng một chức năng nhỏ bằng Java. Mục tiêu không chỉ là kết quả cuối cùng, mà là cách bạn phân tích bài toán và triển khai giải pháp.
4. Vòng trao đổi kinh nghiệm & hành vi
   Vòng này thường xuất hiện với các vị trí từ mid-level trở lên, tập trung vào kinh nghiệm dự án, cách làm việc nhóm, xử lý sự cố và giao tiếp trong môi trường thực tế.
5. Trao đổi về offer và định hướng phát triển
   Đây là bước cuối cùng, nơi hai bên thảo luận về mức lương, chế độ đãi ngộ và lộ trình phát triển. Ứng viên hiểu rõ giá trị bản thân và thị trường sẽ có lợi thế rõ rệt ở giai đoạn này.

Ứng viên cần chuẩn bị gì trước khi tham gia phỏng vấn

Sự chuẩn bị kỹ lưỡng trước phỏng vấn sẽ giúp bạn giảm căng thẳng và tăng khả năng kiểm soát buổi trao đổi. Thay vì học dàn trải, bạn nên tập trung vào những yếu tố có tác động trực tiếp đến kết quả.

Nghiên cứu kỹ lưỡng mô tả công việc

Job description - mô tả công việc không chỉ là danh sách yêu cầu, mà còn là “bản đồ” giúp bạn hiểu nhà tuyển dụng đang tìm kiếm điều gì. Khi đọc JD, bạn nên xác định các kỹ năng cốt lõi, công nghệ chính và mức độ kinh nghiệm mong muốn. Việc này giúp bạn điều chỉnh cách trả lời sao cho sát với nhu cầu thực tế, tránh trình bày những kiến thức không liên quan.

Xây dựng hồ sơ thật rõ ràng

CV và hồ sơ cá nhân cần được trình bày mạch lạc, tập trung vào những dự án và kinh nghiệm liên quan đến Java. Thay vì liệt kê chung chung, bạn nên mô tả rõ vai trò của mình trong từng dự án, vấn đề đã giải quyết và kết quả đạt được, đặc biệt là các kinh nghiệm mà nhà tuyển dụng đang yêu cầu. Điều này giúp nhà tuyển dụng dễ dàng đánh giá năng lực và cũng tạo nền tảng để bạn trả lời các câu hỏi sâu hơn trong buổi phỏng vấn.

Thực hành tự phỏng vấn

Tự phỏng vấn là cách hiệu quả để rèn luyện phản xạ. Bạn có thể tự đặt câu hỏi, trả lời thành tiếng hoặc nhờ bạn bè đóng vai nhà tuyển dụng. Quá trình này giúp bạn phát hiện những điểm chưa rõ ràng trong cách diễn đạt, từ đó điều chỉnh trước khi bước vào buổi phỏng vấn thật.

Các chủ đề chuyên môn thường gặp khi phỏng vấn Java

Trong phỏng vấn Java, nhà tuyển dụng sẽ đánh giá độ chắc nền tảng, cách tư duy kỹ thuật và kinh nghiệm xử lý vấn đề thực tế thông qua những câu hỏi mang tính chuyên môn. Vì vậy, thay vì học thuộc câu trả lời, bạn nên hiểu mục đích đằng sau mỗi nhóm câu hỏi để trả lời đúng trọng tâm.

Tham khảo thêm top những Java Application nổi tiếng để có thể tích luỹ kiến và chinh phục nhà tuyển dụng

Câu hỏi nền tảng Java core

Nhóm câu hỏi Java core gần như xuất hiện trong mọi buổi phỏng vấn, kể cả với ứng viên nhiều kinh nghiệm, vì Java core sẽ phản ánh ứng được mức độ thành thạo của ứng viên đối với ngôn ngữ này. Những câu hỏi phỏng vấn về Java core thường gặp như:

1. Sự khác nhau giữa JDK, JRE và JVM là gì?

Bạn không cần trả lời theo kiểu định nghĩa khô khan. Điều quan trọng là bạn hiểu vai trò của từng thành phần trong quá trình code và chạy ứng dụng, đặc biệt là khi setup môi trường làm việc hoặc deploy.

• JVM chịu trách nhiệm gì khi chạy chương trình
• JRE bổ sung những gì để ứng dụng có thể chạy được
• JDK khác JRE ở điểm nào khi bạn là developer
• Trải nghiệm thực tế khi cài môi trường Java để code và deploy
  
   

2. Java “platform-independent” nhờ cơ chế nào?

Bạn nên tránh trả lời kiểu khẩu hiệu “write once, run anywhere”. Thay vào đó, hãy cho thấy bạn hiểu vì sao Java chạy được trên nhiều hệ điều hành.

• Vai trò của bytecode trong Java
• JVM giúp Java chạy trên nhiều hệ điều hành như thế nào
• Trải nghiệm khi build một ứng dụng Java và chạy trên môi trường khác
• Hạn chế hoặc hiểu nhầm thường gặp về “platform-independent”

3. Khác nhau giữa == và equals()? Khi nào override equals() thì cần override thêm gì?

Bạn không cần nói dài, nhưng nên thể hiện bạn đã từng dùng trong code thật, không chỉ học lý thuyết.

• == so sánh cái gì trong Java
• equals() thường dùng khi nào trong code
• Trường hợp bạn từng dùng equals() cho object/domain
• Vì sao khi override equals() thường phải override thêm hashCode()

4. hashCode() liên quan gì đến equals()? Lỗi phổ biến khi override là gì?

Đây là câu hỏi để đào sâu hơn, nên bạn chỉ cần cho thấy bạn hiểu hậu quả khi làm sai.

• Mối liên hệ giữa hashCode() và equals() trong collection
• Hệ quả khi override một cái mà quên cái còn lại
• Dấu hiệu cho thấy hashCode() đang bị override sai
• Trải nghiệm khi dùng HashMap/HashSet và gặp lỗi khó hiểu

5. Vì sao String là immutable? Lợi ích và trade-off của immutability?

Bạn nên tập trung vào lý do thiết kế và ảnh hưởng thực tế, không cần đi sâu JVM.

• Immutable giúp an toàn ở những khía cạnh nào
• Ảnh hưởng đến concurrency hoặc security
• Trade-off về hiệu năng khi xử lý nhiều string
• Trường hợp bạn cần dùng StringBuilder thay vì String

6. Khác nhau giữa String, StringBuilder, StringBuffer? Khi nào dùng từng loại?

Câu hỏi này thường gắn với hiệu năng, nên bạn nên trả lời theo bối cảnh sử dụng.

• Sự khác nhau về mutability và thread-safety
• Trường hợp code single-thread vs multi-thread
• Trải nghiệm thực tế khi tối ưu xử lý string
• Lý do vì sao StringBuffer ít được dùng hơn hiện nay

7. Cơ chế class loading trong Java diễn ra như thế nào (high-level)?

Bạn không cần giải thích sâu, chỉ cần cho thấy bạn biết Java load class khi nào và vì sao có lỗi liên quan.

• Java load class khi nào (compile vs runtime)
• Vai trò của class loader trong ứng dụng
• Trải nghiệm khi gặp lỗi ClassNotFoundException hoặc NoClassDefFoundError
• Tình huống thực tế liên quan đến dependency hoặc packaging

8. Checked vs unchecked exception khác nhau ra sao? Bạn dùng chúng theo nguyên tắc nào?

Câu này không nhằm phân loại cho đúng, mà để xem cách bạn thiết kế error handling.

• Khác nhau về compiler requirement
• Bạn thường dùng loại nào ở service layer
• Cách bạn tránh việc try-catch lan tràn
• Trải nghiệm debug khi exception bị xử lý không hợp lý

9. final, finally, finalize() khác nhau thế nào?

Câu này rất dễ trả lời kiểu học thuộc, nhưng bạn nên gắn với cách dùng trong code.

• final thường dùng với biến/method/class trong trường hợp nào
• finally có vai trò gì trong xử lý resource
• finalize() hiện nay còn được khuyến khích không
• Trải nghiệm khi clean up resource hoặc xử lý lỗi

10. Garbage Collection hoạt động ra sao ở mức tổng quan? Khi nào GC có thể gây “pause” đáng kể?

Không cần nói thuật toán GC, mà cần cho thấy bạn biết khi nào nên quan tâm đến GC.

• GC giải quyết vấn đề gì trong Java
• Dấu hiệu cho thấy GC đang ảnh hưởng đến performance
• Trải nghiệm khi ứng dụng bị pause hoặc latency tăng
• Nhận thức của bạn về việc tuning GC (ở mức high-level)

Hãy lưu ý: những câu trả lời lý thuyết, trích dẫn định nghĩa từ sách vở sẽ không hấp dẫn được nhà tuyển dụng. Thay vào đó, họ muốn nghe cách bạn liên hệ kiến thức nền tảng với trải nghiệm làm việc thực tế, chẳng hạn như vì sao một cách triển khai lại gây ra vấn đề, hoặc khi nào nên ưu tiên giải pháp này thay vì giải pháp khác. 

Câu hỏi về đa luồng và xử lý đồng thời

Đa luồng là chủ đề mang tính “lọc ứng viên” rất rõ trong phỏng vấn Java. 

Những câu hỏi liên quan đến thread, đồng bộ hóa hay xử lý race condition giúp nhà tuyển dụng đánh giá mức độ trải nghiệm thực tế, ví dụ như:

11. Thread lifecycle trong Java gồm những trạng thái nào?

Bạn không cần thuộc lòng enum hay liệt kê cho đủ. Điều quan trọng là bạn hiểu thread đã từng ở trạng thái nào khi bạn debug một vấn đề thật, và vì sao nó không chạy như bạn mong đợi.

•  Những trạng thái bạn thường gặp khi debug thread
• Thread chuyển từ running sang waiting/blocking trong tình huống nào
• Trải nghiệm khi thread “treo” mà không rõ lý do
• Liên hệ đến concurrency issue bạn từng xử lý

12. synchronized hoạt động như thế nào? Khác gì giữa lock trên method và lock trên block?

Bạn không cần giải thích cơ chế JVM. Thứ interviewer muốn thấy là bạn ý thức được phạm vi lock ảnh hưởng trực tiếp đến hiệu năng.

• synchronized khóa trên object nào trong từng trường hợp
• Khác nhau khi lock cả method vs chỉ lock một đoạn code
• Cách bạn thu hẹp phạm vi lock để tránh nghẽn
• Trải nghiệm lock quá rộng làm hệ thống chậm đi

13. volatile giải quyết vấn đề gì? Có thay thế được synchronization không?

Đây là câu hỏi rất dễ “nói quá”, nên bạn cần cẩn thận. Bạn nên tập trung vào một vấn đề cụ thể mà volatile giải quyết.

• Vấn đề visibility giữa các thread
• Khác nhau giữa visibility và atomicity
• Trường hợp bạn cân nhắc dùng volatile
• Vì sao volatile không thay thế hoàn toàn synchronized

14. Deadlock là gì? Bạn phát hiện và phòng tránh deadlock thế nào?

Bạn không cần đưa ra ví dụ lý thuyết kinh điển. Điều quan trọng là bạn biết deadlock trông như thế nào ngoài đời thật.

• Dấu hiệu hệ thống có thể đang bị deadlock
• Bối cảnh dễ gây deadlock (lock chéo, nhiều resource)
• Cách bạn phát hiện deadlock khi chạy production
• Thói quen hoặc nguyên tắc giúp bạn tránh deadlock về sau

15. wait()/notify()/notifyAll() khác gì so với sleep()?

Bạn không cần so sánh API từng dòng. Hãy tập trung vào việc các thread phối hợp với nhau ra sao.

• sleep() làm thread dừng nhưng ảnh hưởng gì đến lock
• wait() được dùng trong bối cảnh nào
• Khi nào notifyAll() an toàn hơn notify()
• Trải nghiệm dùng sai dẫn đến thread không bao giờ chạy lại

16. Callable và Runnable khác nhau thế nào? Future dùng để làm gì?

Câu này gắn với xử lý async, bạn nên trả lời theo trải nghiệm của bản thân để nhà tuyển dụng hiểu rõ những gì mà bạn đã vận dụng.

• Khác nhau về khả năng trả kết quả
• Khi nào bạn cần Future
• Trải nghiệm xử lý task async
• Liên hệ đến backend thực tế

17. Executor framework là gì? Vì sao nên dùng thread pool thay vì tự tạo thread?

Hãy tập trung vào bài học khi hệ thống bắt đầu có nhiều request song song.

• Vấn đề khi tự tạo quá nhiều thread
• Thread pool giúp kiểm soát resource thế nào
• Trải nghiệm khi hệ thống bị quá tải
• Liên hệ đến hiệu năng và độ ổn định

18. ConcurrentHashMap khác gì HashMap trong môi trường đa luồng?

Câu hỏi này không chỉ hỏi về thread-safety, mà còn về cách bạn chọn data structure phù hợp.

• Vấn đề khi dùng HashMap trong môi trường đa luồng
• ConcurrentHashMap giải quyết vấn đề đó ra sao
• Trải nghiệm khi dùng trong code thực tế
• Trade-off so với các cách synchronize khác

19. ThreadLocal dùng trong trường hợp nào? Rủi ro khi dùng ThreadLocal?

Đây là câu hỏi “bẫy nhẹ”, vì ThreadLocal rất tiện nhưng cũng rất nguy hiểm nếu dùng sai.

• Bối cảnh bạn cần dữ liệu gắn với thread
• Ví dụ thực tế (request context, user info…)
• Rủi ro memory leak khi thread pool tái sử dụng thread
• Cách bạn đảm bảo ThreadLocal được clean up đúng cách

20. Bạn thiết kế producer–consumer trong Java bằng cách nào (BlockingQueue / khác)?  

Bạn không cần code chi tiết. Điều quan trọng là bạn hiểu bản chất bài toán và chọn giải pháp phù hợp.

• Bối cảnh cần producer–consumer trong hệ thống
• Vì sao BlockingQueue thường là lựa chọn an toàn
• Cách bạn đảm bảo không mất dữ liệu
• Trải nghiệm khi workload tăng cao

Điểm mấu chốt khi trả lời không nằm ở việc kể tên bao nhiêu khái niệm, mà ở cách bạn nhận diện rủi ro và kiểm soát chúng. Một câu trả lời được đánh giá cao thường thể hiện được những ý như: bạn đã từng gặp vấn đề gì, hậu quả ra sao và bạn đã học được điều gì từ tình huống đó.

Câu hỏi về tối ưu hiệu năng

Java thường được sử dụng trong các hệ thống lớn, vì vậy câu hỏi về hiệu năng là điều khó tránh. Nhà tuyển dụng muốn biết bạn có tư duy tối ưu hay không, chứ không chỉ viết code cho “chạy được”. 

21. Khi API Java bị chậm đột ngột ở production, bạn sẽ kiểm tra theo thứ tự nào?

Bạn không cần đưa ra một checklist “chuẩn sách vở”. Điều quan trọng là thể hiện được bạn biết ưu tiên, không hoảng loạn và không lao vào tối ưu khi chưa hiểu chuyện gì đang xảy ra.

• API chậm trong bối cảnh nào, ảnh hưởng đến ai
• Việc đầu tiên bạn làm để xác định phạm vi sự cố
• Cách bạn khoanh vùng giữa code, database, hạ tầng hay external service
• Trải nghiệm khi đi sai hướng và phải quay lại

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

Câu hỏi này không yêu cầu phân tích lý thuyết, mà muốn xem bạn nhìn dấu hiệu để đoán đúng vấn đề hay không.

• Dấu hiệu hệ thống nghẽn CPU khác gì nghẽn IO
• Trải nghiệm khi tối ưu code nhưng không cải thiện vì nghẽn IO
• Cách bạn quyết định nên tối ưu logic hay truy vấn
• Liên hệ đến một tình huống bạn từng gặp

23. N+1 query là gì? Dấu hiệu nhận biết và cách xử lý?

Bạn không cần định nghĩa N+1. Điều interviewer muốn nghe là bạn đã từng đau vì nó hay chưa.

• Bối cảnh dễ phát sinh N+1 trong dự án
• Dấu hiệu bạn nhận ra khi chạy production
• Trải nghiệm khi data ít thì không thấy vấn đề
• Cách bạn tiếp cận xử lý và cân nhắc trade-off

24. Bạn đã từng gặp memory leak trong Java chưa? Bạn kiểm tra và xử lý thế nào?

Không cần một memory leak “khủng khiếp”. Một case nhỏ nhưng thật sẽ thuyết phục hơn rất nhiều.

• Dấu hiệu hệ thống dùng memory tăng dần theo thời gian
• Cách bạn phát hiện object không được giải phóng
• Nguyên nhân gốc bạn từng gặp (cache, listener, static reference…)
• Bài học giúp bạn tránh lặp lại

25. GC overhead là gì? Bạn phát hiện GC “đang gây hại” bằng cách nào?

Câu này không để bạn nói thuật toán GC, mà để xem khi nào bạn bắt đầu nghi ngờ GC là thủ phạm.

• GC overhead ảnh hưởng thế nào đến latency
• Dấu hiệu ứng dụng bị pause bất thường
• Trải nghiệm khi GC trở thành bottleneck
• Khi nào bạn quyết định đào sâu vào GC

26. Khi latency tăng sau deploy, bạn khoanh vùng nguyên nhân ra sao (code/config/data)?

Câu hỏi này rất thực tế và thường dành cho mid-level trở lên. Bạn nên trả lời theo quy trình suy luận, không phải theo cảm giác.

• So sánh hành vi hệ thống trước và sau deploy
• Cách bạn phân biệt lỗi do code mới hay do cấu hình
• Trải nghiệm rollback để xác nhận giả thuyết
• Bài học giúp giảm rủi ro cho lần deploy sau

27. Caching có thể cải thiện hiệu năng, vậy bạn chọn cache ở đâu (client/server/db) và vì sao?

Bạn không cần liệt kê mọi loại cache. Chỉ cần cho thấy bạn chọn cache có lý do và hiểu trade-off.

• Bài toán cụ thể bạn từng dùng cache để giải quyết
• Vì sao bạn đặt cache ở tầng đó
• Rủi ro khi cache không đồng bộ dữ liệu
• Trải nghiệm cache giúp hệ thống “sống lại”

28. Khi nào bạn tối ưu thuật toán thay vì tối ưu database (hoặc ngược lại)?

Câu hỏi này kiểm tra khả năng ra quyết định kỹ thuật, không phải kiến thức riêng lẻ.

• Dấu hiệu cho thấy vấn đề nằm ở thuật toán
• Trường hợp tối ưu DB mang lại hiệu quả rõ rệt hơn
• Trải nghiệm tối ưu sai chỗ gây tốn thời gian
• Cách bạn cân nhắc giữa hai hướng

29. Bạn đánh giá hiệu năng bằng metric nào (p95/p99, throughput, error rate…)?

Không cần kể đủ metric, chỉ cần cho thấy bạn đo đúng thứ ảnh hưởng đến người dùng.

• Metric nào phản ánh trải nghiệm thực tế
• Trải nghiệm khi chỉ nhìn average gây hiểu nhầm
• Cách bạn dùng metric để ra quyết định
• Liên hệ đến hệ thống bạn từng theo dõi

30. Bạn đã dùng profiler/monitoring nào (JFR/VisualVM/APM) và tìm ra vấn đề gì?

Câu này không nhằm kiểm tra tool, mà để xem bạn học được gì từ việc dùng tool đó.

• Vấn đề khiến bạn phải dùng profiler/monitoring
• Cách bạn tiếp cận phân tích dữ liệu
• Insight quan trọng bạn rút ra
• Ảnh hưởng của việc đó đến hệ thống

Cách trả lời hiệu quả là bắt đầu từ việc xác định nguyên nhân sau đó mới nói đến hướng cải thiện. Việc bạn biết phân tích và hiểu vấn đề nằm ở đâu và ưu tiên giải pháp phù hợp cho từng bối cảnh sẽ thể hiện rõ kinh nghiệm làm việc thực tế, thay vì chỉ học lý thuyết.

Câu hỏi về design pattern và architecture

Nhóm câu hỏi này thường xuất hiện ở cấp độ mid trở lên. Thay vì hỏi định nghĩa, nhà tuyển dụng thường đặt câu hỏi dạng tình huống để xem bạn chọn giải pháp thiết kế như thế nào.

31. Trong dự án gần nhất, bạn đã dùng design pattern nào? Bạn chọn vì lý do gì?

Bạn không cần liệt kê nhiều pattern để chứng minh mình “biết nhiều”. Một pattern dùng đúng chỗ, giải quyết được vấn đề thật sẽ thuyết phục hơn rất nhiều.

• Vấn đề tồn tại trước khi áp dụng pattern
• Pattern giúp code dễ đọc, dễ thay đổi ở điểm nào
• Phần nào của hệ thống bạn trực tiếp áp dụng
• Trải nghiệm khi pattern giúp giảm bug hoặc giảm effort về sau

32. Khi nào bạn dùng Strategy/Factory/Builder? Bạn mô tả một tình huống thật bạn đã áp dụng.

Câu hỏi này thường dùng để đào sâu, nên bạn nên chọn một tình huống cụ thể, không cần nói hết cả ba pattern.

• Bối cảnh khiến bạn cần tách logic hoặc giảm if–else
• Lý do bạn chọn pattern đó thay vì cách đơn giản hơn
• Trải nghiệm trước và sau khi áp dụng
• Trade-off về độ phức tạp bạn chấp nhận

33. Bạn tổ chức package/module theo cách nào để dễ maintain?

Không có một cấu trúc “chuẩn duy nhất”. Điều quan trọng là bạn có nguyên tắc và đã từng sửa cấu trúc cũ.

• Nguyên tắc bạn dùng để chia package hoặc module
• Trải nghiệm khi codebase lớn dần và khó tìm code
• Vấn đề bạn từng gặp với cấu trúc ban đầu
• Cách bạn cải thiện qua thời gian

34. Dấu hiệu nào cho thấy codebase cần refactor? Bạn ưu tiên refactor phần nào trước?

Câu hỏi này kiểm tra tư duy dài hạn, không phải kỹ năng code thuần túy.

• Dấu hiệu code bắt đầu khó đọc, khó sửa hoặc dễ gây bug
• Phần nào bạn ưu tiên refactor vì rủi ro cao
• Cách bạn tránh refactor lan man, mất kiểm soát
• Trải nghiệm refactor gây bug và bài học rút ra

35. Bạn thiết kế exception handling “toàn cục” trong ứng dụng web Java thế nào?

Bạn không cần mô tả chi tiết annotation hay framework. Điều quan trọng là mục tiêu của cách bạn thiết kế.

• Vì sao cần xử lý exception tập trung
• Trải nghiệm khi API trả lỗi không nhất quán
• Cách bạn đảm bảo client nhận được lỗi rõ ràng
• Lợi ích cho debug và maintain hệ thống

36. Bạn đảm bảo tính mở rộng của hệ thống bằng cách nào (layering, boundaries, contracts)?

Câu hỏi này thường dành cho mid–senior, nên bạn nên trả lời theo tư duy thiết kế, không phải chi tiết kỹ thuật.

• Cách bạn chia layer và trách nhiệm
• Vai trò của interface hoặc contract
• Trải nghiệm khi thêm feature mới vào hệ thống
• Bài học từ hệ thống khó mở rộng

37. Monolith vs microservices: bạn chọn cái nào cho sản phẩm X và vì sao?

Không có đáp án đúng tuyệt đối. Điều quan trọng là bạn chọn có cân nhắc và hiểu cái giá phải trả.

• Bối cảnh sản phẩm bạn từng làm
• Tiêu chí bạn dùng để lựa chọn kiến trúc
• Rủi ro khi chọn sai kiến trúc ngay từ đầu
• Nhận thức về chi phí vận hành lâu dài

38. Bạn xử lý distributed transaction bằng cách nào (saga/outbox/idempotency…)?

Câu hỏi này không yêu cầu bạn triển khai đầy đủ, mà muốn xem bạn hiểu vấn đề nằm ở đâu.

• Bài toán bạn gặp khi hệ thống phân tán
• Vì sao transaction truyền thống không còn phù hợp
• Cách bạn đảm bảo dữ liệu không sai
• Trade-off giữa độ an toàn và độ phức tạp

39. Bạn dùng circuit breaker/retry/backoff trong trường hợp nào?

Câu hỏi này thường xuất hiện khi hệ thống phụ thuộc external service.

• Dấu hiệu hệ thống dễ bị cascade failure
• Khi nào retry là hợp lý, khi nào là nguy hiểm
• Trải nghiệm retry gây overload hệ thống
• Cách bạn bảo vệ hệ thống trước lỗi lan rộng

40. Bạn thiết kế observability (logging, tracing, metrics) ra sao để debug nhanh? 

Đây là câu hỏi rất “đời”, liên quan trực tiếp đến vận hành.

• Logging giúp bạn debug nhanh ở điểm nào
• Trải nghiệm khi log thiếu context gây khó điều tra
• Vai trò của tracing trong hệ thống phân tán
• Bài học sau những incident thực tế

Một lỗi phổ biến là cố gắng trả lời quá nhiều vào câu trả lời. Thực tế, nhà tuyển dụng đánh giá cao những ứng viên biết cách áp dụng đúng bài toán, hiểu được ưu và nhược điểm, cũng như ảnh hưởng đến khả năng mở rộng hệ thống về sau.

Câu hỏi về thuật toán và cấu trúc dữ liệu

Thuật toán không phải lúc nào cũng khó, nhưng nó phản ánh rất rõ tư duy logic của ứng viên. Khi gặp câu hỏi dạng này, điều quan trọng không phải là trả lời thật nhanh, mà là trình bày được cách suy nghĩ của bạn.

41. Bạn chọn ArrayList hay LinkedList trong trường hợp nào?

Bạn không cần phân tích quá sâu về Big-O. Điều quan trọng là thể hiện bạn đã từng chọn sai – chọn đúng trong bối cảnh thực tế.

• Sự khác nhau về truy cập và thêm/xóa phần tử
• Trải nghiệm khi thao tác nhiều với dữ liệu lớn
• Trường hợp bạn ưu tiên đọc nhanh hơn thêm/xóa
• Bài học khi chọn nhầm cấu trúc dữ liệu

42. HashMap hoạt động ra sao ở mức tổng quan? Collision xử lý thế nào?

Câu hỏi này không đòi hỏi bạn nhớ chi tiết implement, mà muốn xem bạn hiểu HashMap ảnh hưởng đến hiệu năng ra sao.

• HashMap lưu và tìm dữ liệu theo cách nào
• Collision xảy ra khi nào và vì sao cần xử lý
• Ảnh hưởng của collision đến performance
• Trải nghiệm khi HashMap chậm hơn bạn kỳ vọng

43. Bạn phân tích độ phức tạp thời gian/không gian (Big-O) trong bài toán như thế nào?

Không cần nêu công thức cho mọi trường hợp. Bạn nên cho thấy cách bạn suy nghĩ khi đứng trước một bài toán.

• Bạn bắt đầu phân tích từ đâu
• Khi nào cần quan tâm đến Big-O, khi nào chưa cần
• Trải nghiệm tối ưu quá sớm làm code khó đọc
• Cách bạn cân bằng giữa hiệu năng và độ rõ ràng

44. Cho một stream dữ liệu lớn, bạn tìm top-K thế nào cho hiệu quả?

Câu hỏi này kiểm tra tư duy xử lý dữ liệu, không phải code cụ thể.

• Khó khăn khi dữ liệu quá lớn để load toàn bộ
• Cách bạn giới hạn lượng dữ liệu cần xử lý
• Trải nghiệm dùng cấu trúc dữ liệu phù hợp
• Trade-off giữa độ chính xác và hiệu năng

45. Bạn thiết kế LRU Cache như thế nào?

Không cần viết code hoàn chỉnh. Điều quan trọng là bạn hiểu các thành phần chính của bài toán.

• Bài toán cache bạn từng gặp trong thực tế
• Cách bạn đảm bảo phần tử ít dùng bị loại bỏ
• Trải nghiệm cache sai gây bug hoặc dữ liệu cũ
• Cách bạn kiểm soát kích thước cache

46. Bài toán “two sum / three sum” bạn giải theo hướng nào?

Đây là bài rất quen, nên interviewer thường chú ý cách bạn trình bày suy nghĩ, không phải đáp án.

• Cách bạn tiếp cận bài toán ban đầu
• Trải nghiệm giải brute-force trước khi tối ưu
• Cách bạn giải thích hướng tối ưu cho interviewer
• Bài học từ các buổi coding interview

47. Bạn xử lý bài toán string (anagram, palindrome, substring) theo cách nào?

Nhóm bài này kiểm tra khả năng xử lý dữ liệu và edge case.

• Đặc điểm chung của các bài toán string
• Cách bạn đơn giản hóa bài toán
• Trải nghiệm với edge case dễ bị bỏ sót
• Cách bạn kiểm tra lại kết quả

48. Bạn phát hiện cycle trong linked list bằng cách nào?

Không cần thuộc tên thuật toán. Quan trọng là bạn hiểu ý tưởng và giải thích được.

• Cách bạn hình dung bài toán
• Ý tưởng chính để phát hiện cycle
• Trải nghiệm khi code lần đầu bị sai
• Cách bạn trình bày ngắn gọn khi phỏng vấn

49. Bạn xử lý concurrency-safe queue/stack ra sao (ý tưởng, không cần code đầy đủ)?

Câu hỏi này kết hợp giữa thuật toán và concurrency, nên bạn nên trả lời theo bài toán thực tế.

• Bối cảnh cần queue/stack an toàn đa luồng
• Cách bạn đảm bảo dữ liệu không bị sai
• Trade-off giữa đơn giản và hiệu năng
• Liên hệ đến hệ thống bạn từng làm

50. Bạn viết test case để bắt edge case như thế nào khi làm coding test?

Câu hỏi này thể hiện bạn tư duy như người làm sản phẩm, không chỉ giải bài cho xong.

• Cách bạn xác định edge case từ yêu cầu
• Trải nghiệm bỏ sót case khiến bài fail
• Cách bạn ưu tiên test quan trọng
• Thói quen bạn rèn khi luyện tập coding test

Ngay cả khi chưa đưa ra lời giải tối ưu, việc bạn phân tích bài toán, đặt giả thuyết và từng bước tiếp cận vẫn có thể ghi điểm. Nhà tuyển dụng thường đánh giá cao quá trình hơn kết quả cuối cùng.

Câu hỏi về framework phổ biến

Framework như Spring, Spring Boot hay các thư viện liên quan là phần không thể thiếu trong phỏng vấn Java hiện nay. Nhà tuyển dụng muốn biết bạn đã sử dụng framework như thế nào trong dự án thực tế thông qua những câu hỏi.

51. Dependency Injection là gì? Bạn so sánh constructor injection vs field injection.

Bạn không cần định nghĩa DI theo sách. Điều quan trọng là bạn đã từng cảm nhận được DI giúp code “dễ thở” hơn ở điểm nào.

• Trải nghiệm khi code dễ test hơn nhờ DI
• Khác nhau khi dùng constructor injection và field injection
• Vì sao bạn ưu tiên một cách trong dự án thực tế
• Bài học khi dependency bị inject sai hoặc khó mock

52. Bean lifecycle trong Spring gồm các bước nào? @PostConstruct/@PreDestroy dùng khi nào?

Bạn không cần kể đầy đủ vòng đời bean. Chỉ cần cho thấy bạn biết khi nào nên can thiệp vào lifecycle.

• Spring tạo và quản lý bean vào thời điểm nào
• Trải nghiệm khi cần init hoặc cleanup resource
• Trường hợp bạn dùng @PostConstruct hoặc @PreDestroy
• Hệ quả khi xử lý lifecycle không đúng

53. @Component, @Service, @Repository khác nhau thế nào?

Câu hỏi này không chỉ là phân biệt annotation, mà là cách bạn tổ chức code cho dễ đọc và dễ maintain.

• Mục đích của việc tách các stereotype
• Trải nghiệm khi codebase rõ ràng hơn
• Lợi ích khi làm việc nhóm hoặc review code
• Cách bạn dùng các annotation này trong dự án

54. Spring Boot auto-configuration hoạt động ra sao (high-level)?

Bạn không cần đi sâu cơ chế nội bộ. Điều quan trọng là bạn hiểu Spring Boot đã làm gì giúp bạn.

• Auto-config giúp bạn tiết kiệm thời gian cấu hình thế nào
• Trải nghiệm khi dùng “mặc định” là đủ
• Trường hợp bạn cần override cấu hình
• Hiểu nhầm phổ biến về auto-configuration

55. @Transactional hoạt động thế nào? Rollback mặc định trong trường hợp nào?

Đây là câu hỏi rất thật với backend Java, nên bạn nên trả lời gắn với bug hoặc sự cố bạn từng gặp.

• Bối cảnh bạn cần dùng transaction
• Trải nghiệm khi rollback không như mong đợi
• Khác biệt giữa checked và unchecked exception
• Bài học khi xử lý dữ liệu quan trọng

56. JPA Entity states là gì (transient/persistent/detached/removed)?

Bạn không cần liệt kê cho đủ, mà nên cho thấy bạn hiểu entity thay đổi trạng thái trong quá trình làm việc.

• Entity ở trạng thái nào khi mới tạo
• Khi nào entity bị detached mà bạn không để ý
• Bug bạn từng gặp liên quan đến entity state
• Cách bạn tránh lỗi này về sau

57. Lazy vs eager loading: khi nào chọn cái nào?

Câu hỏi này thường gắn với performance, nên bạn nên trả lời theo use-case cụ thể.

• Trải nghiệm lazy loading gây lỗi ngoài session
• Eager loading làm query nặng hơn ra sao
• Cách bạn chọn theo nhu cầu API
• Trade-off bạn chấp nhận trong từng trường hợp

58. Bạn xử lý validation cho request (DTO) trong Spring như thế nào?

Câu hỏi này phản ánh cách bạn bảo vệ hệ thống từ đầu vào, không chỉ để “cho có”.

• Vì sao nên validate ở layer DTO
• Trải nghiệm khi thiếu validation gây lỗi logic
• Cách bạn trả lỗi rõ ràng cho client
• Lợi ích cho maintainability và debug

59. Bạn thiết kế REST API chuẩn (status code, pagination, versioning) ra sao?

Không cần trích RFC. Điều quan trọng là bạn có nguyên tắc nhất quán.

• Cách bạn chọn status code phù hợp
• Trải nghiệm khi API không nhất quán gây khó dùng
• Cách bạn làm pagination cho dữ liệu lớn
• Cách bạn xử lý versioning khi API thay đổi

60. Bạn làm security cơ bản với Spring Security/JWT như thế nào?

Bạn không cần nói chi tiết cấu hình. Chỉ cần cho thấy bạn hiểu luồng bảo mật và các rủi ro cơ bản.

• Bài toán security bạn từng xử lý
• JWT được dùng để giải quyết vấn đề gì
• Trải nghiệm cấu hình sai gây lỗi truy cập
• Nhận thức của bạn về bảo mật backend cơ bản

Một câu trả lời tốt nên tập trung vào vai trò của framework trong việc giải quyết vấn đề, thay vì mô tả lại tài liệu. Việc liên hệ đến dự án thật giúp câu trả lời trở nên đáng tin cậy và thuyết phục hơn.

Kết luận

Qua phần 1 của bài viết, bạn có thể thấy rằng phỏng vấn Java không đơn thuần là việc trả lời đúng hay sai từng câu hỏi, mà là quá trình nhà tuyển dụng đánh giá cách bạn tư duy, cách bạn đã va chạm với hệ thống thực tế và cách bạn kể lại trải nghiệm của chính mình. . 

Trong phần 2, chúng ta sẽ tiếp tục đi sâu hơn vào các nhóm câu hỏi còn lại, tập trung nhiều hơn vào tư duy hệ thống, kinh nghiệm dự án và những yếu tố giúp bạn ghi điểm ở các vòng phỏng vấn nâng cao. Nếu phần 1 giúp bạn xây nền, thì phần 2 sẽ giúp bạn hoàn thiện bức tranh tổng thể để tự tin hơn khi đối diện với nhà tuyển dụng.

Bên cạnh việc tự học và luyện phỏng vấn, một lộ trình học bài bản, gắn liền với dự án thực tế cũng là yếu tố then chốt giúp bạn nâng cao năng lực một cách bền vững. Khóa học đào tạo lập trình viên Fullstack Web Java tại Onschool Bootcamp được thiết kế theo định hướng đó: không chỉ dạy bạn Java và framework, mà còn giúp bạn hiểu cách xây dựng một ứng dụng web hoàn chỉnh, tư duy như một backend developer thực thụ và sẵn sàng cho môi trường làm việc thật.