(Junior, Senior) FullStack Developer

== so sánh tham chiếu (hai biến có trỏ cùng một object không), còn equals() so sánh nội dung theo logic bạn định nghĩa.

• Hợp đồng: hai object equals nhau thì bắt buộc có cùng hashCode.
• HashMap/HashSet dùng hashCode để chọn bucket trước, rồi mới dùng equals để so trong bucket. Nếu chỉ override equals, hai object "bằng nhau" có thể rơi vào hai bucket khác nhau, nên set.contains(x) trả về false dù đã add.
• Với Java 16+, record tự sinh equals/hashCode/toString theo các field.

Hay sai: so sánh String hoặc Integer bằng ==. Nó có thể chạy đúng nhờ string pool hoặc cache Integer từ -128 đến 127, rồi sai với giá trị khác.

String bất biến: mọi thao tác "sửa" đều tạo object mới. Nhờ vậy nó an toàn khi chia sẻ giữa nhiều thread, dùng làm key cho HashMap được (hash không đổi) và JVM có thể dùng chung qua string pool.

• Nối chuỗi trong vòng lặp bằng + tạo nhiều object trung gian, nên dùng StringBuilder:

var sb = new StringBuilder();
for (String s : items) sb.append(s).append(',');
String result = sb.toString();

• StringBuffer giống StringBuilder nhưng các method có synchronized, chậm hơn và hiếm khi cần.
• Nối vài chuỗi trên một dòng thì cứ dùng +, compiler đã tối ưu sẵn.

Người phỏng vấn muốn nghe: bạn hiểu lý do thiết kế (an toàn, hash, pool), không chỉ thuộc định nghĩa.

Checked exception (kế thừa Exception nhưng không phải RuntimeException) bị compiler bắt buộc phải catch hoặc khai báo throws, ví dụ IOException. Unchecked (RuntimeException và con của nó) thì không, ví dụ NullPointerException, IllegalArgumentException.

• Checked hợp với lỗi bên ngoài mà caller có thể xử lý được; unchecked thường là lỗi lập trình hoặc vi phạm điều kiện.
• try-with-resources tự gọi close() cho mọi object implement AutoCloseable, kể cả khi có exception:

try (var reader = Files.newBufferedReader(path)) {
    return reader.readLine();
}

Hay sai: catch (Exception e) {} rồi bỏ trống, làm mất dấu lỗi. Ít nhất phải log kèm stack trace, hoặc bọc lại thành exception có ý nghĩa và ném tiếp.

WHERE lọc từng dòng trước khi gom nhóm; HAVING lọc sau GROUP BY, nên dùng được hàm tổng hợp như COUNT, SUM.

Thứ tự logic: FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT/OFFSET.

SELECT department_id, AVG(salary) AS avg_salary
FROM employees
WHERE status = 'active'
GROUP BY department_id
HAVING AVG(salary) > 20000000;

• Vì SELECT chạy sau WHERE, bạn không dùng được alias của SELECT trong WHERE (đa số DB).
• Điều kiện không cần hàm tổng hợp thì nên để ở WHERE để giảm số dòng phải gom nhóm.

Người phỏng vấn muốn nghe: bạn hiểu thứ tự logic, từ đó giải thích được vì sao alias hoặc aggregate dùng sai chỗ bị lỗi.

Index là cấu trúc dữ liệu phụ (thường là B-Tree) giúp tìm dòng theo giá trị cột mà không phải quét cả bảng, đổi lại tốn dung lượng và làm chậm thao tác ghi.

• B-Tree hợp với so sánh =, <, >, BETWEEN, ORDER BY, LIKE 'abc%'.
• Mỗi INSERT/UPDATE/DELETE phải cập nhật thêm mọi index liên quan.
• Cột có độ chọn lọc thấp (vd. gender, is_deleted) đánh index riêng thường ít tác dụng.

Không nên đánh index tràn lan: chỉ thêm cho cột hay xuất hiện trong WHERE, JOIN, ORDER BY của các query quan trọng, rồi kiểm tra bằng EXPLAIN.

Hay sai: bọc cột trong hàm, vd. WHERE YEAR(created_at) = 2026 hoặc LOWER(email) = ..., khiến index thường trên cột đó không được dùng. Hãy viết lại thành khoảng thời gian hoặc dùng index trên biểu thức.

