QA QC

Lúc mới bắt đầu tìm việc trong ngành Information Technology, mình từng nghĩ CV chỉ cần ghi đủ thông tin là được. Mình cố gắng nhét thật nhiều thứ vào CV: kỹ năng, môn học, chứng chỉ, thậm chí cả những thứ mình chỉ mới biết sơ qua. Nhưng sau khi gửi rất nhiều CV mà gần như không nhận được phản hồi, mình mới nhận ra vấn đề không phải là “mình biết ít”, mà là CV chưa thể hiện đúng giá trị bản thân.Sai lầm lớn nhất trước đây của mình là viết CV theo kiểu liệt kê. Ví dụ: “Có kiến thức về testing”  “Biết SQL”  “Đã học API”  “Có kỹ năng teamwork” Mọi thứ nghe khá chung chung và ai cũng có thể viết như vậy. Nhà tuyển dụng đọc xong sẽ rất khó hình dung mình thực sự đã làm gì.Có một thời gian mình gửi CV khá nhiều nhưng tỉ lệ được gọi phỏng vấn rất thấp. Lúc đó mình bắt đầu nhờ người có kinh nghiệm review CV và mới nhận ra CV của mình thiếu tính thực tế. Nó giống một bản “kể mình học gì” hơn là cho thấy mình có thể làm được gì.Thay đổi lớn nhất giúp mình nhận được nhiều lời mời phỏng vấn hơn là: Viết cụ thể hơn về trải nghiệm,  Tập trung vào dự án thực tế,  Và mô tả công việc theo hướng kết quả thay vì chỉ liệt kê nhiệm vụ. Ví dụ thay vì ghi: “Test website và log bug” Mình đổi thành: “Thiết kế testcase và kiểm thử chức năng cho hệ thống web, phối hợp cùng Dev để verify bug và hỗ trợ regression test trước release.” Hoặc thay vì chỉ ghi: “Biết API testing” Mình bổ sung: “Sử dụng Postman để kiểm tra request/response API, verify dữ liệu bằng SQL.” Chỉ những thay đổi nhỏ như vậy thôi nhưng CV có cảm giác thực tế và chuyên nghiệp hơn rất nhiều.Ngoài ra, mình cũng bắt đầu bỏ bớt những thứ không cần thiết khỏi CV: Kỹ năng quá cơ bản,  Thông tin dài dòng,  Hoặc những công nghệ mình chưa thực sự sử dụng. Trước đây mình nghĩ càng viết nhiều càng tốt, nhưng sau này mình nhận ra nhà tuyển dụng thường chỉ dành rất ít thời gian để đọc CV. Một CV dễ đọc, rõ ràng và đúng trọng tâm sẽ hiệu quả hơn rất nhiều.Nếu được viết lại CV đầu tiên, mình sẽ: Tập trung vào trải nghiệm thực tế sớm hơn,  Trình bày ngắn gọn hơn,  Và trung thực hơn với năng lực của mình. Theo mình, để CV nổi bật không nhất thiết phải “đánh bóng” quá mức. Điều quan trọng là biết chọn cách trình bày để người đọc nhìn ra giá trị thật của mình. Dù chỉ là fresher hay mới học testing, nếu bạn có dự án thực tế, biết mình đã học được gì và thể hiện điều đó rõ ràng trong CV thì vẫn có thể tạo được ấn tượng tốt.Mình nghĩ một CV tốt không phải là CV hoàn hảo nhất, mà là CV giúp người khác hiểu: “Bạn có thể làm được gì và bạn đang nghiêm túc với công việc này như thế nào.”

