QA QC

14 posts

Is Being Good at Coding Enough to Grow in the IT Industry?

Huyên Nguyễn

10/06/2026

Tôi không viết nhiều code, nhưng tôi nhận ra IT giỏi không chỉ là viết code giỏi

Khi nhắc đến ngành IT, nhiều người thường nghĩ ngay đến code.Biết nhiều ngôn ngữ lập trình, xử lý được những bài toán khó, viết ra những đoạn code tối ưu — đó chắc chắn là một lợi thế rất lớn.Bản thân tôi cũng từng nghĩ rằng: muốn phát triển trong ngành IT thì điều quan trọng nhất là phải thật giỏi kỹ thuật.Nhưng khi làm QA/Tester, góc nhìn của tôi dần thay đổi.Tôi không phải người viết code nhiều nhất trong team, nhưng để kiểm thử một sản phẩm tốt, tôi nhận ra mình vẫn cần hiểu những gì đang diễn ra phía sau dòng code.Một lỗi có thể không nằm ở giao diện.Nó có thể xuất phát từ logic xử lý, dữ liệu, API hoặc cách các thành phần trong hệ thống kết nối với nhau.Vì vậy, tôi bắt đầu học thêm các kiến thức kỹ thuật như API, SQL và cách hệ thống vận hành.Không phải để trở thành Developer, mà để có thể trao đổi tốt hơn với Developer, hiểu vấn đề sâu hơn và tìm ra nguyên nhân thay vì chỉ nhìn thấy kết quả.Tôi nhận ra một người IT giỏi không chỉ được đánh giá bằng số dòng code viết ra.Một đoạn code tốt cần đi cùng với khả năng hiểu yêu cầu.Một tính năng tốt cần đi cùng với trải nghiệm người dùng.Một sản phẩm tốt cần đi cùng với tư duy giải quyết vấn đề.Đặc biệt khi AI ngày càng phát triển, tôi nghĩ vai trò của kỹ năng kỹ thuật cũng đang thay đổi.AI có thể hỗ trợ viết code nhanh hơn, gợi ý cách xử lý hoặc giúp tự động hóa nhiều công việc.Nhưng AI vẫn cần con người xác định:Bài toán thật sự là gì?Giải pháp nào phù hợp?Kết quả tạo ra có đúng với mục tiêu không?Trong công việc QA, tôi thấy điều này rất rõ.Một công cụ có thể giúp tạo test case nhanh hơn, nhưng việc hiểu sản phẩm, dự đoán rủi ro và đặt đúng câu hỏi vẫn cần tư duy của con người.Tôi cũng nhận ra những kỹ năng tưởng như không liên quan đến code lại ảnh hưởng rất nhiều đến sự phát triển:Khả năng giao tiếp để trao đổi vấn đề.Khả năng học hỏi để thích nghi với công nghệ mới.Khả năng nhìn sản phẩm dưới góc độ người dùng.Theo tôi, code giỏi là một nền tảng quan trọng.Nhưng để thăng tiến trong IT, bạn cần nhiều hơn thế.Bạn cần biết cách biến kiến thức kỹ thuật thành giá trị thực tế.Vì cuối cùng, một người được đánh giá không chỉ bởi việc họ viết được bao nhiêu code, mà bởi họ giúp sản phẩm và đội nhóm tiến lên như thế nào.

Her Tech Story

234

Solo builder: Vibe coding vs Cybersecurity?

Huyên Nguyễn

10/06/2026

Tôi không viết code, nhưng tôi thấy cái giá của việc bỏ qua security