Lỗi trong Go là giá trị kiểu error, được trả về như kết quả thông thường và phải kiểm tra tường minh. panic chỉ dành cho tình huống không thể tiếp tục hoặc lỗi lập trình (ví dụ cấu hình bắt buộc bị thiếu lúc khởi động), không dùng cho lỗi nghiệp vụ.

Bọc lỗi để giữ ngữ cảnh mà không mất lỗi gốc:

if err != nil {
    return fmt.Errorf("load user %d: %w", id, err)
}
// Ở tầng trên:
if errors.Is(err, sql.ErrNoRows) { /* trả 404 */ }

• errors.Is: so với một lỗi cụ thể trong chuỗi bọc.
• errors.As: lấy ra lỗi thuộc một kiểu cụ thể để đọc field của nó.
• recover trong defer dùng ở biên (middleware HTTP) để một request panic không làm sập cả server.

Hay sai: dùng %v thay %w khi bọc, làm errors.Is không tìm thấy lỗi gốc.

HashMap là mảng các bucket. Khi put, nó tính hashCode() của key, suy ra chỉ số bucket, rồi lưu entry vào đó. Nhiều key trùng bucket thì nối thành danh sách; từ Java 8, khi một bucket quá dài thì chuyển thành cây đỏ đen để tránh tìm kiếm O(n).

• Khi số phần tử vượt capacity * loadFactor (mặc định 0.75) thì map resize gấp đôi và phân bố lại.
• get/put trung bình O(1). HashMap không thread-safe.

ArrayList dựa trên mảng: truy cập theo index O(1), thêm cuối nhanh, chèn/xoá ở giữa phải dời phần tử. LinkedList là danh sách liên kết đôi: truy cập theo index O(n), tốn bộ nhớ hơn cho mỗi node.

Người phỏng vấn muốn nghe: trên thực tế ArrayList gần như luôn nhanh hơn nhờ dữ liệu nằm liền nhau trong bộ nhớ (cache-friendly).

IoC container của Spring tạo và quản lý các bean, rồi "tiêm" phụ thuộc vào class cần dùng, thay vì class tự new. Nhờ vậy code ít phụ thuộc cứng, dễ thay implementation và dễ test.

Constructor injection được khuyên dùng vì:

• Field có thể là final, object luôn ở trạng thái đầy đủ sau khi tạo.
• Test unit không cần Spring: chỉ cần new OrderService(mockRepo).
• Constructor quá nhiều tham số là dấu hiệu class đang ôm nhiều việc.
• Class chỉ có một constructor thì không cần ghi @Autowired.

Nên nói thêm về scope: mặc định bean là singleton (một instance cho cả context), ngoài ra có prototype, request, session.

Hay sai: để state thay đổi được (ví dụ biến đếm, list) trong bean singleton. Nhiều request chạy song song sẽ dùng chung và gây race condition.

Spring tạo proxy bao quanh bean. Khi gọi method có @Transactional qua proxy, proxy mở transaction, gọi method thật, rồi commit hoặc rollback.

Những lý do hay gặp khiến nó "không ăn":

• Self-invocation: method A trong cùng class gọi this.b() có @Transactional, lời gọi không đi qua proxy.
• Method là private hoặc final: proxy không chặn được lời gọi.
• Mặc định chỉ rollback với unchecked exception và Error. Checked exception vẫn commit, trừ khi khai báo rollbackFor = Exception.class.
• Exception bị catch và nuốt bên trong method.

Nên biết thêm propagation (REQUIRED, REQUIRES_NEW) và readOnly = true cho các truy vấn chỉ đọc.

Người phỏng vấn muốn nghe: bạn giải thích được bằng cơ chế proxy, không chỉ liệt kê lỗi.

Trả lời thẳng thắn và cân bằng: sẵn sàng khi thật sự cần, nhưng không coi OT kéo dài là bình thường.

Câu mẫu: "Em sẵn sàng làm thêm khi có việc gấp như sự cố production hay trước một đợt release quan trọng. Nhưng nếu OT diễn ra thường xuyên, em nghĩ cần xem lại cách estimate hoặc phạm vi, và em sẽ chủ động nêu điều đó với team. Em cũng muốn hỏi thêm: ở team mình OT thường xảy ra trong trường hợp nào và được tính như thế nào ạ?"

Đây cũng là lúc bạn tìm hiểu ngược: OT có được trả lương hoặc nghỉ bù theo quy định không, tần suất ra sao. Câu trả lời của họ cho bạn biết nhiều về văn hoá công ty.

Hay sai: hứa "OT thoải mái" để lấy điểm, rồi vào làm mới thấy không chịu nổi.