Tôi mất 3 tiếng để viết một cái form validation hồi năm ngoái.Tuần trước, tôi describe yêu cầu cho AI trong 2 phút — và nó trả về đúng thứ tôi cần, kèm error message, kèm accessibility attribute, kèm cả test case.3 tiếng xuống còn 2 phút. Tôi không biết nên vui hay nên lo.Rồi tôi nhận ra: câu hỏi đúng không phải là "AI có thay thế được tôi không?" Câu hỏi đúng là — "Nếu phần code không còn là thứ khó nhất, thứ khó nhất bây giờ là gì?"Code chưa bao giờ là sản phẩmNhìn lại 5 năm làm dev, tôi thấy mình đã nhầm một thứ rất căn bản.Tôi nghĩ công việc của tôi là viết code. Nhưng thật ra, công việc của tôi là giải quyết vấn đề của người dùng - và code chỉ là công cụ để làm điều đó.Sự nhầm lẫn này không sao khi code còn khó. Vì khi code khó, bạn bắt buộc phải tập trung vào nó. Nhưng khi AI có thể xử lý phần lớn việc viết code — sự nhầm lẫn đó trở thành điểm yếu chết người.Tôi đã gặp không ít sản phẩm được build bởi những dev giỏi: code sạch, performance tốt, không bug. Nhưng người dùng không dùng. Vì không ai hỏi họ muốn gì. Vì cái flow thanh toán cần đến 7 bước trong khi 3 bước là đủ. Vì button "Xác nhận" nằm ở chỗ không ai nhìn thấy.Code đúng. Sản phẩm sai.Thứ AI không làm được — và có lẽ sẽ không bao giờ làm đượcAI rất giỏi tối ưu thứ đã được định nghĩa. Nhưng nó không biết nên định nghĩa cái gì.Hỏi AI: "Viết cho tôi một màn hình checkout." — Nó làm được.Hỏi AI: "Người dùng của tôi 60% dùng điện thoại, hay bỏ giỏ hàng ở bước nhập địa chỉ, và họ chủ yếu mua vào buổi tối sau khi đi làm về — màn hình checkout nên trông như thế nào?" — Nó cần bạn đặt câu hỏi đó trước.Insight đó không tự nhiên mà có. Nó đến từ việc ngồi xem người thật dùng sản phẩm. Từ việc đọc feedback và nhận ra pattern ẩn sau những lời phàn nàn. Từ việc hiểu rằng người dùng không nói những gì họ thật sự cần — họ chỉ mô tả triệu chứng.Đó là thứ AI không có: sự đồng cảm với người dùng và khả năng đặt câu hỏi đúng về sản phẩm.Thói quen tôi đang xây lại từ đầuTrước đây, khi nhận một task, câu hỏi đầu tiên trong đầu tôi là: "Cái này implement như thế nào?"Bây giờ tôi tập đặt câu hỏi khác trước: "Cái này giải quyết vấn đề gì của ai?"Nghe đơn giản. Nhưng thay đổi được thói quen đó khó hơn học một ngôn ngữ lập trình mới rất nhiều.Tôi bắt đầu ngồi cùng đội support để nghe người dùng phàn nàn về cái gì. Tôi đọc session recording để xem người ta thật sự làm gì trên app — không phải làm gì mà mình nghĩ họ làm. Tôi bắt đầu hỏi PM "tại sao" nhiều hơn hỏi "cái này cần làm gì".Và tôi nhận ra: những cuộc trò chuyện đó cho tôi nhiều context hơn bất kỳ technical document nào. Context mà nếu có, tôi build ra thứ khác hẳn — ít feature hơn, nhưng đúng hơn rất nhiều.Dev full-stack thời AI — rộng hơn, không chỉ là codeAI đã hạ thấp ngưỡng vào của mọi lĩnh vực kỹ thuật. Frontend dev có thể tự làm được backend cơ bản. Backend dev có thể tự dựng infrastructure. Không phải vì họ giỏi hơn — mà vì AI đỡ phần boilerplate, để họ tập trung vào logic thật sự.Nhưng "full-stack" bây giờ không chỉ còn nghĩa là biết cả frontend lẫn backend. Nó đang mở rộng sang một chiều khác: hiểu sản phẩm đủ để đưa ra quyết định kỹ thuật đúng.Dev nào hiểu được tại sao một tính năng quan trọng với người dùng sẽ build nó tốt hơn người chỉ hiểu phải build cái gì. Sự khác biệt đó không nằm ở skill kỹ thuật. Nó nằm ở việc bạn có thật sự quan tâm đến người dùng cuối hay không.Lời khuyên — nếu bạn đang định chỉ học thêm AI toolĐừng dừng lại ở việc dùng AI giỏi hơn.Hãy dùng thời gian AI tiết kiệm được để làm thứ AI không làm thay bạn được: ra ngoài và hiểu người dùng.Ngồi xem một người thật dùng thứ bạn build — chỉ một lần — sẽ thay đổi cách bạn code mãi mãi. Không có prompt nào cho bạn cảm giác đó.Ba thứ tôi nghĩ dev cần đầu tư vào ngay bây giờ:Tư duy sản phẩm — Học cách đọc metric, hiểu user behavior, phân biệt feature người dùng nói họ muốn và feature họ thật sự cần.Kỹ năng quan sát — Xem session recording, đọc support ticket, ngồi cạnh người dùng khi họ dùng app. Đây là nguồn insight không AI nào có thể generate ra.Khả năng nói không có lý do — Biết từ chối build một feature vì nó không giải quyết vấn đề thật — và giải thích được tại sao. Đó là thứ tách dev khỏi code monkey.AI đã biết code. Điều đó không làm dev mất việc — nó làm công việc của dev trở nên thú vị hơn.Vì bây giờ, thứ quan trọng nhất không còn là bạn viết code nhanh đến đâu. Mà là bạn hiểu người dùng sâu đến đâu.Và đó là thứ không có model nào train được.