JAVA BACKEND + FDE — INTERVIEW FOUNDATION V5.2: LEARN → BUILD → SPEAK

V5.2, cập nhật 18/10/2026. Giữ các bài kiến thức/code/SQL từ V4 và tổ chức lại 261 cặp Q&A xen ngay từng chủ đề; không dồn 225 + 36 câu xuống cuối.

Nguồn: V4/V5.1 và ba file Project Deep Dive người học cung cấp. Các project là bản mô tả code; chưa xác minh độc lập repository hoặc đóng góp cá nhân.

Giáo trình nền (17/10/2026). Nội dung kỹ thuật V3.2 phía dưới được giữ nguyên để bảo toàn ví dụ, bài code/SQL, đáp án, checklist và phạm vi chuyên môn. V4 bổ sung lớp thực hành Speaking Lab vào 20 mô-đun/lab. Các đoạn hội thoại/mẫu trả lời V4 là bài luyện mới biên soạn theo nội dung V3.2, không phải câu hỏi phỏng vấn chính thức của công ty.

Mục tiêu: (1) hiểu và thực hành Java Backend/FDE; (2) hiểu câu hỏi tiếng Anh nói thành tiếng; (3) tự trả lời rõ ràng không đọc script; (4) xử lý follow-up bất ngờ. Không học tiếng Anh bằng cách thuộc lòng 100 đoạn văn.

ĐÁNH SỐ ĐỂ TẠO TTS — 261 cặp, 522 mục đọc

QUY TẮC ĐÁNH SỐ TTS (áp dụng đồng nhất trong hai file): Có 261 cặp Q&A = 522 mục đọc. Mỗi câu hỏi tính là một mục TTS, và toàn bộ câu trả lời tính là một mục TTS, dù câu trả lời có nhiều câu tiếng Anh. Số TTS chạy liên tục từ 001 đến 522 theo đúng thứ tự học. Số lẻ là câu hỏi; số chẵn kế tiếp là đáp án. Ví dụ: TTS 007 (Q) What is a business invariant? và TTS 008 (A) An invariant is a rule that must remain true after every valid operation. For example, one room must not be allocated to two confirmed bookings for the same night. Để tạo giọng đọc, sao chép toàn bộ nội dung sau dấu hai chấm của từng mục TTS, không đọc nhãn số hoặc Q/A. Số cặp Q001–Q261 cũng chạy liên tục và giống nhau giữa hai file.

ĐIỀU HƯỚNG V5.2 — học xen kẽ trong cùng một chủ đề

Nguyên tắc: không đọc hết lý thuyết rồi mới sang tập nói. Mở một bài theo dòng PRETEST → WATCH → COMPLETE/DO → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → FEEDBACK. Đáp án Q&A đều nằm dưới mục mở rộng, không hiện sẵn khi đọc lướt. 261 câu không phải 261 bài phải thuộc lòng.

• Module thường: sau phần kiến thức và bài DO là Speaking Lab chứa đúng Q&A của module đó, đã tách FREE SPEAK và FOLLOW-UP.
• Module dài 04 / 08A / 08B: không phải làm 17/30/30 câu một lúc. Ngay sau các tiểu mục sẽ có MICRO SPEAK (2–10 câu) để học và nói tại chỗ; Speaking Lab cuối module chỉ tổng ôn, không lặp danh sách.
• Project labs: V-Market rồi V-Core sau LAB 08C; V-Pulse sau LAB B; Cross-project sau Module 11. Khi ôn JD Java Backend, ưu tiên V-Market; khi ôn integration/FDE, thêm V-Pulse.
• Mỗi lần: 1 đoạn kiến thức + 1 bài DO + khoảng 3–6 Q&A + một biến thể khó hơn. Lúc ôn mới nghe blind questions hoặc bản TTS.
• Nguyên tắc nguồn: Q&A bám theo bộ 261 câu V5.1; không sửa nội dung câu hỏi hoặc tự thêm achievement/project. Các câu project nói theo tài liệu mô tả, không chứng minh người học đã tự triển khai.

Cách đọc: phần câu hỏi hiện ra trước; bấm vào dòng Mở đáp án mẫu sau khi đã nói. Ở bản đánh số này, mỗi mục TTS nằm trên một dòng, kể cả khi đáp án có nhiều câu; số thứ tự khớp hoàn toàn với bản Q&A riêng.

HƯỚNG DẪN BẮT ĐẦU — đọc 1 lần, rồi học theo module

A. Học thế nào để không gấp đôi thời gian?

Mỗi buổi học 40–55 phút dùng một bài kỹ thuật bên dưới và Speaking Lab ở CUỐI bài đó. Không phải học xong toàn bộ tài liệu rồi mới học tiếng Anh.

Nếu chỉ có 25 phút: 5' ôn source + 8' DO + 4' nghe/nhại + 6' cold speaking + 2' ghi lỗi. Nếu dư thời gian: luyện hội thoại đời thường 5–10 phút và ôn một bài cũ. Không bỏ DO để chỉ tập nói một đáp án sai.

B. Một thang độ khó cho tất cả chủ đề

• L0 — Recognize (10–20 giây): nghe/đọc câu hỏi, biết interviewer yêu cầu định nghĩa, luồng, lý do hay test; giải thích khái niệm bằng tiếng Việt.
• L1 — Supported (20–40 giây): tự nói 2–4 câu tiếng Anh đơn giản có mẫu what → why → example. Có thể nhìn từ khóa; không nhìn nguyên câu.
• L2 — Independent (45–90 giây): không nhìn script, trả lời answer → reasoning → example/failure/test; người nghe hiểu được.
• L3 — Interactive (90–150 giây): interviewer cắt ngang, đổi dữ kiện; bạn hỏi rõ assumption, nói lại lựa chọn và trade-off. L3 quan trọng với FDE và project deep dive.

Chưa đạt L1 thì không ép nói 4 phút. Với người đang giao tiếp cơ bản: bắt đầu chu kỳ 60 → 45 → 30 giây cho cùng một câu hỏi. Khi đã nói liền mạch, dùng 2 phút → 90 giây → 60 giây; khi đủ khả năng duy trì ý, mới thử 4/3/2. Giảm thời lượng không đồng nghĩa cố nói thật nhanh; phải giữ những ý kỹ thuật thiết yếu.

C. Vòng nói 5 lượt để biến từ vựng thụ động thành phản xạ

1. LISTEN: che transcript; nghe câu hỏi 1 lượt bằng Voice/TTS; nói bằng tiếng Việt câu hỏi đang muốn gì. Nghe lại nếu cần.
2. SHADOW: nhìn 1–2 câu mẫu, nghe và bắt chước âm, stress, ngắt cụm 2 lần. Shadowing không thay thế tự trả lời.
3. RETRIEVE: che tài liệu, tự gọi lại 3–5 từ khóa (transaction, rollback, consistency...), giải thích chúng bằng một câu.
4. FREE SPEAK: nhấn thu âm, tự nói 30–90 giây theo ý hiểu. Nếu quên từ: dùng câu dễ hơn; đừng chuyển toàn bộ sang tiếng Việt.
5. FEEDBACK → REPEAT → TRANSFER: mở mẫu sau khi nói, sửa 1–2 điểm, nói lại; trả lời một câu biến thể chưa chuẩn bị. Transfer là phần chống học vẹt.

D. Khung câu ít nhưng đa năng (dùng được trên toàn file)

Câu để câu giờ/hỏi lại: Could you repeat the last part? · Could you rephrase the question? · Do you mean X or Y? · May I take a moment to think? · Let me correct my answer. · I'm not sure about that detail; here's how I would verify it.

E. Cách dùng ChatGPT Voice hoặc một đối tác luyện tập

Dán prompt dưới đây trước một buổi speaking. Không yêu cầu AI đưa đáp án khi bạn chưa nói.

You are my technical English speaking coach. My current level is basic conversational English.
Focus on Java Backend and software-oriented Forward Deployed Engineer interviews.
Today's module: [PASTE MODULE NAME].
Ask ONE question at a time; do not show or read a model answer before I reply.
Start with a simple definition (20–40 seconds), then ask a how/why question,
then ask ONE unpredictable follow-up or change one requirement.
If I do not understand, first rephrase the question in simpler English.
Do not interrupt me for minor errors. After I finish, give feedback in this order:
(1) technical correctness, (2) clarity/organization, (3) two useful language corrections,
(4) one more natural short alternative, (5) ask me to answer again without a script.
Do not invent work experience for me. End with one new transfer question.

Cách làm listening blind: yêu cầu người đọc/AI chỉ đọc câu hỏi, không hiển thị câu hỏi dạng chữ nếu giao diện cho phép; người học nói lại ý yêu cầu trước khi trả lời. TTS có thể đọc với tốc độ vừa phải; tăng tốc dần sau khi hiểu.

F. Cách chấm: tách kỹ thuật khỏi tiếng Anh

Chỉ chuyển mô-đun khi: K ≥ 2, S ≥ 2, hiểu ít nhất 2/3 câu nghe liên quan (L ≥ 2 nếu tự luyện được audio), và giải được bài DO/biến thể ở tài liệu gốc. Không cần phát âm như người bản ngữ. Nếu K thấp hãy quay lại kiến thức; nếu K tốt mà S thấp hãy tăng lượt trả lời/nhận sửa, không đọc lại cả chương.

Ghi lỗi: term (không hiểu từ), concept (không hiểu kỹ thuật), reasoning (không giải thích được), listening (không bắt âm), retrieval (biết nhưng không nhớ khi nói), fluency (dừng quá lâu), pronunciation (nghe không rõ), grammar (lỗi gây hiểu nhầm). Chỉ sửa tối đa 2–3 lỗi trong một lượt nói.

G. Ôn giãn cách và bài hội thoại đời thường

• Cuối buổi: không nhìn file, nói 1 định nghĩa + 1 tình huống biến thể.
• Ngày +1: nghe 1 câu cũ, trả lời không nhìn; sau đó câu mới cùng chủ đề.
• Ngày +3: kể lại một cơ chế/failure 60 giây, dùng từ khác mẫu cũ.
• Ngày +7: 3 câu từ 3 mô-đun ngẫu nhiên, có ít nhất 1 follow-up.
• Ngày +14: mini mock 5 phút không thông báo trước chủ đề.
• Song song: 5–10 phút General English nói về lịch học, công việc, khó khăn, sở thích; mục tiêu là đối đáp tự nhiên, không chỉ đọc thuật ngữ IT.

Các mốc ôn là lịch đề xuất, có thể điều chỉnh theo error log; không phải khoảng cách tối ưu cho mọi người.

H. Ví dụ hoàn chỉnh — đọc 1 lần trước khi dùng Speaking Labs

Tình huống: A user clicks Book twice after a timeout. Could this create two bookings?

1. Hiểu bằng tiếng Việt: Timeout không chứng minh server thất bại. Retry có thể lặp side effect của POST; cần cơ chế chống trùng và kiểm tra kết quả cũ.
2. 3 chunks: the response was lost (phản hồi bị mất), retry the request (thử lại), idempotency key (khóa chống lặp hiệu ứng).
3. Shadow 2 câu: A timeout does not necessarily mean that the server failed. / I would use an idempotency key to prevent duplicate bookings.
4. Guided speaking: The server may have . If the client , it may create . I would .
5. Free speaking: trả lời 30–45 giây không nhìn; ghi âm. Sau đó đọc mẫu 1 lần rồi nói lại.
6. Mẫu tham khảo (mở sau khi tự nói):

1. Transfer (câu mới): What changes if the booking service calls an external room provider? Trả lời dựa trên giới hạn của local transaction, không lặp lại nguyên văn mẫu.

KIẾN THỨC GỐC V3.2 + SPEAKING LABS TÍCH HỢP

Tài liệu gốc V3.2 được giữ nguyên bên dưới (ngoại trừ tiêu đề chính được hiển thị như một tiêu đề nội dung). Mỗi mô-đun có SPEAKING LAB V5.2 sát phần lý thuyết; 04, 08A và 08B có thêm MICRO SPEAK sau từng tiểu mục. Mọi đáp án Q&A và mẫu trả lời dài V4 được đặt ngay tại chủ đề, dưới mục có thể mở sau khi tự nói.

JAVA BACKEND + FDE — INTERVIEW FOUNDATION V3.2

Phiên bản mở rộng V3.2, 17/10/2026 (kế thừa V3.1). Dành cho Intern/Fresher/Junior đang đồng thời ứng tuyển Java Backend và Forward Deployed Engineer (thiên về Software Engineering). Giải thích bằng tiếng Việt, giữ câu hỏi phỏng vấn bằng tiếng Anh. Không phải đề chính thức hoặc cam kết vượt phỏng vấn.

Điểm mới từ V3.1 lên V3.2: thêm 08A Java Core/OOP, 08B Spring Boot/JPA và LAB 08C Java–SQL–English theo PRETEST → WATCH → COMPLETE → DO → EXPLAIN; giữ nguyên các mô-đun CS, LLD, FDE và mock cũ.

Điểm mới so với V3: học thành bài nhỏ hơn; ví dụ mẫu → bài điền khuyết → bài biến thể chưa thấy → câu hỏi follow-up; luyện nghe–nói có quy trình; bài đọc/sửa Java/JSON lạ; FDE case đổi yêu cầu; bài mock suy luận khó hơn; có dấu mốc để biết có nên chuyển bài.

START HERE — Mục tiêu và thứ tự học

Bạn không bắt đầu từ số 0 về lập trình: Java Core, Spring Boot, OOP, SQL, DSA Easy đã quen. Nhưng bạn đang học từ cơ bản về design/decomposition và tiếng Anh kỹ thuật chưa thành phản xạ. Vì vậy:

• Không đọc 100% từ trên xuống như tiểu thuyết. Hoàn thành các bài thực hành bắt buộc trước; CS chỉ mở khi bài tập hoặc bài tự kiểm tra cho thấy bạn đang thiếu.
• Không học thuộc câu trả lời dài. Trả lời ý bằng tiếng Việt được trước, sau đó rút còn 3–5 câu tiếng Anh đơn giản.
• Không xem lời giải trước khi thử. Mỗi ví dụ có 4 nấc: WATCH (xem), COMPLETE (điền), DO (tự làm), EXPLAIN (nói).
• Không yêu cầu đúng hệt đáp án mẫu. Với system design/FDE có nhiều phương án đúng nếu phù hợp giả định, business rules, kiểm chứng và trade-off.

Bản đồ nội dung — đi theo đường học, không theo số môn CS

Nếu chỉ còn 2–3 ngày: - JD Java Backend: ưu tiên 02 → 08A (DO/MOCK) → 08B (DO/MOCK) → 04 → V-Market P0 → LAB 08C → LAB D → HARD MOCK. Chỉ mở lại WATCH ở câu sai. - JD FDE: dùng tuyến gốc 02 → LAB A → 03 → 07 → 09 → 10 → LAB C → 11 → LAB D → HARD MOCK; bổ sung 08A/08B theo JD. - DSA coding: file này không thay luyện Medium thực tế; ôn có chọn lọc ngoài file, nhất là trước online assessment.

Lối học ưu tiên cho Java Backend 0–1 năm [V3.2]

Bạn đã biết Java/SQL/Spring ở mức cơ bản nhưng đang yếu technical English, CS/LLD và project. Không cần đọc mọi mô-đun cùng độ sâu:

1. Mỗi ngày 15–25 phút: Mô-đun 02 + 11/LAB D luyện nghe và trả lời câu kỹ thuật mới bằng tiếng Anh.
2. Kiến thức nghề P0: Mô-đun 08A → 08B → LAB 08C, trước đó xem lại Mô-đun 04 nếu thiếu SQL/transaction. Học WATCH nếu chưa hiểu; nếu làm DO tốt thì nhảy MOCK.
3. Một project sâu: V-Market Deep Dive theo one flow → why → failure → test; đọc source thật, bổ sung kinh nghiệm internship đã triển khai. V-Core/V-Pulse chỉ đào sâu theo JD.
4. CS/LLD ứng dụng: LAB A → Mô-đun 03 → 07 → 09; Mô-đun 05–06 và 08.2/08.3 chỉ đào sâu nếu test cho thấy thiếu.
5. FDE là nhánh riêng: Mô-đun 10 + LAB C khi ứng tuyển FDE/AI-first; không ép người chỉ phỏng vấn Java học hết nhánh này trước.
6. DSA Medium có chọn lọc bên ngoài file: duy trì 20–30 phút theo pattern, rồi tập trung bộ bài phù hợp nếu đã có lịch OA; không dựa vào “học tủ chính xác đề”.

Thứ tự luyện trong một buổi: tự thử câu chưa từng xem → nếu bí thì đọc ví dụ → tự code/giải bài biến thể → nói tiếng Anh 30–60 giây → ghi lỗi. Đạt checkpoint thì chuyển, không đọc lại để đủ trang.

Cách học một bài: 35–45 phút, không quá tải

1. PRETEST (3 phút): che đáp án, thử hai câu đơn giản. Nếu làm được, đọc nhanh ví dụ và chuyển bài thử.
2. WATCH (8 phút): đọc một lời giải từng bước; sau mỗi bước giải thích "vì sao" bằng tiếng Việt.
3. COMPLETE (8 phút): bài tương tự nhưng thiếu một số bước; mở gợi ý một nếu bí sau 2–3 phút.
4. DO (12 phút): đề biến thể hoặc cold question; không dùng AI/đáp án.
5. EXPLAIN (5 phút): nói tiếng Anh câu trả lời 30–60 giây, ghi âm nếu có thể; đánh giá đúng ý → cấu trúc → dễ hiểu trước khi sửa ngữ pháp.
6. ERROR LOG (2 phút): sai vì term / concept / reasoning / implementation / English / nerves? Chỉ ôn đúng loại lỗi.

