Senior PHP Software Engineer (Fullstack, SaaS product)

Có. Composite index sắp xếp theo cột đầu, rồi đến cột thứ hai trong cùng giá trị cột đầu, v.v. Vì vậy nó chỉ dùng hiệu quả khi query dùng các cột từ trái sang (leftmost prefix).

Với INDEX (status, created_at):

• WHERE status = 'paid' AND created_at > ...: dùng tốt.
• WHERE status = 'paid' ORDER BY created_at DESC: dùng cho cả lọc lẫn sắp xếp.
• WHERE created_at > ... (không có status): thường không dùng được.

Nguyên tắc chọn thứ tự: cột so sánh bằng (=) đặt trước, cột so sánh khoảng hoặc sắp xếp đặt sau. Nếu index chứa đủ mọi cột query cần (covering index) thì DB không phải đọc lại bảng.

Hay sai: tạo riêng index cho từng cột rồi nghĩ rằng chúng sẽ kết hợp hiệu quả như một composite index.

Isolation level quyết định một transaction thấy được bao nhiêu thay đổi của transaction khác; mức càng cao càng an toàn nhưng càng dễ tranh chấp.

• Dirty read: đọc dữ liệu transaction khác chưa commit.
• Non-repeatable read: đọc lại cùng một dòng thấy giá trị đã đổi.
• Phantom read: chạy lại cùng điều kiện thấy thêm hoặc mất dòng.

Bốn mức chuẩn: Read Uncommitted, Read Committed, Repeatable Read, Serializable. Mặc định của PostgreSQL, SQL Server, Oracle là Read Committed; MySQL InnoDB là Repeatable Read.

Thực tế các DB dùng MVCC nên hành vi có khác lý thuyết: Repeatable Read của PostgreSQL dùng snapshot nên không gặp phantom, còn InnoDB dùng gap lock cho câu đọc có khoá.

Người phỏng vấn muốn nghe: bạn biết DB mình dùng mặc định ở mức nào và đã từng xử lý lost update, vd. bằng SELECT ... FOR UPDATE hoặc optimistic locking.

Đo trước rồi mới sửa: tìm đúng query chậm, đọc execution plan, rồi chỉnh index hoặc cách viết query.

1. Bật slow query log (MySQL) hoặc pg_stat_statements (PostgreSQL) để biết query nào tốn thời gian nhất.
2. Chạy EXPLAIN (PostgreSQL nên dùng EXPLAIN (ANALYZE, BUFFERS)) xem có full scan, ước lượng số dòng lệch nhiều so với thực tế, sort trên đĩa không.
3. Sửa theo nguyên nhân: thêm hoặc đổi composite index, bỏ hàm bọc cột, chỉ SELECT cột cần, phân trang bằng keyset thay cho OFFSET lớn.
4. Kiểm tra phía ứng dụng: lỗi N+1 query, thiếu connection pool, lock chờ lâu.
5. Cập nhật thống kê (ANALYZE) nếu planner ước lượng sai.

Người phỏng vấn muốn nghe: quy trình có số liệu trước/sau, không phải đoán rồi thêm index bừa.

Cả bốn đều chạy nhiều Promise song song, khác nhau ở cách kết thúc:

• all: chờ tất cả thành công; một cái lỗi là reject ngay.
• allSettled: chờ tất cả xong, trả về trạng thái từng cái; không bao giờ reject.
• race: lấy kết quả (thành công hay lỗi) của cái xong đầu tiên; hay dùng để đặt timeout.
• any: lấy cái thành công đầu tiên; chỉ reject khi tất cả đều lỗi.

try {
  const [user, orders] = await Promise.all([getUser(id), getOrders(id)]);
} catch (err) {
  showError(err);
}

Hay sai: await lần lượt trong vòng lặp các request không phụ thuộc nhau, khiến tổng thời gian cộng dồn. Ngược lại, gọi Promise.all với hàng nghìn request cùng lúc có thể làm quá tải server; khi đó cần giới hạn số request đồng thời.

Cả hai đều mô tả hình dạng object và phần lớn trường hợp dùng thay nhau được.

• interface có thể gộp khai báo (declaration merging) và extends; hợp để mô tả object, API công khai.
• type mô tả được union, tuple, kiểu ánh xạ, kiểu điều kiện: type Status = "idle" | "loading".

Ba kiểu đặc biệt:

• any: tắt kiểm tra kiểu, lỗi lọt qua compiler.
• unknown: nhận mọi giá trị nhưng bắt buộc thu hẹp kiểu trước khi dùng. Hợp cho dữ liệu từ JSON.parse, API, catch (e).
• never: giá trị không bao giờ xảy ra; dùng để bắt thiếu case trong switch.

function assertNever(x: never): never {
  throw new Error("Unhandled: " + x);
}

Hay sai: dùng as SomeType để ép dữ liệu từ API. Đó chỉ là lời hứa với compiler; muốn chắc chắn phải validate lúc runtime (ví dụ bằng Zod).

Cần đủ ba nguồn tín hiệu được liên kết với nhau: metrics, logs, traces.

