Bộ Câu Hỏi Phỏng Vấn Ngành IT Kèm Gợi Ý Trả Lời Chi Tiết - Coding Test Qua Rồi, Vẫn Còn Đây
Mục lục bài viết
Trong kỷ nguyên công nghệ 2026, khi AI đã tham gia sâu vào việc viết code, các nhà tuyển dụng IT không còn quá khắt khe về cú pháp. Thay vào đó, họ tập trung vào tư duy hệ thống (System Design), khả năng giải quyết vấn đề (Problem Solving), và tính thích nghi (Adaptability). Coding test - bài test kỹ thuật - vẫn là vòng đầu tiên mà hầu hết ứng viên IT phải vượt qua. Và sau coding test, những câu hỏi phỏng vấn trực tiếp mới thực sự phân loại ứng viên.
Dưới đây là bộ câu hỏi phỏng vấn ngành IT được phân theo nhóm, kèm gợi ý cách trả lời để bạn tự tin chinh phục nhà tuyển dụng.
👉 Ôn luyện các câu hỏi OOP và SQL phỏng vấn IT tại X Interview để trả lời mạch lạc, có cấu trúc!Nhóm 1 - Câu Hỏi Về Tư Duy Kỹ Thuật & Kiến Trúc
1. Lập trình hướng đối tượng (OOP) là gì? Nêu 4 tính chất đặc thù?
Câu hỏi này kiểm tra bạn hiểu bản chất thay vì học vẹt.
Gợi ý trả lời:
Lập trình hướng đối tượng là phương pháp tổ chức code theo các đối tượng, mỗi đối tượng bao gồm dữ liệu (thuộc tính) và hành vi (phương thức). 4 tính chất cốt lõi:
| Tính chất | Giải thích | Ví dụ thực tế |
|---|---|---|
| Đóng gói (Encapsulation) | Che giấu dữ liệu bên trong, chỉ cho phép truy cập qua phương thức được định nghĩa | Vỏ xe che chắn động cơ - người lái không cần biết piston hoạt động ra sao |
| Kế thừa (Inheritance) | Một lớp có thể sử dụng lại thuộc tính và phương thức của lớp khác | Xe tải và xe con đều là xe, chia sẻ đặc tính chung của "xe" |
| Đa hình (Polymorphism) | Cùng một phương thức nhưng cho kết quả khác nhau tùy đối tượng | Cùng đạp ga nhưng xe điện và xe xăng tăng tốc khác nhau |
| Trừu tượng (Abstraction) | Ẩn đi chi tiết phức tạp, chỉ hiển thị những gì cần thiết | Chỉ cần biết cách lái xe, không cần biết động cơ đốt trong hoạt động thế nào |
Mẹo trả lời: Dùng ví dụ thực tế như "chiếc xe hơi" thay vì chỉ liệt kê định nghĩa. Người phỏng vấn đánh giá cao khả năng diễn đạt bằng ví dụ, không chỉ thuộc lòng định nghĩa.
2. Sự khác biệt giữa SQL và NoSQL là gì? Khi nào nên dùng loại nào?
Gợi ý trả lời:
| Tiêu chí | SQL (Relational) | NoSQL (Non-relational) |
|---|---|---|
| Mô hình dữ liệu | Bảng với quan hệ cố định (rows + columns) | Tài liệu, key-value, đồ thị, column family |
| Tính nhất quán | Đảm bảo ACID - dữ liệu luôn nhất quán | CAP: nhất quán hoặc khả dụng tùy lựa chọn |
| Khả năng mở rộng | Mở rộng theo chiều dọc (vertical scaling) | Mở rộng theo chiều ngang (horizontal scaling) |
| Ngôn ngữ truy vấn | Structured Query Language (SQL) | Tùy loại (MongoDB query, Redis commands...) |
| Phù hợp cho | Hệ thống tài chính, ngân hàng, dữ liệu cần quan hệ chặt chẽ | Big Data, Real-time apps, dữ liệu không cấu trúc |
Nên dùng NoSQL khi: hệ thống cần xử lý Big Data, Real-time, hoặc cấu trúc dữ liệu thường xuyên thay đổi (ví dụ: ứng dụng mạng xã hội, hệ thống chat, IoT).
Nên dùng SQL khi: dữ liệu cần tính toàn vẹn cao, các bảng có quan hệ chặt chẽ, ví dụ hệ thống ngân hàng, ERP, thương mại điện tử (đơn hàng - khách hàng - sản phẩm).
3. Microservices và Monolithic khác nhau thế nào? Khi nào nên chọn loại nào?
Gợi ý trả lời:
| Tiêu chí | Microservices | Monolithic |
|---|---|---|
| Kiến trúc | Ứng dụng được chia thành nhiều dịch vụ nhỏ, độc lập | Toàn bộ ứng dụng trong một khối duy nhất |
| Triển khai | Mỗi dịch vụ triển khai độc lập | Triển khai cùng một lúc |
| Mở rộng | Mở rộng dịch vụ cụ thể cần tài nguyên | Phải scale toàn bộ ứng dụng |
| Bảo trì | Viết code mới, sửa lỗi trên từng dịch vụ | Sửa lỗi trên toàn bộ codebase |
| Rủi ro thay đổi | Thay đổi một dịch vụ ít ảnh hưởng dịch vụ khác | Thay đổi có thể ảnh hưởng toàn bộ hệ thống |
Lưu ý quan trọng: Với dự án nhỏ hoặc startup cần triển khai nhanh, Monolithic vẫn là lựa chọn tối ưu hơn. Không phải lúc nào Microservices cũng tốt hơn - đó là bài toán trade-off về độ phức tạp và quy mô dự án.
4. Làm thế nào để tối ưu hiệu suất một ứng dụng đang bị chậm?
Gợi ý trả lời - quy trình 5 bước:
Bước 1 - Đo lường (Measure): Sử dụng profiling tools (VisualVM, Chrome DevTools, New Relic...) để tìm "nút thắt cổ chai" (bottleneck). Không tối ưu trước khi đo - đoán mò là sai lầm phổ biến nhất của developer.
Bước 2 - Tối ưu Database: Đánh index cho các cột thường xuyên truy vấn, tối ưu câu lệnh SQL (tránh SELECT *, dùng EXPLAIN để phân tích query plan), cân nhắc denormalization nếu read-heavy.
Bước 3 - Sử dụng Caching: Áp dụng Redis hoặc Memcached cho dữ liệu ít thay đổi. Tầng cache có thể giảm tải database đến 90%.
Bước 4 - Tối ưu Code: Giảm vòng lặp lồng nhau, xử lý bất đồng bộ (async/await) cho các tác vụ không cần chờ, xem xét thuật toán có độ phức tạp thấp hơn.
Bước 5 - Tối ưu Front-end: Sử dụng CDN cho static assets, lazy loading cho images, minify CSS/JS, kiểm tra render-blocking resources.
👉 Thực hành các câu hỏi lập trình cơ bản với X Interview để nắm vững nền tảng trước khi phỏng vấn!Nhóm 2 - Câu Hỏi Về Kiến Thức Lập Trình Cơ Bản
5. Sự khác biệt giữa ArrayList, LinkedList và Vector?
Gợi ý trả lời:
| Tiêu chí | ArrayList | LinkedList | Vector |
|---|---|---|---|
| Cấu trúc bên trong | Mảng động (dynamic array) | Danh sách liên kết kép (doubly linked list) | Mảng động (đồng bộ) |
| Truy cập phần tử | O(1) - truy cập theo index rất nhanh | O(n) - phải duyệt từ đầu/cuối | O(1) |
| Thêm/Xóa phần tử | O(n) - phải dịch chuyển các phần tử phía sau | O(1) nếu có reference sẵn | O(n) - synchronized overhead |
| Thread-safe | Không | Không | Có (synchronized) |
| Hiệu suất bộ nhớ | Tốt hơn, ít memory overhead | Memory overhead cao hơn (node chứa 2 con trỏ) | Tương tự ArrayList |
Khi nào dùng:
- ArrayList: Khi cần truy cập theo index nhiều, thêm/xóa ít ở giữa.
- LinkedList: Khi cần thêm/xóa nhiều ở đầu/giữa, ít khi truy cập ngẫu nhiên.
- Vector: Khi cần thread-safe và dùng legacy code (Java cũ). Trong code mới, thường dùng
CopyOnWriteArrayListhoặcCollections.synchronizedList()thay thế.
6. Abstract Class và Interface khác nhau thế nào?
Gợi ý trả lời:
| Tiêu chí | Abstract Class | Interface |
|---|---|---|
| Đa kế thừa | Chỉ kế thừa được một abstract class | Một class có thể implement nhiều interface |
| Phương thức | Có thể có phương thức concrete (có body) | Java 8+ có default methods, nhưng chủ yếu là abstract |
| Thuộc tính | Có thể có thuộc tính instance | Chỉ có hằng số (public static final) |
| Constructor | Có constructor | Không có constructor |
| Mục đích chính | Chia sẻ code và trạng thái giữa các class liên quan | Định nghĩa "hợp đồng" (contract) cho các class không liên quan |
Quy tắc đơn giản:
- Dùng Abstract Class khi các class có mối quan hệ "is-a" chặt chẽ và cần chia sẻ code.
- Dùng Interface khi cần định nghĩa hành vi mà nhiều class không liên quan nhau có thể implement.
7. Exception là gì? Phân biệt Checked và Unchecked Exception?
Gợi ý trả lời:
Exception là sự kiện xảy ra trong quá trình thực thi chương trình, làm gián đoạn luồng bình thường. Exception handling giúp chương trình xử lý lỗi một cách graceful thay vì crash.
| Loại | Đặc điểm | Ví dụ | Xử lý bắt buộc? |
|---|---|---|---|
| Checked Exception | Kế thừa từ Exception nhưng không phải RuntimeException. Compiler yêu cầu khai báo hoặc xử lý. |
IOException, SQLException, FileNotFoundException |
Có - phải try-catch hoặc khai báo throws |
| Unchecked Exception | Kế thừa từ RuntimeException. Không bắt buộc phải xử lý. |
NullPointerException, ArrayIndexOutOfBoundsException, IllegalArgumentException |
Không - nhưng nên xử lý để tránh crash |
Best practice: Chỉ nên throw checked exception khi người gọi có thể kỳ vọng và xử lý được. Unchecked exception nên được dùng cho lỗi lập trình (programming error) - không nên lạm dụng try-catch cho mọi thứ.
8. Git fork và Git clone khác nhau thế nào?
Gợi ý trả lời:
| Khái niệm | Git Clone | Git Fork |
|---|---|---|
| Bản chất | Sao chép repository từ remote về local | Tạo bản sao repository (thường trên GitHub/GitLab) vào tài khoản của mình |
| Quyền truy cập | Có quyền ghi nếu có access | Hoàn toàn kiểm soát bản fork - thoải mái thử nghiệm |
| Liên kết | Liên kết trực tiếp với original repo (remote origin) | Fork tạo repo mới, muốn cập nhật từ original phải thêm upstream remote |
| Dùng khi nào | Lấy code về làm việc trên repository có quyền | Muốn đóng góp vào project không có quyền ghi, hoặc muốn thử nghiệm độc lập |
Ngoài ra cần biết:
- Branch: Tạo nhánh mới trong cùng một repository để phát triển tính năng mà không ảnh hưởng code chính.
- Git stash: Tạm lưu thay đổi chưa commit để chuyển sang làm việc khác, sau đó quay lại áp dụng.
- Git rebase vs merge: Rebase viết lại lịch sử commit để timeline gọn hơn; merge giữ nguyên lịch sử thực tế. Dùng rebase cho local branches, không rebase public/shared branches.
Nhóm 3 - Câu Hỏi Về Quy Trình & Công Cụ
9. RESTful API là gì? Nêu các mã trạng thái HTTP phổ biến?
Gợi ý trả lời:
RESTful API là kiến trúc thiết kế API dựa trên các nguyên tắc REST (Representational State Transfer). Một API được gọi là RESTful khi tuân thủ 6 nguyên tắc: client-server, stateless, cacheable, uniform interface, layered system, và code on demand (tùy chọn).
Các HTTP methods chính:
| Method | Mục đích | Ví dụ |
|---|---|---|
| GET | Lấy dữ liệu | GET /api/users - lấy danh sách users |
| POST | Tạo mới | POST /api/users - tạo user mới |
| PUT | Cập nhật toàn bộ | PUT /api/users/1 - thay thế toàn bộ user id=1 |
| PATCH | Cập nhật một phần | PATCH /api/users/1 - chỉ cập nhật trường được gửi |
| DELETE | Xóa | DELETE /api/users/1 - xóa user id=1 |
Các mã trạng thái HTTP phổ biến:
| Mã | Ý nghĩa | Ghi chú |
|---|---|---|
| 200 OK | Thành công | Response có body |
| 201 Created | Tạo thành công | Dùng sau POST tạo mới |
| 204 No Content | Thành công, không có body | Dùng sau DELETE thành công |
| 400 Bad Request | Lỗi phía client | Request không hợp lệ |
| 401 Unauthorized | Chưa xác thực | Cần login |
| 403 Forbidden | Không có quyền | Đã xác thực nhưng không được phép |
| 404 Not Found | Không tìm thấy | Resource không tồn tại |
| 422 Unprocessable Entity | Lỗi validation | Dữ liệu hợp lệ nhưng không xử lý được |
| 500 Internal Server Error | Lỗi phía server | Bug backend |
| 502 Bad Gateway | Server trả về response không hợp lệ | Thường do reverse proxy |
| 503 Service Unavailable | Server quá tải hoặc bảo trì |
10. CI/CD là gì? Lợi ích của việc tích hợp CI/CD?
Gợi ý trả lời:
CI (Continuous Integration) - Tích hợp liên tục: Mỗi khi developer push code, hệ thống tự động chạy build và test để phát hiện lỗi sớm.
CD (Continuous Deployment/Delivery) - Triển khai liên tục: Code sau khi pass CI tự động được deploy lên môi trường staging hoặc production.
Lợi ích cụ thể:
- ✅ Tự động hóa kiểm thử - giảm lỗi do con người, đảm bảo mỗi commit đều pass tests trước khi merge.
- ✅ Phát hiện lỗi sớm - bug được phát hiện trong vài phút thay vì sau nhiều ngày.
- ✅ Deploy nhanh hơn - từ vài ngày xuống còn vài phút hoặc vài giây.
- ✅ Reduce deployment risk - deploy từng phần nhỏ, rollback dễ dàng.
- ✅ Team làm việc hiệu quả hơn - developer tập trung vào code, không phải manual deployment.
Công cụ phổ biến: Jenkins, GitLab CI/CD, GitHub Actions, CircleCI, ArgoCD, Docker, Kubernetes.
11. Clean Code là gì? Nêu các nguyên tắc SOLID?
Gợi ý trả lời:
Clean Code là code dễ đọc, dễ hiểu, dễ bảo trì và mở rộng - không chỉ chạy được mà còn làm người khác (và chính bạn tương lai) hiểu được.
Các nguyên tắc SOLID:
| Chữ cái | Nguyên tắc | Ý nghĩa |
|---|---|---|
| S - Single Responsibility | Mỗi class chỉ nên có một lý do để thay đổi | Một class chỉ làm một việc duy nhất |
| O - Open/Closed | Mở để mở rộng, đóng để sửa đổi | Dùng inheritance thay vì sửa code hiện có |
| L - Liskov Substitution | Object của subclass có thể thay thế object của superclass mà không sai behavior | Con phải thực sự là "loại" của cha |
| I - Interface Segregation | Nhiều interface nhỏ chuyên biệt tốt hơn một interface lớn | Không bắt class phải implement method không dùng |
| D - Dependency Inversion | Phụ thuộc vào abstraction, không phải concrete class | Dùng interface/abstract class làm type, inject dependency |
Ngoài SOLID, cần nhớ:
- DRY (Don't Repeat Yourself) - Không lặp lại logic. Trích xuất thành hàm, class, hoặc module dùng chung.
- Đặt tên có ý nghĩa -
getUserById()tốt hơngetData(). - Viết Unit Test - test chứng minh code hoạt động đúng và giúp refactor an toàn.
Nhóm 4 - Câu Hỏi Xử Lý Tình Huống (Behavioral)
12. Kể về một bug nghiêm trọng nhất bạn từng gây ra và cách bạn xử lý?
Mục đích câu hỏi: Đo lường sự trung thực, trách nhiệm, và cách bạn xử lý áp lực.
Gợi ý cấu trúc trả lời (STAR):
Situation (Tình huống): Mô tả bối cảnh - dự án gì, bạn đang làm gì, bug xảy ra như thế nào.
Task (Nhiệm vụ): Trách nhiệm của bạn trong tình huống đó là gì.
Action (Hành động): Bạn đã làm gì cụ thể:
- Thừa nhận lỗi - đừng sợ, đừng đổ lỗi
- Hotfix ngay - khắc phục nhanh nhất có thể để giảm thiểu thiệt hại
- Thông báo với team và stakeholders (kể cả khách hàng nếu cần)
- Post-mortem - phân tích nguyên nhân gốc (root cause analysis)
- Thiết lập quy trình mới để không lặp lại (ví dụ: thêm bước Code Review kỹ hơn, viết thêm automated tests, thiết lập monitoring/alerting)
Result (Kết quả): Hệ thống phục hồi thế nào, team phản ứng ra sao, bài học gì được rút ra.
Lưu ý: Người phỏng vấn KHÔNG mong đợI bạn không bao giờ gây bug. Họ muốn thấy bạn đối mặt lỗi lầm như thế nào, có trách nhiệm không, và có hệ thống để rút kinh nghiệm không.
13. Bạn xử lý thế nào khi nhận được yêu cầu "gấp" nhưng deadline không khả thi?
Mục đích: Kiểm tra kỹ năng thương lượng, ưu tiên công việc, và giao tiếp với stakeholders.
Gợi ý trả lời:
Không bao giờ im lặng nhận yêu cầu rồi trễ hạn. Cách xử lý:
Bước 1 - Phân tích khối lượng công việc thực tế: Ước tính thời gian cho từng task cụ thể. Đừng nói "không kịp" mà hãy đưa ra con số cụ thể: "Task này cần ước tính 16 giờ, nhưng chúng ta chỉ có 8 giờ."
Bước 2 - Đề xuất giải pháp ưu tiên:
- MVP approach: Tập trung vào tính năng cốt lõi (core functionality), loại bỏ tính năng "nice-to-have" cho lần đầu.
- De-scope: Đề xuất đẩy một số tính năng phụ sang phase tiếp theo.
- Đề xuất timeline mới: Nếu chất lượng và thời gian không thể cân bằng, hãy đề xuất deadline thực tế với lý do cụ thể.
Bước 3 - Giao tiếp chủ động: Thông báo sớm với quản lý và stakeholders ngay khi nhận ra vấn đề, không phải đến ngày deadline mới báo. Sự chủ động và trung thực được đánh giá cao hơn việc cố gắng "giấu" vấn đề.
14. Bạn học công nghệ mới như thế nào khi dự án yêu cầu gấp?
Gợi ý trả lời:
Không nhảy vào học khi chưa có kế hoạch. Phương pháp học chủ động và có hệ thống:
Bước 1 - Official Documentation trước: Đọc tài liệu chính thống (official docs, RFC, spec) trước khi tìm tutorial. Đây là nguồn chính xác nhất, không bị "outdated" hay hiểu sai.
Bước 2 - Xem ví dụ thực tế: Tìm các open-source project trên GitHub sử dụng công nghệ đó. Quan sát cách họ tổ chức code, giải quyết vấn đề.
Bước 3 - Làm Proof of Concept (PoC) nhỏ: Xây dựng một demo nhỏ để nắm tư duy (how it works, why it works) thay vì chỉ học lý thuyết. PoC giúp hiểu sâu hơn và có cái để hỏi khi stuck.
Bước 4 - Hỏi khi cần: Nhờ đồng nghiệp đã có kinh nghiệm giới thiệu "big picture" - giúp tiết kiệm thời gian hàng tuần.
Bước 5 - Ghi chép và chia sẻ: Viết notes, chia sẻ với team - vừa củng cố kiến thức vừa xây dựng uy tín.
👉 Khám phá xu hướng câu hỏi phỏng vấn IT 2026 tại X Interview để chuẩn bị tốt nhất!Nhóm 5 - Xu Hướng Câu Hỏi IT 2026
15. Bạn đánh giá thế nào về việc sử dụng AI tools (như Copilot) trong công việc?
Gợi ý trả lời:
Không phủ nhận AI, nhưng cũng không phụ thuộc mù quáng.
AI tools như GitHub Copilot, ChatGPT giúp:
- Tăng tốc viết code boilerplate, tìm syntax nhanh
- Gợi ý giải thuật, cấu trúc code
- Viết document, unit test nhanh hơn
Nhưng cần lưu ý:
- AI có thể sai - suggest code không đúng hoặc không tối ưu. Cần có kiến thức nền để đánh giá output.
- Phụ thuộc AI quá mức → kỹ năng giải quyết vấn đề bị mai một - bạn có thể không biết tại sao code chạy được khi AI viết, nhưng không debug được khi nó sai.
- Ownership: Code do AI viết, bạn chịu trách nhiệm debug và maintain.
Trả lời hay: "Tôi dùng AI như một công cụ tăng năng suất, nhưng luôn review và hiểu mọi thứ tôi commit. Tôi không bao giờ copy-paste mà không hiểu."
16. Lộ trình phát triển nghề nghiệp 3 năm tới của bạn là gì?
Gợi ý trả lời:
Không nói những tham vọng mơ hồ như "làm manager." Hãy nói cụ thể và có lộ trình:
| Giai đoạn | Mục tiêu | Cách đạt được |
|---|---|---|
| Năm 1 | Vững chuyên môn, hiểu sâu hệ thống đang làm | Master ít nhất 1 ngôn ngữ/framework chuyên sâu, đọc codebase, contribute feature thực tế |
| Năm 2 | Mở rộng phạm vi, bắt đầu mentor | Học system design cơ bản, bắt đầu review code của junior, học cách truyền đạt |
| Năm 3 | Chuyên môn sâu hoặc chuyển hướng tech lead/architect | Tech lead: học quản lý team nhỏ, điều phối. Architect: học distributed systems, infrastructure |
Nguyên tắc: Nói những gì bạn thực sự muốn và có kế hoạch đạt, không phải những gì người phỏng vấn muốn nghe. Sự trung thực và có tư duy dài hạn được đánh giá cao.
Bạn có thể đọc thêm:
- Bộ Câu Hỏi Phỏng Vấn Data Analyst 2026
- Bộ Câu Hỏi Phỏng Vấn Web Developer
- Bộ Câu Hỏi Phỏng Vấn Tester
Tổng Kết
Buổi phỏng vấn IT không chỉ kiểm tra bạn nhớ được多少 câu hỏi, mà còn đánh giá cách bạn suy nghĩ, giải quyết vấn đề, và giao tiếp. Nhà tuyển dụng IT 2026 tìm kiếm người có:
- Nền tảng kỹ thuật vững - OOP, SQL, Git, API là những thứ không thể thiếu dù công nghệ nào ra đời.
- Tư duy hệ thống - không chỉ code được, mà hiểu tại sao thiết kế như vậy.
- Khả năng tự học - công nghệ thay đổi nhanh, người giỏi là người tự cập nhật được.
- Kỹ năng mềm - giao tiếp, trách nhiệm, cách xử lý áp lực.
Coding test qua rồi - những câu hỏi này mới thực sự phân biệt ứng viên. Chuẩn bị kỹ, trả lời thật, và thể hiện con người bạn - không phải một bản copy的理想 ứng viên.
Tài Liệu Tham Khảo
- Tuyển tập cheatsheet câu hỏi phỏng vấn IT - TopDev
- Top 15 câu hỏi phỏng vấn ngành IT "kinh điển" - Viblo
- Thị trường IT Việt 2025-2026 - TopCV
- 30 Common Software Engineer Interview Questions 2026 - Wiz
👉 Luyện tập thêm với bộ câu hỏi phỏng vấn IT tại x-interview.com/mypage/questions - nền tảng luyện phỏng vấn AI với phản hồi chi tiết theo từng câu trả lời.