Mức qua bài (tiêu chuẩn tự học, không phải chuẩn công ty): - Recognize: giải thích được nghĩa thuật ngữ khi gặp. - Explain: không nhìn tài liệu, nói được nguyên lý và ví dụ. - Apply: xử lý một đề đã đổi yêu cầu, vẫn giữ được business invariant. - Interview: nêu assumptions, reasoning, trade-off, tests; nói bằng tiếng Anh dễ hiểu.

Với CS rộng chỉ cần Explain; với LLD, decomposition và technical English phải cố đạt Apply/Interview.

Retrieval + spaced practice (ôn mà không đọc lại cả file)

Các mốc trên là lịch thực dụng. Nguyên tắc hỗ trợ bởi nghiên cứu về worked examples, retrieval practice, distributed practice; xem mục Tài liệu tham khảo cuối file.

Bài chẩn đoán 8 phút — làm trước khi đọc

Không cần ghi đáp án hoàn hảo. Viết ngắn và đánh dấu chỗ bí:

1. A user clicks Book twice and receives a timeout. Did the server necessarily fail? Tại sao?
2. Design an API to borrow one library copy. Bạn cần hỏi lại điều gì trước?
3. Explain one difference between an entity and a service.
4. An operator says imports sometimes create duplicated products. Bạn cần hỏi gì trước khi đề xuất sửa?
5. Walk me through a request from browser to database. Nói trong 30 giây.
6. Nhìn câu Java count++; chạy từ hai threads: có thể sai ở đâu?

Định hướng: bí (2)/(3) → LAB A; bí (1)/(6) → transaction/OS modules; bí (4) → FDE decomposition; hiểu mà không nói được (5) → English modules. Đây là bài phân loại lỗ hổng, không phải bài thi chấm điểm.

CHẶNG I — CƠ BẢN VỀ REQUIREMENTS VÀ TIẾNG ANH

MÔ-ĐUN 01 [CORE] — “Thiết kế hệ thống” thực ra là làm gì?

01.1. Bắt đầu bằng một câu chuyện không có thuật ngữ

Một khách gọi khách sạn: “Tôi muốn đặt phòng ngày 20–22/10”. Nhân viên sẽ:

1. Hỏi ngày, số khách, loại phòng.
2. Kiểm tra phòng có còn trống trong toàn bộ khoảng ngày không.
3. Cho khách biết giá và điều kiện.
4. Ghi nhận booking.
5. Xác nhận hoặc chuyển nhân viên duyệt.

Chuyển sang hệ thống phần mềm:

Người dùng (UI)
   ↓ HTTP request
Backend API (Controller)
   ↓
Business logic (Service): kiểm tra dữ liệu, ngày, giá, quyền, trạng thái
   ↓
Database / external room provider
   ↓
Service quyết định kết quả
   ↓
HTTP response → UI

Bạn đã biết Spring Boot nên nhiều khối này không mới. Phần mới là học trả lời năm câu:

1. WHAT: Chức năng cần làm gì? (functional requirement)
2. WHO/WHEN: Ai dùng và khi nào được làm? (actor / business rules)
3. HOW: Dữ liệu và API đi qua những đâu? (components / data flow)
4. WHAT IF: Nếu dữ liệu sai, hai người thao tác cùng lúc, service bên ngoài chết thì sao? (failure cases)
5. WHY: Vì sao chọn cách A thay vì B? (trade-off)

Phân biệt từ đầu: LLD quan tâm chi tiết entities/classes/methods/APIs; basic system design quan tâm components, data flow, storage và những thuộc tính như reliability; problem decomposition bắt đầu sớm hơn: khách hàng chưa biết rõ cần xây cái gì.

01.2. Từ yêu cầu đến mô tả rõ ràng

Yêu cầu mơ hồ: “Xây chức năng booking”.

Làm rõ thành: - Actor: Customer, Staff. - Input: arrival date, departure date, room type, guest count. - Rules: departure > arrival; không chấp nhận hết phòng; booking cần duyệt nếu quy trình yêu cầu. - Output: booking ID + trạng thái hoặc lý do từ chối. - Error: room unavailable, malformed dates, downstream timeout.

Worked example — trả lời tiếng Anh chỉ 3 câu:

First, I would clarify who uses the feature and what the booking rules are. Then I would define the main entities and APIs. Finally, I would consider invalid requests, concurrent bookings, and how we verify the result.

Tự kiểm tra (che phần trên): Nếu khách hỏi “cho phép huỷ phòng”, bạn nêu được 2 câu làm rõ + 2 business rules không?

🎙️ SPEAKING LAB V5.2 — 01. Requirements, rules và request flow

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: Functional requirement; business rule; component/data flow; failure case; trade-off.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Hoàn thành ít nhất một bài COMPLETE/DO ở phía trên (hoặc giải thích một ví dụ mới). Nếu chưa giải thích được cơ chế bằng tiếng Việt, quay lại bài kỹ thuật trước khi bắt đầu nói.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. First, I would clarify the booking requirements.
2. Then I would define the data flow and possible failure cases.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

A booking feature needs . The service checks . If , the API should .

4. FREE SPEAK — định nghĩa / cơ chế (không nhìn script)

Chọn 3–5 câu/lượt trong 4 câu sau. Đáp án được thu gọn dưới từng câu; chỉ mở sau khi đã nói.

Q001 · MECHANISM / WHY · BASE V4

TTS 001 · Q: What is the difference between a requirement and a business rule?

Q002 · MECHANISM / WHY · BASE V4

TTS 003 · Q: Walk me through a simple booking request.

Q003 · FOUNDATION · ADD V5

TTS 005 · Q: What is a functional requirement?

Q004 · FOUNDATION · ADD V5

TTS 007 · Q: What is a business invariant?

5. UNEXPECTED FOLLOW-UP — thay giả định và suy luận

Chọn ít nhất một câu dưới đây, tự trả lời trước; sau đó yêu cầu người luyện thay một điều kiện mới.

Q005 · SCENARIO / FOLLOW-UP · BASE V4

TTS 009 · Q: Why would you ask about staff approval before writing code?

Q006 · SCENARIO / FOLLOW-UP · BASE V4

TTS 011 · Q: What changes if customers can cancel a booking?

Q007 · SCENARIO / FOLLOW-UP · BASE V4

TTS 013 · Q: What would you test before releasing the feature?

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: 30–40 giây; L2: 60 giây, nêu requirement → rule → flow → failure.
• Điều kiện qua bài: Không lẫn business rule với API endpoint; nêu được 1 actor, 1 invariant, 1 failure và 1 cách test.
• Điểm dễ nói sai / hiểu sai: Nói “use Spring Boot” không trả lời được requirement; luôn bắt đầu với nhu cầu và quy tắc.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

MÔ-ĐUN 02 [CORE] — Đọc, nghe và trả lời câu hỏi kỹ thuật bằng tiếng Anh (từ cơ bản)

Tại sao học trước? Không hiểu interviewer hỏi gì thì biết kiến thức vẫn trả lời sai. Nhưng không cần học cả giáo trình ngữ pháp: học theo những cấu trúc xuất hiện trong phỏng vấn.

02.1. “Giải mã” câu hỏi theo cấu trúc

02.2. 12 từ “đổi nghĩa câu hỏi” phải nhận ra ngay

Ví dụ: “Which action is LEAST likely to prevent duplicate bookings?” → chọn hành động ít có tác dụng nhất, không phải hiệu quả nhất.

02.3. Bốn khung trả lời thay cho học thuộc từng câu

Khung A — định nghĩa: X is ... → It is used for ... → Example ...

A database transaction groups multiple operations into one logical unit. It helps preserve consistency when something fails. For example, booking creation and inventory updates may need to succeed or fail together.

Khung B — giải thích cơ chế: Input → Step 1 → Step 2 → Result → Failure

When a request reaches the controller, we validate the input, call the service, access the database, and return a response. If validation fails, we return a client error.

Khung C — giải thích quyết định: Goal → Choice → Because → Trade-off

For an early MVP, I would choose a modular monolith because it's simpler to build and deploy. The trade-off is that independent scaling and deployment are more limited than with separate services.

Khung D — gặp bài chưa rõ: Clarify → Assume → Propose → Verify

Could I clarify whether reservations need staff approval? If approval is required, I would introduce a pending state and a staff approval API. We can verify this with acceptance tests.

02.4. Các câu cứu nguy khi nghe chưa hiểu

• Could you repeat the last part, please? — Nhắc lại phần cuối.
• Could you rephrase the question? — Diễn đạt lại câu hỏi.
• Do you mean X or Y? — Xác nhận hiểu đúng.
• May I take a moment to think? — Xin vài giây suy nghĩ.
• I haven't implemented that myself. My current understanding is ... — Thành thật về phạm vi kinh nghiệm.
• Let me correct my previous answer. — Sửa câu trả lời.

Không nên: trả lời thật dài để che việc chưa hiểu, hoặc nhận đã dùng công nghệ mà mình chưa dùng.

02.5. Luyện nghe không cần có partner

1. Chép 6 câu trong §1.1 vào ứng dụng đọc văn bản tiếng Anh (text-to-speech) hoặc nhờ người khác đọc; ẩn bản chữ.
2. Nghe 1 lần, nói lại bằng tiếng Việt interviewer muốn dạng câu trả lời nào.
3. Nghe lần 2 và trả lời bằng 2–4 câu tiếng Anh.
4. Ghi lỗi vào ba nhóm: (a) không nghe rõ từ; (b) nghe rõ nhưng không hiểu thuật ngữ; (c) hiểu nhưng không nói ra được.

Bài tập tăng dần: - Dễ: What is an index? - Vừa: Why would an index improve some queries but slow down writes? - Khó: A query is slow even though the indexed column appears in WHERE. What would you check first?

Checkpoint Mô-đun 02: Tự nghe và phân loại đúng ≥ 8/10 câu dạng trên; tự trả lời 3 câu không đọc script. Nếu chưa làm được, lặp Mô-đun 02 trước khi đi tiếp.

🎙️ SPEAKING LAB V5.2 — 02. Nghe và phân loại câu hỏi phỏng vấn

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: What / How / Why / Difference / What if / Verify / MOST / LEAST / EXCEPT / only if.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Hoàn thành ít nhất một bài COMPLETE/DO ở phía trên (hoặc giải thích một ví dụ mới). Nếu chưa giải thích được cơ chế bằng tiếng Việt, quay lại bài kỹ thuật trước khi bắt đầu nói.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. Could you rephrase the last part of the question?
2. The main trade-off is better read performance but more write overhead.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

You are asking about . My short answer is . For example, ___.

4. FREE SPEAK — định nghĩa / cơ chế (không nhìn script)

Chọn 3–5 câu/lượt trong 4 câu sau. Đáp án được thu gọn dưới từng câu; chỉ mở sau khi đã nói.

Q008 · MECHANISM / WHY · BASE V4

TTS 015 · Q: What kind of answer does “How does an index work?” require?

Q009 · MECHANISM / WHY · BASE V4

TTS 017 · Q: Which action is LEAST likely to prevent duplicate bookings? Explain what LEAST changes.

Q010 · MECHANISM / WHY · BASE V4

TTS 019 · Q: Could you compare a requirement and an assumption?

Q011 · FOUNDATION · ADD V5

TTS 021 · Q: What does the word EXCEPT mean in a multiple-choice question?

5. UNEXPECTED FOLLOW-UP — thay giả định và suy luận

Chọn ít nhất một câu dưới đây, tự trả lời trước; sau đó yêu cầu người luyện thay một điều kiện mới.

Q012 · SCENARIO / FOLLOW-UP · BASE V4

TTS 023 · Q: What would you say if you did not hear a technical term?

Q013 · SCENARIO / FOLLOW-UP · BASE V4

TTS 025 · Q: How would you clarify a question about a “best” solution with missing constraints?

Q014 · SCENARIO / FOLLOW-UP · ADD V5

TTS 027 · Q: What would you say if you did not know the answer to a technical question?

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L0: nghe và phân loại 8/10 prompts; L1: trả lời 2–4 câu; L2: hỏi lại tự nhiên.
• Điều kiện qua bài: Chỉ ra đúng nghĩa các từ phủ định/so sánh; hỏi lại khi thiếu dữ kiện thay vì đoán.
• Điểm dễ nói sai / hiểu sai: Đừng thấy BEST/MOST/NOT/EXCEPT rồi chọn theo phản xạ; tóm tắt lại yêu cầu đề trước.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

CHẶNG II — TẬP THIẾT KẾ TỪ NHỎ ĐẾN TỔNG THỂ

LAB A [CORE] — Cầu nối cho người mới: từ một câu nói thành Entities → Rules → APIs

Vì sao làm lab này trước LLD đầy đủ? Khi mới học design, entity, business rule, state và API dễ bị trộn lẫn. Ta chia nhỏ, tập từng việc rồi mới ghép.

A0. Từ điển cực ngắn

Bẫy: Không phải mọi danh từ đều phải thành table hoặc class. BookingStatus có thể là enum, Price có thể là value object; chia thế nào phụ thuộc domain.

A1. WATCH — một yêu cầu cực nhỏ

A user can create a personal note and archive it later.

Bước 1 — actor/use cases: User; Create note, Archive note.

Bước 2 — entity: Note(id, ownerId, content, status, createdAt).

Bước 3 — rules: content không để trống; chỉ owner được archive; archived note không được archive lần hai theo chính sách đã chốt.

Bước 4 — states: ACTIVE → ARCHIVED.

Bước 5 — API: POST /notes nhận {content} → 201 + note; POST /notes/{id}/archive → 200/204, 403 nếu thiếu quyền, 404 nếu không tồn tại. Quyết định trả 409/204 khi đã archived phải thống nhất với contract.

Bước 6 — classes: NoteController xử lý HTTP; NoteService kiểm owner và trạng thái; NoteRepository đọc/ghi DB.

Bước 7 — tests: tạo note rỗng → 400; người B archive note A → 403; archive thành công → DB status ARCHIVED.

English, ba câu đủ dùng: The main entity is Note. The service validates ownership and status changes. I would test invalid content and unauthorized archiving.

A2. COMPLETE — điền những ô còn thiếu (5 phút)

A student can enroll in a course. A course has a maximum capacity.

1. Actor: __________.
2. Use case: __________.
3. Entities: Student, Course, __________.
4. Invariant: total active enrollments for a course must not exceed __________.
5. Proposed API: POST /courses/{id}/__________.
6. Concurrent case: Two students enroll for the last seat. How would you protect the rule? __________.

A3. DO — case lạ không có khung điền (8 phút)

A team lead can approve an employee's leave request. An employee cannot approve their own request.

Trước khi xem đáp án, tự viết: 2 actors, tối đa 3 entities, states, 2 endpoints, 3 rules, 2 tests, một câu tiếng Anh giải thích vì sao cần role check.

Qua LAB A nếu: Bạn tự chỉ được actor/entity/state/rule/API cho một yêu cầu hoàn toàn mới trong 6–8 phút. Nếu chưa, làm lại A2/A3 trước khi vào Registration.

🎙️ SPEAKING LAB V5.2 — A. Entities → Rules → APIs

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: Actor; entity; state; invariant; endpoint; authorization; concurrency test.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Hoàn thành ít nhất một bài COMPLETE/DO ở phía trên (hoặc giải thích một ví dụ mới). Nếu chưa giải thích được cơ chế bằng tiếng Việt, quay lại bài kỹ thuật trước khi bắt đầu nói.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. The main entity is an enrollment with a student, a course, and a status.
2. I would protect the last available seat with database concurrency control.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

The actor is . The main entities are . A key invariant is ___.

4. FREE SPEAK — định nghĩa / cơ chế (không nhìn script)

Chọn 3–5 câu/lượt trong 3 câu sau. Đáp án được thu gọn dưới từng câu; chỉ mở sau khi đã nói.

Q015 · FOUNDATION · BASE V4

TTS 029 · Q: Design a small course enrollment feature. What are the entities?

Q016 · FOUNDATION · BASE V4

TTS 031 · Q: Should the same student be allowed to enroll twice?

Q017 · MECHANISM / WHY · ADD V5

TTS 033 · Q: What is the difference between an entity and a service?

5. UNEXPECTED FOLLOW-UP — thay giả định và suy luận

Chọn ít nhất một câu dưới đây, tự trả lời trước; sau đó yêu cầu người luyện thay một điều kiện mới.

Q018 · SCENARIO / FOLLOW-UP · BASE V4

TTS 035 · Q: Two students take the last seat. How do you keep the capacity rule?

Q019 · SCENARIO / FOLLOW-UP · BASE V4

TTS 037 · Q: How would you test unauthorized approval of a leave request?

Q020 · SCENARIO / FOLLOW-UP · BASE V4

TTS 039 · Q: What if a student drops a course?

Q021 · SCENARIO / FOLLOW-UP · ADD V5

TTS 041 · Q: How would you represent the lifecycle of a leave request?

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: tên entities/rules bằng 3 câu; L2: 60 giây actor → entities → rule → endpoint → test.
• Điều kiện qua bài: Tách được entity, enum/state và service, đưa ra giải pháp bảo vệ invariant ở DB.
• Điểm dễ nói sai / hiểu sai: Chỉ kiểm tra count rồi insert không đảm bảo giới hạn khi request concurrent.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

MÔ-ĐUN 03 [CORE] — LLD bước 1: yêu cầu → entities, classes, API

Mục tiêu: sau bài này, được giao “thiết kế đăng ký tài khoản”, bạn không còn đứng hình vì không biết bắt đầu từ đâu.

03.1. LLD khác code Spring sẵn có ở đâu?

Bạn đã biết Controller → Service → Repository. LLD yêu cầu bạn quyết định vì sao có những lớp đó, mỗi lớp chịu trách nhiệm gì, cấu trúc dữ liệu ra sao, rồi giải thích được khi thay đổi yêu cầu.

