Tự giới thiệu & kể về project

Câu này không phải để kể tiểu sử. Người phỏng vấn muốn biết trong 1–2 phút: bạn là ai, làm được gì, và vì sao hợp vị trí này. Nó cũng là lúc bạn chọn chủ đề cho phần sau: cái gì bạn nhắc đến, họ sẽ hỏi tiếp vào đó.

1. Bài toán

Bạn ứng tuyển Java Backend Developer. Bạn có 3 năm kinh nghiệm, làm một hệ thống bán vé (giống project Ticket Booking) dùng Spring Boot, PostgreSQL, Kafka, Redis.

2. Vấn đề với cách hay gặp

• Đọc lại CV từ năm tốt nghiệp: dài, không có điểm nhấn.
• Liệt kê 20 công nghệ: nghe như danh sách từ khóa, không biết bạn giỏi gì.
• Nói chung chung ("mình chăm chỉ, ham học hỏi"): không kiểm chứng được.
• Quá 3 phút: người nghe mất tập trung.

3. Khung 4 phần (1–2 phút)

1. Hiện tại      → vai trò, số năm, domain           (~15 giây)
2. Điểm nổi bật  → 1–2 việc lớn nhất, CÓ SỐ LIỆU      (~45 giây)
3. Thế mạnh      → 2–3 kỹ năng gắn với vị trí này      (~20 giây)
4. Vì sao ở đây  → điều bạn tìm ở công ty/vị trí này   (~15 giây)

4. Mẫu

🇻🇳 Tiếng Việt:

Em là Java backend developer, 3 năm kinh nghiệm, chủ yếu làm hệ thống thương mại điện tử và bán vé. Hiện tại em ở team Booking, hệ thống gồm 6 service Spring Boot, PostgreSQL, Kafka và Redis, chạy trên Kubernetes. Việc em tự hào nhất là xử lý bài toán bán trùng ghế khi mở bán: em đổi cách giữ ghế sang update có điều kiện trong DB kèm TTL, thêm idempotency key cho thanh toán, nên từ vài chục ca trùng mỗi đợt về 0, p99 API đặt vé giảm từ 1,2 giây xuống 300 ms. Em mạnh về Spring, thiết kế database và debug production. Em ứng tuyển vị trí này vì bên mình đang xây hệ thống thanh toán có tải lớn, đúng hướng em muốn đi sâu.

🇬🇧 English:

I'm a Java backend developer with three years of experience, mostly in e-commerce and ticketing. I'm currently on the Booking team; our system has six Spring Boot services with PostgreSQL, Kafka and Redis, running on Kubernetes. The work I'm proudest of is fixing double booking during sales launches: I moved seat holds to a conditional update in the database with a TTL and added idempotency keys to payments. Double bookings went from dozens per launch to zero, and p99 latency of the booking API dropped from 1.2 seconds to 300 milliseconds. My strengths are Spring, database design and production debugging. I applied because your team is building a high-traffic payment platform, which is exactly where I want to grow.

5. Mẹo

Dùng khung 5 bước. Mỗi bước 2–3 câu, tổng 3–4 phút. Vẽ sơ đồ nếu có bảng trắng.

1. Context      → sản phẩm gì, cho ai, quy mô (user, QPS, dữ liệu)
2. Architecture → các thành phần chính và luồng chính
3. Your role    → BẠN làm gì (không phải "team em")
4. Hard problem → một vấn đề khó: triệu chứng → nguyên nhân → giải pháp → trade-off
5. Result       → con số trước/sau + bài học

Mẫu: Ticket Booking

1. Context. Hệ thống bán vé concert. Bình thường 50 request/giây, lúc mở bán lên 5.000 request/giây trong 10 phút đầu. Mỗi show khoảng 20.000 ghế.

2. Architecture.

Client → Gateway → Booking Service ──► PostgreSQL (seat, booking)
                        │      └──► Redis (giữ chỗ, rate limit)
                        ▼ outbox
                      Kafka → Payment Service → Notification Service

3. Your role. Em phụ trách Booking Service: API giữ ghế, xác nhận, hủy; thiết kế bảng seat_hold; viết outbox publisher.

