Chương 13. Kể chuyện dự án, Behavioral và vòng HR

Tôi đã loại không ít ứng viên trả lời kỹ thuật ổn nhưng không kể nổi dự án của chính mình trong 5 phút. Ở mức 2–4 năm, người phỏng vấn không chỉ tuyển một người biết Spring Boot, mà tuyển một người sẽ nhận task, trao đổi với BA, xử lý sự cố lúc 11 giờ đêm và không làm team mệt mỏi. Phần kể chuyện dự án và behavioral là nơi họ kiểm chứng điều đó, còn vòng HR là nơi bạn có thể mất vài triệu mỗi tháng chỉ vì một câu trả lời vội.

Người phỏng vấn muốn kiểm tra

• Bạn hiểu dự án ở mức nghiệp vụ và kiến trúc, không chỉ ở mức "em làm API"
• Bạn tách bạch được phần mình làm và phần của team, có con số đo được
• Bạn xử lý sự cố, bất đồng và áp lực thế nào (qua câu chuyện có thật, không phải lý thuyết)
• Mọi dòng trong CV đều có thể đào sâu mà bạn không lúng túng
• Bạn biết giá trị của mình trên thị trường và thương lượng một cách chuyên nghiệp

13.1 Vì sao ứng viên 2–4 năm trượt ở phần này

Những lý do tôi gặp lặp đi lặp lại trong phiếu đánh giá:

• Kể dự án như đọc lại CV: liệt kê công nghệ, không có bối cảnh nghiệp vụ, không nói được hệ thống giải quyết vấn đề gì cho ai.
• Chỉ dùng "chúng em": "chúng em dùng Kafka, chúng em làm microservice". Người phỏng vấn không biết bạn đóng góp gì, và thường mặc định là bạn đóng góp ít.
• Không có con số: "hệ thống chạy nhanh hơn nhiều". Nhanh hơn bao nhiêu, đo bằng gì, trước và sau là bao nhiêu?
• CV ghi thứ không trả lời được: ghi Kafka, Kubernetes, Elasticsearch nhưng hỏi hai câu là lộ ra chỉ từng đọc qua. Một dòng như vậy làm giảm lòng tin vào toàn bộ CV.
• Tiêu cực về công ty cũ: chê sếp, chê dự án, chê đồng nghiệp. Người nghe sẽ nghĩ sáu tháng nữa bạn cũng nói về họ như vậy.
• Không chuẩn bị câu hỏi ngược và deal lương lộn xộn: nói một con số rồi tự hạ xuống ngay khi HR im lặng.

Tin tốt là tất cả những lỗi này đều sửa được bằng chuẩn bị, không cần năng khiếu ăn nói.

13.2 Giới thiệu bản thân trong 60–90 giây

Câu "Em giới thiệu về bản thân đi" gần như luôn mở đầu buổi phỏng vấn. Đây là 90 giây bạn kiểm soát hoàn toàn nội dung, nên hãy dùng nó để dẫn người phỏng vấn tới những chủ đề bạn mạnh nhất.

Khung 4 phần tôi khuyên dùng:

1. Hiện tại: vai trò, số năm kinh nghiệm, lĩnh vực và stack chính.
2. Điểm nhấn: 1–2 dự án hoặc thành tựu nổi bật, có con số.
3. Điểm mạnh riêng: thứ làm bạn khác một backend dev bình thường (xử lý sự cố, tối ưu database, làm việc trực tiếp với khách hàng...).
4. Lý do ứng tuyển: vì sao vị trí này là bước tiếp theo hợp lý.

Ví dụ mẫu của một backend developer 3 năm kinh nghiệm (tên công ty và dự án là giả định):

"Em là backend developer với 3 năm kinh nghiệm Java và Spring Boot, hiện đang làm ở một công ty fintech, phụ trách nhóm service thanh toán của một ví điện tử khoảng 2 triệu người dùng. Trước đó em làm 1 năm rưỡi cho một nền tảng thương mại điện tử, chủ yếu ở phần đơn hàng và tồn kho. Việc em tự hào nhất gần đây là thiết kế lại luồng xác nhận giao dịch với cổng thanh toán đối tác: bổ sung idempotency key và cơ chế đối soát tự động, giúp giảm các ca giao dịch treo cần xử lý tay từ khoảng 40 ca mỗi tuần xuống dưới 5. Em cũng thường là người được gọi khi có sự cố hiệu năng ở database, vì em khá quen với việc đọc execution plan và tối ưu query trên PostgreSQL. Em ứng tuyển vị trí này vì muốn làm sâu hơn về hệ thống phân tán và có cơ hội tham gia thiết kế từ đầu, điều mà JD của anh chị nhắc tới ở dự án core banking mới."

Đoạn trên nói chậm rãi mất chừng 75–80 giây. Để ý rằng nó cài sẵn ba "móc câu": idempotency, đối soát, tối ưu PostgreSQL. Người phỏng vấn gần như chắc chắn sẽ hỏi tiếp vào một trong ba chủ đề đó, và đó chính là chỗ bạn đã chuẩn bị kỹ.

Bẫy thường gặp

Kể lan man từ thời đại học và điểm GPA, đọc thuộc lòng như văn mẫu, hoặc kéo dài 5 phút. Cũng đừng cài "móc câu" vào thứ bạn không nắm chắc: nhắc tới Kafka trong phần giới thiệu nghĩa là bạn mời người phỏng vấn hỏi về consumer group, offset và rebalancing.

13.3 Trình bày dự án: từ nghiệp vụ tới con số

Khi tôi nói "Em kể về dự án gần nhất", tôi muốn nghe theo thứ tự sau. Mỗi phần vài câu, tổng cộng 3–5 phút, sau đó dừng lại để tôi hỏi.

Bước	Trả lời câu hỏi	Ví dụ ngắn
Bối cảnh nghiệp vụ	Hệ thống phục vụ ai, giải quyết gì, quy mô?	Sàn TMĐT, 50 nghìn đơn/ngày, cao điểm gấp 10
Kiến trúc	Gồm những khối nào, giao tiếp ra sao?	8 service Spring Boot, REST + Kafka, PostgreSQL, Redis
Phần bạn làm	Bạn sở hữu module nào, quyết định gì?	Service đơn hàng và luồng hoàn tiền
Vấn đề khó	Khó ở đâu, bạn đã cân nhắc những phương án nào?	Trừ tồn kho khi flash sale bị bán vượt
Kết quả	Con số trước và sau, bài học	Bán vượt từ vài chục đơn mỗi đợt về 0

Hãy chuẩn bị sẵn một sơ đồ kiến trúc mà bạn vẽ được trong 2 phút trên giấy hoặc bảng trắng. Không cần đẹp, cần đúng luồng dữ liệu chính và chỉ rõ phần của bạn. Ví dụ dưới đây là sơ đồ dạng chữ cho dự án thương mại điện tử giả định ở trên.

Mobile/Web -> API Gateway -> Order Service (phần em làm) -> PostgreSQL
                                  |                      -> Redis (khóa tồn kho)
                                  v  (phát event, bất đồng bộ)
                            Kafka: order-events
                             |               |
                   Payment Service     Notification Service