Quy tắc bắt đầu đơn giản — không phải phép màu: 1. Tìm danh từ trong yêu cầu → ứng viên entity/object (User, Booking, Room). 2. Tìm động từ → hành vi (register, approve, cancel). 3. Tìm business rules → invariants (email unique, room not overbooked). 4. Tìm vai trò → permissions. 5. Tìm sự kiện thay đổi trạng thái → lifecycle / state transitions.

03.2. Worked example đầy đủ: User Registration

Đề: Users can register with email and password. The email must be unique. After registration, a verification email is sent.

Bước 1 — hỏi trước khi design: - Email verification là bắt buộc trước khi login? - Chính sách mật khẩu thế nào? - Trùng email trả lỗi gì, có cần tránh user enumeration? - Gửi email thất bại có hủy việc đăng ký không?

Giả định cho MVP: tài khoản ở PENDING_VERIFICATION đến khi verify; email unique case-insensitive theo quy tắc đã thống nhất; việc gửi email có thể bất đồng bộ và retry được.

Bước 2 — data model:

User
- id: UUID                 PK
- email: String            UNIQUE theo normalized_email / quy tắc DB
- passwordHash: String
- status: UserStatus       PENDING_VERIFICATION / ACTIVE
- createdAt: Instant

VerificationToken
- id: UUID
- userId: UUID             FK → User.id
- tokenHash: String
- expiresAt: Instant
- consumedAt: Instant?

Bước 3 — chia responsibilities:

RegistrationController : HTTP request + validation boundary + response
RegistrationService    : use case register user, phối hợp các thành phần
UserRepository         : lưu/truy xuất User, kiểm tra uniqueness qua DB constraint
PasswordHasher         : tạo password hash
VerificationService    : quản lý token và verification policy
EmailSender            : gửi email qua abstraction

Đừng đặt mọi logic vào Controller; cũng đừng tạo 20 interfaces cho một MVP nhỏ. High cohesion / low coupling: một module có trách nhiệm liên quan, phụ thuộc ngoài càng ít càng tốt.

Bước 4 — API:

POST /api/users/register
Content-Type: application/json

{"email":"an@example.com","password":"..."}

HTTP/1.1 201 Created
{"userId":"...","status":"PENDING_VERIFICATION"}

Status code và response cụ thể do API contract lựa chọn, không có một đáp án tuyệt đối. Với hệ thống public, cân nhắc thông báo chung để hạn chế tiết lộ email nào đã đăng ký.

Bước 5 — sequence diagram dạng text:

Client          Controller       RegistrationService       Database       Email
  | POST register   |                    |                    |             |
  |---------------->| validate           |                    |             |
  |                 |------------------->| normalize/hash     |             |
  |                 |                    | INSERT User+token  |             |
  |                 |                    |------------------->|             |
  |                 |                    | <--- commit result |             |
  |                 |                    | request delivery ----------------->|
  |                 |<-------------------| result             |             |
  |<-- 201 + status |                    |                    |             |

Production nuance: gọi email trực tiếp sau DB commit có thể bị mất nếu process crash giữa commit và gửi. Một cách xử lý đáng học ở bước sau là outbox pattern; không bắt buộc thiết kế ngay trong bài LLD đầu tiên.

Bước 6 — edge cases / tests: invalid email; weak password; duplicate registration; email provider timeout; expired token; reused token; two concurrent registrations of same email (DB unique constraint là điểm bảo vệ cuối cùng).

03.3. UML căn bản — nhớ ý, đừng học quá nhiều ký hiệu

• ERD mô tả bảng và cardinality.
• Class diagram mô tả classes, fields, methods, relationships.
• Sequence diagram mô tả thứ tự message giữa components.
• State diagram mô tả trạng thái/chuyển trạng thái.
• Use-case diagram mô tả actors và chức năng từ góc người dùng.

03.4. SOLID từ ứng dụng chứ không phải 5 định nghĩa trừu tượng

Không lạm dụng: nguyên lý là hướng dẫn thiết kế, không phải yêu cầu tạo interface cho mọi class.

03.5. Design patterns chỉ cần biết tình huống

• Strategy: nhiều cách tính giá/discount thay đổi được.
• Factory: chọn cách tạo một object phức tạp, che chi tiết khởi tạo.
• Observer / pub-sub: sự kiện booking confirmed → nhiều subscribers xử lý.
• Adapter: biến API của vendor A thành interface thống nhất bên trong hệ thống.
• Singleton: quản lý một instance theo scope xác định; không mặc định thread-safe.
• Decorator [PLUS]: bọc thêm behavior mà không sửa object gốc.

Tự làm — bản có gợi ý: Thiết kế PasswordReset.

• Gợi ý 1: tìm entities User, PasswordResetToken.
• Gợi ý 2: states / expiration / one-time use.
• Gợi ý 3: API request-reset và confirm-reset.

Câu tiếng Anh: I would separate HTTP handling from business logic and data access. The registration service coordinates validation, persistence, and verification. A database uniqueness constraint protects against concurrent duplicate registrations.

🎙️ SPEAKING LAB V5.2 — 03. Registration LLD

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: Unique normalized email; hashed password; verification token; responsibilities; email failure.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Hoàn thành ít nhất một bài COMPLETE/DO ở phía trên (hoặc giải thích một ví dụ mới). Nếu chưa giải thích được cơ chế bằng tiếng Việt, quay lại bài kỹ thuật trước khi bắt đầu nói.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. The registration service coordinates validation and persistence.
2. A database uniqueness constraint helps prevent duplicate registrations.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

I would model ___ and ___. The ___ handles HTTP, while the ___ handles business logic.

4. FREE SPEAK — định nghĩa / cơ chế (không nhìn script)

Chọn 3–5 câu/lượt trong 4 câu sau. Đáp án được thu gọn dưới từng câu; chỉ mở sau khi đã nói.

Q022 · MECHANISM / WHY · BASE V4

TTS 043 · Q: Explain the responsibilities of a registration controller and service.

Q023 · MECHANISM / WHY · BASE V4

TTS 045 · Q: Why should the email comparison policy be defined explicitly?

Q024 · MECHANISM / WHY · ADD V5

TTS 047 · Q: Why should passwords be hashed instead of encrypted for storage?

Q025 · MECHANISM / WHY · ADD V5

TTS 049 · Q: What is the difference between validation and authorization in registration?

5. UNEXPECTED FOLLOW-UP — thay giả định và suy luận

Chọn ít nhất một câu dưới đây, tự trả lời trước; sau đó yêu cầu người luyện thay một điều kiện mới.

Q026 · SCENARIO / FOLLOW-UP · BASE V4

TTS 051 · Q: How do you prevent two concurrent registrations with the same email?

Q027 · SCENARIO / FOLLOW-UP · BASE V4

TTS 053 · Q: What happens if the email provider fails after the user is saved?

Q028 · SCENARIO / FOLLOW-UP · BASE V4

TTS 055 · Q: How would you protect password-reset tokens?

Q029 · SCENARIO / FOLLOW-UP · ADD V5

TTS 057 · Q: How would you handle verification-email delivery reliably?

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: explain Controller/Service/Repository; L2: 60–90 giây kèm race và email failure.
• Điều kiện qua bài: Tách HTTP, domain, persistence và external side effect; không coi “check tồn tại trước insert” là bảo vệ duy nhất.
• Điểm dễ nói sai / hiểu sai: Email failure không nên được giải thích như được DB transaction bảo đảm rollback tự động.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

CHẶNG III — CS CẦN ĐÚNG LÚC (KHÔNG NHỒI TOÀN BỘ)

MÔ-ĐUN 04 [CORE] — Database / SQL: từ bảng dữ liệu đến transaction và index

04.1. Khởi đầu thật đơn giản: entity → table

Giả sử có:

Customer(customer_id, email)
Room(room_id, room_type)
Booking(booking_id, customer_id, room_id, check_in, check_out, status)

• Primary key (PK): phân biệt duy nhất từng dòng.
• Foreign key (FK): tham chiếu đến một dòng ở bảng khác.
• 1:N: một Customer có nhiều Booking; mỗi Booking thuộc một Customer.
• N:M: cần bảng liên kết (ví dụ student_course) nếu nhiều student học nhiều course.
• Constraint: dữ liệu phải thoả rule ở tầng DB khi rule có thể biểu diễn tại đó.

MICRO SPEAK V5.2 — sau mục 04.1 · 2 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: A primary key uniquely identifies each row in a table. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (2 câu)

Q030 · FOUNDATION · ADD V5

TTS 059 · Q: What is a primary key?

Q031 · FOUNDATION · ADD V5

TTS 061 · Q: What is a foreign key?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

04.2. SQL từ dễ đến vừa

Dữ liệu ví dụ:

Customers
id | name
1  | An
2  | Binh
3  | Chi

Bookings
id  | customer_id | amount | status
10  | 1           | 500    | CONFIRMED
11  | 1           | 700    | CANCELLED
12  | 2           | 400    | CONFIRMED

Bước 1 — lọc: SELECT * FROM bookings WHERE status = 'CONFIRMED';

Bước 2 — JOIN:

SELECT c.name, b.id, b.amount
FROM customers c
JOIN bookings b ON b.customer_id = c.id
WHERE b.status = 'CONFIRMED';

Bước 3 — GROUP BY/HAVING:

SELECT c.id, c.name, SUM(b.amount) AS total_confirmed
FROM customers c
JOIN bookings b ON b.customer_id = c.id
WHERE b.status = 'CONFIRMED'
GROUP BY c.id, c.name
HAVING SUM(b.amount) >= 400;

Thấy gì? WHERE lọc rows trước grouping; HAVING lọc nhóm sau aggregate. LEFT JOIN giữ cả customer không booking; cần hiểu vì sao filter ở WHERE có thể vô tình làm mất những rows NULL phía phải.

5 điều SQL dễ nhầm: - COUNT(*) đếm rows; COUNT(column) bỏ NULL trong column đó. - IS NULL thay vì = NULL (SQL three-valued logic). - UNION loại duplicate; UNION ALL giữ lại. - INNER JOIN chỉ match; LEFT JOIN giữ tất cả phía trái. - LIMIT / OFFSET thường đi sau ORDER BY; muốn kết quả ổn định cần sort key xác định.

MICRO SPEAK V5.2 — sau mục 04.2 · 4 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: An INNER JOIN returns only customers with matching bookings. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (4 câu)

Q032 · MECHANISM / WHY · BASE V4

TTS 063 · Q: Explain INNER JOIN versus LEFT JOIN with customer bookings.

Q033 · MECHANISM / WHY · ADD V5

TTS 065 · Q: What is the difference between WHERE and HAVING?

Q034 · MECHANISM / WHY · ADD V5

TTS 067 · Q: What is the difference between COUNT(*) and COUNT(column)?

Q035 · MECHANISM / WHY · ADD V5

TTS 069 · Q: What is the difference between UNION and UNION ALL?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

04.3. Index — vì sao giúp đọc nhưng có thể làm ghi chậm?

Tưởng tượng một cuốn từ điển: index giúp nhảy gần vị trí cần tìm thay vì đọc tuần tự. Nhưng mỗi lần thêm/sửa dữ liệu, cấu trúc index có thể phải cập nhật theo.

Ví dụ truy vấn:

SELECT * FROM bookings WHERE customer_id = 7 ORDER BY created_at DESC;

Có thể xem xét index (customer_id, created_at DESC) tùy workload, query plan và DBMS. Không phải cứ có index là query dùng index. Với bảng nhỏ hoặc filter chọn phần lớn bảng, sequential scan có thể tốt hơn.

Interview answer: An index can speed up eligible reads by reducing unnecessary scanning, but it costs storage and write maintenance. I'd check the query plan and actual workload before adding one.

MICRO SPEAK V5.2 — sau mục 04.3 · 4 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: Not automatically. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (2 câu)

Q036 · FOUNDATION · ADD V5

TTS 071 · Q: What is a database index?

Q037 · MECHANISM / WHY · ADD V5

TTS 073 · Q: Why can an index slow down INSERT and UPDATE operations?

FOLLOW-UP — case / phản biện (2 câu)

Q038 · SCENARIO / FOLLOW-UP · BASE V4

TTS 075 · Q: Would you add an index on a low-selectivity status column?

Q039 · SCENARIO / FOLLOW-UP · ADD V5

TTS 077 · Q: How would you investigate a slow SQL query that already has an index?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

04.4. Transactions / ACID — hình dung trước khi học chữ

Ví dụ chuyển tiền từ tài khoản A sang B: không thể trừ A thành công mà cộng B thất bại rồi dừng mãi. Database transaction giúp quản lý nhiều thao tác thành một đơn vị theo các bảo đảm cụ thể.

• A — Atomicity: all-or-nothing đối với transaction.
• C — Consistency: các ràng buộc/điều kiện đúng được duy trì qua transaction hợp lệ.
• I — Isolation: các transaction concurrent tương tác trong giới hạn isolation level.
• D — Durability: committed data bền theo bảo đảm DB.

Không nhầm: Atomicity không đồng nghĩa Isolation. Transaction không tự bảo vệ mọi business invariant nếu isolation/locking không phù hợp.

04.5. Những bất thường do concurrent transactions

Các isolation levels chuẩn hay gặp: Read Uncommitted → Read Committed → Repeatable Read → Serializable (không coi đây là lời hứa hành vi đồng nhất giữa mọi DBMS; PostgreSQL và MySQL có chi tiết triển khai khác nhau).

Optimistic locking: thường dùng version, cập nhật có điều kiện WHERE id=? AND version=?, phát hiện conflict và xử lý/retry có kiểm soát.
Pessimistic locking: lấy khóa trước khi đọc/sửa critical data, có thể làm tăng contention.

MICRO SPEAK V5.2 — sau mục 04.5 · 4 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: Atomicity means a transaction succeeds or fails as one unit. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (4 câu)

Q040 · MECHANISM / WHY · BASE V4

TTS 079 · Q: What is the difference between atomicity and isolation?

Q041 · FOUNDATION · ADD V5

TTS 081 · Q: What does ACID stand for?

Q042 · MECHANISM / WHY · ADD V5

TTS 083 · Q: What is the difference between a dirty read and a non-repeatable read?

Q043 · FOUNDATION · ADD V5

TTS 085 · Q: What is a phantom read?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

04.6. Worked example — hai người cùng đặt một phòng

1. Rule: chỉ có một booking hiệu lực cho cùng room_id và stay_date.
2. Data model đơn giản: booking_nights(room_id, stay_date, booking_id) và ràng buộc unique (room_id, stay_date) cho các nights đã giữ theo mô hình này; trạng thái hủy/giải phóng phải được thiết kế đồng bộ.
3. Khi tạo booking: xác thực → cố gắng giữ toàn bộ nights trong transaction thích hợp → nếu conflict thì từ chối → commit.
4. Nếu nối với nhà cung cấp phòng bên ngoài: local transaction không bao trùm external API; cần điều chỉnh workflow, reconciliation/idempotency và trạng thái pending theo contract của bên ngoài.
5. Test: hai requests đồng thời cho cùng room/date → không bao giờ có hai booking active hợp lệ cho cùng đêm.

Đây là một mô hình minh họa, không phải mô hình booking duy nhất hay giải pháp sẵn sàng production.

MICRO SPEAK V5.2 — sau mục 04.6 · 3 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: A transaction gives atomic behavior, but two transactions can still pass the same availability check. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (2 câu)

Q044 · MECHANISM / WHY · BASE V4

TTS 087 · Q: Why is a transaction not always enough to prevent overselling?

Q045 · MECHANISM / WHY · ADD V5

TTS 089 · Q: What is the difference between optimistic and pessimistic locking?

FOLLOW-UP — case / phản biện (1 câu)

Q046 · SCENARIO / FOLLOW-UP · BASE V4

TTS 091 · Q: How would you test a lost update with two requests?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

04.7. Tự làm 3 câu SQL ngắn

1. Viết SQL lấy mọi customer, kể cả customer chưa booking, cùng tổng số booking.
2. Viết SQL lấy customer có tổng confirmed amount > 450.
3. Tại sao thêm index lên status (cột chỉ có 2 giá trị) có thể không giúp query nhanh hơn?

-- 1
SELECT c.id, c.name, COUNT(b.id) AS booking_count
FROM customers c
LEFT JOIN bookings b ON b.customer_id = c.id
GROUP BY c.id, c.name;

-- 2
SELECT c.id, c.name, SUM(b.amount) AS total
FROM customers c
JOIN bookings b ON b.customer_id = c.id
WHERE b.status = 'CONFIRMED'
GROUP BY c.id, c.name
HAVING SUM(b.amount) > 450;

Checkpoint Mô-đun 04: Giải thích được JOIN vs LEFT JOIN, WHERE vs HAVING, atomicity vs isolation, why index, và xử lý một lost update.

🎙️ SPEAKING LAB V5.2 — 04. SQL, indexes, ACID và locking

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: JOIN vs LEFT JOIN; WHERE vs HAVING; index trade-offs; atomicity vs isolation; concurrent updates.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Đã được chia nhỏ: 17 cặp Q&A của mô-đun này được đặt sau từng mục lý thuyết ở phía trên (MICRO SPEAK V5.2). Không đọc lại toàn bộ câu hỏi ở đây; chọn 3 câu khó nhất để làm lại không nhìn.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. A left join keeps rows from the left table even when there is no match.
2. An index can improve reads, but it also adds storage and write costs.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

I would use ___ because . The downside is . To verify it, I would ___.

4. FREE SPEAK + FOLLOW-UP — ôn các micro-lab

Lấy ngẫu nhiên 2 câu cơ chế + 1 câu tình huống đã làm trong các MICRO SPEAK phía trên. Không đọc script; câu nào sai phải sửa kèm một ví dụ/code/test.