• Metrics: theo phương pháp RED cho service (Rate, Errors, Duration với p95, p99) và USE cho tài nguyên. Cảnh báo dựa trên SLO (vd. tỉ lệ lỗi, độ trễ) thay vì CPU đơn thuần.
• Logs có cấu trúc (JSON), kèm trace_id và request_id để lọc toàn bộ log của một request qua nhiều service.
• Distributed tracing với OpenTelemetry: thấy request đi qua những service nào, chậm ở đoạn nào.
• Dashboard theo từng service, ghi nhận các lần deploy để đối chiếu với thời điểm lỗi.

Khi có sự cố: ưu tiên khôi phục (rollback, tắt feature flag) trước, tìm nguyên nhân gốc sau, rồi viết postmortem không đổ lỗi cá nhân.

Người phỏng vấn muốn nghe: một sự cố thật bạn từng tham gia và điều đã cải thiện sau đó.

Chuẩn hoá là tách dữ liệu để mỗi thông tin chỉ lưu ở một chỗ, tránh dư thừa và sai lệch khi cập nhật.

• 1NF: mỗi ô một giá trị nguyên tử, không lưu danh sách trong một cột.
• 2NF: cột không khoá phụ thuộc vào toàn bộ khoá chính, không chỉ một phần.
• 3NF: cột không khoá không phụ thuộc bắc cầu qua cột không khoá khác.

Denormalize khi đọc nhiều hơn ghi rất nhiều và JOIN trở thành điểm nghẽn: lưu sẵn comment_count trong bảng bài viết, chép customer_name vào đơn hàng để giữ đúng tên tại thời điểm đặt, hoặc dựng bảng báo cáo riêng.

Hay sai: denormalize mà không có cơ chế đồng bộ (trigger, job, event) nên số liệu lệch dần. Hãy nói rõ cái giá phải trả là logic ghi phức tạp hơn.

Deadlock là khi hai transaction giữ khoá mà bên kia cần và chờ nhau mãi. DB tự phát hiện, chọn một transaction làm nạn nhân và rollback nó.

Ví dụ: T1 khoá dòng A rồi muốn B, cùng lúc T2 khoá B rồi muốn A.

Cách giảm deadlock:

• Luôn khoá tài nguyên theo cùng một thứ tự (vd. sắp xếp theo id trước khi update nhiều dòng).
• Giữ transaction ngắn, không chờ I/O bên ngoài khi đang giữ khoá.
• Có index phù hợp để câu UPDATE/DELETE không khoá quá nhiều dòng.
• Ứng dụng bắt lỗi deadlock và retry có giới hạn.

Khi điều tra: MySQL dùng SHOW ENGINE INNODB STATUS, PostgreSQL xem log (deadlock được ghi kèm câu lệnh) và pg_locks.

Người phỏng vấn muốn nghe: bạn coi retry là bình thường nhưng vẫn tìm gốc rễ ở thứ tự khoá.

Chọn theo mô hình truy cập dữ liệu, không theo xu hướng. SQL mạnh ở quan hệ, ràng buộc và transaction; NoSQL mạnh ở schema linh hoạt, mô hình dữ liệu đặc thù hoặc scale ngang dễ hơn.

• Document (MongoDB): dữ liệu dạng cây, đọc nguyên khối theo một khoá, schema thay đổi thường xuyên.
• Key-value (Redis): cache, session, rate limit, bộ đếm, hàng đợi nhỏ; dữ liệu chủ yếu nằm trong RAM.
• Wide-column, time-series, search engine: ghi khối lượng lớn, log, tìm kiếm full-text.

Trade-off: JOIN và transaction nhiều document hạn chế hoặc đắt hơn, ràng buộc dữ liệu chuyển sang tầng ứng dụng, và phải thiết kế theo query ngay từ đầu.

Người phỏng vấn muốn nghe: nhiều hệ thống dùng kết hợp, vd. PostgreSQL làm nguồn sự thật, Redis làm cache. PostgreSQL với JSONB cũng đủ cho nhiều nhu cầu "schema linh hoạt".

Cho thấy bạn tách góp ý khỏi cảm xúc cá nhân và biến nó thành hành động.

• Lắng nghe hết, hỏi lại để hiểu ví dụ cụ thể và kỳ vọng.
• Cảm ơn, kể cả khi chưa đồng ý hoàn toàn; nếu có góc nhìn khác, trao đổi bằng thông tin, không phòng thủ.
• Lên kế hoạch cải thiện và chủ động xin phản hồi lại sau một thời gian.

Câu mẫu: "Có lần lead góp ý code review của em quá dài, khó review. Lúc đầu em hơi chột dạ, nhưng em hỏi anh muốn chia thế nào cho dễ. Từ đó em tách pull request nhỏ theo từng thay đổi, thời gian review của team giảm hẳn và em cũng ít bị yêu cầu sửa lại hơn."

Hay sai: nói "em luôn vui vẻ đón nhận mọi góp ý" mà không có ví dụ.