Giải thích: đọc sơ đồ từ trái sang phải: request đặt hàng đi đồng bộ từ app qua API Gateway vào Order Service; Order Service ghi đơn vào PostgreSQL, dùng Redis để khóa tồn kho, rồi phát event lên topic order-events. Payment Service và Notification Service đọc event đó một cách bất đồng bộ, nên Notification Service chết thì đơn vẫn tạo được, thông báo chỉ bị gửi trễ. Với mỗi mũi tên, bạn nên trả lời được: đồng bộ hay bất đồng bộ, nếu phía bên kia chết thì chuyện gì xảy ra, dữ liệu có thể bị trùng hoặc mất không. Đây là những câu người phỏng vấn middle sẽ hỏi ngay trên sơ đồ.

Mẹo từ người phỏng vấn

Luôn tách rõ "team" và "em": "Team có 5 backend. Phần em sở hữu là service đơn hàng; em là người đề xuất chuyển việc gửi thông báo sang Kafka thay vì gọi REST đồng bộ." Nói "em" không phải là khoe, mà là giúp người phỏng vấn chấm đúng năng lực của bạn.

Nguyên tắc sống còn: mọi công nghệ ghi trong CV đều có thể bị đào sâu tới tầng thứ ba. Bảng dưới là những chuỗi câu hỏi tôi hay dùng.

Trong CV ghi	Câu hỏi 1	Câu hỏi đào sâu
Kafka	Vì sao dùng Kafka ở đây?	Consumer xử lý trùng thế nào, mất message khi nào?
Redis	Cache cái gì, TTL bao nhiêu?	Invalidate ra sao, cache stampede xử lý thế nào?
Microservices	Chia service theo tiêu chí gì?	Transaction xuyên service giải quyết thế nào?
Docker, K8s	Em tự viết Dockerfile không?	Pod restart liên tục thì em debug từ đâu?
Tối ưu query	Query nào, chậm bao nhiêu?	Execution plan trước và sau khác gì?

13.4 Công thức STAR và 3 ví dụ mẫu

Với câu hỏi behavioral ("Kể về một lần..."), hãy trả lời theo STAR: Situation (bối cảnh ngắn), Task (trách nhiệm của bạn), Action (bạn đã làm gì, chiếm phần lớn thời lượng), Result (kết quả đo được). Tôi luôn muốn nghe thêm một chữ L ở cuối: Lesson, bạn rút ra gì và thay đổi quy trình ra sao. Ba ví dụ dưới đây dùng dự án giả định, bạn thay bằng chuyện thật của mình.

Ví dụ 1: Sự cố production khó nhất

Nhắc lại kiến thức

Câu chuyện dưới đây dựa trên hai kiến thức kỹ thuật: connection pool (HikariCP giữ một số connection database cố định để dùng lại; hết connection thì request phải xếp hàng chờ) và việc @Transactional giữ một connection suốt thời gian method chạy. Xem mục 4.5 về @Transactional và mục 11.8 về kịch bản xử lý sự cố. Người phỏng vấn sẽ hỏi đúng vào những điểm này, nên chỉ kể chuyện mà bạn giải thích được cơ chế.

• Situation: Ví điện tử, tối thứ Sáu cao điểm, API thanh toán bắt đầu timeout hàng loạt, tỷ lệ lỗi lên khoảng 30% trong 15 phút.
• Task: Em đang trực on-call và là người sở hữu payment service, cần khôi phục dịch vụ trước rồi tìm nguyên nhân gốc.
• Action: Em xem dashboard thấy HikariCP pool luôn ở mức 100% active, còn CPU database thấp, nên loại trừ khả năng query chậm. Lấy thread dump thì phần lớn thread đang chờ phản hồi từ API của đối tác ngân hàng, và lời gọi này nằm bên trong một method @Transactional, nghĩa là mỗi request giữ connection database suốt thời gian chờ đối tác. Đối tác đang chậm 8–10 giây nên pool cạn. Em đề xuất và được lead duyệt hotfix: đặt timeout 3 giây cho HTTP client và tách lời gọi đối tác ra ngoài transaction. Sau sự cố em bổ sung circuit breaker và alert khi pool usage vượt 80%.
• Result: Hotfix lên sau khoảng 40 phút, tỷ lệ lỗi về dưới 0,5%. Ba tháng sau đó đối tác chậm thêm hai lần nhưng hệ thống chỉ báo lỗi cho đúng các giao dịch liên quan, không sập toàn bộ.
• Lesson: Em viết postmortem và thêm vào checklist review code một mục: không gọi I/O bên ngoài trong transaction database.

Ví dụ 2: Bất đồng với tech lead

• Situation: Sàn thương mại điện tử, sprint sắp release, em phát hiện API tạo đơn không có idempotency, app mobile khi mạng chập chờn sẽ retry và tạo đơn trùng.
• Task: Em muốn bổ sung idempotency trước release, nhưng lead muốn để sang sprint sau vì sợ trễ hạn.
• Action: Em không tranh luận bằng cảm tính mà lấy số liệu: truy vấn log 2 tuần thấy khoảng 0,3% đơn bị trùng, mỗi ca team CS mất khoảng 15 phút xử lý hoàn tiền. Em đề xuất phương án tối thiểu gói trong 1,5 ngày công: client gửi header Idempotency-Key, server lưu key kèm unique constraint, chưa làm phần cache kết quả phức tạp. Em nói rõ nếu lead vẫn quyết định để sau thì em sẽ ghi thành tech debt có ưu tiên cao.
• Result: Lead đồng ý làm bản tối thiểu, release đúng hạn. Tỷ lệ đơn trùng sau release gần như bằng 0.
• Lesson: Khi bất đồng, em đi kèm dữ liệu và một phương án nhỏ hơn thay vì chỉ nói "cách của em tốt hơn", và em chấp nhận quyết định cuối cùng của người chịu trách nhiệm.

Ví dụ 3: Tối ưu hiệu năng có số đo

Nhắc lại kiến thức

N+1 là lỗi một query lấy danh sách cha rồi phát sinh thêm N query để lấy dữ liệu con của từng dòng, thường do lazy loading của JPA (xem mục 6.4). Composite index và EXPLAIN ANALYZE xem mục 6.2. "p95" là mức thời gian mà 95% request nhanh hơn, thước đo phổ biến hơn trung bình vì phản ánh trải nghiệm của nhóm người dùng chậm nhất (xem mục 11.6).

• Situation: Trang quản trị đơn hàng tải danh sách mất khoảng 3,2 giây (p95), đội vận hành phàn nàn mỗi ngày.
• Task: Em được giao đưa thời gian phản hồi xuống dưới 500 ms mà không thay đổi giao diện.
• Action: Em bật log SQL và thấy mỗi trang 50 đơn sinh ra 101 câu query do N+1 khi load khách hàng và danh sách sản phẩm. Em đổi sang JOIN FETCH cho quan hệ ManyToOne và @BatchSize cho collection, chỉ lấy các cột cần hiển thị qua DTO projection. Dùng EXPLAIN ANALYZE thì thấy bảng đơn hàng bị quét toàn bộ khi lọc theo trạng thái và ngày tạo, em thêm composite index (status, created_at). Cuối cùng em đổi phân trang OFFSET sang keyset cho các trang sâu.
• Result: p95 từ 3,2 giây xuống khoảng 180 ms, số query mỗi request từ 101 xuống 3. Em đo bằng số liệu từ APM trong một tuần trước và sau khi triển khai.
• Lesson: Đo trước khi sửa. Nếu em thêm cache ngay từ đầu như ý tưởng ban đầu thì đã che mất vấn đề N+1.

Bẫy thường gặp