Mã câu trong mô-đun: Q032, Q044, Q038, Q040, Q046, Q030, Q031, Q033, Q034, Q035, Q036, Q037, Q039, Q041, Q042, Q043, Q045.

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: 3 câu cho JOIN hoặc index; L2: 60–90 giây về một race/lock/test.
• Điều kiện qua bài: Nêu một query/constraint cụ thể, giải thích trade-off và không tuyệt đối hóa index hay isolation.
• Điểm dễ nói sai / hiểu sai: @Transactional hay ACID không tự động biến một logic check-then-act thành an toàn ở mọi isolation level.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

MÔ-ĐUN 05 [CORE] — Network / HTTP: một request chạy từ trình duyệt đến backend thế nào?

05.1. Luồng thực tế

User enters https://example.com
  ↓
DNS lookup (tìm thông tin IP của hostname, có thể qua cache)
  ↓
Connect (thường TCP; HTTP/3 dùng QUIC/UDP)
  ↓
TLS handshake (nếu HTTPS)
  ↓
HTTP request → reverse proxy / backend
  ↓
Application xử lý → DB / external APIs
  ↓
HTTP response → browser render

Mấu chốt: DNS khác HTTP; TCP cung cấp luồng byte có độ tin cậy/thứ tự; TLS bảo vệ kết nối; HTTPS là HTTP qua TLS. HTTP là stateless theo ngữ nghĩa giao thức, nhưng ứng dụng có thể quản lý session/cookies/tokens.

05.2. HTTP methods và response codes

05.3. Timeout và retry: câu hỏi hay gặp

• Connection timeout: không kết nối được trong giới hạn thời gian.
• Read/response timeout: đã kết nối nhưng không nhận được phản hồi kịp lúc.
• Retry: thử lại, không mặc định an toàn cho yêu cầu tạo booking/thanh toán.
• Idempotency key: client dùng cùng key khi retry; server lưu kết quả/operation và ngăn thực thi lặp ngoài ý muốn.
• Exponential backoff: tăng thời gian chờ giữa các lần retry, nên kèm jitter trong hệ phân tán thực tế.

Bẫy quan trọng: khi client timeout, ta không biết chắc server đã hoàn thành thao tác hay chưa. Không được suy luận “timeout ⇒ booking chưa được tạo”.

05.4. Mạng nền tảng — chỉ ghi nhớ vừa đủ

• IP: địa chỉ tầng mạng; MAC: địa chỉ ở link-local network.
• Switch / router: chuyển frame trong LAN / định tuyến giữa các mạng (mô hình đơn giản).
• TCP / UDP: TCP có cơ chế reliable ordered stream; UDP là datagram không tự bảo đảm các tính chất đó.
• OSI 7 tầng: Physical → Data Link → Network → Transport → Session → Presentation → Application.
• NAT: chuyển đổi địa chỉ; CORS là cơ chế trình duyệt điều tiết truy cập cross-origin, không thay cho authorization.
• Serialization / deserialization: chuyển object thành dạng truyền/lưu trữ như JSON và ngược lại.

Tự trả lời: A customer clicks Book. The browser times out. Should we retry automatically?

🎙️ SPEAKING LAB V5.2 — 05. HTTP request, timeout và retry

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: DNS, connection, TLS, request/response; HTTP semantics; timeout uncertainty; idempotency.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Hoàn thành ít nhất một bài COMPLETE/DO ở phía trên (hoặc giải thích một ví dụ mới). Nếu chưa giải thích được cơ chế bằng tiếng Việt, quay lại bài kỹ thuật trước khi bắt đầu nói.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. A response timeout does not prove that the server failed.
2. The client should reuse an idempotency key when retrying the operation.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

First, the browser . Then the backend . If the request times out, ___.

4. FREE SPEAK — định nghĩa / cơ chế (không nhìn script)

Chọn 3–5 câu/lượt trong 9 câu sau. Đáp án được thu gọn dưới từng câu; chỉ mở sau khi đã nói.

Q047 · MECHANISM / WHY · BASE V4

TTS 093 · Q: Walk me through an HTTPS request from browser to backend.

Q048 · MECHANISM / WHY · BASE V4

TTS 095 · Q: What is the difference between HTTP 401 and 403?

Q049 · FOUNDATION · BASE V4

TTS 097 · Q: Should a client automatically retry a booking POST after a timeout?

Q050 · MECHANISM / WHY · ADD V5

TTS 099 · Q: What is the difference between GET and POST?

Q051 · MECHANISM / WHY · ADD V5

TTS 101 · Q: What is the difference between PUT and PATCH?

Q052 · FOUNDATION · ADD V5

TTS 103 · Q: What do HTTP 200, 201, and 204 mean?

Q053 · FOUNDATION · ADD V5

TTS 105 · Q: What do HTTP 400, 404, 409, and 500 mean?

Q054 · MECHANISM / WHY · ADD V5

TTS 107 · Q: What is the difference between a timeout and a connection refusal?

Q055 · MECHANISM / WHY · ADD V5

TTS 109 · Q: Why is an idempotency key useful for a payment or booking API?

5. UNEXPECTED FOLLOW-UP — thay giả định và suy luận

Chọn ít nhất một câu dưới đây, tự trả lời trước; sau đó yêu cầu người luyện thay một điều kiện mới.

Q056 · SCENARIO / FOLLOW-UP · BASE V4

TTS 111 · Q: What if the first response is lost after a successful commit?

Q057 · SCENARIO / FOLLOW-UP · BASE V4

TTS 113 · Q: How would you expose the status of an uncertain operation?

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: 30 giây request flow; L2: 60–90 giây timeout → duplicate risk → mitigation.
• Điều kiện qua bài: Biết phân biệt network timeout với kết quả nghiệp vụ; có phương án idempotency/status lookup.
• Điểm dễ nói sai / hiểu sai: Timeout không suy ra “server failed”; POST không tự động idempotent.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

MÔ-ĐUN 06 [CORE] — OS + JVM + concurrency: vì sao hệ thống có thể sai khi nhiều request cùng đến?

06.1. Process, thread và bộ nhớ — giải thích bằng mô hình

• Process: một chương trình đang chạy, thường có không gian địa chỉ ảo được cách ly với process khác.
• Thread: luồng thực thi bên trong process; các threads cùng process dùng chung nhiều vùng dữ liệu, nhưng mỗi thread có call stack riêng.
• Concurrency: nhiều công việc tiến triển chồng lấn về thời gian.
• Parallelism: các công việc thực sự chạy đồng thời trên nhiều đơn vị xử lý.

Java process / JVM
 ├─ Heap: objects được các threads cùng truy cập
 ├─ Thread A → call stack A
 └─ Thread B → call stack B

Ví dụ: hai HTTP requests cùng gọi reserveLastRoom(). Nếu logic chỉ “đọc số phòng = 1 → cả hai cùng ghi lại = 0”, có thể xác nhận hai booking khi chỉ còn một phòng. Đây là vấn đề read–modify–write / race condition.

06.2. Race condition, atomicity và bảo vệ invariant

Invariant = điều luôn phải đúng, ví dụ: availableRooms >= 0, hoặc “cùng một phòng không được bán hai lần cho cùng một đêm”.

Sai (mô hình giả):

Request A: READ available=1
Request B: READ available=1
Request A: WRITE available=0 → success
Request B: WRITE available=0 → success

Ý tưởng đúng: thao tác dành phòng phải được kiểm soát tại nguồn dữ liệu có thẩm quyền, ví dụ:

UPDATE room_inventory
SET available = available - 1
WHERE room_type_id = :id AND stay_date = :date AND available > 0;

Chỉ coi bước giữ chỗ thành công khi số dòng cập nhật đúng kỳ vọng. Với booking nhiều đêm, phải xử lý tất cả các đêm như một đơn vị giao dịch phù hợp, không chỉ một dòng; kiểm tra điều kiện, transaction, và ranh giới giữa DB nội bộ / hệ thống bên ngoài phải được thiết kế cụ thể. Không khẳng định chỉ một câu SQL là đủ cho mọi booking system.

Phân biệt: Java synchronized bảo vệ truy cập trong một JVM; không đủ nếu chạy nhiều instances hoặc dữ liệu nằm ở external service. Database constraints, transactions/locks hoặc concurrency control phù hợp thường cần thiết.

06.3. Deadlock là gì?

• Race condition: kết quả sai vì thứ tự thực thi không kiểm soát.
• Deadlock: A giữ tài nguyên X chờ Y, B giữ Y chờ X, không bên nào tiến được.
• Starvation: một task liên tục bị trì hoãn do thiếu công bằng.
• Livelock: các task vẫn thay đổi trạng thái nhưng không tiến bộ.

Bốn điều kiện Coffman thường được nhắc trong OS deadlock: mutual exclusion, hold-and-wait, no preemption, circular wait. Không cần học thuật toán Banker nâng cao ở giai đoạn này.

06.4. CPU scheduling: chỉ phần đủ đọc MCQ

06.5. Java Memory / GC ở mức entry-level

• JDK: bộ công cụ phát triển Java; JVM: môi trường thực thi bytecode; JRE: runtime terminology (trong hệ Java hiện đại không nhất thiết được phân phối riêng).
• Stack theo lời gọi method; heap chứa objects (mô hình JVM điển hình); local variable có thể chứa reference dẫn tới object trên heap.
• GC dọn objects không còn reachable, không có nghĩa Java không thể memory leak.
• OutOfMemoryError khác StackOverflowError: không đủ bộ nhớ cho yêu cầu cấp phát vs stack của luồng bị tràn (ví dụ recursion không dừng).
• volatile chủ yếu liên quan visibility/order, không làm counter++ thành atomic.
• synchronized / locks: điều phối truy cập shared state trong JVM; transaction DB: bảo vệ dữ liệu và rules ở database với phạm vi bảo đảm do DB quyết định.

Câu hỏi phỏng vấn: What is the difference between a process and a thread?

A process has its own virtual address space, while threads within one process share many resources, including heap objects. Each thread has its own execution stack. Shared state requires care because concurrent access can cause race conditions.

Bài biến thể — không xem gợi ý: Hai requests tăng viewCount bằng count = count + 1. Vì sao kết quả đôi khi tăng chỉ 1?

🎙️ SPEAKING LAB V5.2 — 06. Threads, shared state và race conditions

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: Process vs thread; heap/stack; concurrency vs parallelism; race; deadlock; synchronized vs DB.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Hoàn thành ít nhất một bài COMPLETE/DO ở phía trên (hoặc giải thích một ví dụ mới). Nếu chưa giải thích được cơ chế bằng tiếng Việt, quay lại bài kỹ thuật trước khi bắt đầu nói.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. Two threads may read the same counter value before either one writes.
2. A Java lock does not protect shared database state across multiple application instances.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

A race condition can happen when . Both requests . I would protect ___.

4. FREE SPEAK — định nghĩa / cơ chế (không nhìn script)

Chọn 3–5 câu/lượt trong 10 câu sau. Đáp án được thu gọn dưới từng câu; chỉ mở sau khi đã nói.

Q058 · MECHANISM / WHY · BASE V4

TTS 115 · Q: What is the difference between a process and a thread?

Q059 · MECHANISM / WHY · BASE V4

TTS 117 · Q: Why can count++ lose increments under concurrent requests?

Q060 · MECHANISM / WHY · BASE V4

TTS 119 · Q: Why might synchronized be insufficient in a multi-instance backend?

Q061 · FOUNDATION · BASE V4

TTS 121 · Q: Does volatile make count++ atomic?

Q062 · FOUNDATION · ADD V5

TTS 123 · Q: What is a race condition?

Q063 · FOUNDATION · ADD V5

TTS 125 · Q: What is a deadlock?

Q064 · MECHANISM / WHY · ADD V5

TTS 127 · Q: What is the difference between concurrency and parallelism?

Q065 · MECHANISM / WHY · ADD V5

TTS 129 · Q: What is the difference between a thread's stack and the JVM heap?

Q066 · MECHANISM / WHY · ADD V5

TTS 131 · Q: What is the difference between synchronized and ReentrantLock?

Q067 · FOUNDATION · ADD V5

TTS 133 · Q: What can cause memory leaks in a Java application even with garbage collection?

5. UNEXPECTED FOLLOW-UP — thay giả định và suy luận

Chọn ít nhất một câu dưới đây, tự trả lời trước; sau đó yêu cầu người luyện thay một điều kiện mới.

Q068 · SCENARIO / FOLLOW-UP · BASE V4

TTS 135 · Q: When would you choose an atomic SQL update over an in-memory lock?

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: process/thread 30 giây; L2: 60–90 giây diễn giải race từng bước và cách bảo vệ.
• Điều kiện qua bài: Không nhầm visibility với atomicity, và hiểu phạm vi lock trong JVM so với DB.
• Điểm dễ nói sai / hiểu sai: Concurrency không nhất thiết là parallelism; volatile không thay thế atomic operation.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

CHẶNG IV — GHÉP LLD, TESTING VÀ THIẾT KẾ HỆ THỐNG

MÔ-ĐUN 07 [CORE] — LLD bước 2: Hotel Booking + states + concurrency

Mục tiêu: ghép những khối ở Mô-đun 03 thành một design có tính “interview-ready”.

07.1. Đề bài và cách khoanh phạm vi

Design a hotel booking module. Customers can request a room, staff can approve it, and customers can cancel before check-in.

Hỏi interviewer 4 điều trước: booking có thanh toán không? xác định theo phòng vật lý hay loại phòng? inventory lấy local DB hay external provider? quy tắc cancel cụ thể?

Giả định để học: 1 booking = 1 phòng vật lý cho nhiều đêm; xác nhận cần staff approval; payment chưa nằm trong MVP; inventory chỉ quản lý local DB. Khi đề thay đổi, nói lại assumption.

07.2. Các entities bắt buộc trước khi nghĩ tới class code

Rule: dùng khoảng ngày [checkIn, checkOut), tức check-out date không tính là một đêm lưu trú; muốn đặt 20→22 thì giữ đêm 20 và 21.

07.3. State machine

PENDING --staff approves--> CONFIRMED
   |                         |
   | staff rejects           | customer cancels (if allowed)
   v                         v
REJECTED                   CANCELLED

CONFIRMED --stay completed--> COMPLETED

Một số nghiệp vụ yêu cầu hold inventory ngay khi PENDING, một số chỉ giữ khi CONFIRMED; đây là trade-off cần làm rõ, không đoán. Nếu PENDING giữ phòng, phải có chính sách hết hạn hold.

Đề kiểm tra: CANCELLED → CONFIRMED có hợp lệ? Không trong state machine đang giả định; muốn cho phép khôi phục phải thiết kế thêm rule riêng.

07.4. API contract cho MVP

POST   /api/bookings                 tạo request
GET    /api/bookings/{id}            xem trạng thái
POST   /api/bookings/{id}/approve    staff approval
POST   /api/bookings/{id}/reject     staff rejection
POST   /api/bookings/{id}/cancel     cancel theo chính sách

Vì approve là một state transition có side effect, nên endpoint hành động có thể được chọn rõ ràng thay vì ép tất cả thành PUT/DELETE. Status codes: 201 mới tạo; 200/204 hành động thành công; 400 input sai; 401/403 auth; 404 không tìm thấy; 409 trạng thái không hợp lệ hoặc inventory conflict.

07.5. Các classes và đường đi request

BookingController
  ↓
BookingService
  ├─ BookingPolicy (state transitions, cancellation rules)
  ├─ InventoryReservationService (atomic allocation)
  ├─ BookingRepository
  └─ NotificationPort (không để email failure tự quyết định DB transaction)

Phỏng vấn viên hỏi: “Why do you need BookingPolicy?”

It keeps business rules separate from HTTP handling and persistence. For example, it checks whether cancellation is allowed based on the booking status and check-in date.

07.6. Worked sequence — booking phòng cuối

Customer → API: POST booking with room/date + idempotency key
API → Service: validate input, identity, date range
Service → DB transaction: check/allocate every required night with conflict protection
DB → Service: success OR conflict
Service → DB: create Booking + status; commit
Service → API: created booking ID/status
API → Customer: 201

Nếu client timeout rồi retry bằng cùng idempotency key, service nên trả/tra lại kết quả phù hợp mà không tạo booking thứ hai. Key phải có scope, request fingerprint/expiry và chính sách concurrent duplicate requests rõ ràng.

Lỗi hay mắc: “Tôi check available=true rồi insert booking” nhưng quên rằng hai request có thể cùng đọc available=true. Kiểm tra logic trên Java trước insert không đủ khi concurrent operations.

07.7. Bài tập biến thể, giảm gợi ý

Đề: Add a waiting list when rooms are fully booked. If a reservation is cancelled, notify the next eligible customer.

Hãy tự điền: 1. Entity mới? ___ 2. State mới? ___ 3. Ai được vào waitlist? ___ 4. Nếu email notification fails? ___ 5. Nếu hai phòng cùng trống? ___ 6. Một test concurrent? ___

07.8. Checklist LLD khi đi phỏng vấn

• [ ] Hỏi lại requirement; nêu assumptions.
• [ ] Actor và use cases rõ.
• [ ] Entities, PK/FK, relationships.
• [ ] State transitions và business invariants.
• [ ] API contract + validation/status codes.
• [ ] Controller/Service/Repository responsibilities.
• [ ] Happy path + 2 failures + 1 concurrent case.
• [ ] Vì sao chọn design, có thể đơn giản hơn không?
• [ ] Trình bày ít nhất 60 giây bằng tiếng Anh.

🎙️ SPEAKING LAB V5.2 — 07. Hotel Booking LLD + state machine

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: Actors; booking nights; PENDING/CONFIRMED/CANCELLED; atomic allocation; idempotent retries.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Hoàn thành ít nhất một bài COMPLETE/DO ở phía trên (hoặc giải thích một ví dụ mới). Nếu chưa giải thích được cơ chế bằng tiếng Việt, quay lại bài kỹ thuật trước khi bắt đầu nói.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. I would model booking states explicitly and validate each transition.
2. Inventory allocation must protect every required night from concurrent conflicts.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