4. Hard problem. Đợt mở bán đầu tiên có 37 ghế bị bán cho hai người. Nguyên nhân: code đọc trạng thái ghế rồi mới ghi (check-then-act), hai request chen giữa. Em đổi sang UPDATE seat SET status='HELD' WHERE id=? AND status='AVAILABLE', kiểm tra số row bị ảnh hưởng, thêm unique constraint trên (show_id, seat_id) của booking. Trade-off: request thua nhận lỗi 409 ngay, không xếp hàng.

5. Result. 0 ca trùng ghế trong 4 đợt mở bán tiếp theo. p99 đặt vé từ 1,2 s xuống 300 ms vì bỏ được distributed lock. Bài học: tính đúng đắn đặt ở DB, Redis chỉ để giảm tải.

Chi tiết thiết kế xem bài 15.10 Ticket Booking và project Final Project.

Đúng rồi, mấy câu này gần như luôn có. Chuẩn bị trước cho project chính của bạn:

Với câu "nếu làm lại", đừng nói "em không đổi gì". Nghe như bạn không học được gì.

Nên luôn có 2–3 câu. Nói "không" làm bạn trông ít quan tâm.

Câu nên hỏi

• Team đang gặp vấn đề kỹ thuật lớn nhất là gì?
• Một ngày làm việc của vị trí này trông thế nào? Deploy bao lâu một lần?
• Team review code, on-call, xử lý sự cố ra sao?
• Sau 3–6 tháng, người ở vị trí này được kỳ vọng làm được gì?

Hỏi lương, nghỉ phép thì để vòng HR.

Lỗi nên tránh

• Nói "team em" suốt, không rõ bạn làm gì. Dùng "em".
• Nhận làm thứ mình không làm. Một câu follow-up là lộ.
• Chê công ty cũ hoặc đồng nghiệp.
• Không có con số nào.
• Bị hỏi điều không biết thì đoán bừa. Nên nói: "Em chưa làm, nhưng em hiểu là… và em sẽ kiểm tra bằng…".

Q1. Giới thiệu về bản thân.

🇻🇳 Tiếng Việt:

Em là Java backend developer, 3 năm kinh nghiệm với Spring Boot, PostgreSQL và Kafka, hiện làm hệ thống bán vé. Em phụ trách Booking Service và đã đưa số ca bán trùng ghế về 0, giảm p99 từ 1,2 giây xuống 300 ms. Em mạnh về thiết kế database và debug production, và muốn phát triển tiếp ở hệ thống tải lớn như của bên mình.

🇬🇧 English:

I'm a Java backend developer with three years of experience in Spring Boot, PostgreSQL and Kafka, currently working on a ticketing platform. I own the Booking Service; I brought double bookings down to zero and cut p99 latency from 1.2 seconds to 300 milliseconds. I'm strong in database design and production debugging, and I want to keep growing on high-traffic systems like yours.

Q2. Vấn đề khó nhất bạn từng giải quyết?

🇻🇳 Tiếng Việt:

Đợt mở bán đầu tiên có 37 ghế bị bán cho hai người. Em xem log và thấy hai request cùng đọc ghế trống rồi cùng ghi, tức là race condition kiểu check-then-act. Em đổi sang một câu UPDATE có điều kiện trạng thái và thêm unique constraint, request thua nhận 409. Sau 4 đợt mở bán không còn ca trùng nào, và vì bỏ được distributed lock nên p99 giảm còn 300 ms. Bài học của em là đặt tính đúng đắn ở database.

🇬🇧 English:

During our first sales launch, 37 seats were sold twice. From the logs I saw two requests reading the seat as available and both writing it, a check-then-act race condition. I replaced it with a single conditional UPDATE plus a unique constraint, so the losing request gets a 409. Across the next four launches we had zero double bookings, and removing the distributed lock cut p99 to 300 milliseconds. My takeaway was to enforce correctness in the database.

Cách nhớ ngắn gọn

• Giới thiệu: hiện tại → điểm nổi bật có số → thế mạnh → vì sao ở đây, 90 giây.
• Project: context → architecture → role → hard problem → result.
• Luôn nói "em làm", luôn có con số.
• Chuẩn bị sẵn "khó nhất" và "nếu làm lại".
• Cuối buổi hỏi lại 2–3 câu về team và công việc.