30 câu hỏi phỏng vấn Selenium phiên bản Nói và Code

Vấn đề với các bộ câu hỏi đang trôi nổi trên mạng

Hãy thử click vào bất kỳ bài "Top 50 câu hỏi phỏng vấn Selenium" nào trên mạng tiếng Việt hiện tại. Bạn sẽ thấy chúng giống nhau đến mức buồn cười:

Q: Selenium là gì? A: Selenium là một bộ công cụ tự động hóa trình duyệt mã nguồn mở do Jason Huggins phát triển năm 2004...

Q: Sự khác nhau giữa findElement và findElements? A: findElement trả về một WebElement, findElements trả về danh sách WebElement...

Vấn đề là không interviewer nào hỏi vậy nữa. Họ không cần bạn đọc Wikipedia. Họ đã có ChatGPT cho việc đó. Họ muốn biết:

• Bạn đã từng có một test fail 30% trên CI mà pass 100% local chưa? Bạn debug ra sao?
• Suite của team bạn chạy 45 phút, bạn tối ưu xuống thế nào?
• Khi nào bạn chọn Selenium thay vì Playwright? Đừng nói "Selenium tốt hơn".
• Team bạn handle session login giữa các test ra sao? Đăng nhập mỗi test à?
• Bạn review một PR test của junior, bạn reject vì lý do gì?

Đây là câu hỏi của người đang đi tuyển một đồng nghiệp thật sự. Và đây cũng là câu mà người làm 6 tháng với người làm 4 năm trả lời khác nhau một trời một vực.

Vì sao Selenium vẫn quan trọng năm 2026?

Một điều cần thẳng thắn: cộng đồng dev front-end đang nói về Playwright và Cypress nhiều hơn Selenium. Có người thậm chí khuyên người mới bỏ qua Selenium.

Đây là lời khuyên sai cho thị trường Việt Nam.

Lý do: phần lớn enterprise và outsourcing tại Việt Nam vẫn chạy trên Java và .NET — hai stack mà Selenium có ecosystem mạnh nhất, được chống lưng lâu năm nhất. Một dự án bảo hiểm, ngân hàng, ERP đã đầu tư hàng nghìn giờ test với Selenium Grid trên CI sẽ không "vứt đi để dùng Playwright". Họ tuyển người bảo trì và mở rộng suite Selenium hiện tại.

Hơn nữa, Selenium 4 đã trưởng thành đáng kể:

• W3C WebDriver Protocol chuẩn hóa, ổn định hơn nhiều so với Selenium 3
• Selenium Manager tự quản lý driver — không còn nỗi đau "ChromeDriver version mismatch"
• Chrome DevTools Protocol mở khóa network interception, performance metrics, mock response
• Relative Locators cho test layout
• Grid 4 viết lại hoàn toàn, scale tốt với Docker

Nói cách khác: nếu bạn nhắm vị trí QA Automation ổn định, lương khá, dự án lớn — Selenium vẫn là kỹ năng cốt lõi. Học Playwright thêm là tốt, nhưng đừng bỏ Selenium.

Bộ tài liệu này có gì khác?

Sau nhiều buổi phỏng vấn thật (cả vai trò ứng viên lẫn người tuyển), mình tổng hợp lại 30 câu hỏi mà mình thấy hay xuất hiện nhất trong các buổi phỏng vấn Selenium tại Việt Nam và quốc tế. Mỗi câu được viết theo công thức 4 lớp:

1. Vì sao interviewer hỏi câu này — hiểu được intent để trả lời đúng hướng. Câu hỏi về implicit wait không phải để check bạn biết định nghĩa, mà để xem bạn có biết tại sao không nên dùng nó.
2. Câu trả lời ở mức senior — không phải lý thuyết khô, mà là cách một người đã làm thật sẽ kể lại. Có ví dụ thật, có con số cụ thể, có thừa nhận trade-off.
3. Mẹo nói hoặc câu chốt trademark — một câu ngắn gọn để in dấu vào trí nhớ interviewer. Sau buổi phỏng vấn họ có thể quên chi tiết, nhưng nhớ "ứng viên hôm nay nói cái gì về sleep ấy nhỉ".
4. Bẫy thường gặp và follow-up question — chuẩn bị sẵn cho câu truy ngược. Khi bạn trả lời tốt, interviewer sẽ đào sâu — đây là chỗ phân loại ứng viên.

Hai phiên bản — hai mục đích khác nhau