I assume ___ and . The booking starts in . I would prevent double booking by ___.

4. FREE SPEAK — định nghĩa / cơ chế (không nhìn script)

Chọn 3–5 câu/lượt trong 3 câu sau. Đáp án được thu gọn dưới từng câu; chỉ mở sau khi đã nói.

Q069 · FOUNDATION · BASE V4

TTS 137 · Q: Design a booking module where staff must approve requests.

Q070 · MECHANISM / WHY · BASE V4

TTS 139 · Q: Should pending bookings hold inventory? What is the trade-off?

Q071 · FOUNDATION · ADD V5

TTS 141 · Q: What is a state transition in a booking system?

5. UNEXPECTED FOLLOW-UP — thay giả định và suy luận

Chọn ít nhất một câu dưới đây, tự trả lời trước; sau đó yêu cầu người luyện thay một điều kiện mới.

Q072 · SCENARIO / FOLLOW-UP · BASE V4

TTS 143 · Q: How do you handle two requests for the same room and night?

Q073 · SCENARIO / FOLLOW-UP · BASE V4

TTS 145 · Q: What changes if a customer can cancel before check-in?

Q074 · SCENARIO / FOLLOW-UP · BASE V4

TTS 147 · Q: What if a booking contains multiple nights and allocation fails halfway through?

Q075 · SCENARIO / FOLLOW-UP · ADD V5

TTS 149 · Q: How would you prevent double booking for overlapping date ranges?

Q076 · SCENARIO / FOLLOW-UP · ADD V5

TTS 151 · Q: What happens if an external hotel provider confirms a room but our database update fails?

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: nêu entities/states; L2: design 90 giây; L3: phản ứng khi interviewer thay chính sách hold.
• Điều kiện qua bài: Nêu rõ assumption, status transitions, inventory invariant, failure và một concurrent test.
• Điểm dễ nói sai / hiểu sai: Không tự giả định PENDING có giữ chỗ hay không; phải thống nhất chính sách.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

MÔ-ĐUN 08 [CORE] — Testing, Cloud, Security, Java & DSA: những gì cần để đọc đề và bảo vệ giải pháp

Mục tiêu: không học chứng chỉ. Chỉ học “tôi đã triển khai tính năng, vậy làm sao biết nó đúng, an toàn, vận hành được?”.

08.1. Testing từ trực giác đến lựa chọn

• Boundary value: thử input tại biên và sát biên, ví dụ guestCount = 0,1,max,max+1.
• Equivalence partitioning: chia input thành nhóm được xử lý giống nhau, test một vài đại diện.
• Verification vs validation: build đúng theo đặc tả hay build đúng thứ người dùng thực sự cần?
• Statement vs branch coverage: bao nhiêu câu lệnh vs bao nhiêu nhánh đã được test; coverage cao không bảo đảm hết bug.
• Mock vs stub: đều thay dependency trong test; “mock” thường xác minh tương tác, “stub” trả dữ liệu được chuẩn bị trước (cách dùng phụ thuộc framework).

Bài thực hành: Ngày 20/10 không còn phòng, nhưng API vẫn trả 201. Hãy viết 3 tests: happy path, validation/boundary, concurrency/conflict.

08.2. Cloud và triển khai: định nghĩa + ứng dụng

Ví dụ: ứng dụng chậm khi lượng người dùng tăng. Trước khi hô “microservices”, kiểm tra query plan, app logs, latency distribution, CPU/memory, connection pool, external dependency. Có thể vấn đề là SQL index chứ không phải số lượng servers.

08.3. Security cơ bản — nhìn theo rủi ro

• Authentication: bạn là ai? Authorization: bạn được làm gì?
• Least privilege: chỉ cấp quyền cần thiết; đừng dùng admin DB credentials cho mọi service.
• Hash vs encryption: password nên dùng password hashing có salt với thuật toán phù hợp; không lưu password kiểu reversible encryption thông thường.
• SQL injection: query không parameterized; XSS: dữ liệu không tin cậy chạy script trong browser; CSRF: browser bị lợi dụng gửi request với phiên đã xác thực.
• JWT: chữ ký không đồng nghĩa payload được mã hóa; kiểm tra issuer/audience/expiry và quyền theo contract.
• CIA: Confidentiality / Integrity / Availability.
• Defense in depth: không chỉ dựa vào một tầng kiểm tra.
• Shared responsibility: ranh giới trách nhiệm nhà cung cấp cloud / người triển khai thay đổi theo dịch vụ.

08.4. Java Core và OOP — đối chiếu theo lỗi hay hỏi

Java ví dụ tối thiểu:

List<String> names = List.of("An", "Binh", "Chi");
List<String> filtered = names.stream()
    .filter(name -> name.length() > 2)
    .map(String::toUpperCase)
    .toList();
// [BINH, CHI] (toList() có từ Java 16)

Tự giải thích bằng tiếng Anh: The stream filters names with more than two characters, converts the remaining names to uppercase, and collects them into a list.

08.5. DSA vocabulary và complexity — đủ dùng cho lời giải

• Time/space complexity: tăng input thì thời gian/bộ nhớ tăng thế nào.
• O(1), O(log n), O(n), O(n log n), O(n²) — biết thứ tự tăng trưởng.
• Worst/average/amortized: xấu nhất / trung bình theo input assumption / chi phí trung bình trên chuỗi thao tác.
• Array O(1) index access; linked list O(n) cho truy cập vị trí bất kỳ; hash map expected O(1), không bảo đảm worst case mọi tình huống.
• Stack LIFO / Queue FIFO / PriorityQueue theo ưu tiên.
• BFS dùng queue / DFS stack hoặc recursion; traversal adjacency list thường O(V+E).
• Binary search trên một điều kiện đơn điệu.
• Prefix sum / sliding window / two pointers / greedy — nhận diện pattern trước khi tối ưu.

Các giá trị theo implementation thường được dạy; không đánh đồng toàn bộ biến thể.

Câu tự nói: My solution uses a hash map to count occurrences in O(n) expected time, with O(k) extra space for k distinct keys.

08.6. Glossary nén để không bỏ mất nội dung hai file cũ [PLUS]

Checkpoint CS (tự nói không nhìn file): “A user times out when booking the last room. What problems could occur from the browser to the database? How would you verify the behavior?” Nếu bạn tách được network timeout, duplicate retry, DB concurrency, logging/test, bạn đã liên kết được phần nền tảng thay vì học rời rạc.

🎙️ SPEAKING LAB V5.2 — 08. Testing, Cloud, Security và DSA recap

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: Unit/integration/E2E; boundary/regression; authn/authz; logs/metrics/traces; cloud/scaling.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Hoàn thành ít nhất một bài COMPLETE/DO ở phía trên (hoặc giải thích một ví dụ mới). Nếu chưa giải thích được cơ chế bằng tiếng Việt, quay lại bài kỹ thuật trước khi bắt đầu nói.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. An integration test checks whether components work together with a real database.
2. Before scaling the application, I would inspect latency, logs, and database queries.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

I would start with a ___ test. It should verify . If the system is slow, I would .

4. FREE SPEAK — định nghĩa / cơ chế (không nhìn script)

Chọn 3–5 câu/lượt trong 12 câu sau. Đáp án được thu gọn dưới từng câu; chỉ mở sau khi đã nói.

Q077 · MECHANISM / WHY · BASE V4

TTS 153 · Q: How do unit tests differ from integration tests?

Q078 · FOUNDATION · BASE V4

TTS 155 · Q: Does high test coverage guarantee there are no bugs?

Q079 · MECHANISM / WHY · BASE V4

TTS 157 · Q: What is the difference between authentication and authorization?

Q080 · FOUNDATION · ADD V5

TTS 159 · Q: What is mocking in unit testing?

Q081 · MECHANISM / WHY · ADD V5

TTS 161 · Q: What is the difference between authentication and role-based authorization?

Q082 · MECHANISM / WHY · ADD V5

TTS 163 · Q: What is the difference between symmetric and asymmetric encryption?

Q083 · MECHANISM / WHY · ADD V5

TTS 165 · Q: What is the difference between a virtual machine and a container?

Q084 · FOUNDATION · ADD V5

TTS 167 · Q: What does Big O notation describe?

Q085 · MECHANISM / WHY · ADD V5

TTS 169 · Q: What is the difference between a stack and a queue?

Q086 · MECHANISM / WHY · ADD V5

TTS 171 · Q: What is the difference between BFS and DFS?

Q087 · MECHANISM / WHY · ADD V5

TTS 173 · Q: Why can Quick Sort be O(n²) in the worst case while Merge Sort stays O(n log n)?

Q088 · FOUNDATION · ADD V5

TTS 175 · Q: How can you prevent SQL injection in a Java backend?

5. UNEXPECTED FOLLOW-UP — thay giả định và suy luận

Chọn ít nhất một câu dưới đây, tự trả lời trước; sau đó yêu cầu người luyện thay một điều kiện mới.

Q089 · SCENARIO / FOLLOW-UP · BASE V4

TTS 177 · Q: How would you test that only staff can approve a booking?

Q090 · SCENARIO / FOLLOW-UP · BASE V4

TTS 179 · Q: An application is slow. Would you add more servers immediately?

Q091 · SCENARIO / FOLLOW-UP · ADD V5

TTS 181 · Q: How would you explain the time complexity of binary search?

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: định nghĩa + ví dụ test; L2: 60 giây symptom → measurement → fix → regression.
• Điều kiện qua bài: Chọn đúng loại test cho rule, DB hoặc end-to-end; không nhầm authn và authz.
• Điểm dễ nói sai / hiểu sai: Coverage chỉ là chỉ số phạm vi chạy code, không chứng minh không có lỗi.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

MÔ-ĐUN 08A [CORE][JAVA BACKEND] — Java Core + OOP: từ biết dùng đến giải thích được cơ chế

Vì sao bổ sung? Mục 08.4 phía trên chỉ là bảng ôn nhanh. Mô-đun này dành cho ứng viên đã code Java cơ bản nhưng dễ bí khi interviewer hỏi why / what if / show me. Mục tiêu Intern/Fresher/Junior 0–1 năm: không học JVM nội bộ đến mức senior, không học thuộc câu trả lời dài.

Thứ tự mỗi cụm: PRETEST → WATCH → COMPLETE → DO → EXPLAIN theo cách học ở START HERE. Có thể bỏ qua WATCH nếu tự giải được DO và giải thích rõ.

08A.0. PRETEST — 8 câu (6 phút, chưa xem phần dưới)

1. Hai Counter objects có static int total và int ownCount: gọi increment() trên object A thì B nhìn thấy trường nào đổi?
2. Vì sao static void print() không thể trực tiếp dùng một instance field mà không có object?
3. Vì sao hai object có equals() trả true phải có cùng hashCode()?
4. Với List<String> xs = new ArrayList<>(), khác gì Set<String> khi thêm trùng?
5. change(name) nhận String name rồi gán name = "new": biến bên ngoài có đổi không?
6. Một HashMap dùng làm shared state giữa nhiều threads có an toàn không?
7. Khác nhau thế nào giữa overloading và overriding? Static method có override không?
8. count++ trên static int count có đảm bảo chính xác khi hai threads cùng gọi không?

Phân luồng: sai (1–2) → 08A.1; (3–5) → 08A.2–3; (6–8) → 08A.4–5. Nếu đúng hết, làm ngay DO/MOCK ở 08A.6.

08A.1. static / instance / final: một ví dụ từ đơn giản đến tình huống

WATCH — code có thể chạy bằng Java 21:

class Counter {
    static int total = 0;  // Một field gắn với lớp Counter (trong một class-loader context)
    int ownCount = 0;      // Mỗi object có field riêng

    void increment() {
        total++;
        ownCount++;
    }
    static int totalSoFar() { return total; }
}

class Demo {
    public static void main(String[] args) {
        Counter a = new Counter();
        Counter b = new Counter();
        a.increment();
        a.increment();
        b.increment();
        System.out.println(Counter.totalSoFar()); // 3
        System.out.println(a.ownCount);           // 2
        System.out.println(b.ownCount);           // 1
    }
}

• static field thuộc lớp, các instances của lớp dùng chung giá trị đó (trong cùng JVM/class-loader tương ứng); thường gọi Counter.total, không gọi qua instance dù Java cho phép một số trường hợp truy cập như thế.
• static method không có this; muốn đọc ownCount, phải có reference đến object cụ thể (hoặc tạo object).
• static method ở subclass có thể hide static method cùng signature của superclass, không phải override động như instance method.
• final với biến/reference: không gán lại reference; không làm object được tham chiếu thành immutable. static final thường dùng hằng số; immutable/thread-safe còn tùy loại dữ liệu.
• static không có nghĩa thread-safe. total++ vẫn là read–modify–write, có thể mất increment.

COMPLETE — điền trước khi mở đáp án:

class Config {
    static final int MAX_RETRIES = 3;
    private String environment;
    Config(String environment) { this.environment = environment; }
    // Viết static method trả MAX_RETRIES và instance method trả environment.
}

static int maxRetries() { return MAX_RETRIES; }
String environment() { return environment; }

DO — đề biến thể (5 phút): Cart chứa static double discountPercent và double subtotal. Bạn muốn mỗi giỏ có chính sách giảm giá khác nhau. Thiết kế hiện tại có rủi ro gì? Sửa field nào? Nếu nhiều luồng cùng cập nhật tổng doanh thu của cửa hàng thì sao?

EXPLAIN: “A static field belongs to the class and is shared across instances, while an instance field belongs to each object. Static alone does not make updates thread-safe.” Nói thêm một ví dụ.

MICRO SPEAK V5.2 — sau mục 08A.1 · 4 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: No. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (4 câu)

Q092 · MECHANISM / WHY · BASE V4

TTS 183 · Q: Does static imply thread safety? Why not?

Q093 · FOUNDATION · ADD V5

TTS 185 · Q: What does static mean, and does it imply thread safety?

Q094 · MECHANISM / WHY · ADD V5

TTS 187 · Q: What happens when you invoke a static method through a superclass reference to a subclass object?

Q095 · MECHANISM / WHY · ADD V5

TTS 189 · Q: What is the difference between final, finally, and finalize?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

08A.2. Reference, pass-by-value, String, equality và hashCode()

WATCH — mô hình cần nhớ: Java luôn truyền arguments by value. Với object, giá trị được truyền là bản sao của reference. Method có thể sửa object thông qua reference đó, nhưng gán biến parameter sang object khác không đổi biến của caller.

import java.util.*;
class Demo {
    static void append(List<String> items) { items.add("B"); }
    static void replace(List<String> items) { items = new ArrayList<>(); items.add("C"); }
    public static void main(String[] args) {
        List<String> xs = new ArrayList<>(List.of("A"));
        append(xs);
        replace(xs);
        System.out.println(xs); // [A, B]
    }
}

• == so identity của hai references (với primitives là so giá trị); .equals() là logical equality theo implementation của class.
• String immutable: s.toUpperCase() tạo/trả một giá trị mới, không sửa object cũ; so chuỗi theo nội dung dùng equals().
• Contract: a.equals(b) đúng ⇒ a.hashCode() == b.hashCode(); hash bằng nhau không đảm bảo equals đúng.
• HashMap/HashSet dựa vào hash và equality. Nếu dùng object làm key, key nên có equality/hash ổn định trong thời gian đang được lưu. record thường tiện cho value objects vì cung cấp equality/hash theo components.

COMPLETE: Kết quả đoạn sau là gì? Vì sao?

String x = new String("java");
String y = new String("java");
System.out.println(x == y);       // ?
System.out.println(x.equals(y));  // ?
String z = x.toUpperCase();
System.out.println(x);            // ?

DO — hai bug rất hay gặp:

1. Một HashSet<Customer> chứa hai objects khác nhau có cùng customerId, nhưng vẫn giữ cả hai. Có thể sai ở đâu?
2. Dùng object OrderKey(id, status) mutable làm key cho HashMap, sau đó đổi status; tại sao map.get(key) có thể thất bại?

MICRO SPEAK V5.2 — sau mục 08A.2 · 8 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: For object references, double equals compares whether they point to the same object. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (8 câu)

Q096 · MECHANISM / WHY · BASE V4

TTS 191 · Q: What is the difference between == and equals for objects?

Q097 · MECHANISM / WHY · BASE V4

TTS 193 · Q: Why can mutable HashMap keys cause problems?

Q098 · MECHANISM / WHY · BASE V4

TTS 195 · Q: What does Java pass when you pass an object to a method?

Q099 · MECHANISM / WHY · ADD V5

TTS 197 · Q: Why do HashMap keys need a stable hashCode and equals contract?

Q100 · MECHANISM / WHY · ADD V5

TTS 199 · Q: Why doesn't changing a method's object parameter reference replace the caller's reference?

Q101 · MECHANISM / WHY · ADD V5

TTS 201 · Q: What is the difference between String, StringBuilder, and StringBuffer?

Q102 · MECHANISM / WHY · ADD V5

TTS 203 · Q: What is the difference between stack memory and heap memory in Java?

Q103 · MECHANISM / WHY · ADD V5

TTS 205 · Q: What is the difference between equals and hashCode contracts?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

08A.3. OOP, access modifiers và polymorphism — khi nào dùng interface?

WATCH:

WATCH — code ví dụ:

interface DiscountPolicy {
    int discount(int subtotal);
}
class NoDiscount implements DiscountPolicy {
    public int discount(int subtotal) { return 0; }
}
class TenPercent implements DiscountPolicy {
    public int discount(int subtotal) { return subtotal / 10; }
}
class CheckoutService {
    private final DiscountPolicy policy;
    CheckoutService(DiscountPolicy policy) { this.policy = policy; }
    int finalPrice(int subtotal) { return subtotal - policy.discount(subtotal); }
}

Đây là Strategy + constructor injection bằng Java thuần. Bạn có thể thay policy mà không viết nhiều if bên trong CheckoutService. Không cần tạo interface cho mọi class; chỉ tạo abstraction khi giải quyết được nhu cầu thực tế.

