Vòng đánh giá: làm việc nhóm, thuyết trình, giải quyết vấn đề trong thời gian ngắn, behavioral. Nguyên tắc xuyên suốt: họ không chấm đáp án đúng/sai, họ chấm CÁCH bạn làm việc — cách nghe, cách nói, cách phản ứng khi bị phản biện, cách đóng góp cho nhóm.
| Thời lượng | Hoạt động |
|---|---|
| 30' | Nghe phổ biến quy chế phỏng vấn |
| 5' | Vào phòng, chào Ban Giám khảo (BGK), nhận đề business case |
| 30' | Thảo luận nhóm tìm giải pháp + chuẩn bị bài trình bày |
| 10' | Cả nhóm thuyết trình bằng PowerPoint — TẤT CẢ thành viên PHẢI tham gia thuyết trình |
| 45' | Hỏi đáp với BGK |
Ngôn ngữ: tiếng Việt; được phép trình bày tiếng Anh nếu muốn — chỉ nên nếu bạn nói trôi chảy, tiếng Việt rõ ràng tốt hơn tiếng Anh vấp.
Bộ slide an toàn (5–6 slide, nền trắng, chữ to, bullet ngắn):
Laptop được cung cấp không có mạng → không tải template được, đừng mất thời gian trang trí.
Tiêu chí họ chấm: chủ động nhưng không lấn át, biết lắng nghe, xây dựng trên ý người khác, quản lý thời gian, kéo nhóm về đúng hướng khi lạc đề.
Khung 4 bước, áp dụng được cho hầu hết mọi đề:
Mẹo trình bày: nói chậm hơn bình thường ~20%; nhìn giám khảo, không nhìn giấy; mở đầu bằng câu kết luận ("Nhóm em đề xuất giải pháp A vì 3 lý do sau") thay vì kể lể.
Khi bị hỏi vặn (Q&A) — đây mới là phần chấm chính:
Khi nhận đề, đừng lao vào giải ngay. Trình tự:
Case thiên kỹ thuật (ví dụ: "hệ thống chuyển tiền chậm giờ cao điểm, xử lý thế nào?"): làm rõ triệu chứng → khoanh vùng (DB? network? code? traffic tăng?) → giải pháp ngắn hạn (scale, cache, queue) vs dài hạn (redesign) → rủi ro.
| Câu chuyện | Dùng cho câu hỏi về |
|---|---|
| Đồ án tốt nghiệp / đồ án nhóm lớn | teamwork, mâu thuẫn, deadline, leadership |
| Kỳ thực tập | mắc lỗi, nhận feedback, học công nghệ mới |
| Dự án cá nhân / hackathon | chủ động, đam mê kỹ thuật, học nhanh |
| CLB / part-time | giao tiếp, xử lý người khó tính |
| Một lần fail thật sự | câu thất bại, bài học |
Mỗi chuyện viết ra giấy theo khung STAR, tập nói to đến khi kể trơn tru trong ~90 giây.
Ý đồ: kiểm tra sự tự tin, khả năng tóm tắt, mức độ phù hợp vị trí.
Khung: Học vấn (1 câu) → kinh nghiệm nổi bật nhất liên quan backend (2–3 câu, có công nghệ cụ thể) → điểm mạnh có dẫn chứng (1 câu) → vì sao ứng tuyển (1 câu).
Bài mẫu:
"Em chào anh/chị, em là [Tên], vừa tốt nghiệp ngành CNTT trường [X]. Trong quá trình học, em tập trung theo hướng backend: đồ án tốt nghiệp của em là hệ thống [Y] dùng [Spring Boot/NodeJS], em phụ trách thiết kế REST API, database và phân quyền JWT. Em cũng có [3–6 tháng] thực tập tại [Z], tham gia viết API và fix bug trong dự án thật. Điểm mạnh của em là code cẩn thận và học công nghệ mới nhanh — trong kỳ thực tập em tự học Docker trong 2 tuần để phục vụ task được giao. Em ứng tuyển VPBank vì muốn làm backend trong môi trường có bài toán giao dịch lớn, yêu cầu độ chính xác cao — nơi em tin mình trưởng thành nhanh nhất."
Lỗi tránh: kể lại CV theo dòng thời gian từ cấp 3; nói quá 90 giây; không có chi tiết kỹ thuật nào.
Ý đồ: xử lý xung đột có văn minh không, có tìm nguyên nhân gốc không.
Bài mẫu:
"Trong đồ án tốt nghiệp, nhóm em 4 người xây hệ thống đặt lịch khám bệnh; em phụ trách backend, một bạn phụ trách frontend. Giữa kỳ, em và bạn ấy mâu thuẫn về thiết kế API: bạn muốn backend trả dữ liệu gộp sẵn theo từng màn hình cho frontend đỡ xử lý, còn em muốn thiết kế theo resource chuẩn REST để dễ bảo trì. Tranh luận qua nhóm chat mấy ngày không ai nhường, phần tích hợp đứng lại.
Em nhận ra càng cãi qua tin nhắn càng căng, nên chủ động hẹn bạn nói chuyện trực tiếp. Em hỏi lý do thật sự trước, mới biết bạn đang quá tải vì ôm cả UI lẫn logic hiển thị nên muốn đẩy bớt xử lý sang backend. Hiểu ra vấn đề gốc là khối lượng việc chứ không phải đúng sai kỹ thuật, em đề xuất dung hòa: API chính vẫn theo resource, em viết thêm endpoint tổng hợp cho 2 màn hình phức tạp nhất, và nhận hỗ trợ phần validate.
Kết quả tích hợp xong đúng tiến độ, đồ án 9 điểm. Bài học của em: khi mâu thuẫn, phải tìm nguyên nhân thật sự đằng sau quan điểm của đối phương, và nói chuyện trực tiếp thay vì qua tin nhắn."
Lỗi tránh: kể mâu thuẫn cá nhân (ghét nhau, tính cách); kể xong phần mình thắng — trọng tâm phải là cách hòa giải; nói "em chưa từng mâu thuẫn với ai" (bị coi là né tránh hoặc thiếu trải nghiệm).
Follow-up có thể bị hỏi: "Cụ thể em mở lời thế nào?", "Nếu bạn đó vẫn không chịu thì sao?"
Ý đồ: trung thực, dám nhận trách nhiệm, có học được gì không. Với ngân hàng, đây là câu quan trọng nhất — họ sợ nhất người giấu lỗi.
Bài mẫu:
"Trong kỳ thực tập, em được giao viết API cập nhật thông tin người dùng. Em test trên máy thấy ổn nên push code, được merge vào nhánh dev. Nhưng em không kiểm tra trường hợp một field bị null từ dữ liệu hệ thống cũ, nên hôm sau API lỗi 500 hàng loạt trên môi trường test, team QA bị block gần nửa buổi.
Việc đầu tiên em làm là báo ngay cho mentor thay vì im lặng tự sửa, để team biết nguyên nhân và QA không mất thời gian truy tìm. Sau đó em rollback, viết fix kèm unit test cho case null và các case biên tương tự. Quan trọng hơn, em tự đặt quy trình cho bản thân: trước mỗi lần push luôn tự review lại diff, viết test cho case biên, và test với dữ liệu giống môi trường thật chứ không chỉ dữ liệu tự tạo.
Từ đó đến cuối kỳ em không lặp lại lỗi tương tự, mentor đánh giá cao việc báo sớm và thẳng thắn. Em nghĩ với backend ngân hàng bài học này càng quan trọng, vì một lỗi dữ liệu nhỏ cũng ảnh hưởng trực tiếp đến khách hàng."
Lỗi tránh: đổ lỗi hoàn cảnh/người khác; chọn "thất bại giả" (kiểu "em ôn thi hơi trễ nhưng vẫn được A"); quên phần thay đổi hành vi sau đó.
Follow-up: "Mentor phản ứng thế nào?", "Vì sao lúc đó em không nghĩ đến case null?"
Ý đồ: ưu tiên hóa, chịu áp lực, có dám báo sớm không.
Bài mẫu:
"Kỳ trước em có 3 môn thi cuối kỳ trong cùng một tuần với buổi demo giữa kỳ đồ án, trong khi phần backend của em còn 2 tính năng chưa xong. Việc đầu tiên em làm là liệt kê hết mọi việc và đánh giá tác động: em nhận ra buổi demo chỉ thực sự cần 1 trong 2 tính năng, cái còn lại demo bằng dữ liệu giả được. Em chủ động trao đổi với nhóm để thống nhất thu hẹp phạm vi demo, thay vì im lặng cố làm hết rồi trễ. Sau đó em chia lịch cụ thể — sáng ôn thi, tối làm đồ án — và tắt thông báo mạng xã hội cả tuần. Kết quả demo suôn sẻ, các môn thi đều trên 8. Bài học của em: khi quá tải, quan trọng nhất không phải cố làm nhanh hơn, mà là chọn đúng việc và báo sớm cho người liên quan."
Lỗi tránh: trả lời chung chung "em sẽ cố gắng hết sức, thức khuya làm cho xong" — đây là red flag, không phải điểm cộng.
Ý đồ: có tìm hiểu thật không, hay rải CV hàng loạt.
Khung: điều cụ thể em biết về VPBank → khớp với định hướng của em → điều em mang lại.
Bài mẫu:
"Em chọn VPBank vì ba lý do. Thứ nhất, VPBank là một trong những ngân hàng đẩy mạnh chuyển đổi số mạnh nhất với VPBank NEO có hàng triệu người dùng — nghĩa là bài toán backend ở đây là bài toán thật về xử lý giao dịch lớn, độ ổn định và bảo mật, đúng môi trường mà fresh backend học nhanh nhất. Thứ hai, VPBank có hợp tác chiến lược với SMBC và đầu tư mạnh vào công nghệ, nên em tin định hướng phát triển kỹ sư ở đây nghiêm túc, dài hạn. Thứ ba, em muốn gắn với domain tài chính – ngân hàng ngay từ đầu sự nghiệp, vì domain này đòi hỏi sự chính xác và kỷ luật cao trong code, đúng cách em muốn rèn bản thân."
Lỗi tránh: "vì công ty lớn, lương tốt, gần nhà"; nói được với ngân hàng nào cũng đúng.
Bài mẫu:
"Em thích phần logic và dữ liệu đằng sau sản phẩm hơn giao diện. Trải nghiệm khiến em chắc chắn là khi làm đồ án, có trang danh sách load mất hơn 5 giây; em đọc query log, phát hiện vấn đề N+1 query và tối ưu còn khoảng 300ms. Cảm giác truy ra tận gốc vấn đề và thấy con số cải thiện rõ ràng khiến em biết đây là việc dành cho mình. Em cũng xác định backend ngân hàng là nơi tốt nhất để đi sâu về transaction, tính nhất quán dữ liệu và hiệu năng."
Điểm mấu chốt: phải có một trải nghiệm cụ thể làm bằng chứng, không chỉ "em thích logic".
Ý đồ: tự nhận thức, coachability (có tiếp thu để sửa không).
Công thức: điểm yếu thật + không chí mạng với vị trí + ví dụ ngắn + đang khắc phục thế nào + tiến bộ.
Bài mẫu:
"Điểm yếu của em là có xu hướng tự mò quá lâu khi gặp vấn đề khó, vì ngại làm phiền người khác. Đầu kỳ thực tập, có lần em mất gần một ngày tự debug một lỗi cấu hình mà nếu hỏi mentor chỉ mất 10 phút. Sau khi được góp ý, em đặt quy tắc: bế tắc quá 45 phút thì tổng hợp những gì đã thử rồi đi hỏi, kèm ngữ cảnh rõ ràng để người được hỏi trả lời nhanh. Cách này giúp em không lãng phí thời gian của team mà vẫn giữ thói quen tự tìm hiểu trước."
Lỗi tránh: điểm yếu giả ("em cầu toàn quá", "em tham công tiếc việc"); điểm yếu chí mạng ("em hay ẩu", "em không thích làm việc nhóm"); nói xong không có phần khắc phục.
Ý đồ: cân bằng giữa chính kiến và tinh thần tổ chức — ngân hàng rất quan tâm vì có hierarchy rõ.
Bài mẫu:
"Trước hết em xem lại cách mình trình bày, vì nhiều khi ý kiến đúng nhưng chưa thuyết phục là do thiếu dẫn chứng. Em sẽ chuẩn bị lại với dữ liệu cụ thể — benchmark, số liệu, hoặc một bản demo nhỏ — và chọn thời điểm trao đổi riêng thay vì tranh luận giữa cuộc họp. Nếu team hoặc sếp vẫn quyết theo hướng khác, em tôn trọng và làm hết sức theo quyết định chung, vì có thể sếp có thông tin về bối cảnh mà em chưa thấy. Nhưng em sẽ theo dõi kết quả, để nếu rủi ro em dự đoán xảy ra thật thì có sẵn phương án và góp ý kịp thời."
Lỗi tránh: hai cực đoan — "em sẽ bảo vệ đến cùng vì em đúng" hoặc "sếp nói gì em nghe đó".
Bài mẫu:
"1–2 năm đầu, mục tiêu của em là nắm vững hệ thống và nghiệp vụ ngân hàng, trở thành người nhận trọn vẹn một module và chịu trách nhiệm về chất lượng của nó. Từ năm 3 đến năm 5, em muốn thành kỹ sư backend vững về thiết kế hệ thống — tham gia thiết kế các service quan trọng, review code cho thành viên mới, đi sâu vào các bài toán đặc thù của ngân hàng như xử lý giao dịch và tính nhất quán dữ liệu. Em muốn đi chuyên môn sâu trước; quản lý hay không sẽ tùy cơ hội và thế mạnh bộc lộ trong quá trình làm việc."
Lỗi tránh: "em muốn làm manager/CTO" (sáo rỗng với fresh); "em chưa nghĩ tới" (thiếu định hướng); mục tiêu không liên quan gì đến vị trí đang tuyển.
Ý đồ: rất hay hỏi fresh backend — khả năng tự học quyết định tốc độ onboard.
Bài mẫu:
"Kỳ thực tập, em được giao viết tính năng cache bằng Redis trong khi em chưa từng dùng Redis. Em bắt đầu bằng đọc tài liệu chính thức và làm một ví dụ nhỏ chạy được ngay trong buổi đầu, thay vì đọc lý thuyết quá lâu. Sau đó em đọc code sẵn có trong dự án xem team dùng pattern nào, và hỏi mentor 2 câu về convention của team. Khoảng 3 ngày em hoàn thành tính năng kèm test. Cách học của em: làm ví dụ nhỏ chạy được sớm nhất có thể, học qua code thật của dự án, và hỏi đúng người đúng câu."
Ý đồ: tự đánh giá trung thực — họ đã quan sát bạn suốt buổi, đừng tô vẽ.
Khung trả lời: 1 đóng góp cụ thể ("em là người đề xuất khung thời gian / tổng hợp 2 luồng ý kiến lúc nhóm bế tắc") + 1 điều làm chưa tốt ("em nghĩ mình có thể chủ động mời bạn X phát biểu sớm hơn") + đánh giá công bằng về nhóm (khen cụ thể 1–2 bạn).
Luôn hỏi — không hỏi bị xem là thiếu quan tâm. 3 câu gợi ý:
Nhớ: fresh graduate không bị đòi hỏi trả lời xuất sắc mọi thứ. Thứ họ tìm ở vòng này là thái độ hợp tác, tư duy có cấu trúc, và sự trung thực khi không biết.