Khi làm QA/Tester, có một thời gian tôi từng nghĩ: chỉ cần một tính năng hoạt động đúng theo yêu cầu thì đó đã là một sản phẩm tốt.Một màn hình hiển thị đúng, một nút bấm hoạt động đúng, dữ liệu trả về đúng kết quả — mọi thứ đều có vẻ ổn.Nhưng càng tham gia nhiều dự án, tôi càng nhận ra có những vấn đề không nằm ở việc “tính năng có chạy hay không”, mà nằm ở câu hỏi: “Nếu người dùng sử dụng sai cách thì chuyện gì sẽ xảy ra?”Đây cũng là lúc tôi nhìn vấn đề security khác đi.Trong quá trình test một hệ thống, tôi từng gặp một tình huống khiến tôi thay đổi cách suy nghĩ. Một chức năng về mặt giao diện hoạt động hoàn toàn bình thường. User không có quyền xem dữ liệu của người khác trên màn hình.Nhưng khi kiểm tra sâu hơn ở phía API, tôi phát hiện nếu thay đổi một vài thông tin trong request, hệ thống vẫn có thể trả về dữ liệu không thuộc quyền truy cập.Về mặt chức năng, tính năng vẫn có thể được xem là “pass”.Nhưng về mặt bảo mật, đó là một rủi ro.Nếu chỉ test theo luồng thông thường:đăng nhậpthao tác đúngkiểm tra kết quả hiển thịthì có thể sẽ bỏ qua những trường hợp quan trọng như:User có thể truy cập dữ liệu của người khác không?API có kiểm tra quyền thật sự không?Dữ liệu nhạy cảm có bị trả về quá nhiều không?Người dùng có thể cố tình thay đổi request để vượt qua giới hạn không?Từ đó, cách test của tôi thay đổi.Tôi không chỉ kiểm tra “happy case” nữa, mà bắt đầu suy nghĩ theo hướng của một người dùng muốn làm sai:“Nếu tôi cố tình đổi ID thì sao?”“Nếu tôi gọi API trực tiếp thì sao?”“Nếu tài khoản này thử truy cập dữ liệu của tài khoản khác thì sao?”Tôi cũng nhận ra một điều: security không nên là việc để đến cuối cùng mới xử lý.Tất nhiên, trong thực tế, các team luôn có áp lực về thời gian. Đặc biệt với những sản phẩm cần ra mắt nhanh, việc cân bằng giữa tốc độ và an toàn không hề đơn giản.Theo tôi, không nhất thiết phải xây dựng mọi thứ quá phức tạp ngay từ đầu. Cách hiệu quả hơn là xác định đâu là phần quan trọng cần bảo vệ trước:Dữ liệu cá nhân của người dùng.Quyền truy cập giữa các nhóm tài khoản.Các API quan trọng.Những luồng liên quan đến thanh toán hoặc thông tin nhạy cảm.Những phần này cần được đặt security ngay từ đầu, thay vì chờ đến khi sản phẩm lớn lên mới sửa.Trước đây tôi từng nghĩ security là phần việc chủ yếu của Developer. Nhưng sau quá trình làm việc, tôi thấy đây là trách nhiệm của cả team.Dev xây dựng hệ thống.QA tìm ra những góc nhìn khác.Product hiểu người dùng.Mỗi vị trí đều góp phần tạo nên một sản phẩm đáng tin cậy.Vibe coding hay phát triển nhanh giúp chúng ta kiểm chứng ý tưởng sớm hơn. Nhưng nếu chỉ tập trung vào tốc độ mà bỏ qua an toàn, cái giá phải trả sau này có thể lớn hơn rất nhiều.Bài học tôi rút ra là:Một sản phẩm tốt không chỉ là sản phẩm chạy được, mà còn là sản phẩm có thể bảo vệ người dùng khi mọi thứ không diễn ra như mong đợi.Build nhanh giúp sản phẩm đi trước.Security giúp sản phẩm đi xa.

Tech-away

325

Do You Believe the “Tech Stack Determines Salary” Myth?

Huyên Nguyễn

10/06/2026

Tôi từng nghĩ học tech stack “hot” là con đường nhanh nhất để tăng lương