COMPLETE: Đổi từ NoDiscount sang TenPercent mà không sửa CheckoutService như thế nào? Vì sao ví dụ này thể hiện polymorphism?

CheckoutService service = new CheckoutService(new TenPercent());
System.out.println(service.finalPrice(100)); // 90

DO — follow-up: Interviewer yêu cầu “thêm discount VIP”. Bạn sẽ thêm subclass của CheckoutService hay thêm implementation DiscountPolicy? Khi nào một interface trở nên không cần thiết?

MICRO SPEAK V5.2 — sau mục 08A.3 · 7 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: I would use an interface to define a contract that different classes can implement. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (6 câu)

Q104 · MECHANISM / WHY · ADD V5

TTS 207 · Q: What's the difference between interface and abstract class?

Q105 · MECHANISM / WHY · ADD V5

TTS 209 · Q: What's the difference between an overloaded and an overridden method?

Q106 · FOUNDATION · ADD V5

TTS 211 · Q: What is encapsulation in object-oriented programming?

Q107 · MECHANISM / WHY · ADD V5

TTS 213 · Q: What is inheritance, and when could composition be better?

Q108 · FOUNDATION · ADD V5

TTS 215 · Q: What is polymorphism in Java?

Q109 · FOUNDATION · ADD V5

TTS 217 · Q: What is abstraction in OOP?

FOLLOW-UP — case / phản biện (1 câu)

Q110 · SCENARIO / FOLLOW-UP · BASE V4

TTS 219 · Q: When would you use an interface rather than an abstract class?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

08A.4. Collections, generics, Optional, Stream và exceptions

WATCH — phân biệt đủ dùng:

WATCH — hai idiom ngắn:

Map<String, Integer> freq = new HashMap<>();
for (String s : List.of("A", "B", "A")) {
    freq.merge(s, 1, Integer::sum);
}
// {A=2, B=1} (thứ tự duyệt HashMap không được đảm bảo)

Optional<String> name = Optional.empty();
System.out.println(name.orElse("Unknown")); // Unknown

COMPLETE — dự đoán:

List<Integer> nums = new ArrayList<>(List.of(1, 2, 3, 4));
long count = nums.stream().filter(n -> n % 2 == 0).count();
// count = ? ; nums sau khi đếm = ?

DO — Java interview nhỏ (8 phút): Viết Map<String,Integer> countByCategory(List<String> categories); bỏ qua null và chuỗi blank, trim khoảng trắng, gộp category không phân biệt hoa/thường. Viết hai test cases.

static Map<String, Integer> countByCategory(List<String> categories) {
    Map<String, Integer> ans = new HashMap<>();
    for (String raw : categories) {
        if (raw == null || raw.isBlank()) continue;
        String key = raw.trim().toLowerCase(Locale.ROOT);
        ans.merge(key, 1, Integer::sum);
    }
    return ans;
}

MICRO SPEAK V5.2 — sau mục 08A.4 · 10 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: I usually choose ArrayList for indexed access and efficient iteration. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (8 câu)

Q111 · FOUNDATION · ADD V5

TTS 221 · Q: Can garbage collection replace closing a database connection?

Q112 · MECHANISM / WHY · ADD V5

TTS 223 · Q: What is the difference between checked and unchecked exceptions?

Q113 · MECHANISM / WHY · ADD V5

TTS 225 · Q: What is the difference between List, Set, and Map?

Q114 · MECHANISM / WHY · ADD V5

TTS 227 · Q: What is the difference between HashMap and ConcurrentHashMap?

Q115 · MECHANISM / WHY · ADD V5

TTS 229 · Q: What is the difference between HashSet and TreeSet?

Q116 · FOUNDATION · ADD V5

TTS 231 · Q: What is a generic type in Java?

Q117 · MECHANISM / WHY · ADD V5

TTS 233 · Q: What is the difference between Comparable and Comparator?

Q118 · MECHANISM / WHY · ADD V5

TTS 235 · Q: What is the difference between map and filter in Java Streams?

FOLLOW-UP — case / phản biện (2 câu)

Q119 · SCENARIO / FOLLOW-UP · ADD V5

TTS 237 · Q: When would you choose ArrayList instead of LinkedList?

Q120 · SCENARIO / FOLLOW-UP · ADD V5

TTS 239 · Q: When would you use Optional rather than returning null?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

08A.5. Thread safety và dữ liệu: kết nối Java với Backend

WATCH:

class Counter {
    private int value;
    synchronized void increment() { value++; }
    synchronized int get() { return value; }
}

Trong một Counter object, hai synchronized instance methods dùng chung intrinsic lock của object đó. Nhưng nếu có hai Counter objects / hai JVM instances / hai backend pods, chúng không chia sẻ lock với nhau. volatile giúp visibility/order, không làm value++ atomic.

Khi data thật nằm ở PostgreSQL, hãy xét transaction + database locking/constraint/atomic conditional update thay vì tin rằng synchronized ở một application instance đã bảo vệ dữ liệu chung.

DO — tình huống: Hai người cùng mua sản phẩm còn 1 món. Vì sao synchronized method trong Spring service vẫn có thể không giải quyết được nếu chạy nhiều replicas? Thiết kế một test đồng thời và điều kiện sau test.

MICRO SPEAK V5.2 — sau mục 08A.5 · 1 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: Both requests may read the same old value and overwrite each other's update. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FOLLOW-UP — case / phản biện (1 câu)

Q121 · SCENARIO / FOLLOW-UP · ADD V5

TTS 241 · Q: Two requests increment a shared counter. What can go wrong?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

08A.6. MOCK mới (12 phút): trả lời rồi mới mở đáp án

1. What does static mean, and does it imply thread safety?
2. Why do HashMap keys need a stable hashCode and equals contract?
3. What's the difference between interface and abstract class?
4. When would you choose ArrayList instead of LinkedList?
5. What's the difference between an overloaded and an overridden method?
6. Why doesn't changing a method's object parameter reference replace the caller's reference?
7. When would you use Optional rather than returning null?
8. Can garbage collection replace closing a database connection?
9. What happens when you invoke a static method through a superclass reference to a subclass object?
10. Two requests increment a shared counter. What can go wrong?

Checkpoint 08A: tự làm 08A.4 và trả lời 10 câu mock đạt chuẩn, giải thích bằng 2–4 câu tiếng Anh ngắn với ít nhất 4 câu bất kỳ. Khi đã đạt, không đọc lại toàn module; chỉ flashcard lỗi.

🎙️ SPEAKING LAB V5.2 — 08A. Java Core + OOP

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: static/instance; Java pass-by-value; equals/hashCode; polymorphism; Collections; thread safety.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Đã được chia nhỏ: 30 cặp Q&A của mô-đun này được đặt sau từng mục lý thuyết ở phía trên (MICRO SPEAK V5.2). Không đọc lại toàn bộ câu hỏi ở đây; chọn 3 câu khó nhất để làm lại không nhìn.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. Static fields belong to the class rather than one object, but that does not make them thread-safe.
2. Equal objects must return the same hash code under the equals and hashCode contract.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

In Java, ___ means . For example, . However, it does not guarantee ___.

4. FREE SPEAK + FOLLOW-UP — ôn các micro-lab

Lấy ngẫu nhiên 2 câu cơ chế + 1 câu tình huống đã làm trong các MICRO SPEAK phía trên. Không đọc script; câu nào sai phải sửa kèm một ví dụ/code/test.

Mã câu trong mô-đun: Q096, Q092, Q110, Q097, Q098, Q093, Q099, Q104, Q119, Q105, Q100, Q120, Q111, Q094, Q121, Q106, Q107, Q108, Q109, Q095, Q112, Q101, Q113, Q114, Q115, Q116, Q117, Q118, Q102, Q103.

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: 2–4 câu/cặp khái niệm; L2: 90 giây với ví dụ code và lỗi hay gặp.
• Điều kiện qua bài: Nói đúng static/equals/hashCode, override/overload, Java pass-by-value; không nói static = thread-safe.
• Điểm dễ nói sai / hiểu sai: Java luôn pass-by-value, kể cả khi value được copy là reference tới object.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

MÔ-ĐUN 08B [CORE][JAVA BACKEND] — Spring Boot + JPA/Hibernate: từ HTTP request đến database

Vị trí: học sau 08A và Mô-đun 04 (SQL/transaction). Không cần biết microservices/Kafka/Kubernetes để hoàn thành. Mục tiêu là giải thích và sửa được một luồng Spring Boot đơn giản, sau đó phát hiện những lỗi ORM/transaction phổ biến.

08B.0. PRETEST — 7 câu (6 phút)

1. @Service và @Repository tự tạo object khác gì với new UserService(...)?
2. Bean là gì? Vì sao có hai beans cùng type thì constructor injection có thể không rõ chọn bean nào?
3. @Valid ở Controller có thay thế được check “email đã tồn tại trong DB” không?
4. JpaRepository.findById(id) trả về gì? Vì sao không nên tự gọi .get() mù?
5. Vì sao có @Transactional mà hai requests vẫn có thể cùng mua món hàng cuối cùng?
6. Vì sao vòng lặp for (Order o : orders) o.getCustomer().getName() có thể tạo N+1 queries?
7. flush() đồng nghĩa với commit() chưa? @Transactional có rollback với mọi checked exception theo mặc định không?

Nếu sai nhiều: học 08B.1 → 08B.4 theo thứ tự; nếu đúng gần hết: làm LAB 08C và MOCK 08B.7 trước.

08B.1. Spring Container, IoC, DI, Beans — ví dụ đơn giản

WATCH — lần theo nguồn tạo object:

@Service
public class BookingService {
    private final BookingRepository repository;

    public BookingService(BookingRepository repository) {
        this.repository = repository;
    }
}

@Repository
public class BookingRepository {
    // Data access methods
}

• IoC: quyền điều phối việc khởi tạo/wiring đối tượng chuyển sang framework/container.
• Dependency Injection: dependency được cung cấp cho object (ở đây qua constructor), thay vì tự new bên trong business class.
• Bean: object được Spring IoC container quản lý theo bean definition/scope; stereotype @Component, @Service, @Repository, @Controller giúp đăng ký bean qua component scanning khi thuộc phạm vi quét. @SpringBootApplication có cơ chế component scan mặc định từ package cấu hình.
• Constructor injection giúp dependency bắt buộc rõ ràng, dễ test với fake/mock; với class chỉ có một constructor, Spring hiện đại không đòi @Autowired trên constructor đó.
• @Bean + @Configuration: đăng ký object từ factory method, hữu ích với class của thư viện hoặc khi cần cấu hình cụ thể.
• Scope: singleton mặc định là một bean instance trên một Spring container (không phải singleton toàn hệ phân tán). Singleton bean có mutable shared fields phải quan tâm concurrency.
• @Repository có vai trò mô tả persistence layer và tham gia exception translation trong các điều kiện tích hợp phù hợp; annotation không tự làm một class thường thành CRUD repository.

WATCH — một bean từ thư viện Java:

@Configuration
class TimeConfig {
    @Bean
    Clock applicationClock() { return Clock.systemUTC(); }
}

@Service
class DeadlineService {
    private final Clock clock;
    DeadlineService(Clock clock) { this.clock = clock; }
    boolean expired(Instant until) { return Instant.now(clock).isAfter(until); }
}

COMPLETE: Có Clock.systemUTC() và Clock.systemDefaultZone() đều đăng ký với tên khác nhau, cùng type Clock. Spring biết inject cái nào thế nào?

DO: Viết một @Service nhận Clock qua constructor và có String nowIso() trả UTC instant. Nói một lợi ích khi unit test.

@Service
class TimeService {
    private final Clock clock;
    TimeService(Clock clock) { this.clock = clock; }
    String nowIso() { return Instant.now(clock).toString(); }
}

MICRO SPEAK V5.2 — sau mục 08B.1 · 7 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: Spring is a framework and ecosystem for building applications. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (6 câu)

Q122 · MECHANISM / WHY · ADD V5

TTS 243 · Q: What is the difference between Spring and Spring Boot?

Q123 · MECHANISM / WHY · ADD V5

TTS 245 · Q: What is a bean, and how does constructor injection work?

Q124 · MECHANISM / WHY · ADD V5

TTS 247 · Q: What's the difference between @Component, @Service, and @Repository?

Q125 · FOUNDATION · ADD V5

TTS 249 · Q: What is inversion of control in Spring?

Q126 · MECHANISM / WHY · ADD V5

TTS 251 · Q: Why is constructor injection often preferred over field injection?

Q127 · FOUNDATION · ADD V5

TTS 253 · Q: What is Spring Boot auto-configuration?

FOLLOW-UP — case / phản biện (1 câu)

Q128 · SCENARIO / FOLLOW-UP · ADD V5

TTS 255 · Q: What happens if two beans have the same type?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

08B.2. Request flow, DTO, validation và status codes

WATCH — một luồng cơ bản:

HTTP POST /api/products
  → @RestController (JSON body → request DTO)
  → Bean Validation @Valid (shape/range)
  → @Service (business rules, authorization, DB checks)
  → repository/JPA/SQL
  → transaction commit
  → response DTO + HTTP 201 hoặc lỗi theo API contract

Ví dụ code học concept (bỏ qua imports và exception handler; chưa phải API hoàn chỉnh):

record CreateProductRequest(
    @NotBlank String sku,
    @NotNull @Positive BigDecimal price
) {}
record ProductResponse(Long id, String sku, BigDecimal price) {}

@RestController
@RequestMapping("/api/products")
class ProductController {
    private final ProductService service;
    ProductController(ProductService service) { this.service = service; }

    @PostMapping
    ResponseEntity<ProductResponse> create(@Valid @RequestBody CreateProductRequest req) {
        ProductResponse saved = service.create(req);
        return ResponseEntity.status(HttpStatus.CREATED).body(saved);
    }
}

• @RestController thường serialize return value thành response body; @RequestMapping trên class là base path, @PostMapping gắn HTTP POST.
• @RequestBody deserializes JSON sang DTO; @Valid kích hoạt Bean Validation khi dependency/provider validation đã cấu hình. @NotBlank, @NotNull, @Positive là Jakarta Bean Validation constraints trong Spring Boot 3.
• Validation trên DTO không đảm bảo SKU unique khi hai requests đồng thời; dùng rule/constraint ở DB và xử lý constraint violation phù hợp.
• Không trả trực tiếp JPA Entity một cách máy móc: có thể leak dữ liệu, gặp lazy loading, recursive JSON và ràng buộc API với persistence model. Dùng response DTO.
• @RestControllerAdvice + @ExceptionHandler để chuyển các lỗi ứng dụng thành error response thống nhất; không bắt mọi exception rồi trả 200.

COMPLETE: JSON { "sku":"", "price":-5 } gửi vào API trên: có nên tạo product? Lỗi thuộc DTO validation hay business rule trong DB?

DO: Thiết kế POST /api/tasks với title không blank, priority 1–5, chỉ người có role MEMBER được tạo; nêu ít nhất 3 HTTP responses và 3 tests. Không cần viết Spring Security hoàn chỉnh.

MICRO SPEAK V5.2 — sau mục 08B.2 · 7 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: The controller handles the HTTP request and input validation. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (6 câu)

Q129 · MECHANISM / WHY · BASE V4

TTS 257 · Q: Walk me through Controller → Service → Repository in Spring Boot.

Q130 · FOUNDATION · BASE V4

TTS 259 · Q: Can @Valid enforce uniqueness across concurrent requests?

Q131 · FOUNDATION · ADD V5

TTS 261 · Q: Can @Valid prevent two users from registering the same email concurrently?

Q132 · FOUNDATION · ADD V5

TTS 263 · Q: What does @RestController do?

Q133 · MECHANISM / WHY · ADD V5

TTS 265 · Q: What is the difference between @RequestParam, @PathVariable, and @RequestBody?

Q134 · MECHANISM / WHY · ADD V5

TTS 267 · Q: How does validation work with @Valid in a Spring controller?

FOLLOW-UP — case / phản biện (1 câu)

Q135 · SCENARIO / FOLLOW-UP · ADD V5

TTS 269 · Q: How would you secure a Spring REST endpoint?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

08B.3. JPA/Hibernate, Repository và entity lifecycle

WATCH — phân biệt:

• JPA (Jakarta Persistence): specification/API cho object–relational persistence; Hibernate là một implementation phổ biến. Spring Data JPA cung cấp repository abstraction trên JPA.
• Entity: class mapping table/rows; @Entity, @Id, @GeneratedValue; object references/collections có thể mapping relationships.
• Persistence context quản lý managed entities; thay đổi của managed entity có thể được dirty-checking và đồng bộ xuống DB khi flush, trong transaction phù hợp.
• save() không đồng nghĩa ngay lập tức commit. flush() đồng bộ SQL cần thiết với DB trong transaction nhưng không commit; rollback vẫn có thể hủy thay đổi chưa commit.
• findById() thường trả Optional<T>; findBy... theo naming convention được Spring Data suy ra từ property names, không phải JPA core tự tạo.
• @ManyToOne mặc định JPA là EAGER; @OneToMany mặc định LAZY. Với API backend, thường khai báo fetch rõ ràng và thiết kế query theo use case thay vì dựa máy móc vào defaults.

WATCH — entity giản lược để học:

@Entity
class Task {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String title;

    @ManyToOne(fetch = FetchType.LAZY, optional = false)
    private Workspace workspace;

    protected Task() {} // cho JPA
    Task(String title, Workspace workspace) {
        this.title = title;
        this.workspace = workspace;
    }
    void rename(String title) { this.title = title; }
}

interface TaskRepository extends JpaRepository<Task, Long> {
    List<Task> findByWorkspaceId(Long workspaceId);
}