Câu chuyện STAR mà không có con số, hoặc Action toàn "chúng em". Một lỗi khác là bịa chuyện: người phỏng vấn giỏi sẽ hỏi "thread dump đó em lấy bằng lệnh gì?", "index đó tạo trên bảng bao nhiêu dòng, có lock bảng không?". Chuyện thật dù nhỏ vẫn tốt hơn chuyện hoành tráng mà không chịu nổi ba câu hỏi.

13.5 Các câu behavioral hay gặp

Câu hỏi (Cơ bản): Vì sao bạn muốn nghỉ việc ở công ty hiện tại?

Nói về thứ bạn đang tìm kiếm, không phải thứ bạn đang chạy trốn. Ví dụ: "Dự án hiện tại đã vào giai đoạn bảo trì, em muốn làm ở môi trường có bài toán tải lớn hơn và được tham gia thiết kế." Nếu lý do là lương, có thể nói thẳng nhưng nhẹ nhàng: "Em nghĩ mức đãi ngộ hiện tại chưa phản ánh đúng phạm vi công việc em đang đảm nhận."

Bẫy thường gặp

Chê sếp, chê công ty, hoặc kể lể mâu thuẫn cá nhân. Dù đúng sự thật, người nghe chỉ nhớ bạn là người hay đổ lỗi.

Câu trả lời tồi: "Dạ công ty em quản lý kém lắm anh, sếp toàn giao việc vô lý, OT liên tục mà không trả thêm." Tồi vì ba lý do: nói xấu nơi cũ, không nói được mình đang tìm gì, và người nghe tự hỏi "ở đây có OT thì em có bỏ đi không". Cùng sự thật đó có thể nói: "Em muốn một môi trường có quy trình ước lượng và lập kế hoạch rõ hơn, để thời gian của em dành cho giải quyết bài toán kỹ thuật thay vì chữa cháy."

Câu hỏi (Cơ bản): Điểm yếu lớn nhất của bạn là gì?

Chọn một điểm yếu thật, không ảnh hưởng cốt lõi tới vị trí, và nói bạn đang cải thiện thế nào. Ví dụ: "Em từng hay ôm việc, ngại nhờ giúp khi bị kẹt, có lần làm trễ task 2 ngày. Giờ em đặt quy tắc kẹt quá nửa ngày thì báo lead trong daily." Tránh câu sáo rỗng "em quá cầu toàn" hoặc "em làm việc quá chăm chỉ".

Câu trả lời tồi: "Em hơi yếu về database" khi đang ứng tuyển backend. Tồi vì điểm yếu chạm vào năng lực cốt lõi của vị trí và không kèm kế hoạch cải thiện. Một ví dụ khác đạt yêu cầu: "Em từng ngại trình bày trước đông người, nên các buổi demo em hay nói lan man. Sáu tháng nay em xin chủ động trình bày sprint review và chuẩn bị trước ba ý chính, lead nhận xét phần demo của em đã gọn hơn nhiều."

Câu hỏi (Thực chiến): Bạn xử lý thế nào khi deadline quá gấp?

Người phỏng vấn muốn nghe bạn báo sớm và thương lượng phạm vi, chứ không phải thức trắng. Hướng trả lời: ước lượng lại, báo rủi ro sớm cho lead/PM, đề xuất cắt phạm vi (làm phần lõi trước, phần phụ sau), giữ những thứ không được bỏ như test cho luồng tiền. Làm thêm giờ ngắn hạn là chấp nhận được, nhưng không phải chiến lược.

Ví dụ trả lời mẫu: "Ở dự án trước, khách hàng muốn đưa tính năng xuất hóa đơn điện tử lên sớm một tuần vì thay đổi quy định. Em ước lượng lại thì thấy làm đủ cần 8 ngày, còn 5 ngày. Em báo ngay trong buổi daily hôm đó, đề xuất chia hai đợt: đợt 1 làm luồng xuất hóa đơn chuẩn chiếm khoảng 90% giao dịch, có đủ test tích hợp; đợt 2 làm hóa đơn điều chỉnh và thay thế. PM đồng ý, khách hàng cũng chấp nhận. Đợt 1 lên đúng hạn không lỗi, đợt 2 lên sau 4 ngày. Em làm thêm hai buổi tối trong tuần đó, nhưng quyết định quan trọng là cắt phạm vi sớm chứ không phải làm thêm giờ."

Câu trả lời tồi: "Em sẵn sàng thức đêm, cuối tuần làm bù để kịp deadline ạ." Nghe có vẻ chăm chỉ, nhưng người phỏng vấn nghe ra: bạn không biết báo rủi ro, không biết thương lượng phạm vi, và khi mệt thì chất lượng code sẽ giảm, bug sẽ đẩy sang người khác.

Câu hỏi (Thực chiến): Bạn đã làm việc với khách hàng nước ngoài hoặc trong mô hình outsource chưa?

Rất hay gặp ở công ty outsource làm cho thị trường Nhật, Mỹ, châu Âu. Nêu cụ thể: bạn trao đổi trực tiếp hay qua BrSE/PM, đọc tài liệu đặc tả bằng ngôn ngữ gì, xử lý khác múi giờ thế nào. Câu chuyện tốt là khi yêu cầu mơ hồ, bạn viết lại câu hỏi dạng Q&A có ví dụ cụ thể, gửi trước buổi họp để khách xác nhận, tránh làm sai rồi phải sửa. Nếu có, nói thật trình độ tiếng Anh hoặc tiếng Nhật, đừng phóng đại vì người phỏng vấn có thể chuyển ngôn ngữ ngay.

Ví dụ trả lời mẫu: "Em làm 2 năm cho khách hàng Nhật, trao đổi qua BrSE. Tài liệu đặc tả bằng tiếng Nhật, team dịch sang tiếng Việt nhưng nhiều chỗ dịch mất ý. Em tập thói quen gom các chỗ chưa rõ thành bảng Q&A, mỗi câu có ví dụ input và output mong muốn, gửi trước giờ họp chiều. Khách trả lời trước khi em bắt đầu code, nhờ vậy số lần phải sửa lại do hiểu sai đặc tả trong module của em giảm rõ rệt so với giai đoạn đầu. Tiếng Nhật của em mới đọc được tài liệu kỹ thuật cơ bản, giao tiếp vẫn cần BrSE; tiếng Anh em đọc viết tốt, nói ở mức trao đổi công việc."

Câu trả lời tồi: "Dạ có, em làm với khách Nhật, cũng bình thường ạ." Không có chi tiết nào để chấm: bạn làm gì khác với một người chưa từng làm với khách nước ngoài?

Câu hỏi (Cơ bản): Bạn học công nghệ mới như thế nào?

Trả lời bằng một ví dụ gần đây thay vì liệt kê kênh học. Ví dụ: "Khi dự án cần Kafka, em đọc tài liệu chính thức phần consumer group và delivery semantics, dựng thử bằng Docker Compose, viết một PoC mô phỏng consumer chết giữa chừng để xem message có bị xử lý lại không, sau đó trình bày lại cho team 30 phút." Điểm cộng là có kiểm chứng bằng thực nghiệm và chia sẻ lại.

Câu trả lời tồi: "Em hay xem YouTube, đọc Medium, học trên Udemy ạ." Đây là danh sách kênh, không phải cách học. Nó không cho thấy bạn hiểu sâu tới đâu, cũng không có bằng chứng bạn đã áp dụng được gì.

Câu hỏi (Cơ bản): Mục tiêu của bạn trong 3–5 năm tới là gì?