Khi mới bước vào ngành IT, tôi từng có suy nghĩ khá đơn giản: công nghệ nào càng phổ biến thì cơ hội việc làm và mức lương sẽ càng cao.Nhìn vào thị trường, tôi thấy nhiều vị trí yêu cầu những tech stack đang được nhắc đến rất nhiều. Điều đó khiến tôi nghĩ rằng nếu muốn phát triển nhanh, có lẽ mình chỉ cần tập trung học đúng những công nghệ “đang hot”.Nhưng sau quá trình làm QA/Tester, tôi nhận ra câu chuyện không chỉ nằm ở việc bạn đang dùng công nghệ gì.Trong công việc, tôi từng gặp những tình huống mà cùng một sản phẩm, cùng một hệ thống, nhưng giá trị của mỗi người trong team lại rất khác nhau.Một Tester không chỉ là người kiểm tra xem chức năng có hoạt động hay không.Có những lúc tôi cần hiểu dữ liệu được lưu ở đâu, API hoạt động như thế nào, các luồng xử lý phía sau ra sao để tìm ra vấn đề mà người dùng bình thường không nhìn thấy.Từ đó, tôi bắt đầu học thêm SQL, API testing và tìm hiểu sâu hơn về cách hệ thống vận hành.Ban đầu, tôi nghĩ học thêm những kỹ năng này đơn giản là để tăng cơ hội việc làm.Nhưng sau đó tôi nhận ra giá trị lớn nhất không nằm ở việc có thêm một công cụ trong CV, mà là khả năng giải quyết vấn đề tốt hơn.Biết SQL không chỉ là viết câu query.Nó giúp tôi kiểm tra dữ liệu có đúng sau một thao tác hay không.Biết API không chỉ là gửi request.Nó giúp tôi hiểu cách dữ liệu đi qua hệ thống và phát hiện những vấn đề có thể bị bỏ sót khi chỉ test giao diện.Tôi cũng từng nghĩ đến việc chạy theo một tech stack mới chỉ vì nghe nói mức lương tốt hơn. Nhưng sau khi suy nghĩ lại, tôi thấy nếu chỉ chọn công nghệ vì xu hướng mà không xây nền tảng, mình rất dễ rơi vào vòng lặp học mãi nhưng chưa thật sự tạo ra giá trị.Theo tôi, tech stack chắc chắn có ảnh hưởng đến thu nhập.Một công nghệ có nhu cầu cao có thể mở ra nhiều cơ hội hơn. Nhưng mức lương cuối cùng vẫn phụ thuộc vào cách bạn sử dụng kiến thức đó để giải quyết vấn đề.Một người biết ít công nghệ hơn nhưng hiểu sâu sản phẩm, tư duy tốt, làm việc hiệu quả có thể tạo ra nhiều giá trị hơn một người chỉ biết nhiều công cụ nhưng thiếu khả năng áp dụng.Với tôi, tech stack giống như một chiếc chìa khóa.Chìa khóa tốt giúp mở nhiều cánh cửa hơn, nhưng để đi xa hơn thì vẫn cần năng lực, tư duy và kinh nghiệm của chính mình.Bài học tôi rút ra là:Đừng chỉ hỏi: “Công nghệ nào đang có lương cao?”Hãy hỏi thêm:“Công nghệ nào giúp mình giải quyết vấn đề tốt hơn và trở thành người có giá trị hơn?”Khi giá trị bản thân tăng lên, thu nhập thường sẽ là kết quả đi cùng.

Deep Talk

201

CV Tips I Wish I Knew Earlier

Huyên Nguyễn

11/05/2026

Từ một CV “không ai phản hồi” đến những cuộc gọi phỏng vấn

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.”

CV Debug

761

ITviec's Choice

In the Age of AI: How I’m Building My "New-normal" Skill Set

Huyên Nguyễn

11/05/2026

Từ Tester đến người “làm việc cùng AI”

Khi Artificial Intelligence ngày càng xuất hiện nhiều trong ngành Information Technology, mình nhận ra công việc của một người IT đang thay đổi khá rõ. Trước đây, mình nghĩ chỉ cần làm tốt chuyên môn là đủ. Nhưng hiện tại, điều quan trọng không chỉ là “biết làm”, mà còn là biết cách làm việc cùng AI để tăng hiệu quả và tạo ra giá trị thực tế hơn.Mình từng tham gia dự án AI Buddy Chat — một chatbot giáo dục hỗ trợ học sinh hỏi đáp kiến thức, gợi mở nội dung học tập và đồng hành theo bộ sách Trí tuệ nhân tạo. Dự án này khiến mình thay đổi khá nhiều về tư duy làm việc.Trước đây khi làm testing, phần lớn thời gian của mình dành cho việc viết testcase thủ công, kiểm tra từng flow hoặc lặp đi lặp lại các bước regression test. Từ khi bắt đầu ứng dụng AI vào công việc, mình có thể dùng AI để: Gợi ý testcase nhanh hơn,  Tạo edge case,  Hỗ trợ viết query SQL,  Phân tích log,  Hoặc tổng hợp nhanh các scenario có thể xảy ra. AI giúp mình giảm khá nhiều thời gian ở các tác vụ lặp lại. Nhưng đổi lại, mình phải “nghĩ nhiều hơn” ở những phần mà AI chưa thể làm tốt hoàn toàn.Ví dụ trong dự án chatbot giáo dục, AI có thể tạo ra câu trả lời rất tự nhiên nhưng chưa chắc phù hợp với học sinh. Có lần chatbot giải thích khái niệm machine learning quá dài và dùng nhiều thuật ngữ khó hiểu với học sinh cấp hai. Nếu chỉ nhìn theo góc độ “chatbot trả lời đúng” thì có thể xem là pass, nhưng nhìn từ trải nghiệm người học thì chưa thực sự hiệu quả.Điều đó khiến mình bắt đầu quan tâm nhiều hơn đến: Context conversation,  Độ phù hợp của nội dung với người dùng,  Logic nghiệp vụ,  Và trải nghiệm thực tế thay vì chỉ test theo checklist. Mình cũng nhận ra bản thân đang làm nhiều việc hơn trước đây. Ngoài testing, mình phải: Hiểu thêm về sản phẩm giáo dục,  Phân tích intent của người dùng,  Kiểm tra chất lượng nội dung AI trả về,  Trao đổi với team về trải nghiệm hội thoại,  Và đôi khi tham gia góp ý cách chatbot phản hồi sao cho tự nhiên hơn. Có những kỹ năng trước đây chỉ là “nên có”, nhưng bây giờ gần như trở thành “phải có”, ví dụ: Kỹ năng đặt câu hỏi,  Tư duy phân tích,  Khả năng học nhanh,  Hiểu API và dữ liệu,  Và đặc biệt là biết sử dụng AI đúng cách thay vì phụ thuộc hoàn toàn vào nó. Khó khăn lớn nhất với mình trong giai đoạn đầu là học cách kiểm chứng thông tin AI đưa ra. Vì AI có thể trả lời rất thuyết phục dù đôi khi chưa đúng hoàn toàn. Có những testcase AI gợi ý nghe hợp lý nhưng lại thiếu business rule quan trọng của hệ thống giáo dục. Điều đó khiến mình hiểu rằng dùng AI hiệu quả không phải là copy kết quả, mà là biết đánh giá và chọn lọc.Với những bạn mới vào ngành IT, mình nghĩ ngoài kiến thức chuyên môn thì nên chuẩn bị thêm: Khả năng tự học,  Kỹ năng giao tiếp,  Tư duy logic,  Và khả năng làm việc cùng AI. Theo mình, AI sẽ không thay thế hoàn toàn người làm IT, nhưng chắc chắn sẽ thay đổi cách chúng ta làm việc mỗi ngày. Vì vậy mình đang cố gắng phát triển theo hướng hiểu sản phẩm nhiều hơn, học thêm API, SQL, automation và quan trọng nhất là giữ tư duy chủ động học hỏi để không bị tụt lại phía sau.Hiện tại, mình không xem AI là đối thủ, mà là một công cụ giúp mình làm việc hiệu quả hơn. Nhưng để thực sự tạo ra giá trị, mình nghĩ người làm IT vẫn cần khả năng phân tích, hiểu người dùng và đưa ra quyết định phù hợp trong những tình huống thực tế mà AI chưa thể thay thế hoàn toàn.