Đây chỉ là ví dụ chưa đủ code để chạy độc lập: cần Workspace entity, imports, config, dependencies, schema và API. Dùng nó để giải thích mapping/relationship/repository, không nhận là production-ready.

COMPLETE: Service @Transactional tìm Task với findById, gọi task.rename("X") rồi return, không thấy save(task). Khi nào DB vẫn được update?

DO: Vì sao API GET /tasks có thể bị lỗi hoặc chậm nếu trả thẳng List<Task> rồi serializer truy cập task.workspace.name? Nêu hai cách sửa.

MICRO SPEAK V5.2 — sau mục 08B.3 · 10 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: Flush sends pending SQL changes to the database, but the transaction may still be open. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (9 câu)

Q136 · MECHANISM / WHY · BASE V4

TTS 271 · Q: What is the difference between flush and commit in JPA?

Q137 · MECHANISM / WHY · BASE V4

TTS 273 · Q: Why can an ORM loop cause an N+1 query problem?

Q138 · MECHANISM / WHY · ADD V5

TTS 275 · Q: What is the difference between JPA and Hibernate?

Q139 · MECHANISM / WHY · ADD V5

TTS 277 · Q: What happens when you modify a managed JPA entity inside a transaction?

Q140 · MECHANISM / WHY · ADD V5

TTS 279 · Q: What is lazy loading, and when can it fail?

Q141 · MECHANISM / WHY · ADD V5

TTS 281 · Q: What is the difference between a JPA entity and a DTO?

Q142 · FOUNDATION · ADD V5

TTS 283 · Q: What is the persistence context in JPA?

Q143 · MECHANISM / WHY · ADD V5

TTS 285 · Q: What is the difference between persist and merge in JPA?

Q144 · MECHANISM / WHY · ADD V5

TTS 287 · Q: What is the difference between LAZY and EAGER fetching?

FOLLOW-UP — case / phản biện (1 câu)

Q145 · SCENARIO / FOLLOW-UP · ADD V5

TTS 289 · Q: When would you use a fetch join or an EntityGraph?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

08B.4. @Transactional: rollback, concurrency và self-invocation

WATCH — những điều phải nói chính xác:

WATCH — ví dụ self-invocation:

@Service
class ImportService {
    public void importAll() {
        applyOneBatch(); // call nội bộ, không đi qua transactional proxy mặc định
    }
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void applyOneBatch() { /* DB writes */ }
}

Không nên tự kết luận mỗi applyOneBatch có một transaction riêng. Có thể tách BatchWorker thành Spring bean riêng và gọi qua injected bean, dùng TransactionTemplate hoặc thiết kế transaction boundary phù hợp. Khi giải thích, luôn nhắc proxy mode đang dùng.

COMPLETE: Một service @Transactional đọc stock=1, kiểm stock > 0, trừ 1 và ghi. Hai requests cùng chạy, đều commit được trong cấu hình READ COMMITTED và không khóa/điều kiện bảo vệ. Vì sao?

DO — tình huống thật: createBooking() trong transaction ghi Booking, rồi gọi provider external và gặp timeout. Nếu transaction rollback, có chắc provider chưa tạo booking không? Bạn sẽ cải tiến như thế nào?

MICRO SPEAK V5.2 — sau mục 08B.4 · 4 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: No. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FREE SPEAK — định nghĩa / cơ chế (2 câu)

Q146 · FOUNDATION · BASE V4

TTS 291 · Q: Does @Transactional automatically prevent all inventory races?

Q147 · FOUNDATION · ADD V5

TTS 293 · Q: What is the default rollback behavior of @Transactional?

FOLLOW-UP — case / phản biện (2 câu)

Q148 · SCENARIO / FOLLOW-UP · ADD V5

TTS 295 · Q: Does @Transactional guarantee that two requests won't oversell inventory?

Q149 · SCENARIO / FOLLOW-UP · ADD V5

TTS 297 · Q: Why might @Transactional not work on a method called from within the same class?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

08B.5. N+1, query tuning, authorization và tests

WATCH — N+1: query lấy N orders, sau đó N lần lazy-load customer: 1 query danh sách + N query association. Không phải mọi lần truy cập @ManyToOne đều gây N+1; phụ thuộc fetch plan, persistence context, dữ liệu được lấy và implementation.

Giải pháp phải chọn theo nhu cầu: DTO projection cho list endpoints; fetch join hoặc EntityGraph khi muốn association; kiểm Hibernate SQL logs / query count / actual query plan; tránh mặc định fetch tất cả collection trong page query.

Authorization không giống authentication: biết người dùng là ai chưa có nghĩa được sửa task của workspace khác. Truy vấn theo workspace_id + kiểm membership/role, kết hợp domain rule và DB constraints. Object ID khó đoán không thay thế authorization.

Kiểm thử nên phân biệt:

DO — phát hiện lỗi theo thứ tự: Endpoint /api/workspaces/{w}/tasks trả chậm khi số task lớn; sau đó phát hiện user A có thể đọc task của workspace B. Nêu hai nhóm nguyên nhân và đề xuất test.

MICRO SPEAK V5.2 — sau mục 08B.5 · 2 Q&A. Chỉ làm khi đã hiểu ví dụ/code ở ngay phía trên. Mỗi lượt chọn tối đa 4–6 câu; nếu nhiều hơn, chia 2 lượt.

SHADOW: N plus one happens when one query loads a list and additional queries fetch related data item by item. (nghe và nhại 2 lần). Sau đó che đáp án, tự trả lời bằng tiếng Anh rồi mới mở mẫu.

FOLLOW-UP — case / phản biện (2 câu)

Q150 · SCENARIO / FOLLOW-UP · ADD V5

TTS 299 · Q: What is the N+1 query problem and how would you detect it?

Q151 · SCENARIO / FOLLOW-UP · ADD V5

TTS 301 · Q: How would you test a service that uses DB transactions and external APIs?

DO → TRANSFER: quay lại bài thực hành ngay phía trên; đổi một dữ kiện và giải thích hệ quả bằng tiếng Anh. Ghi một lỗi kiến thức và một lỗi nói.

08B.6. LAB Spring/SQL tích hợp (18–25 phút)

Đề mới: Implement an API to move a task to another column. Each column has a maximum number of active tasks. Only workspace members may move tasks.

Phần A (5 phút): ghi actor, Task, Column, Membership, API, DTO và 3 HTTP statuses.

Phần B (7 phút): nêu Controller/Service/Repository responsibilities, transaction boundary, 2 concurrency bugs, hướng phòng ngừa.

Phần C (5 phút): viết query SQL lấy các columns và số lượng active tasks; dùng LEFT JOIN để vẫn có column trống.

Phần D (3 phút): nói 3–5 câu tiếng Anh giải thích flow và một trade-off. Không nhìn V-Core trả lời mẫu trước.

SELECT c.id, COUNT(t.id) AS active_count
FROM workflow_columns c
LEFT JOIN tasks t ON t.column_id = c.id AND t.status = 'ACTIVE'
WHERE c.workspace_id = :workspaceId
GROUP BY c.id;

08B.7. MOCK Spring/JPA — 12 câu chưa có đáp án lộ sẵn (15 phút)

1. What is the difference between Spring and Spring Boot?
2. What is a bean, and how does constructor injection work?
3. What happens if two beans have the same type?
4. What's the difference between @Component, @Service, and @Repository?
5. Can @Valid prevent two users from registering the same email concurrently?
6. What is the difference between JPA and Hibernate?
7. What happens when you modify a managed JPA entity inside a transaction?
8. What is lazy loading, and when can it fail?
9. What is the N+1 query problem and how would you detect it?
10. Does @Transactional guarantee that two requests won't oversell inventory?
11. Why might @Transactional not work on a method called from within the same class?
12. How would you test a service that uses DB transactions and external APIs?

Checkpoint 08B: làm LAB 08B.6 không xem đáp án; đạt mock; mở một flow thật từ V-Market rồi chỉ được Controller, Service, SQL/Repository, transaction boundary và integration test. Nói rõ code repo dùng JDBC ở flow nào, JPA ở flow nào; không tự nhận V-Market checkout dùng Hibernate nếu code dùng JDBC.

🎙️ SPEAKING LAB V5.2 — 08B. Spring Boot + JPA/Hibernate

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: IoC/DI/Bean; controller/service/repository; DTO validation; JPA flush/commit; transaction and N+1.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Đã được chia nhỏ: 30 cặp Q&A của mô-đun này được đặt sau từng mục lý thuyết ở phía trên (MICRO SPEAK V5.2). Không đọc lại toàn bộ câu hỏi ở đây; chọn 3 câu khó nhất để làm lại không nhìn.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. Spring manages beans and injects dependencies through the application context.
2. Flushing changes to the database is not the same as committing a transaction.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

The controller . The service . The repository . A common issue is .

4. FREE SPEAK + FOLLOW-UP — ôn các micro-lab

Lấy ngẫu nhiên 2 câu cơ chế + 1 câu tình huống đã làm trong các MICRO SPEAK phía trên. Không đọc script; câu nào sai phải sửa kèm một ví dụ/code/test.

Mã câu trong mô-đun: Q129, Q136, Q137, Q130, Q146, Q122, Q123, Q128, Q124, Q131, Q138, Q139, Q140, Q150, Q148, Q149, Q151, Q125, Q126, Q127, Q132, Q133, Q134, Q141, Q142, Q143, Q144, Q145, Q147, Q135.

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: nói request flow 30–40 giây; L2: 90 giây về transaction/N+1 kèm test.
• Điều kiện qua bài: Phân biệt JPA spec, Hibernate implementation, Spring Data; hiểu flush != commit và validate != DB constraint.
• Điểm dễ nói sai / hiểu sai: Không nói save/flush luôn commit; không dùng @Transactional thay cho concurrency strategy.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

LAB 08C [CORE][JAVA BACKEND] — Kiểm tra cuối: code → SQL → English → follow-up

LAB này chỉ 35–45 phút, dùng để kiểm tra năng lực vận dụng chứ không kiểm tra trí nhớ về file. Nếu cần, đổi tên entity / input để tự tạo biến thể.

C1. Java code (10 phút, không dùng AI)

Viết Map<String, Long> summarize(List<String> tags) đếm từ khóa không phân biệt hoa thường, bỏ null/blank, trả map bất kỳ thứ tự. Viết 3 tests (input thường, null/blank, empty). Giải thích complexity theo tổng số ký tự và số phần tử (không chỉ nói O(n) nếu phải trim/lowercase strings).

static Map<String, Long> summarize(List<String> tags) {
    Map<String, Long> counts = new HashMap<>();
    for (String raw : tags) {
        if (raw == null || raw.isBlank()) continue;
        String key = raw.trim().toLowerCase(Locale.ROOT);
        counts.merge(key, 1L, Long::sum);
    }
    return counts;
}

C2. SQL (8 phút)

Có users(id,name) và orders(id,user_id,total,status). Viết query liệt kê mọi user với total_paid của các đơn PAID; người không có PAID trả 0. Vì sao đặt điều kiện status trong WHERE có thể làm mất người không có orders?

SELECT u.id, u.name, COALESCE(SUM(o.total), 0) AS total_paid
FROM users u
LEFT JOIN orders o ON o.user_id = u.id AND o.status = 'PAID'
GROUP BY u.id, u.name;

C3. Spring scenario (10 phút)

Một endpoint POST /api/bookings dùng DTO validation, @Transactional, findAvailableRoom() rồi lưu booking. Hai requests cùng room/date đều trả 201. Hãy nói tại sao, đề xuất hai phương án bảo vệ, và một integration test chứng minh không overbook.

C4. English (5 phút)

Trả lời mỗi câu trong 30–45 giây, không nhìn script:

• Why would you use constructor injection?
• How does your service prevent two users from buying the last item?
• What would happen if the external provider timed out after receiving a request?

Chuẩn: nói đúng ý, ít nhất 1 reason hoặc test, thừa nhận giới hạn khi không có provider status/idempotency. Sau đó ghi 3 lỗi vào error log của tài liệu gốc.

C5. Quy tắc chuyển bài

• Đạt: C1 code đúng + có tests; C2 đúng; C3 phân biệt transaction với concurrency; C4 giao tiếp hiểu được và không trả lời sai bản chất. Chuyển sang project deep dive/mocks, chỉ ôn lỗi.
• Chưa đạt: lỗi Java → 08A; lỗi bean/JPA/transaction → 08B; lỗi SQL → Mô-đun 04; lỗi English → 02/11/LAB D. Không phải đọc lại cả 3.000 dòng.
• JD DSA-heavy: LAB này không thay LeetCode Medium; duy trì vài pattern, tăng cường khi có lịch OA.

🎙️ SPEAKING LAB V5.2 — 08C. Java + SQL + English integrated case

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: Read code → explain bug → implement/query → defend design → follow-up.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Hoàn thành ít nhất một bài COMPLETE/DO ở phía trên (hoặc giải thích một ví dụ mới). Nếu chưa giải thích được cơ chế bằng tiếng Việt, quay lại bài kỹ thuật trước khi bắt đầu nói.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. The current implementation can fail when two requests update the same inventory record.
2. I would protect the invariant in the database and verify it with a concurrent test.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

The current code . This can fail when . I would change ___ and test ___.

4. FREE SPEAK — định nghĩa / cơ chế (không nhìn script)

Chọn 3–5 câu/lượt trong 5 câu sau. Đáp án được thu gọn dưới từng câu; chỉ mở sau khi đã nói.

Q152 · MECHANISM / WHY · BASE V4

TTS 303 · Q: Explain the main bug you found in the LAB 08C code.

Q153 · FOUNDATION · BASE V4

TTS 305 · Q: What SQL query or constraint would support your fix?

Q154 · FOUNDATION · BASE V4

TTS 307 · Q: Which part of your fix is guaranteed by a database transaction, and which part is not?

Q155 · MECHANISM / WHY · ADD V5

TTS 309 · Q: How do you explain a concurrent inventory bug in one minute?

Q156 · FOUNDATION · ADD V5

TTS 311 · Q: What should a database integration test assert after two simultaneous bookings?

5. UNEXPECTED FOLLOW-UP — thay giả định và suy luận

Chọn ít nhất một câu dưới đây, tự trả lời trước; sau đó yêu cầu người luyện thay một điều kiện mới.

Q157 · SCENARIO / FOLLOW-UP · BASE V4

TTS 313 · Q: How would you explain the solution to a teammate in under one minute?

Q158 · SCENARIO / FOLLOW-UP · BASE V4

TTS 315 · Q: What happens if a retry arrives with the same operation ID?

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: bug 20–30 giây; L2: 60–90 giây evidence → root cause → fix → test.
• Điều kiện qua bài: Giải được case độc lập; câu trả lời nói tương ứng code/query thực sự đã kiểm tra.
• Điểm dễ nói sai / hiểu sai: Không chỉ nói “I fixed the bug”; phải nêu cách tái hiện, giới hạn và test.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

🎙️ CASE LAB V5.2 — V-Market (11 cặp Q&A)

Nguồn: PROJECT_DEEP_DIVE_PREP(4).md; snapshot commit được mô tả: ff9fde3. Chưa kiểm chứng repo độc lập; không tự nhận đã triển khai hoặc chạy test khi chưa làm.

Mục tiêu kiến thức: Stock-safe checkout, idempotency, JDBC/PostgreSQL, Redis metadata và legacy CSV.

WATCH → DO (đọc code/test thực tế): OrderController → OrderService.create → integration tests; CSV: LegacyImportService/ImportChunkService.

LISTEN → SHADOW: V-Market is a Java and Spring Boot commerce project with a product catalog, guest checkout, and CSV imports. (2 lượt), rồi giải thích lại flow mà không nhìn script.

FREE SPEAK — P0 (ưu tiên, 4–6 câu mỗi buổi)

Q159 · P0 · PROJECT-SPECIFIC V5.1

TTS 317 · Q: What problem does V-Market solve?

Q160 · P0 · PROJECT-SPECIFIC V5.1

TTS 319 · Q: Walk me through a V-Market checkout request.

Q161 · P0 · PROJECT-SPECIFIC V5.1

TTS 321 · Q: Two customers each buy twenty items when only twenty-seven are in stock. What happens?

Q162 · P0 · PROJECT-SPECIFIC V5.1

TTS 323 · Q: Why does V-Market need both an operation-key lock and stock locks?

Q163 · P0 · PROJECT-SPECIFIC V5.1

TTS 325 · Q: How does V-Market handle a repeated checkout with the same key?

Q164 · P0 · PROJECT-SPECIFIC V5.1

TTS 327 · Q: The client times out after checkout. Should it create a new request key?

Q165 · P0 · PROJECT-SPECIFIC V5.1

TTS 329 · Q: Why does V-Market use Redis, and can the cache cause overselling?

Q166 · P0 · PROJECT-SPECIFIC V5.1

TTS 331 · Q: What happens if a database error occurs while creating an order?

Q167 · P0 · PROJECT-SPECIFIC V5.1

TTS 333 · Q: What evidence and limitations can you discuss for V-Market?

FOLLOW-UP — P1 (chỉ học sâu sau P0)

Q168 · P1 · PROJECT-SPECIFIC V5.1

TTS 335 · Q: How does V-Market validate Japanese legacy CSV imports?

Q169 · P1 · PROJECT-SPECIFIC V5.1

TTS 337 · Q: Why can't an old CSV stock snapshot restore inventory that has already been sold?

UNEXPECTED FOLLOW-UP: Giả định client mất response sau khi server đã commit. Giải thích vì sao không tạo operation key mới và cách kiểm tra kết quả.

SELF-CHECK: có nêu một invariant, một failure, một test và một giới hạn thật? Chỉ nói I implemented hoặc I ran với phần mình đã xác minh từ công việc cá nhân.

🎙️ CASE LAB V5.2 — V-Core (11 cặp Q&A)