Mình chia thành 2 phiên bản vì thực tế phỏng vấn có 2 dạng rất khác:

📘 Phiên bản 1 — Phỏng vấn nói miệng (19 trang PDF):

Dành cho vòng HR screen, vòng technical interview qua call, hoặc trao đổi face-to-face không có laptop. Interviewer hỏi miệng, bạn trả lời miệng.

Câu trả lời viết theo nhịp điệu hội thoại — không có code block, không có tên method khô khan như getWindowHandles() hay WebDriverWait. Thay vào đó là "lấy danh sách tab đang mở", "chờ có điều kiện". Mỗi câu kèm phần 💡 Mẹo nói hướng dẫn nhấn ý nào, dùng câu chốt ra sao.

Đọc to 2-3 lần là thuộc nhịp — không phải thuộc lòng từng chữ, mà thuộc cách dẫn dắt câu chuyện.

📗 Phiên bản 2 — Thực chiến có code (66 trang PDF):

Dành cho vòng live coding, take-home assignment, hoặc khi bạn muốn ôn kỹ thuật trước phỏng vấn. Java 100% với Selenium WebDriver 4 + TestNG/JUnit 5 — stack chuẩn enterprise.

Mỗi câu có code thật chạy được, kèm các bẫy thường gặp, anti-pattern cần tránh, và best practice từ kinh nghiệm thực tế. Có thể copy code này dùng thẳng cho dự án.

Một vài câu hỏi tiêu biểu trong bộ tài liệu

Để bạn hình dung tone và độ sâu, đây là vài ví dụ ngắn:

Câu hỏi 9 — Thread.sleep, khi nào chấp nhận được?

Câu hỏi này là một cái bẫy. Đừng trả lời "tuyệt đối không bao giờ" — interviewer sẽ counter bằng tình huống bất khả kháng. Cũng đừng nói "tùy trường hợp" mà không cụ thể.

Cách trả lời tốt: thừa nhận có một vài trường hợp nhỏ (debug local, chờ animation không có hook, reproduce race condition cố ý), nhưng nhấn vào quy tắc chung. Câu chốt trademark:

"Sleep là che bug, không phải fix bug. Nếu test cần sleep để pass, có nghĩa là tôi chưa hiểu vì sao test đang flaky."

Câu hỏi 11 — Em đã debug flaky test ra sao?

Đây là câu phân biệt rõ nhất giữa người làm 3 tháng và người làm 3 năm. Câu trả lời lý thuyết "thì retry thôi" lập tức loại bạn khỏi vị trí mid-senior.

Câu trả lời tốt là kể một case thật theo công thức: triệu chứng → bằng chứng → nguyên nhân gốc → fix → kết quả đo được. Ví dụ: "Test fail 20% trên CI nhưng pass 100% local. Em bật screenshot khi fail, video record, console log. Sau 20 lần chạy có dữ liệu — phát hiện call API trên CI mất 1.8 giây trong khi local chỉ 200ms. Element xuất hiện trong DOM nhưng bị overlay che. Fix bằng đổi điều kiện chờ từ visibilityOf sang elementToBeClickable. Sau fix, fail rate về 0 sau 200 lần chạy."

Câu chốt: "Flaky test không phải để retry, mà để học."

Câu hỏi 24 — Login một lần dùng cho mọi test

Đây là kỹ thuật tối ưu suite mạnh nhất mà nhiều team chưa biết. Nếu mỗi test bạn đăng nhập qua UI — gõ email, gõ password, chờ chuyển trang — bạn đang lãng phí 5-10 giây mỗi test. Suite 100 test là 10 phút thuần lãng phí.

Bộ tài liệu code mẫu cách inject cookie và session từ một lần login duy nhất, hoặc cao cấp hơn là login qua API và set token vào localStorage — bypass UI hoàn toàn.

Mình đã từng dùng kỹ thuật này giảm thời gian một suite của dự án từ 25 phút xuống 9 phút mà không bỏ test nào.

Cấu trúc 3 phần — từ căn bản đến nâng cao

Cả 2 phiên bản đều có cùng cấu trúc 30 câu chia 3 phần:

Phần 1 — Căn bản (Câu 1-10): Khái niệm cốt lõi, 8 loại locator, wait pattern, Page Object Model, stale element, Actions API, alert/frame/window, upload/download, screenshot khi fail, JavaScript executor.

