[Hanoi] Principal/Lead Fullstack QA Engineer (Auto, AI)

Không có framework tốt nhất, chỉ có cái hợp với sản phẩm và team.

• Loại ứng dụng: web, mobile (Appium hoặc framework native), desktop, API.
• Ngôn ngữ của team: nên trùng với dev để họ cùng review và viết test.
• Trình duyệt cần hỗ trợ, có cần nhiều tab/domain, iframe, file upload.
• Tốc độ và độ ổn định: auto-wait, chạy song song, retry, trace khi lỗi.
• Tích hợp CI/CD, báo cáo, chạy trên container.
• Cộng đồng, tài liệu, khả năng tuyển người.

Ví dụ: "Dự án web mới, team dùng TypeScript, em chọn Playwright vì auto-wait giảm test chập chờn, chạy song song sẵn, có trace viewer để debug. Selenium vẫn hợp với dự án Java có sẵn nhiều script."

Hay sai: chọn vì "đang hot" mà không có lý do gắn với dự án.

Flaky test làm team mất niềm tin vào automation, nên cần xử lý có hệ thống chứ không chỉ bấm chạy lại.

Nguyên nhân thường gặp:

• Chờ bằng sleep cứng thay vì chờ điều kiện (element hiển thị, API trả về).
• Locator dễ vỡ (XPath dài, phụ thuộc thứ tự); nên dùng data-testid hoặc role.
• Dữ liệu test dùng chung, test phụ thuộc thứ tự chạy.
• Môi trường test không ổn định, dịch vụ bên thứ ba.

Cách làm:

• Theo dõi tỷ lệ fail từng test, cách ly test flaky khỏi pipeline chặn release cho tới khi sửa.
• Mỗi test tự tạo và dọn dữ liệu của mình; mock dịch vụ ngoài khi phù hợp.
• Lưu screenshot, video, trace khi fail để tìm nguyên nhân.

Hay sai: cấu hình retry thật nhiều để che lỗi.

Bắt đầu từ hiểu hiện trạng và rủi ro, rồi cải thiện từng bước thay vì áp nguyên một quy trình nặng.

• Tuần đầu: tìm hiểu sản phẩm, luồng nghiệp vụ chính, lịch sử bug sau release, cách team đang làm việc.
• Nền tảng: thống nhất quy trình bug (template, severity, vòng đời ticket), Definition of Done có bước test, môi trường test tách khỏi production.
• Shift-left: tham gia refinement để làm rõ acceptance criteria trước khi code.
• Phủ test: bộ smoke cho luồng quan trọng, sau đó automation dần (ưu tiên API), đưa vào CI.
• Đo lường: số bug lọt ra production, thời gian xử lý bug, độ phủ regression, để chứng minh hiệu quả.

Người phỏng vấn muốn nghe: bạn biết ưu tiên, làm việc với dev chứ không đứng ngoài "bắt lỗi", và đo được kết quả.

Ba chỉ số chính đo trải nghiệm thật của người dùng:

• LCP (Largest Contentful Paint): thời gian hiện phần tử lớn nhất. Cải thiện: tối ưu ảnh (định dạng hiện đại, đúng kích thước, ưu tiên tải ảnh hero), giảm thời gian phản hồi server, cache/CDN, render phía server.
• INP (Interaction to Next Paint, thay FID từ 2024): độ trễ khi tương tác. Cải thiện: chia nhỏ tác vụ JS dài, giảm JS chạy trên main thread, tránh render lại quá nhiều.
• CLS (Cumulative Layout Shift): độ xô lệch bố cục. Cải thiện: khai báo kích thước cho ảnh, video, quảng cáo; tránh chèn nội dung đẩy trang xuống; xử lý font.

Ngoài ra: code splitting và lazy load theo route, bỏ thư viện nặng không cần, nén và cache tài nguyên tĩnh.

Người phỏng vấn muốn nghe: bạn đo bằng dữ liệu người dùng thật (field data) lẫn Lighthouse, và biết điểm Lighthouse không phải là mục tiêu cuối.

• XSS: kẻ tấn công chèn script chạy trên trang của bạn. Phòng: framework tự escape khi render; tránh innerHTML, v-html, dangerouslySetInnerHTML với dữ liệu người dùng (nếu bắt buộc thì sanitize); cấu hình Content-Security-Policy.
• CSRF: trang lạ khiến trình duyệt gửi request kèm cookie của người dùng. Phòng: cookie SameSite=Lax hoặc Strict, CSRF token, kiểm tra Origin.
• CORS: là cơ chế trình duyệt nới lỏng same-origin policy, do server cấu hình. Nó không phải lớp bảo vệ API khỏi người gọi ngoài trình duyệt.

Lưu token:

• localStorage tiện nhưng script XSS nào cũng đọc được.
• Cookie HttpOnly + Secure + SameSite thì JS không đọc được, nhưng phải tính đến CSRF.

Người phỏng vấn muốn nghe: không có chỗ lưu nào an toàn tuyệt đối; chặn XSS mới là việc quan trọng nhất, vì có XSS thì mọi cách lưu đều bị lợi dụng.

Agent cho LLM tự quyết định gọi tool theo nhiều bước, nên lỗi và rủi ro tăng theo số bước; cần giới hạn quyền và kiểm soát chặt.

• Tool rõ ràng: mô tả và schema tham số chặt, kiểm tra đầu vào bằng code trước khi thực thi.
• Quyền tối thiểu: tool chỉ đọc khi có thể; thao tác ghi, xoá, chuyển tiền cần người xác nhận.
• Prompt injection: nội dung lấy từ web, email, tài liệu là dữ liệu không tin cậy; không để nó điều khiển tool nhạy cảm.
• Giới hạn số bước, timeout, ngân sách token; xử lý lỗi tool và cho phép thử lại có kiểm soát.
• Log và tracing toàn bộ chuỗi hành động để audit.
• Đánh giá theo tỷ lệ hoàn thành tác vụ trên bộ kịch bản.

Người phỏng vấn muốn nghe: workflow cố định thường đủ; chỉ dùng agent tự do khi thật cần.

Đừng đợi tài liệu hoàn hảo; chủ động làm rõ và ghi lại giả định.

• Đặt câu hỏi cụ thể cho BA/PO ngay từ lúc refinement, ưu tiên những chỗ ảnh hưởng tới acceptance criteria.
• Tham khảo nguồn khác: bản thiết kế UI, hệ thống cũ, sản phẩm tương tự, hỏi dev về logic đã code.
• Viết test scenario ở mức cao trước, ghi rõ giả định, gửi lại cho BA/PO xác nhận.
• Kết hợp exploratory testing theo session có mục tiêu và ghi chú.
• Chỗ chưa rõ thì log thành câu hỏi/ticket thay vì tự quyết là bug hay không.

Người phỏng vấn muốn nghe: bạn chủ động và minh bạch. Ví dụ: "Em gửi danh sách 8 câu hỏi kèm giả định, PO trả lời 6, 2 câu còn lại em đánh dấu là rủi ro trong test report."

Giữ bình tĩnh, dựa vào bằng chứng và requirement, không tranh cãi cảm tính.

• Kiểm tra lại: đúng build, đúng môi trường, đúng dữ liệu chưa? Có thể do cache hoặc tài khoản test khác nhau.
• Bổ sung video, log, request/response; nếu được thì ngồi tái hiện cùng dev.
• Nếu tranh luận là "đúng thiết kế hay không", dẫn chiếu acceptance criteria. Requirement không nói rõ thì kéo BA/PO vào quyết định.
• Bug thỉnh thoảng mới xảy ra: ghi tần suất, điều kiện nghi ngờ, giữ ticket mở để theo dõi.

Hay sai: đóng ticket cho xong chuyện, hoặc biến nó thành chuyện cá nhân. Câu trả lời tốt cho thấy bạn coi dev là đồng đội cùng bảo vệ chất lượng.

"I'm working on an e-commerce platform that handles orders for several retail brands. The system is built with microservices on Node.js, using PostgreSQL and Redis, deployed on AWS. My team has six people and we work in two-week sprints. I'm mainly in charge of the order and payment services. Recently, I led the integration with a new payment gateway, from reading the API docs to handling edge cases like timeouts and duplicate callbacks."

Mẹo: đi từ tổng quan (sản phẩm làm gì, cho ai) tới vai trò của riêng bạn. Nói "my team" và "I" rõ ràng để người nghe biết phần nào bạn làm. Không cần kể tên khách hàng nếu bị ràng buộc bảo mật.

Chọn một hai điểm mạnh liên quan tới vị trí, và chứng minh bằng ví dụ thật, không liệt kê tính từ.

Cấu trúc: điểm mạnh, ví dụ ngắn, kết quả, liên hệ với công việc mới.

Câu mẫu: "Điểm mạnh của em là chủ động tìm nguyên nhân gốc. Ở dự án trước, hệ thống thỉnh thoảng bị timeout mà không ai tái hiện được. Em tự đọc log, thêm theo dõi ở các điểm nghi ngờ và tìm ra một truy vấn bị khoá bảng vào giờ cao điểm. Sau khi sửa, lỗi đó không còn xuất hiện. Em nghĩ điều này hữu ích với vị trí bên mình vì hệ thống có lượng truy cập lớn."

Hay sai: "Em chăm chỉ, ham học hỏi, chịu được áp lực" mà không có ví dụ. Ai cũng nói vậy nên không đọng lại gì.