Nguồn: PROJECT_DEEP_DIVE_PREP(3).md; snapshot commit được mô tả: aff7e93. Chưa kiểm chứng repo độc lập; không tự nhận đã triển khai hoặc chạy test khi chưa làm.

Mục tiêu kiến thức: Kanban WIP limit, task version, quyền workspace và SSE refresh.

WATCH → DO (đọc code/test thực tế): TaskController → TaskMoveService.move → WorkflowColumnRepository/TaskEntity → integration tests.

LISTEN → SHADOW: V-Core is a Kanban collaboration project using Java, Spring Boot, PostgreSQL, and a React frontend. (2 lượt), rồi giải thích lại flow mà không nhìn script.

FREE SPEAK — P0 (ưu tiên, 4–6 câu mỗi buổi)

Q170 · P0 · PROJECT-SPECIFIC V5.1

TTS 339 · Q: What problem does V-Core solve?

Q171 · P0 · PROJECT-SPECIFIC V5.1

TTS 341 · Q: Walk me through a task move in V-Core.

Q172 · P0 · PROJECT-SPECIFIC V5.1

TTS 343 · Q: Why does V-Core use both a column lock and a task version?

Q173 · P0 · PROJECT-SPECIFIC V5.1

TTS 345 · Q: Two users move tasks into the last free slot. How does V-Core prevent overflow?

Q174 · P0 · PROJECT-SPECIFIC V5.1

TTS 347 · Q: What does V-Core do when the same task move request is retried?

Q175 · P0 · PROJECT-SPECIFIC V5.1

TTS 349 · Q: What does the task-move transaction guarantee, and what does it not guarantee?

Q176 · P0 · PROJECT-SPECIFIC V5.1

TTS 351 · Q: How does V-Core prevent a user from changing tasks in another workspace?

Q177 · P0 · PROJECT-SPECIFIC V5.1

TTS 353 · Q: How would you verify V-Core's WIP concurrency rule?

FOLLOW-UP — P1 (chỉ học sâu sau P0)

Q178 · P1 · PROJECT-SPECIFIC V5.1

TTS 355 · Q: What is the purpose of SSE in V-Core, and is delivery guaranteed?

Q179 · P1 · PROJECT-SPECIFIC V5.1

TTS 357 · Q: What happens to an existing SSE stream when a user's access is revoked?

Q180 · P1 · PROJECT-SPECIFIC V5.1

TTS 359 · Q: Can an administrator lower a WIP limit below the current task count?

UNEXPECTED FOLLOW-UP: Giả định hai task cùng tranh slot cuối trong cột. Phân biệt column lock với task version và nêu một test.

SELF-CHECK: có nêu một invariant, một failure, một test và một giới hạn thật? Chỉ nói I implemented hoặc I ran với phần mình đã xác minh từ công việc cá nhân.

MÔ-ĐUN 09 [CORE] — Basic System Design: từ 1 server đến một hệ thống đủ tin cậy

09.1. System Design không đồng nghĩa “thiết kế YouTube/Netflix”

Đối với bài cơ bản, interviewer có thể chỉ muốn biết API nào, lưu dữ liệu ở đâu, luồng hoạt động và khi service ngoài lỗi thì sao. Đừng nhảy sang Kafka + Kubernetes + microservices khi bài toán chưa cần.

09.2. Level 1 — khởi đầu bằng cấu trúc tối giản

[Browser] ──HTTPS──> [Spring Boot App] ──SQL──> [PostgreSQL]

Ưu điểm: dễ xây, debug, deploy; transaction nội bộ rõ. Nhược: một app instance có thể là single point of failure; DB có thể thành bottleneck. Đây thường là thiết kế xuất phát tốt, không phải thiết kế sai.

Framework 5 bước cần thuộc: 1. Requirements: functions, users, traffic, availability/security constraints. 2. APIs + Data: endpoints, objects/tables, invariants. 3. Components + Flow: ai gọi ai, source of truth. 4. Failures + Bottlenecks: timeout, duplicate, consistency, scaling. 5. Trade-offs + Tests: vì sao chọn và cách chứng minh.

09.3. Level 2 — khi nhiều người đọc availability

          ┌──> [Redis cache] (optional, derived data)
[App] ────┤
          └──> [PostgreSQL] (source of truth)

Vì sao cache? Giảm truy vấn lặp cho dữ liệu đọc nhiều.
Tại sao cache nguy hiểm? Có thể stale; không tin cache là authority duy nhất khi xác nhận đặt phòng.

• Cache hit / miss: đọc được / không có key.
• TTL: dữ liệu tồn tại trong cache bao lâu.
• Invalidation: xóa/cập nhật cache khi source data thay đổi.

Answer: I might cache read-heavy availability summaries with a short TTL, but the final booking decision must be validated against the authoritative inventory store.

09.4. Level 3 — external service bị chậm / lỗi

[Client] → [Backend] → [Third-party room provider]
                 ↓              × timeout
               logs / pending state / safe retry / reconciliation

Có thể làm gì? - Đặt timeout để request không treo vô hạn. - Phân loại lỗi tạm thời / lỗi business / lỗi không retry. - Retry với backoff nếu operation safe hoặc idempotency mechanism đã được xác nhận. - Có trạng thái PENDING_CONFIRMATION nếu chưa biết kết quả thực tế. - Log correlation ID, request ID để truy vết. - Reconciliation: đối soát lại sau lỗi để không tạo booking ảo/nhân đôi.

Không hứa chính xác-once chỉ vì đã bật retry.

09.5. Level 4 — scale và background work

                 ┌─ [App instance 1] ─┐
[Load balancer] ──┤                    ├── [Database]
                 └─ [App instance 2] ─┘
                              │
                              └─[Queue]→[Worker]→ email / report

• Horizontal scale: nhiều app instances; cần stateless app hoặc quản lý session phù hợp, shared DB/cache.
• Queue: các công việc không cần trả kết quả ngay (ví dụ gửi email), nhưng introduces retry, duplicates và eventual delivery.
• Monolith vs microservices: một ứng dụng dễ thay đổi/transaction nội bộ, so với triển khai từng service độc lập nhưng vận hành/giao tiếp phức tạp.

09.6. Bảng ra quyết định 8 trade-offs phổ biến

Nhớ: không có đáp án “luôn luôn chọn X”. Đáp án tốt là theo yêu cầu và có lý do.

09.7. Một bài worked example đầy đủ (ngắn)

Đề: Design a URL shortener for a small internal team.

1. Clarify: custom alias? expiration? internal only? anticipated traffic?
2. API: POST /links → short code; GET /{code} → redirect.
3. DB: Link(code UNIQUE, originalUrl, createdAt, expiresAt, ownerId).
4. Flow: create validates URL + uniqueness; redirect looks up code and returns redirect response.
5. Failure: collision in generated code → generate another; expired link → appropriate response; abuse prevention.
6. Scaling: start with single app + relational DB; add cache for very frequent redirects if measurements justify it.

Mẫu tiếng Anh:

I'd start by clarifying traffic and expiration requirements. For the MVP, I'd use a Spring Boot service and a relational database with a unique short code. Redirect requests look up the code and return a redirect. If read traffic increases, I'd consider caching popular mappings, while keeping the database as the source of truth.

09.8. Tự làm — không có sẵn một đáp án duy nhất

Đề: Design a task management API for a team of 20 users. The app must support create/update tasks and an activity log.

Viết tối đa 10–12 dòng cho: requirements, entities, APIs, components, one failure case, one trade-off. Đừng giải thích Kubernetes/queues trước khi chỉ ra lý do cần.

🎙️ SPEAKING LAB V5.2 — 09. Basic System Design

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: MVP monolith; database authority; caching; queue; failure/timeouts; scaling and trade-offs.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Hoàn thành ít nhất một bài COMPLETE/DO ở phía trên (hoặc giải thích một ví dụ mới). Nếu chưa giải thích được cơ chế bằng tiếng Việt, quay lại bài kỹ thuật trước khi bắt đầu nói.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. I would start with one backend service and a relational database for the MVP.
2. Caching can reduce read load, but stale data must not break booking correctness.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

For the MVP, I would use . If ___ becomes a bottleneck, I would . The trade-off is ___.

4. FREE SPEAK — định nghĩa / cơ chế (không nhìn script)

Chọn 3–5 câu/lượt trong 4 câu sau. Đáp án được thu gọn dưới từng câu; chỉ mở sau khi đã nói.

Q181 · FOUNDATION · BASE V4

TTS 361 · Q: Design a simple booking service for an MVP.

Q182 · MECHANISM / WHY · BASE V4

TTS 363 · Q: When might you add Redis caching, and what should not rely on a stale cache?

Q183 · FOUNDATION · ADD V5

TTS 365 · Q: What is a load balancer?

Q184 · FOUNDATION · ADD V5

TTS 367 · Q: What is eventual consistency?

5. UNEXPECTED FOLLOW-UP — thay giả định và suy luận

Chọn ít nhất một câu dưới đây, tự trả lời trước; sau đó yêu cầu người luyện thay một điều kiện mới.

Q185 · SCENARIO / FOLLOW-UP · BASE V4

TTS 369 · Q: Why would you choose a modular monolith before microservices?

Q186 · SCENARIO / FOLLOW-UP · BASE V4

TTS 371 · Q: What changes if an external provider is frequently slow?

Q187 · SCENARIO / FOLLOW-UP · BASE V4

TTS 373 · Q: How would you measure whether scaling actually helped?

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: 30 giây kiến trúc tối thiểu; L2: 90 giây gồm 1 bottleneck và 1 trade-off.
• Điều kiện qua bài: Có assumption, component flow, consistency owner, ít nhất 2 failure paths và cách đo/test.
• Điểm dễ nói sai / hiểu sai: Không thêm microservices/Redis/Kafka chỉ để thể hiện biết công nghệ; phải có nhu cầu.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

LAB B [CORE] — Debugging + API Integration: từ triệu chứng đến nguyên nhân

Tại sao có LAB này? Java Backend và FDE đều có thể yêu cầu bạn xử lý một lỗi lạ, đọc API/data hiện có và đưa ra cách kiểm chứng — không phải chỉ nêu tên design pattern.

B1. Quy trình 6 bước (dùng cho mọi lỗi)

Symptom → Reproduce → Locate boundary → Hypotheses → Evidence → Fix & regression test.

Tránh lỗi thường gặp: timeout ở browser không chứng minh database rollback; response 500 không chứng minh bên thứ ba chưa thực hiện side effect.

B2. WATCH — đơn đặt hàng trả 504 nhưng DB đã có order

• User gửi POST /orders với Idempotency-Key: K1.
• Backend tạo order và commit DB; response bị rớt trên đường về.
• Browser nhận 504 và người dùng bấm “Pay/Order” lại.

Phân tích: 504 nói gateway/upstream đã chờ quá lâu. Cần query tình trạng operation theo key/order ID trước khi tạo lại. Nếu retry cùng operation, client phải giữ K1. Backend phải có dedup durable, và tốt hơn là kiểm tra payload hash; concurrent duplicates cần có chiến lược xử lý rõ. Không chỉ thêm @Transactional là đủ.

English (45s): A timeout does not prove that the operation failed. I would check the order status using a stable request ID or idempotency key. If the client retries the same operation, the backend must avoid creating a second order. I'd test a timeout after commit and concurrent retries.

B3. COMPLETE — triệu chứng khác nhau, xử lý khác nhau

B4. DO — API/data integration (10 phút)

An external vendor sends a CSV file every morning. Some rows are duplicated, some product names have garbled Japanese characters, and a few quantities are negative.

Không chọn tech ngay. Tự viết:

1. 5 câu hỏi làm rõ (định dạng, encoding, business key, tần suất, cách xử lý sai).
2. Pipeline 5 bước từ raw file tới DB.
3. Một quy tắc dedup cấp file và một quy tắc dedup cấp row, vì hai thứ khác nhau.
4. Một chiến lược xử lý lỗi: reject cả file hay partial success? Điều kiện nào quyết định?
5. 4 tests kể cả replay/crash.

B5. Liên hệ đúng với V-Market (đọc sau khi hiểu B4)

Trong tài liệu phân tích project V-Market do bạn cung cấp, flow importer được mô tả dùng staged rows, checksum, Windows-31J, tasklet và các nhóm ghi REQUIRES_NEW. Tài liệu cũng cảnh báo: API hiện tại chưa có workflow restart đầy đủ, dù dữ liệu tiến độ đã lưu, và reconciliation phát hiện chênh lệch nhưng không tự chứng minh chênh lệch là lỗi. Đây là điều tài liệu phân tích code mô tả, không phải test tôi vừa chạy lại.

Câu FDE gợi ý: The client wants to import inventory without stopping sales. What would you ask before making changes? → hỏi feed là snapshot/delta, cutoff time, update stock ghi đè sale hợp lệ hay không, quyền operator, tiêu chí đối soát.

Qua LAB B nếu: Bạn không còn trả lời “cứ retry”, “cứ thêm Redis” khi chưa xác định root cause, có thể nêu evidence và một regression test.

🎙️ SPEAKING LAB V5.2 — B. Debugging và external integration

Thứ tự sử dụng: PRETEST → WATCH & DO ngay trong phần kiến thức phía trên → LISTEN/SHADOW → FREE SPEAK → FOLLOW-UP → feedback. Không mở đáp án trước lượt nói đầu.

Những ý kỹ thuật phải hiểu trước khi nói: Symptom → evidence → reproduce → hypothesis → fix → verify; external timeout; duplicate imports.

Từ đơn → cụm nói được (chỉ chọn 3–5 cụm để ôn hôm nay):

1. PRETEST + WATCH + DO

Hoàn thành ít nhất một bài COMPLETE/DO ở phía trên (hoặc giải thích một ví dụ mới). Nếu chưa giải thích được cơ chế bằng tiếng Việt, quay lại bài kỹ thuật trước khi bắt đầu nói.

2. LISTEN → SHADOW

A — LISTEN & SHADOW (3–4 phút): Ẩn chữ; dùng TTS/Voice đọc lần lượt các câu sau. Lượt 1 nghe và tóm tắt ý; lượt 2–3 bắt chước nhịp nói, rồi nói lại không nhìn.

1. A gateway timeout does not prove that the database operation was rolled back.
2. I would correlate request IDs, database records, and downstream logs.

3. COMPLETE ORALLY

B — COMPLETE ORALLY (1–2 phút): Điền bằng giọng nói, không cần viết câu hoàn chỉnh trước.

The symptom is . My first hypothesis is . I would check ___ before changing ___.

4. FREE SPEAK — định nghĩa / cơ chế (không nhìn script)

Chọn 3–5 câu/lượt trong 1 câu sau. Đáp án được thu gọn dưới từng câu; chỉ mở sau khi đã nói.

Q188 · FOUNDATION · BASE V4

TTS 375 · Q: Which evidence would tell you that a retry is safe?

5. UNEXPECTED FOLLOW-UP — thay giả định và suy luận

Chọn ít nhất một câu dưới đây, tự trả lời trước; sau đó yêu cầu người luyện thay một điều kiện mới.

Q189 · SCENARIO / FOLLOW-UP · BASE V4

TTS 377 · Q: An API returns 504, but an order exists in the database. What do you do first?

Q190 · SCENARIO / FOLLOW-UP · BASE V4

TTS 379 · Q: How would you investigate duplicate product imports?

Q191 · SCENARIO / FOLLOW-UP · BASE V4

TTS 381 · Q: What if logs show the same request ID twice?

Q192 · SCENARIO / FOLLOW-UP · BASE V4

TTS 383 · Q: How would you design a regression test for the root cause?

Q193 · SCENARIO / FOLLOW-UP · ADD V5

TTS 385 · Q: How would you trace an HTTP request across multiple services?

Q194 · SCENARIO / FOLLOW-UP · ADD V5

TTS 387 · Q: What would you do if an external API returned an unfamiliar error?

Q195 · SCENARIO / FOLLOW-UP · ADD V5

TTS 389 · Q: How would you prevent duplicate records during a CSV import?

6. REPEAT + FEEDBACK — checkpoint

E — REPEAT + FEEDBACK: Chọn câu khó nhất ở phần FREE SPEAK, nói 3 lượt (45–60 giây → 30–45 giây → 20–30 giây ở L1; tăng thời lượng ở L2), giữ ý chính và một test/example. Mở câu trả lời ngay dưới câu hỏi sau lượt 1; mỗi lượt chỉ sửa tối đa 2 lỗi.

• Thời lượng mục tiêu: L1: mô tả symptom + evidence; L2: 90 giây giả thuyết → kiểm chứng → fix → test.
• Điều kiện qua bài: Không đoán nguyên nhân khi chưa có bằng chứng; không xóa dữ liệu hoặc retry mù.
• Điểm dễ nói sai / hiểu sai: Không hứa “adding a queue will fix it” trước khi biết bottleneck/bug.

Mẫu trả lời dài V4 (tùy chọn; xem sau khi tự nói)

🎙️ CASE LAB V5.2 — V-Pulse (11 cặp Q&A)

Nguồn: PROJECT_DEEP_DIVE_PREP(5).md; snapshot commit được mô tả: 08e6a01. Chưa kiểm chứng repo độc lập; không tự nhận đã triển khai hoặc chạy test khi chưa làm.

Mục tiêu kiến thức: Payment-reliability demo với simulated rails, timeout, retry safety và recovery.

WATCH → DO (đọc code/test thực tế): PaymentController → PaymentService.create/process → RailGateway → integration tests.

LISTEN → SHADOW: V-Pulse is a payment-reliability demo built with Java, Spring Boot, PostgreSQL, Redis, and React. (2 lượt), rồi giải thích lại flow mà không nhìn script.

FREE SPEAK — P0 (ưu tiên, 4–6 câu mỗi buổi)

Q196 · P0 · PROJECT-SPECIFIC V5.1

TTS 391 · Q: What is V-Pulse, and does it connect to real banks?

Q197 · P0 · PROJECT-SPECIFIC V5.1