AI & I

675

Beyond Tasks: How I "build impact" in Fintech

Huyên Nguyễn

11/05/2026

Từ người chỉ “làm task” đến người hiểu sản phẩm

Trong môi trường Financial Technology, mình nhận ra rằng “hoàn thành task” chỉ là điểm bắt đầu. Điều tạo nên giá trị thực sự không nằm ở việc làm xong bao nhiêu đầu việc, mà là mình đã góp phần giúp sản phẩm tốt hơn, người dùng hài lòng hơn và đội ngũ vận hành hiệu quả hơn như thế nào.Khi mới tham gia dự án Fintech, mình chủ yếu tập trung vào việc xử lý task được giao: viết test case, kiểm thử chức năng, log bug và theo dõi tiến độ fix lỗi. Ban đầu mình nghĩ chỉ cần hoàn thành đúng deadline là đủ.  Nhưng sau một thời gian làm việc, mình nhận ra nếu chỉ “đợi được giao gì làm nấy” thì rất khó phát triển và cũng khó tạo ra giá trị thật cho sản phẩm. Càng làm, mình càng nhận ra đặc thù của Fintech khác với nhiều lĩnh vực khác: chỉ một lỗi nhỏ liên quan đến giao dịch, số dư hay bảo mật cũng có thể ảnh hưởng lớn đến trải nghiệm và niềm tin của người dùng.  Từ đó, mình bắt đầu thay đổi cách làm việc. Thay vì chỉ test theo yêu cầu có sẵn, mình chủ động tìm hiểu nghiệp vụ tài chính, luồng thanh toán, logic xử lý giao dịch và hành vi thực tế của người dùng. Mình học cách đặt câu hỏi: Nếu hệ thống mất kết nối giữa lúc thanh toán thì sao?  Nếu người dùng bấm thanh toán nhiều lần liên tiếp thì sao?  Nếu dữ liệu trả về chậm hoặc sai định dạng thì điều gì sẽ xảy ra? Chính tư duy đó giúp mình phát hiện thêm nhiều edge case và bug tiềm ẩn trước khi sản phẩm được release. Có những lỗi không nằm trong checklist ban đầu nhưng lại ảnh hưởng trực tiếp đến trải nghiệm người dùng hoặc độ an toàn của hệ thống.Có giai đoạn team chạy deadline khá gấp, tài liệu không đầy đủ, requirement thay đổi liên tục. Lúc đó mình không chỉ test theo checklist nữa mà bắt đầu tự tìm hiểu flow nghiệp vụ để hiểu hệ thống đang hoạt động như thế nào. Ví dụ với một chức năng thanh toán, mình không chỉ test case happy case mà còn thử những tình huống người dùng thật có thể gặp: Mạng chập chờn giữa lúc thanh toán,  Bấm thanh toán nhiều lần,  Chuyển màn hình giữa chừng,  Dữ liệu trả về chậm hoặc sai format. Nhiều bug mình tìm ra không nằm trong tài liệu nhưng nếu lên production thì ảnh hưởng khá lớn đến trải nghiệm người dùng. Có lần mình phát hiện trường hợp giao dịch bị tạo trùng khi người dùng bấm liên tục vì hệ thống xử lý chậm. Dev ban đầu nghĩ khó xảy ra, nhưng sau khi test lại bằng API và log dữ liệu thì đúng là có thể phát sinh thật. Sau đó team phải bổ sung xử lý duplicate transaction trước khi release.Ngoài công việc testing, mình cũng cố gắng học thêm những thứ giúp công việc hiệu quả hơn, đóng góp nhiều hơn cho team:Chủ động review flow nghiệp vụ cùng BA và Dev để hiểu vấn đề từ đầu thay vì chỉ đợi đến lúc có bug mới xử lý Đề xuất cải thiện quy trình test để giảm lỗi lặp lại  Học SQL để tự kiểm tra dữ liệu thay vì phụ thuộc hoàn toàn vào Dev  Học test API để verify logic backend   Tìm hiểu automation để tăng hiệu quả regression test Mình nhận ra rằng giá trị của một người làm IT không chỉ nằm ở kỹ năng kỹ thuật, mà còn ở tinh thần chủ động học hỏi và khả năng nhìn vấn đề từ góc độ sản phẩm và người dùng.Hành trình “tạo dấu ấn” của mình trong Fintech không phải là làm điều gì quá lớn lao, mà là từng bước làm tốt hơn mỗi ngày: suy nghĩ nhiều hơn một chút, kiểm tra kỹ hơn một chút và luôn cố gắng tạo ra sản phẩm ổn định, an toàn hơn cho người dùng. Đó cũng là điều khiến mình thấy công việc IT không chỉ là hoàn thành task, mà là đang góp phần xây dựng niềm tin trong môi trường tài chính số.Có thể những việc đó không quá nổi bật, nhưng mình nghĩ chính sự chủ động và tinh thần làm nhiều hơn một bước đã giúp mình trưởng thành hơn trong công việc IT nói chung và Fintech nói riêng. 