Phần 2 — Framework và best practices (Câu 11-20): Project structure Maven, parallel execution với JUnit 5, Selenium Grid Docker, test data management, cookie injection và API login, retry mechanism, logging, Allure report, CI/CD GitHub Actions, cross-browser config.

Phần 3 — Nâng cao và kỹ thuật đặc biệt (Câu 21-30): Selenium 4 Relative Locators, Chrome DevTools Protocol network interception, performance metrics, visual regression testing, mobile web testing, database verification, BrowserStack/Sauce Labs integration, custom expected conditions, accessibility testing với axe-core, Page Factory pattern.

Cách dùng tài liệu hiệu quả nhất

Đây là routine 1 tuần mình khuyên ứng viên nghiêm túc:

Ngày 1-2: Đọc lướt cả 2 file để hình dung tổng thể. Đánh dấu các câu mình không tự tin trả lời.

Ngày 3-4: Tập trung vào Phần 1 (10 câu căn bản). Đây là 80% câu hỏi sẽ được hỏi. Đọc to bản nói, gõ thử code của bản thực chiến.

Ngày 5-6: Phần 2 và 3 — đọc kỹ các case thật, các con số. Đây là chỗ tạo khác biệt giữa ứng viên giỏi và ứng viên xuất sắc.

Ngày 7: Tự phỏng vấn — bật ghi âm, lấy random 10 câu trả lời. Nghe lại sẽ phát hiện chỗ nào còn ấp úng. Lặp lại 2-3 lần là tự tin.

Trước buổi phỏng vấn 1-2 giờ: Lướt lại các "câu chốt trademark" trong bản nói. Một câu chốt đắt giá có thể quyết định cả buổi phỏng vấn.

Một số quan điểm mình muốn chia sẻ thêm

Đừng cố thuộc lòng. Interviewer giỏi sẽ phát hiện ngay trong 30 giây đầu nếu bạn đang đọc thuộc. Họ sẽ đặt câu hỏi xoáy ngược để kiểm tra. Tài liệu này dùng để hiểu, không phải để nhớ.

Có case thật của mình. Mỗi câu trong bộ tài liệu có ví dụ — nhưng đó là ví dụ của mình. Bạn nên có 3 case story của riêng bạn: một về flaky test, một về tối ưu performance, một về xử lý feature khó. Mọi câu hỏi tình huống đều có thể quy về một trong ba case này.

Thành thật khi không biết. Câu "em chưa làm cụ thể cái này nhưng em sẽ tiếp cận theo cách..." mạnh hơn nhiều so với câu trả lời nửa vời. Interviewer trân trọng người biết cách học, không phải người biết tất cả.

Hỏi ngược lại interviewer. Cuối buổi, một câu hỏi tốt thể hiện bạn quan tâm thật sự: "Suite hiện tại của team chạy bao lâu? Tỉ lệ flaky là bao nhiêu?" — Nếu họ ấp úng hoặc nói "rất nhiều", đó là red flag về văn hóa engineering của công ty. Bạn cũng nên có quyền chọn lựa.

Download tài liệu

Cả 2 file PDF đều miễn phí, có thể tải về dùng offline, in ra hoặc đọc trên iPad. Footer mỗi trang có link Anh Tester để bạn ghi nhớ nguồn gốc và quay lại khi cần thêm tài liệu khác.

📘 30 câu hỏi phỏng vấn Selenium — Phiên bản phỏng vấn nói (19 trang)

📗 30 câu hỏi phỏng vấn Selenium — Phiên bản thực chiến có code (66 trang)

Lời chốt

Selenium không phải là tool "hot" trên Twitter, không có người làm content hô hào 24/7 như Playwright hay Cypress. Nhưng nó là kỹ năng thực dụng trả tiền lương ổn định cho hàng nghìn QA Engineer tại Việt Nam và toàn cầu mỗi năm.

Mục tiêu của bộ tài liệu này không phải là biến bạn thành "chuyên gia Selenium". Mục tiêu là giúp bạn tự tin bước vào buổi phỏng vấn tiếp theo với đủ vũ khí để trả lời mọi câu hỏi thường gặp, và biết cách phản ứng khôn ngoan với câu hỏi mới.

Chúc bạn phỏng vấn thành công. Nếu tài liệu giúp ích, hãy chia sẻ cho đồng nghiệp đang cần — đây là cách tốt nhất để cộng đồng QA Việt Nam mạnh lên.

Anh Tester — Chia sẻ kiến thức Test Automation cho cộng đồng QA Việt Nam

🌐 https://anhtester.com