Nêu hướng rõ ràng và gắn với vị trí đang ứng tuyển: trở thành senior có thể sở hữu một domain, hoặc đi theo hướng kỹ thuật chuyên sâu (hệ thống phân tán, hiệu năng), hoặc tech lead. Nói kèm bước cụ thể bạn đang làm. Tránh "em chưa nghĩ tới" hoặc "em muốn mở công ty riêng" khi phỏng vấn cho vị trí cần gắn bó lâu dài.

Ví dụ trả lời mẫu: "Trong 3 năm tới em muốn trở thành senior backend có thể sở hữu trọn một domain, ví dụ toàn bộ luồng thanh toán: từ thiết kế, vận hành tới xử lý sự cố. Để đi tới đó, năm nay em đang tập trung vào hai việc: hiểu sâu hệ thống phân tán qua việc tự làm lại các pattern như outbox và saga, và nhận thêm phần review code cho hai bạn mới vào team. Vị trí này hấp dẫn em vì JD nhắc tới việc tách hệ thống thanh toán hiện tại thành các service, đó đúng là loại bài toán em muốn làm."

Câu trả lời tồi: "Em muốn lên leader trong 1 năm." Mốc thời gian không thực tế với 2–4 năm kinh nghiệm và không kèm bước cụ thể, nghe như mong muốn chức danh chứ không phải kế hoạch phát triển năng lực.

Câu hỏi (Thực chiến): Kể về một lần bạn gây ra lỗi trên production.

Câu này kiểm tra sự trung thực và trách nhiệm. Nhận lỗi rõ ràng, nói bạn đã khắc phục và phòng ngừa thế nào (thêm test, thêm bước review migration, feature flag). Trả lời "em chưa gây lỗi bao giờ" ở mức 3 năm kinh nghiệm thường bị hiểu là chưa làm việc gì quan trọng hoặc không thành thật.

Ví dụ trả lời mẫu: "Em từng viết một migration thêm cột NOT NULL có giá trị mặc định vào bảng đơn hàng khoảng 20 triệu dòng. Trên môi trường test dữ liệu nhỏ nên chạy trong vài giây, lên production thì lệnh ALTER khóa bảng gần 4 phút, API tạo đơn timeout suốt thời gian đó. Em là người viết và tự tay chạy migration, nên em báo ngay trên kênh sự cố và phối hợp với DBA theo dõi tới khi xong. Sau đó em đề xuất ba thay đổi: migration trên bảng lớn phải được kiểm thử trên bản sao dữ liệu production, tách thành các bước không khóa bảng (thêm cột cho phép NULL, backfill theo batch, rồi mới thêm ràng buộc), và chạy ngoài giờ cao điểm. Từ đó team không gặp lại lỗi tương tự."

Câu trả lời tồi: "Có lần hệ thống lỗi nhưng do bạn QA test không kỹ ạ." Câu hỏi là về lỗi bạn gây ra; đổ sang người khác cho thấy bạn né trách nhiệm, đúng thứ câu hỏi này muốn phát hiện.

Câu hỏi (Thực chiến): Bạn phản ứng thế nào khi bị review code gay gắt?

Tách cảm xúc khỏi code: đọc kỹ, hỏi lại chỗ chưa hiểu, sửa nếu hợp lý, và bảo vệ bằng lý lẽ nếu không đồng ý. Kể thêm chiều ngược lại: khi review cho người khác, bạn góp ý vào code chứ không vào người, phân biệt góp ý bắt buộc và góp ý nhỏ.

Ví dụ trả lời mẫu: "Có lần em mở pull request khoảng 800 dòng, lead để lại hơn 30 comment, có câu khá thẳng như 'đoạn này không test được'. Lúc đầu em hơi chột dạ, nhưng em đọc lại thì thấy phần lớn đúng: em nhét logic tính phí vào controller. Em sửa theo, tách service và viết unit test. Có hai comment em không đồng ý, về việc đổi tên một enum trùng với thuật ngữ nghiệp vụ; em giải thích lý do kèm link tài liệu nghiệp vụ, lead đồng ý giữ nguyên. Sau lần đó em chia pull request nhỏ dưới 300 dòng, và thời gian review của team với code của em ngắn hẳn."

Câu trả lời tồi: "Em thấy review gay gắt là không tôn trọng nên em sẽ nói thẳng với anh đó." Hoặc ngược lại: "Anh lead nói gì em cũng sửa theo." Câu đầu cho thấy bạn đặt cảm xúc lên trên code, câu sau cho thấy bạn không có chính kiến kỹ thuật.

Câu hỏi (Thực chiến): Khi nhận một task có yêu cầu không rõ ràng, bạn làm gì?

Liệt kê giả định, hỏi BA/PO bằng ví dụ cụ thể, xác nhận bằng văn bản (comment trên ticket), chia task thành phần chắc chắn làm được ngay và phần chờ xác nhận. Người phỏng vấn đánh giá cao việc bạn không im lặng làm theo phỏng đoán.

Ví dụ trả lời mẫu: "Em từng nhận ticket 'cho phép khách hủy đơn'. Em liệt kê ra các câu hỏi: hủy được tới trạng thái nào, đơn đã thanh toán thì hoàn tiền tự động hay chờ duyệt, voucher đã dùng có trả lại không. Em gửi BA dưới dạng bảng, mỗi dòng một tình huống kèm đề xuất mặc định của em. Trong lúc chờ, em làm trước phần chắc chắn là API hủy đơn chưa thanh toán. BA trả lời sau một ngày và sửa hai trong năm đề xuất của em; nếu em tự làm theo phỏng đoán thì đã phải làm lại phần hoàn tiền."

Câu trả lời tồi: "Em sẽ làm theo cách em hiểu, sai thì sửa sau ạ." Sửa sau nghĩa là tốn gấp đôi công sức của bạn, của QA và có thể của khách hàng.

Câu hỏi (Cơ bản): Vì sao bạn chọn công ty chúng tôi?

Chứng minh bạn đã tìm hiểu: sản phẩm của họ, bài toán kỹ thuật trong JD, blog kỹ thuật hoặc phát biểu công khai của team. Nối với mục tiêu của bạn. Câu "vì công ty lớn, môi trường chuyên nghiệp" áp dụng được cho mọi nơi nên gần như không có giá trị.

Ví dụ trả lời mẫu (công ty giả định): "Em dùng app của anh chị để thanh toán hóa đơn điện nước hằng tháng, nên em khá tò mò phía backend xử lý đối soát với nhiều nhà cung cấp thế nào. Em có đọc bài blog của team về việc chuyển từ batch cuối ngày sang xử lý theo sự kiện, và JD cũng nhắc tới Kafka và PostgreSQL. Đây đúng là mảng em đang làm ở công ty hiện tại, và em muốn làm ở quy mô lớn hơn."

Câu trả lời tồi: "Em thấy công ty mình lớn, lương tốt, môi trường chuyên nghiệp ạ." Câu này thay tên công ty nào vào cũng đúng, nên người nghe hiểu là bạn chưa tìm hiểu gì.

Câu hỏi (Hiểu sâu): Tại sao chúng tôi nên chọn bạn thay vì ứng viên khác?

Tóm tắt 2–3 điểm khớp nhất giữa bạn và JD, mỗi điểm có một bằng chứng. Ví dụ: "Anh chị cần người có kinh nghiệm thanh toán và tối ưu PostgreSQL; em đã làm cả hai ở quy mô 2 triệu người dùng, với kết quả như em vừa kể."