Deep Talk

676

In the Age of AI: How I’m Building My "New-normal" Skill Set

Phan Trung Nghĩa

28/04/2026

Khi code không còn là thứ khó nhất

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.

Career Hack

182

ITviec's Choice

Beyond Tasks: How I "build impact" in Fintech

Phan Trung Nghĩa

28/04/2026

Một dev hơn 5 năm full-stack - lần đầu đặt chân vào Fintech

Tôi vào nghề với một niềm tin giản dị: code tốt là đủ. Viết clean code, close ticket đúng deadline, không để bug lên production — vậy là một dev giỏi. Hơn năm năm đi làm, tôi dần trở thành người được giao task khó nhất team. Rồi đến lúc tôi nhảy vào một dự án Fintech.Tuần đầu tiên tưởng bình thường. CRUD vẫn là CRUD. API vẫn là API. Nhưng rồi có một buổi chiều, PM hỏi: "Nếu hệ thống xử lý sai số tiền của người dùng, chuyện gì xảy ra?"Tôi định trả lời theo kiểu dev: "Thì mình log lỗi rồi rollback." Nhưng nhìn khuôn mặt mọi người trong phòng — tôi hiểu câu hỏi đó không phải về technical.Trong Fintech, bug không phải là lỗi phần mềm. Bug là ai đó mất tiền thật.Từ "viết code chạy được" đến "viết code đáng tin"Dev 5 năm dạy tôi nhiều thứ: clean architecture, performance, CI/CD pipeline. Nhưng có một thứ tôi chưa từng nghĩ tới — chi phí của sự sai lầm.Trong các project trước, nếu UI hiển thị sai giá sản phẩm, user reload lại là xong. Còn khi số dư tài khoản hiển thị sai vì một race condition không ai kiểm tra — không có chuyện "reload lại là xong".Tôi bắt đầu đọc lại codebase không phải để hiểu logic làm gì, mà để hỏi: cái này sai được không? Nếu sai, sai đến đâu?Ba câu hỏi tôi học được cách đặt ra mỗi ngày:Nếu request này chạy 2 lần cùng lúc thì sao? — Idempotency không còn là khái niệm học thuật, đó là thứ phải code mỗi ngày.Khi nào transaction thực sự "xong"? — Eventual consistency đẹp trên giấy. Trong Fintech, bạn phải biết chính xác moment nào tiền "an toàn".Ai có thể xem dữ liệu này? — Authorization không chỉ là middleware. Đó là kiến trúc, là audit log, là compliance.Cái tôi tưởng là thừa, hoá ra là thiếu5 năm làm full-stack, tôi quen move fast. Nhưng Fintech dạy tôi một bài học kỳ lạ: đôi khi đi chậm mới là tạo ra value thật.Có lần tôi propose một feature tưởng là "quick win" — cho phép user xem lịch sử giao dịch real-time. Tôi tự tin lắm: websocket, 2 ngày là xong.Nhưng senior trong team hỏi: Audit log ở đâu? Nếu user dispute giao dịch, mình chứng minh bằng gì? Hệ thống fraud detection có nhận được event này không?Tôi ngồi im. Hai ngày của tôi hóa thành hai tuần — và feature đó tốt hơn rất nhiều."Làm nhiều hơn task" không phải là code thêm tính năng. Đó là hiểu tại sao task đó tồn tại — rồi làm cho mục đích đó được phục vụ thật sự.Khi dev học nói chuyện với người không biết codeMột trong những thay đổi lớn nhất không liên quan đến keyboard. Đó là học cách giải thích.Trong Fintech, quyết định kỹ thuật ảnh hưởng đến compliance, đến risk, đến tiền thật. Bạn không thể chỉ nói "tôi dùng optimistic locking để handle concurrent write" rồi kết thúc. Bạn phải nói được: "Nếu không có cơ chế này, hai người có thể rút cùng một số tiền lúc 3 giờ sáng và cả hai đều thành công."Kỹ năng dịch technical sang business impact — không ai dạy trong trường. Tôi học được từ những buổi họp awkward, từ những lần bị hỏi ngược mà không trả lời được.Công thức tôi đang tập dùng: [Quyết định kỹ thuật] giúp/ngăn chặn [điều gì xảy ra với người dùng], điều mà nếu không có sẽ gây ra [hậu quả cụ thể].Dấu ấn không nằm ở số dòng codeLần đầu tiên tôi cảm thấy mình thật sự tạo ra giá trị — không phải khi ship một feature phức tạp. Mà là lúc tôi ngồi cùng đội fraud analyst, lắng nghe họ mô tả workflow thủ công làm mỗi buổi sáng, rồi nói: "Mình có thể tự động hoá bước này."Feature đó chỉ tốn 3 ngày code. Nhưng để biết cần làm gì, tôi mất 2 tuần ngồi hiểu bài toán. Đó là thứ 5 năm trước tôi sẽ không làm — vì "đó không phải task của tôi".Fintech không cần thêm người viết code. Fintech cần người hiểu rằng code là phương tiện, không phải đích đến.Hành trình từ "dev hoàn thành task" đến "người tạo ra dấu ấn" bắt đầu bằng một câu hỏi rất đơn giản: Tại sao cái này quan trọng?Khi bạn có câu trả lời cho câu hỏi đó — mọi dòng code bạn viết ra đều có trọng lượng hơn.