Câu trả lời tồi: "Vì em chăm chỉ, ham học hỏi và có tinh thần trách nhiệm." Ba tính từ không có bằng chứng, ứng viên nào cũng nói được. Câu này là cơ hội để tóm tắt lại những bằng chứng mạnh nhất bạn đã kể trong buổi phỏng vấn, đừng bỏ phí.

Câu hỏi (Thực chiến): Bạn đang phỏng vấn ở đâu khác hoặc có offer nào chưa?

Trung thực nhưng không cần chi tiết: "Em đang ở vòng cuối một công ty khác, dự kiến có kết quả trong tuần sau." Thông tin này giúp HR đẩy nhanh quy trình. Tuyệt đối không bịa offer để ép giá, vì thị trường IT Việt Nam nhỏ hơn bạn nghĩ.

Câu trả lời tồi: "Em có 3 offer rồi, bên kia trả 50 triệu, bên mình trả hơn thì em đi." Vừa gây áp lực thô, vừa cho thấy tiền là tiêu chí duy nhất; nhiều HR sẽ dừng quy trình vì đoán bạn sẽ rời đi ngay khi có nơi trả cao hơn.

13.6 Câu hỏi nên hỏi ngược lại nhà tuyển dụng

Câu "Em có câu hỏi gì cho anh chị không?" là một phần của đánh giá. "Dạ không ạ" là cơ hội bị bỏ phí. Chuẩn bị 3–5 câu, chọn tùy người đối diện:

• Với người phỏng vấn kỹ thuật: "Hệ thống hiện tại đang gặp thách thức kỹ thuật lớn nhất là gì?", "Quy trình từ lúc merge code tới lúc lên production diễn ra thế nào?", "Team xử lý sự cố và on-call ra sao?"
• Về công việc cụ thể: "Ba tháng đầu, người vào vị trí này cần đạt được gì thì anh chị coi là thành công?", "Tỷ lệ phát triển tính năng mới và bảo trì khoảng bao nhiêu?"
• Về phát triển: "Cơ chế đánh giá và review lương diễn ra mấy lần một năm, dựa trên tiêu chí gì?", "Người ở vị trí này thường phát triển lên đâu sau 2 năm?"
• Với công ty outsource: "Dự án em tham gia là cho khách hàng nào (thị trường nào), thời hạn bao lâu, hết dự án thì em được sắp xếp thế nào?"

Bẫy thường gặp

Hỏi về lương, ngày nghỉ ngay ở vòng kỹ thuật, hoặc hỏi những điều có sẵn trên website. Để chuyện đãi ngộ cho vòng HR.

13.7 Deal lương

Tìm mức thị trường

Trước khi phỏng vấn, bạn phải biết khoảng lương cho vị trí của mình. Nguồn tham khảo: báo cáo lương IT thường niên của các trang tuyển dụng và công ty headhunt, khoảng lương ghi trong JD của các vị trí tương tự, trao đổi với headhunter, và hỏi bạn bè cùng level (hỏi khoảng, không hỏi con số chính xác). Lưu ý mức lương chênh lệch đáng kể giữa công ty outsource, product, ngân hàng và công ty nước ngoài, cũng như giữa Hà Nội, TP.HCM và remote cho khách hàng nước ngoài.

Nói con số thế nào

• Nếu có thể, để nhà tuyển dụng đưa khoảng trước: "Anh chị có thể chia sẻ khoảng ngân sách cho vị trí này không ạ?"
• Nếu buộc phải nói, đưa một khoảng hẹp mà đáy là mức bạn đã hài lòng, ví dụ "em mong muốn khoảng 35 đến 40 triệu gross". HR thường đề xuất gần đáy.
• Giải thích bằng giá trị bạn mang lại và mặt bằng thị trường, không bằng nhu cầu cá nhân ("em mới vay mua nhà").
• Khi HR im lặng sau con số của bạn, đừng tự hạ giá để lấp khoảng lặng.

Gross, net và các thành phần

Luôn nói rõ gross hay net. Gross là tổng trước khi trừ bảo hiểm bắt buộc phần người lao động đóng (BHXH 8%, BHYT 1,5%, BHTN 1%, tổng 10,5%) và thuế thu nhập cá nhân lũy tiến sau giảm trừ gia cảnh. Mức giảm trừ và biểu thuế có thể thay đổi theo quy định mới, nên hãy dùng công cụ tính gross sang net được cập nhật thay vì nhớ số cũ. Hỏi thêm "lương đóng bảo hiểm là bao nhiêu", vì một số nơi đóng trên mức lương cơ bản thấp hơn tổng thu nhập, ảnh hưởng tới quyền lợi dài hạn của bạn.

Thành phần	Câu nên hỏi
Lương tháng 13	Có cam kết trong hợp đồng hay tùy kết quả kinh doanh?
Performance bonus	Trung bình bao nhiêu tháng lương, điều kiện nhận?
Thử việc	Bao lâu, hưởng bao nhiêu phần trăm lương?
Review lương	Mấy lần một năm, mức tăng trung bình?
Bảo hiểm sức khỏe	Có gói tư nhân, áp dụng cho người thân không?
Remote, hybrid	Bao nhiêu ngày mỗi tuần, có ghi trong chính sách?
Khác	Ngày phép, phụ cấp, ngân sách học tập, thiết bị, OT

Ghi chú

Theo Bộ luật Lao động 2019, lương thử việc ít nhất bằng 85% lương chính thức, và thời gian thử việc tối đa 60 ngày với công việc yêu cầu trình độ từ cao đẳng trở lên. Khi so sánh offer, hãy quy về tổng thu nhập năm (12 tháng lương cộng tháng 13 cộng bonus kỳ vọng) chứ không chỉ so lương tháng.

Khi có nhiều offer

• So sánh bằng tổng thu nhập năm, rồi tới những yếu tố khó đổi ra tiền: bài toán kỹ thuật, người lead trực tiếp, sự ổn định, lộ trình phát triển.
• Nói thật với công ty bạn thích hơn rằng bạn có offer khác và mức của nó, hỏi họ có điều chỉnh được không. Chỉ làm điều này một lần, không kéo co nhiều vòng.
• Xin thêm thời gian suy nghĩ là bình thường (vài ngày), nhưng đừng giữ offer quá lâu rồi im lặng.
• Từ chối lịch sự bằng email, cảm ơn thời gian của họ. Bạn có thể quay lại công ty đó sau hai năm.
• Cẩn trọng với counter-offer từ công ty hiện tại: nếu lý do bạn ra đi không chỉ là lương, tăng lương hiếm khi giữ bạn được lâu.

13.8 Viết CV cho 2–4 năm kinh nghiệm

CV của bạn là danh sách câu hỏi mà người phỏng vấn sẽ dùng. Mỗi dòng phải là thứ bạn muốn được hỏi và trả lời được ít nhất ba tầng.

• Độ dài 1–2 trang, dự án gần nhất ở trên cùng. Mỗi dự án: bối cảnh một dòng, quy mô team, vai trò, stack, rồi 3–5 dòng thành tựu.
• Dòng thành tựu theo công thức: động từ + việc bạn làm + công nghệ + con số kết quả.
• Chia kỹ năng theo mức độ thật: dùng thành thạo trong dự án, đã dùng, đang tìm hiểu. Không ghi thứ bạn không trả lời được hai câu hỏi.
• Điều chỉnh CV theo từng JD: đưa kỹ năng khớp lên trước, dùng đúng từ khóa trong JD, vì nhiều nơi lọc CV tự động bằng từ khóa.
• GitHub hay blog chỉ ghi khi có nội dung thực sự, một repo trống gây ấn tượng tệ hơn là không ghi.