Career Hack

178

My Funemployment Story

Huyên Nguyễn

03/03/2026

Tôi mất việc, nhưng không mất mình

Tôi không “thất nghiệp”, tôi đang nâng cấpCó một thời điểm, tôi nghe hai chữ “thất nghiệp” mà tim chùng xuống.Trong ngành IT, nó không chỉ là mất việc. Nó là mất thu nhập, mất nhịp sống, mất cảm giác mình “đang có ích”. Và đáng sợ nhất, là nỗi sợ mình đang… thất bại.Nhưng sau khi trải qua (hoặc chứng kiến rất gần) một giai đoạn như vậy, tôi bắt đầu nhìn nó khác đi. Tôi tin rằng: “thất nghiệp tích cực” là có thật.1. “Thất nghiệp tích cực” là gì?Với tôi, “thất nghiệp tích cực” là:Không có công ty trả lương cho bạn, nhưng bạn vẫn đang đầu tư nghiêm túc vào chính mình.Đó là giai đoạn bạn:Tạm dừng để hồi phục sau burnout.Bị layoff nhưng không buông xuôi.Chủ động nghỉ để chuyển hướng nghề nghiệp.Khác biệt nằm ở chỗ: Bạn không để hoàn cảnh định nghĩa giá trị của mình.Thất nghiệp tiêu cực là khi ta dừng lại, thu mình, tự dán nhãn “mình kém”. Thất nghiệp tích cực là khi ta nói: “Ok, đây là khoảng lặng. Mình sẽ dùng nó có chủ đích.”2. Tôi đã học được gì về nỗi sợ “khoảng trống CV”?Điều ám ảnh dân IT nhất có lẽ là: “2 lần bị mất việc mỗi 1 lần sau 2 tháng không đi làm thì CV nhìn sao?”Nhưng sau này tôi nhận ra: Nhà tuyển dụng không sợ khoảng trống. Họ sợ khoảng trống không có câu chuyện.4 tháng:Nếu bạn chỉ ở nhà, lo lắng và chờ cơ hội → đó là khoảng trống.Nhưng nếu bạn học 1 tech mới, viết blog, làm freelance nhỏ, học thêm 1 ngôn ngữ mới → đó là hành trình nâng cấp.Cùng là 4 tháng. Khác nhau ở cách bạn dùng nó.Bài học tôi rút ra:Đừng hỏi “mình có việc chưa?” Hãy hỏi “mình đang tạo giá trị gì mỗi ngày?”3. Làm gì để thất nghiệp không trở thành thất bại?Tôi không muốn tô hồng. Giai đoạn này rất áp lực. Vì vậy, cần thực tế.(1) Tính toán tài chính trước tiênĐộng lực không thay thế được tiền nhà.Việc đầu tiên nên làm:Tính runway: mình sống được bao lâu nếu chưa có thu nhập?Cắt chi phí không cần thiết.Sẵn sàng nhận freelance/part-time nếu cần.Sự bình tĩnh đến từ con số rõ ràng.(2) Giữ kỷ luật như đang đi làmSai lầm lớn nhất là mất nhịp sinh hoạt.Nếu rơi vào giai đoạn này, tôi sẽ:Dậy giờ cố định.Chia ngày thành block: học thêm kiến thức mới, ngôn ngữ mới – tìm việc.Mỗi ngày tạo ra ít nhất một “kết quả hữu hình” (1 commit, 1 bài viết, 1 CV gửi đi).Cảm giác tiến bộ nhỏ mỗi ngày giúp mình không trôi.(3) Biến thời gian rảnh thành tài sảnThay vì chỉ học cho biết, hãy:Xây project có thể demo.Deploy thật.Viết README tử tế.Ghi lại quá trình học.Một portfolio sống động có sức nặng hơn một dòng “đang tìm việc”.(4) Học cách chịu đựng bị từ chốiGửi 20 CV, rớt 15 cái là chuyện bình thường.Thị trường khó không đồng nghĩa bạn kém.Mỗi lần phỏng vấn là một buổi tập:Cải thiện cách trình bày.Nhận diện lỗ hổng kiến thức.Tối ưu lại CV.Thất bại thật sự không phải là bị từ chối. Mà là bạn ngừng cố gắng vì nghĩ mình không đủ giỏi.4. Nếu bạn đang hoang mang, tôi muốn nói điều nàyBạn không vô dụng chỉ vì chưa có offer.Giá trị con người không nằm hoàn toàn ở hợp đồng lao động.Có thể bạn đang:Mất tự tin.So sánh mình với bạn bè đã “ổn định”.Lo lắng về tương lai.Nhưng hãy nhớ:Rất nhiều người giỏi từng có giai đoạn chông chênh.Khoảng dừng không phải dấu chấm hết.Đây là trạng thái tạm thời, không phải bản sắc vĩnh viễn.Hãy tự hỏi:Một năm nữa, mình muốn cảm ơn phiên bản hiện tại vì điều gì?5. Thất nghiệp là khoảng lặng giữa hai chươngCuộc đời không phải đường thẳng đi lên mãi. Nó có nhịp nghỉ.Có khi chính giai đoạn:Không bị deadline dí,Không bị họp triền miên,Không bị áp lực KPI,Lại là lúc bạn nghĩ sâu nhất về việc mình thực sự muốn gì.Có người chuyển từ dev sang data. Có người học thêm product. Có người khởi nghiệp. Có người nhận ra mình cần một môi trường khác.Nếu bạn chủ động viết lại mình trong khoảng lặng đó, thì nó không phải thất nghiệp. Nó là tái cấu trúc.6. Tôi không “thất nghiệp”Nếu hôm nay bạn:Vẫn học.Vẫn xây dựng.Vẫn kỷ luật.Vẫn không bỏ cuộc.Thì bạn không thất bại.Bạn đang chuẩn bị cho chương tiếp theo.Và có thể vài năm nữa, khi nhìn lại, bạn sẽ nhận ra:Chính giai đoạn “thất nghiệp” này đã khiến bạn trưởng thành hơn bất kỳ thời điểm nào khác.Tôi không “thất nghiệp”. Tôi đang nâng cấp.Và nếu bạn đang ở đó — bạn cũng thế. 