Dòng CV yếu	Dòng CV tốt
Phát triển API cho hệ thống đơn hàng	Xây dựng 12 REST API order service (Spring Boot 3), 50 nghìn đơn/ngày
Tối ưu hiệu năng hệ thống	Giảm p95 trang đơn hàng từ 3,2 s xuống 180 ms (sửa N+1, thêm index)
Sử dụng Kafka	Chuyển luồng thông báo sang Kafka, idempotent consumer, hết timeout khi SMS chậm
Làm việc nhóm tốt	Viết tài liệu onboarding, rút thời gian làm quen của người mới từ 3 tuần còn 1 tuần

Mẹo từ người phỏng vấn

Nếu không nhớ con số chính xác, dùng con số ước lượng trung thực và nói rõ khi được hỏi ("khoảng", "theo dashboard APM tuần đó"). Nếu hoàn toàn không có số đo, hãy mô tả tác động nghiệp vụ: "loại bỏ bước đối soát tay hằng ngày của đội kế toán". Đừng bịa phần trăm, người phỏng vấn sẽ hỏi bạn đo bằng cách nào.

13.9 Câu hỏi tình huống tự luyện

Các câu dưới đây là tình huống tôi và đồng nghiệp hay dùng ở vòng behavioral và vòng quản lý. Mỗi câu có ý chính (người phỏng vấn muốn kiểm tra gì) và khung trả lời để bạn điền câu chuyện thật của mình vào. Hãy tự nói to từng câu trong 2–3 phút, ghi âm lại và nghe xem có con số, có "em" rõ ràng và có bài học không.

Câu hỏi (Thực chiến): Kể về dự án bạn tự hào nhất trong 3 phút.

Ý chính: người phỏng vấn kiểm tra bạn hiểu bối cảnh nghiệp vụ, phần mình đóng góp và kết quả đo được, không phải danh sách công nghệ.

Khung trả lời:

• Bối cảnh một câu: hệ thống phục vụ ai, quy mô bao nhiêu.
• Phần của bạn: module nào, quyết định kỹ thuật nào do bạn đề xuất.
• Một vấn đề khó và các phương án đã cân nhắc.
• Kết quả có con số và một điều bạn sẽ làm khác nếu làm lại.

Câu hỏi (Thực chiến): Nếu được làm lại dự án gần nhất, bạn sẽ thay đổi gì?

Ý chính: kiểm tra tư duy trade-off và khả năng tự nhìn lại mà không đổ lỗi.

Khung trả lời:

• Chọn một quyết định kỹ thuật cụ thể (ví dụ tách microservice quá sớm, thiếu test tích hợp cho luồng tiền).
• Giải thích vì sao lúc đó quyết định như vậy là hợp lý với thông tin khi ấy.
• Hệ quả thực tế bạn quan sát được, có số liệu nếu có.
• Bạn sẽ làm gì khác và cái giá của phương án mới.

Bẫy thường gặp

"Em sẽ viết lại toàn bộ bằng công nghệ X" hoặc "dự án đó do team cũ thiết kế dở". Câu đầu cho thấy bạn nghĩ công nghệ giải quyết mọi thứ, câu sau là đổ lỗi.

Câu hỏi (Thực chiến): Một đồng nghiệp liên tục trễ phần việc và làm chậm cả team. Bạn xử lý thế nào?

Ý chính: kiểm tra bạn giải quyết vấn đề trực tiếp, tôn trọng, dựa trên sự việc, và biết khi nào cần báo lên.

Khung trả lời:

• Nói chuyện riêng trước, hỏi nguyên nhân (task quá khó, bị giao nhiều việc, việc cá nhân) thay vì phán xét.
• Đề xuất hỗ trợ cụ thể: pair programming, chia nhỏ task, làm rõ yêu cầu.
• Nếu ảnh hưởng tới deadline chung, báo lead bằng dữ kiện (task nào, trễ bao lâu), không bằng cảm nhận.
• Kết quả và điều bạn học được về làm việc nhóm.

Câu hỏi (Thực chiến): Lead yêu cầu bạn làm theo một thiết kế bạn cho là sai. Bạn làm gì?

Ý chính: kiểm tra bạn biết phản biện bằng dữ liệu và biết "disagree and commit" (không đồng ý nhưng vẫn cam kết làm khi quyết định đã chốt).

Khung trả lời:

• Nêu cụ thể rủi ro kỹ thuật, kèm bằng chứng: số liệu, PoC nhỏ, tài liệu chính thức.
• Đề xuất phương án thay thế và chi phí của nó.
• Nếu lead vẫn giữ quyết định, làm hết sức và ghi lại rủi ro (ADR, ticket tech debt).
• Kể câu chuyện thật; ví dụ 2 ở mục 13.4 là một khuôn mẫu.

Câu hỏi (Thực chiến): 5 giờ chiều thứ Sáu bạn phát hiện một bug nghiêm trọng trong code mình đã release sáng nay. Bạn làm gì?

Ý chính: kiểm tra tinh thần trách nhiệm và thứ tự ưu tiên khi có sự cố: giảm thiệt hại trước, tìm nguyên nhân sau.

Khung trả lời:

• Đánh giá mức ảnh hưởng: bao nhiêu người dùng, có sai lệch tiền hay dữ liệu không.
• Báo ngay cho lead và người trực, không tự âm thầm sửa.
• Chọn cách khôi phục nhanh nhất: rollback, tắt feature flag, hotfix nhỏ có review.
• Sau đó sửa dữ liệu bị ảnh hưởng, viết postmortem và thêm test hoặc bước kiểm tra để không lặp lại.

Câu hỏi (Thực chiến): Kể về một lần bạn phải học một công nghệ hoàn toàn mới trong thời gian ngắn.

Ý chính: kiểm tra tốc độ và phương pháp học, cùng khả năng biến kiến thức mới thành kết quả.

Khung trả lời:

• Bối cảnh: vì sao phải học, thời hạn bao lâu.
• Cách học: tài liệu chính thức, PoC có kịch bản lỗi, hỏi người có kinh nghiệm.
• Áp dụng vào dự án: phần nào bạn làm, gặp khó khăn gì.
• Kết quả và cách bạn chia sẻ lại cho team.

Câu hỏi (Thực chiến): Khách hàng hoặc PM thay đổi yêu cầu khi sprint đã đi được một nửa. Bạn phản ứng thế nào?

Ý chính: kiểm tra bạn có làm rõ tác động và để người có thẩm quyền quyết định, thay vì âm thầm ôm việc hoặc từ chối cứng.

Khung trả lời:

• Làm rõ thay đổi bằng ví dụ cụ thể và hỏi mức độ gấp.
• Ước lượng tác động: phần nào phải làm lại, ảnh hưởng tới deadline và các task khác.
• Đưa ra lựa chọn: đổi task khác ra khỏi sprint, lùi hạn, hoặc làm bản tối thiểu.
• Ghi lại quyết định trên ticket để cả team cùng nắm.

Câu hỏi (Thực chiến): Bạn được giao một module legacy không có test và không có tài liệu. Bạn bắt đầu từ đâu?

Ý chính: kiểm tra bạn làm việc an toàn với code cũ, không đập đi xây lại theo cảm hứng.

Khung trả lời:

• Đọc luồng chính và log production để hiểu hành vi thật; hỏi người từng làm nếu còn.
• Viết test bao quanh hành vi hiện tại (characterization test) trước khi sửa.
• Sửa từng bước nhỏ, mỗi bước có review và có thể rollback.
• Ghi lại tài liệu ngắn cho người sau, kể kết quả cụ thể nếu có.

Câu hỏi (Thực chiến): Hai stakeholder yêu cầu hai việc mâu thuẫn và đều nói là gấp. Bạn làm gì?

Ý chính: kiểm tra bạn biết đẩy quyết định ưu tiên về đúng người có thẩm quyền, kèm thông tin đủ để họ quyết.

Khung trả lời:

• Làm rõ với từng bên: gấp vì sao, trễ thì ảnh hưởng gì.
• Tổng hợp lại hai yêu cầu, chi phí và tác động, gửi cho PM hoặc lead.
• Đề xuất thứ tự nếu được hỏi ý kiến, nhưng không tự chọn phe.
• Thông báo quyết định cuối cho cả hai bên bằng văn bản.

Câu hỏi (Thực chiến): Kể về một lần bạn giúp đồng nghiệp mới hoặc junior tiến bộ.

Ý chính: với ứng viên 3–4 năm, người phỏng vấn muốn thấy dấu hiệu bạn đã bắt đầu nâng người khác lên, không chỉ làm tốt việc của mình.

Khung trả lời:

• Người đó gặp khó khăn gì (chưa quen codebase, chưa viết test, sợ hỏi).
• Bạn làm gì cụ thể: tài liệu onboarding, pair programming, review có giải thích.
• Kết quả đo được: thời gian làm quen, số lỗi review lặp lại giảm.
• Bạn học được gì về cách giải thích.

Câu hỏi (Thực chiến): Bạn ước lượng task 3 ngày nhưng làm 7 ngày vẫn chưa xong. Chuyện gì đã xảy ra và bạn làm gì?

Ý chính: kiểm tra sự trung thực về ước lượng sai và việc bạn báo sớm hay báo muộn.

Khung trả lời:

• Thời điểm bạn nhận ra sẽ trễ và lúc bạn báo (càng sớm càng tốt).
• Nguyên nhân thật: phụ thuộc chưa biết, yêu cầu phát sinh, đánh giá thấp độ phức tạp.
• Cách khắc phục lúc đó: cắt phạm vi, nhờ hỗ trợ.
• Thay đổi về cách ước lượng sau đó, ví dụ chia task nhỏ hơn một ngày, spike trước khi ước lượng.

Bẫy thường gặp

"Em chưa bao giờ trễ task." Với 2–4 năm kinh nghiệm, câu này không đáng tin và cho thấy bạn không tự nhìn lại.

Câu hỏi (Thực chiến): Bạn nhận ra một quy trình trong team đang gây lãng phí. Bạn đã từng cải thiện nó chưa?

Ý chính: kiểm tra tính chủ động (ownership): bạn thấy vấn đề và làm gì đó, không chỉ than phiền.

Khung trả lời:

• Vấn đề cụ thể và cái giá của nó (ví dụ deploy tay mất 1 giờ mỗi lần, hay lỗi do quên bước).
• Bạn đề xuất gì, thuyết phục team ra sao.
• Triển khai: làm thử nhỏ, đo, rồi mở rộng.
• Con số trước và sau.

Câu hỏi (Thực chiến): Bạn đang on-call, lúc 2 giờ sáng alert báo tỷ lệ lỗi tăng nhưng bạn không quen phần hệ thống đó. Bạn làm gì?

Ý chính: kiểm tra bạn giữ bình tĩnh, làm theo quy trình và biết leo thang (escalate) đúng lúc.

Khung trả lời:

• Xác nhận alert có thật, đánh giá ảnh hưởng tới người dùng.
• Mở runbook, dashboard, xem có deploy hay thay đổi cấu hình gần đây không.
• Nếu không xử lý được trong khoảng thời gian quy định, gọi người sở hữu hệ thống, không cố một mình.
• Ghi lại timeline trong kênh sự cố để viết postmortem.

Câu hỏi (Thực chiến): Bạn phát hiện đồng nghiệp commit mật khẩu database lên Git. Bạn làm gì?

Ý chính: kiểm tra ý thức bảo mật và cách xử lý chuyện nhạy cảm mà không làm người khác mất mặt.

Khung trả lời:

• Báo ngay cho người đó và lead; coi mật khẩu đã bị lộ, dù repo là private.
• Ưu tiên đổi (rotate) mật khẩu, sau đó mới xóa khỏi lịch sử Git nếu cần.
• Đề xuất phòng ngừa: secret scanning trong CI, dùng secret manager, .gitignore cho file cấu hình local.
• Không bêu tên trong kênh chung; tập trung vào quy trình.

Câu hỏi (Thực chiến): Người phỏng vấn hỏi một công nghệ ghi trong CV mà bạn chỉ dùng qua loa. Bạn trả lời thế nào?

Ý chính: kiểm tra sự trung thực; nói rõ mức độ thật của mình và phần bạn đã làm, không cố nói vượt quá.

Khung trả lời:

• Nói thẳng phạm vi: "Em dùng Kafka ở phía consumer, phần cấu hình cluster do team platform làm."
• Trả lời chắc những gì bạn đã làm thật.
• Với phần chưa biết, nói cách bạn sẽ tìm hiểu hoặc suy luận từ nguyên lý.
• Sau buổi phỏng vấn, sửa CV cho đúng mức độ.

Câu hỏi (Thực chiến): Kể về một quyết định kỹ thuật bạn phải đưa ra khi không đủ thông tin.

Ý chính: kiểm tra cách bạn cân rủi ro và làm cho quyết định có thể đảo ngược được.

Khung trả lời:

• Bối cảnh và thông tin còn thiếu.
• Các phương án, và phương án nào dễ quay lại nhất nếu sai.
• Cách bạn giảm rủi ro: feature flag, làm thử nhỏ, thiết lập chỉ số theo dõi.
• Kết quả thực tế và bạn điều chỉnh gì khi có thêm thông tin.

Câu hỏi (Thực chiến): HR hỏi "Mức lương hiện tại của bạn là bao nhiêu?". Bạn trả lời thế nào?

Ý chính: kiểm tra bạn có chuẩn bị và có thương lượng chuyên nghiệp không; bạn có thể chuyển trọng tâm sang mức mong muốn.

Khung trả lời:

• Có thể trả lời thật và ngắn, nói rõ gross hay net, kèm tổng thu nhập năm nếu có thưởng.
• Chuyển trọng tâm: "Với phạm vi công việc của vị trí này và mặt bằng thị trường, em mong muốn khoảng X đến Y gross."
• Nếu không muốn tiết lộ, từ chối lịch sự và đưa luôn mức mong muốn.
• Không nói dối về con số, vì một số nơi yêu cầu xác minh qua bảng lương hoặc sổ bảo hiểm.

Câu hỏi (Thực chiến): HR đưa offer thấp hơn mức mong muốn 15%. Bạn phản hồi thế nào?

Ý chính: kiểm tra bạn thương lượng dựa trên giá trị và dữ kiện, giữ thái độ hợp tác.

Khung trả lời:

• Cảm ơn và thể hiện bạn quan tâm tới vị trí.
• Nêu lại mức mong muốn, dựa trên phạm vi công việc, kinh nghiệm liên quan và mặt bằng thị trường.
• Hỏi các phần có thể điều chỉnh khác: thưởng, review lương sau thử việc, ngày phép, remote.
• Xin thời gian suy nghĩ có hạn rõ ràng (2–3 ngày), không trả lời vội tại chỗ.

Câu hỏi (Thực chiến): Công ty hiện tại đưa counter-offer tăng 20% khi bạn nộp đơn nghỉ. Bạn quyết định thế nào?

Ý chính: kiểm tra bạn hiểu rõ lý do mình ra đi và giữ uy tín với cả hai bên.

Khung trả lời:

• Nhìn lại lý do ra đi: nếu không chỉ vì tiền, tăng lương không giải quyết được.
• So sánh bằng tổng thu nhập năm và cơ hội phát triển, không chỉ lương tháng.
• Đã nhận offer mới thì tôn trọng cam kết, trừ khi có lý do rất lớn và báo sớm.
• Rời đi lịch sự, bàn giao đầy đủ, vì thị trường nhỏ.

Câu hỏi (Thực chiến): Bạn trượt vòng kỹ thuật của một công ty bạn rất thích. Bạn làm gì sau đó?

Ý chính: câu này thường được hỏi dưới dạng "Kể về một thất bại"; người phỏng vấn muốn thấy cách bạn biến thất bại thành kế hoạch cải thiện.

Khung trả lời:

• Nói thật chuyện đã xảy ra và phần trách nhiệm của bạn (chuẩn bị chưa đủ phần nào).
• Bạn đã làm gì ngay sau đó: ghi lại câu hỏi, xin phản hồi.
• Kế hoạch cụ thể để lấp lỗ hổng và kết quả của kế hoạch đó.
• Không oán trách người phỏng vấn hay đề bài.

Câu hỏi (Thực chiến): Bạn làm gì trong 30 ngày đầu ở công ty mới?

Ý chính: kiểm tra bạn có kế hoạch hòa nhập chủ động và biết cân bằng giữa học và đóng góp.

Khung trả lời:

• Tuần 1–2: dựng môi trường, đọc kiến trúc, chạy luồng chính, hỏi nhiều và ghi chép.
• Tuần 2–3: nhận task nhỏ có thể release, làm quen quy trình review và deploy.
• Tuần 4: nhận một task trọn vẹn, cập nhật lại tài liệu onboarding chỗ còn thiếu.
• Hẹn gặp lead cuối tháng để xác nhận kỳ vọng và phản hồi.

Câu hỏi (Thực chiến): Người phỏng vấn nói "Câu trả lời vừa rồi của em chưa đúng". Bạn phản ứng thế nào?

Ý chính: kiểm tra bạn tiếp nhận phản hồi ngay tại chỗ: bình tĩnh, hỏi lại, suy nghĩ lại công khai.

Khung trả lời:

• Không phòng thủ, không im lặng; hỏi lại chỗ nào chưa đúng hoặc xin gợi ý.
• Suy nghĩ lại thành lời: "Nếu vậy thì trường hợp X sẽ...".
• Nếu vẫn tin mình đúng, trình bày lập luận hoặc ví dụ một cách lịch sự.
• Nếu sai, nhận và nói lại cách hiểu đúng; điều này được đánh giá cao hơn cố cãi.

13.10 Tóm tắt trọng tâm

• Phần kể chuyện dự án và behavioral quyết định kết quả không kém vòng kỹ thuật, vì người phỏng vấn tuyển một người để làm việc cùng hằng ngày chứ không chỉ một người biết Spring Boot.
• Bài giới thiệu 60–90 giây nên theo khung hiện tại, điểm nhấn, điểm mạnh riêng, lý do ứng tuyển, và cài sẵn "móc câu" vào chủ đề bạn mạnh nhất, vì câu hỏi tiếp theo thường xoay quanh những gì bạn vừa nhắc.
• Kể dự án theo thứ tự nghiệp vụ, kiến trúc, phần mình làm, vấn đề khó, con số, vì liệt kê công nghệ không cho người nghe biết bạn giải quyết được gì.
• Luôn tách "team" và "em", vì người phỏng vấn chỉ chấm được những gì bạn nói rõ là của mình.
• Mọi công nghệ trong CV đều có thể bị hỏi tới tầng thứ ba, nên chỉ ghi thứ bạn trả lời được và nói thật mức độ khi bị hỏi.
• Câu chuyện behavioral theo STAR cộng Lesson, phần Action chiếm nhiều nhất, vì đó là nơi thể hiện năng lực, còn Lesson cho thấy bạn thay đổi sau sự việc.
• Chuyện thật dù nhỏ tốt hơn chuyện hoành tráng mà bịa, vì người phỏng vấn giỏi luôn hỏi chi tiết kỹ thuật tới khi lộ.
• Câu trả lời tồi thường có chung dấu hiệu: đổ lỗi, sáo rỗng, không có con số hoặc có thể áp dụng cho bất kỳ ai; tự kiểm tra câu trả lời của mình theo bốn dấu hiệu này.
• Khi bất đồng, dùng dữ liệu và phương án nhỏ hơn, rồi tôn trọng quyết định cuối cùng, vì người phỏng vấn tìm người phản biện được nhưng không gây chia rẽ.
• Chuẩn bị 3–5 câu hỏi ngược theo từng vòng, vì "dạ không ạ" bị hiểu là bạn không quan tâm tới công việc.
• Deal lương bằng khoảng hẹp có đáy là mức bạn hài lòng, nói rõ gross hay net, và so sánh offer bằng tổng thu nhập năm, vì chỉ so lương tháng dễ chọn sai.
• Không bịa offer hay số liệu, vì thị trường IT Việt Nam nhỏ và mất uy tín một lần rất khó lấy lại.

13.11 Checklist ôn tập

Có bài giới thiệu 60–90 giây theo khung 4 phần, cài sẵn 2–3 "móc câu" vào chủ đề mạnh nhất Kể được dự án gần nhất theo thứ tự: nghiệp vụ, kiến trúc, phần mình làm, vấn đề khó, con số Vẽ được sơ đồ kiến trúc trong 2 phút, trả lời được mỗi mũi tên đồng bộ hay bất đồng bộ, lỗi thì sao Rà từng công nghệ trong CV, tự hỏi 3 tầng câu hỏi, gạch bỏ thứ không trả lời được Chuẩn bị 3 câu chuyện STAR có Lesson: sự cố production, bất đồng, tối ưu hiệu năng có số đo Chuẩn bị thêm câu chuyện về một lỗi mình gây ra và một lần xử lý yêu cầu mơ hồ Luyện 12 câu behavioral, không nói xấu công ty cũ, không dùng điểm yếu sáo rỗng Có 3–5 câu hỏi ngược cho từng vòng (kỹ thuật, quản lý, HR) Biết khoảng lương thị trường cho vị trí, chốt trước mức đáy và khoảng sẽ nói Phân biệt gross và net, hỏi lương đóng bảo hiểm, tháng 13, bonus, thử việc, review lương, remote So sánh offer bằng tổng thu nhập năm cộng các yếu tố phát triển, không bịa offer Mỗi dòng thành tựu trong CV có động từ, công nghệ và con số hoặc tác động nghiệp vụ Tự nói to ít nhất 10 câu tình huống ở mục 13.9, ghi âm và kiểm tra có con số, có "em" rõ ràng và có bài học Với mỗi câu behavioral, biết một kiểu câu trả lời tồi và vì sao nó tồi