Deep Talk

#18

AI For Good

Trần Lương Phán

27/02/2026

Mình đã quay lại với Automation Testing với sự hỗ trợ của AI

Lời mở đầuNhư bao bạn mới vào nghề Tester, công việc của mình là đọc requirement, viết test case, click từng màn hình và ghi bug ticket. Rồi một ngày, khi muốn thăng tiến sự nghiệp, mình bắt đầu tự thử automation testing.Với một người không đam mê code, mình chọn cách dễ nhất: dùng công cụ record thao tác và sinh ra script. Cứ tưởng chỉ cần click, nhập liệu, submit là xong, nhưng khi bấm Run thì script fail, lúc được lúc không, có khi record chạy mãi mà không hoàn thành hết script.Sau nhiều lần thử nhưng không hiệu quả, cộng thêm môi trường công việc khi đó không yêu cầu automation mà chỉ cần kết quả là hạn chế bug, mình quyết định quay lại với manual testing và cứ như vậy trong một khoảng thời gian dài.Những khó khăn mình gặp khi ấyTest chạy được lúc record nhưng fail khi chạy lạiChỉ cần UI/UX thay đổi là phải chỉnh sửa test script cho phù hợpDebug stack trace rất dài và khó xác định lỗi ở đâuBắt đầu ứng dụng AI agentDù trước đó đã có Cursor hay Claude Code, mình thử áp dụng Anti Gravity. Đơn giản vì nó đang miễn phí, được phát triển bởi Google và sử dụng mô hình Gemini 3.Bước đầu, mình nhờ AI agent cài đặt Playwright và các plugin cần thiết. Khi chưa rành các cú pháp Node.js của yarn hay npx, mình cũng prompt để AI chạy giúp.Sau khi record các test và chạy thử, nếu script fail, mình sẽ prompt để AI đề xuất cách “debug” sao cho test có thể chạy ổn định hơn. Điểm mình thích ở Anti Gravity là trước khi thực hiện, AI luôn đề xuất plan và yêu cầu người dùng review.  Trong trường hợp này, mình nhờ AI viết script để bắt các lỗi network 500 và 504 trước khi deployment. Trước đây, mình không biết cú pháp hay câu lệnh để xử lý các sự kiện lỗi này. Vì vậy phải Google, copy rồi chỉnh sửa lại code của người khác rất nhiều lần mà chưa chắc đã đúng.Kết quả đạt được bây giờỨng dụng được automation test để hỗ trợ regression testingViết được những case yêu cầu hiểu về technical caoDễ refactor test script khi có thay đổi về UI/UXCác test script đủ ổn định để đưa vào các công cụ CI/CDLời chốtAI đã và đang làm được rất nhiều thứ, nhưng đừng ỷ lại hoàn toàn hay để AI thay thế mình. Hãy tự bổ sung các kiến thức chuyên môn, cùng chủ động tìm hiểu cách sử dụng AI một cách phù hợp.Dù cách làm này chưa hoàn hảo 100%, và không phải lúc nào cũng có thể áp dụng cho tất cả mọi case, nhưng đây vẫn là một bước tiến mới giúp mình thay đổi cách làm việc so với trước đây.Chúc mọi người thành công trong việc áp dụng AI một cách hiệu quả, tốt đẹp trong công việc và cuộc sống.

AI & I

#17

Solo builder: Vibe coding vs Cybersecurity?

Do You Believe the “Tech Stack Determines Salary” Myth?

Menu

QA QC

Tôi không viết nhiều code, nhưng tôi nhận ra IT giỏi không chỉ là viết code giỏi

Tôi không viết code, nhưng tôi thấy cái giá của việc bỏ qua security

Tôi từng nghĩ học tech stack “hot” là con đường nhanh nhất để tăng lương

Từ một CV “không ai phản hồi” đến những cuộc gọi phỏng vấn

Từ Tester đến người “làm việc cùng AI”

Từ người chỉ “làm task” đến người hiểu sản phẩm

Khi code không còn là thứ khó nhất

Một dev hơn 5 năm full-stack - lần đầu đặt chân vào Fintech

Tôi mất việc, nhưng không mất mình

Mình đã quay lại với Automation Testing với sự hỗ trợ của AI

Make Your Experience Better

Feedback topic *

Your feedback *

Attached image (0/2)

Are you satisfied with ITviec?

Feedback submitted