Create post

Menu

Career Hack

Create post
7 posts
Here we discuss how to level up your IT career - from success and failure stories to proven roadmaps that truly work.
  • Do: Share real experiences from your own journey, or methods and roadmaps you’ve applied effectively.
  • Don’t: Promote courses or post job ads.
challenge-icon

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

user-avatar
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.
category-icon
Career Hack
Design
QA QC
challenge-post-cover
#4
3
139
ITviec's Choice
Winning badge
challenge-icon

Beyond Tasks: How I "build impact" in Fintech

user-avatar
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.
category-icon
Career Hack
DevOps
QA QC
Product Management
challenge-post-cover
#3
4
145
challenge-icon

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

user-avatar
Bình Phạm Châu
23/04/2026

Xuất phát trễ 4 năm và Cuộc đua trong Kỷ nguyên AI.

"Mình xuất phát trễ hơn mọi người 4 năm.", đó là suy nghĩ của mình kể từ khi bắt đầu sự nghiệp. Với background từ dân Cơ điện tử (Mechatronics) rẽ hướng sang làm Firmware/Embedded, mình đã phải tự học, viết và debug từng dòng code.Khởi đầu một thứ mới đâu phải là chuyện giản đơn, và khởi đầu một skill set mới chưa bao giờ là điều dễ làm. Nhưng khi bản thân vừa bắt đầu quen với nhịp độ của ngành nhúng, một làn sóng lớn lại ập đến: Kỷ nguyên AI.Khi thấy các công cụ AI có thể gen ra những đoạn code C chuẩn mực hay tìm ra lỗi logic chỉ trong vài giây – những thứ từng ngốn của mình cả buổi trời – mình thực sự khựng lại. Nếu AI viết code nhanh và ít bug như thế, một người xuất phát chậm như mình lấy gì để cạnh tranh?Câu trả lời mình tìm được là: "Biết gõ code" không còn là phao cứu sinh duy nhất. Để tồn tại và phát triển, mình bắt buộc phải xây dựng một "new-normal" skill set. Nó không nằm ở tốc độ code, mà nằm ở Tư duy Hệ thống (System Thinking) và Kiến trúc Phần mềm (Software Architecture). AI có thể viết một hàm xử lý cực giỏi, nhưng nó chưa thể tự thiết kế một hệ thống mạng Mesh tối ưu, hay xử lý trọn vẹn các giao thức giao tiếp RF trong một môi trường nhiễu sóng thực tế.Thay vì cắm đầu vào code ngay lập tức, mình dành nhiều thời gian hơn để vẽ architecture, phân tích luồng dữ liệu (data flow) và thiết kế cách các task giao tiếp trong hệ điều hành thời gian thực (RTOS). Khi kiến trúc (Architecture) đã rành mạch, việc implement code hay nhờ AI hỗ trợ sẽ trở nên cực kỳ sắc bén. Mình học cách làm "Kiến trúc sư" trước khi làm "Thợ xây".Xuất phát từ Cơ điện tử hóa ra lại là một điểm cộng. Trong Embedded C, phần mềm và phần cứng luôn dính chặt lấy nhau. AI chỉ sống trong thế giới digital. Nó không thể tự tay cắm dây mạch, không thể cầm máy hiện sóng (oscilloscope) đo tín hiệu để xem tại sao phần cứng lại bị nhiễu điện từ. Nắm vững nền tảng cốt lõi ở tầng Low-level, hiểu rõ thanh ghi (registers) và cách tối ưu hóa bộ nhớ chính là mỏ neo giữ vững giá trị của một Firmware Engineer.Thay vì sợ hãi, mình dùng AI làm đòn bẩy. Mình nhờ AI tóm tắt những cuốn datasheet hàng ngàn trang khô khan, tạo các đoạn boilerplate code cơ bản, hay giải thích các concept thuật toán phức tạp. Nhờ đó, mình tiết kiệm được rất nhiều thời gian ở "phần ngọn" để dồn sức đào sâu vào "phần gốc" của bài toán.Bất kể công nghệ thay đổi chóng mặt ra sao, sự bền bỉ vẫn là vũ khí mạnh nhất. Việc duy trì nhịp độ học tập kỷ luật mỗi ngày – từ việc đọc spec, nghiên cứu công nghệ mới, đến tự tay cày cuốc các project cá nhân – giúp mình giữ được sự nhạy bén.Xuất phát trễ 4 năm không đáng sợ bằng việc đứng im. Kỷ nguyên AI không lấy đi cơ hội, nó chỉ đang ép chúng ta phải chơi một ván game ở level cao hơn. Và ở ván game này, người có tư duy kiến trúc và nền tảng vững chắc sẽ là người chiến thắng.
category-icon
Career Hack
Software Architecture
Embedded C
challenge-post-cover
#7
1
93
challenge-icon

My Funemployment Story

user-avatar
Vu Nguyen Thanh
04/03/2026

Thất nghiệp rồi "bát" bại – câu chuyện Funemployment

1. FunemploymentFunemployment = fun + unemploymentCó lẽ các bạn cũng sẽ nghĩ như mình: "thất nghiệp mà vui sao nổi".Đúng vậy, vừa mất kế sinh nhai cho bản thân và gia đình vừa chẳng tài nào vui được.Dù trước mắt ta không thể thay đổi điều đó, mà không vui quá 1 phút 30 giây đó chả được gì.Trái đất vẫn xoay và ta có thể lập trình lại bản thân.Hãy vui mừng đi! Vì mình được thoát khỏi những ngày vội vã, cật lực và chuẩn bị cho cơ hội sắp đến.2. Khi nào thất nghiệp trở thành funemployment?Nếu ta vẫn thấy mất mát và chưa sẵn sàng để nghĩ về cơ hội thì việc đơn giản nhất có lẽ là làm một giấc ngủ cho đã đời.Còn gì mà vương vấn? Vất hết hôm nay để ngày mai đầy pin mà tính tiếp.Vui ở đây có lẽ là cảm giác nhận ra giai đoạn này có ý nghĩa.Cần một động cơ cụ thể là xác định được việc cần làm, kiến thức cần học và nâng tầm giá trị bản thân.3. Làm gì để biến giai đoạn này thành tiến bộ?Một mai qua cơn mê, đây là cơ hội vàng để điều chỉnh lại trạng thái và làm những điều mình chưa có giờ thử.Chăm chút bản thân và gia đình.Cập nhật CV.Luyện tập phỏng vấn, kỹ năng mềm và ngoại ngữ.Rải CV.Bổ sung kiến thức còn thiếu từ JD hoặc thị trường.Nhìn nhận lại quy trình làm việc của bản thân.Tạo chứng minh thư cho kỹ năng của mình bằng những bản demo, bài nghiên cứu hoặc đóng góp cho cộng đồng.Gặp gỡ bạn bè trong ngành, mở rộng mối quan hệ.Có thể lúc này không có ai giúp mình nhưng có AI giúp mìnhNhìn lại thì ta thấy có cả tá việc làm muốn không xuể. Mỗi việc nhỏ đều là bước tiến, không phải thất bại.4. Thông điệp gửi đến "ta" đang lo lắngCảm giác lo âu là bình thường.Đó cũng là động lực để ta tìm kiếm và hoạch định những bước tiến tiếp theo.Bước ra khỏi phòng tắm hơi đó trước khi xỉu nhé!Thất nghiệp không định nghĩa giá trị của bạn.Đây là chương “chuyển tiếp” chứ không phải “kết thúc”.Còn thở là còn gỡ.Hãy coi đây là cơ hội để chuẩn bị cho bước tiếp theo.5. Kết luậnfunemployment là cách nhìn tích cực về thất nghiệp.Thất nghiệp có thể là khoảng thời gian để học hỏi, phát triển và tìm lại chính mình.“Bạn không hề đứng yên, bạn đang chuẩn bị cho cú nhảy tiếp theo.”Kết luận cá nhân: Đây là bước đóng góp cho cộng đồng hiếm hoi trong sự nghiệp của mình. Dù hành văn có hơi phóng túng nhưng hy vọng bà con cô bác anh chị em vui và sớm gặt hái thành công như ý nhé!Chúc mừng năm mới!
category-icon
Career Hack
Leadership
PHP
Python
SQL
JavaScript
challenge-post-cover
#12
2
176
user-avatar
Minh Hiếu
05/12/2025

Làm sao để Junior mới đi làm không trở thành “gánh nặng” cho Senior?

Năm đầu đi làm Data Analyst, điều mình sợ nhất không phải là SQL khó hay dashboard nhiều yêu cầu. Mình sợ… trở thành gánh nặng cho Senior. Không phải vì họ khó tính, mà vì nhìn họ bận rộn thật sự. Chỉ cần họ đang tập trung vào một vấn đề lớn, mình chen ngang bằng một câu “Anh/ Chị ơi cho em hỏi xíu”, là mình cảm giác mình vừa kéo họ ra khỏi dòng suy nghĩ quan trọng nào đó. Mấy tuần đầu mình rất hay rơi vào cảnh này, và sau mỗi lần như vậy, mình tự hỏi: “Có cách nào để mình hỏi ít phiền hơn mà vẫn không làm sai task không?”Mà cũng vì mình ngại hỏi, ngại làm phiền, mà chỉ muốn làm ra kết quả nhanh nhất có thể nên thành ra… mình làm sai tùm lum hết trơn :D. Có lần mình làm một dashboard bốn trang rất hoành tráng, xong Senior bảo chỉ cần một bảng excel. Anh còn nói với mình là “Nếu em chưa rõ yêu cầu thì sao em không hỏi lại anh?”Khi đó, mình mới hiểu là vì muốn tiết kiệm thời gian cho các anh/chị mentor mà mình làm sai yêu cầu, thành ra còn làm tốn nhiều thời gian của mọi người hơn nữa vì phải chỉnh sửa và làm lại với mình. Bây giờ thì mình đã hiểu là mình nên đặt đầy đủ câu hỏi cần thiết trước khi bắt đầu bất kỳ task nào để vừa tiết kiệm thời gian vừa làm đúng yêu cầu.Đây là một số các câu hỏi mình thường hay hỏi anh/chị mỗi khi được giao task nào đó:“Task này làm để trả lời câu hỏi gì?”: Nghe đơn giản nhưng nhiều lần giúp mình tránh đi sai hướng. Cùng là phân tích churn, nhưng có task chỉ cần trend, có task lại cần xác định segment, nên mình không dám đoán nữa.“Kết quả cuối cùng cần ở dạng gì?”: Dashboard, excel, slide hay chỉ một bảng số. Có lần mình làm dashboard đẹp đẽ, cuối cùng khách chỉ cần vài dòng metric. Từ đó mình không bỏ qua câu này nữa.“Có tài liệu hoặc phân tích cũ nào em nên xem trước không?”: Câu này giúp mình tiết kiệm rất nhiều thời gian. Senior thường có query hoặc report cũ, chỉ là họ thường không nhớ để đưa.“Phần nào em có thể tự quyết, phần nào cần review trước?”: Mình không dám tự tin quá, nhưng cũng không muốn cái gì cũng hỏi. Nhờ câu này, mình biết phần nào nhạy cảm và phần nào mình được toàn quyền làm.“Timeline mong đợi là gì?”: Nhờ câu này mình ít bị trễ deadline hơn, vì có task nhìn nhẹ nhưng tốn nhiều thời gian hơn mình nghĩ.Còn làm sao để ra được list câu hỏi này thì cứ mỗi lần mình quên hỏi gì đó và bị sửa, mình thêm nó vào danh sách. Lâu dần, nó thành một list câu hỏi mà mình dùng cho mọi task mới. Không phải Senior nào cũng có thời gian brief lại từ A đến Z, nên việc này giúp cả hai đỡ mệt.Điều thú vị là từ khi mình bắt đầu dùng các câu hỏi này, Senior giao việc cho mình cũng tự tin hơn. Không phải vì mình trở nên giỏi, mà vì mình ít sai do hiểu nhầm ngay từ đầu. Mình cũng bớt cảm giác mình đang làm phiền người khác. Nhiều task mình làm một mạch rồi gửi review, và Senior chỉ chỉnh vài chi tiết nhỏ.Mong là những chia sẻ trên sẽ giúp được cho mọi người.Em cũng mong nhận được những chia sẻ từ những anh chị đi trước ạ :D
categry-icon
Career Hack
Data Analysis
4
248
user-avatar
Thoa Nguyen
05/12/2025

Một mẹo kỹ năng đã giúp mình tiến xa hơn trong công việc (mà mình đã từng bỏ qua)

Sau hơn mười năm làm kiểm thử, mình từng nghĩ rằng muốn tiến xa trong nghề thì phải học thêm nhiều tool, nhiều framework, chạy nhiều automation script hơn. Nhưng càng làm lâu, mình càng nhận ra một điều quan trọng: kỹ thuật không phải là thứ duy nhất định hình giá trị của một Senior Tester.Điểm tạo nên khác biệt lại nằm ở thứ mà ngày xưa mình ít để ý (thật ra là mình nghĩ là không quan trọng): hiểu về toàn cảnh kinh doanh.Khi ở vị trí Senior, công việc không đơn thuần là viết nhiều test case hay tối ưu script chạy nhanh hơn vài giây. Điều quan trọng hơn là hiểu: mình đang bảo vệ điều gì trong sản phẩm và vì sao doanh nghiệp lại ra mắt sản phẩm này.Có một lần, dự án mình đang làm tung ra một bản release có một lỗi mà team không ai ngờ tới. Lỗi rất nhỏ, không gây crash, không sai UI, không lệch dữ liệu. Nó chỉ đơn giản khiến một nút “Continue” trong luồng thanh toán hiển thị trễ hơn bình thường khoảng 1-2 giây.Trong checklist automation của mình, bước này pass. Mình chỉ validate logic và trạng thái. Còn thời gian phản hồi thì mình không để ý, vì trong tài liệu yêu cầu kỹ thuật không nói gì đến performance cho màn đó. Mình cũng không nghĩ việc chậm chỉ 1 giây lại là vấn đề lớn.Sau khi release, team Customer Support báo lại rằng số lượng người dùng bỏ dở thanh toán và phàn nàn về quy trình thanh toán tăng vọt. Conversion rate giảm một cách bất thường, khiến cả team hoảng hồn. Đến cuối tháng, phía kinh doanh báo doanh thu bị hụt một khoản không nhỏ. Lúc đó mọi người tá hỏa đi tìm nguyên nhân.Cuối cùng, cái lỗi “nhỏ đến mức tưởng không ảnh hưởng gì” đó chính là thủ phạm. Một độ trễ vài giây, và người dùng nghĩ hệ thống bị đơ hoặc nghi vấn bảo mật, bị hack (do chủ yếu người dùng là mobile) dẫn đến họ thoát ra và làm gián đoạn luồng mua sắm.Khi nói chuyện với BA và PO, mình mới hiểu rõ rằng người dùng của mình là ai, hành vi mua sắm của họ là gì, giá trị của một đơn hàng là như thế nào,... nên việc họ để họ chờ thêm 1-2 giây cũng khiến họ khó chịu đến như thế nào và sẵn sàng từ bỏ đơn hàng đó.Mình test theo checklist, nhưng không nhìn sản phẩm như một người dùng, và càng không nghĩ về tác động kinh doanh phía sau. Nhưng chính câu chuyện này làm mình thay đổi suy nghĩ.Khi hiểu luồng nghiệp vụ và KPI sản phẩm, mình tự nhiên test tập trung hơn, ưu tiên đúng chỗ hơn. Không phải test nhiều, mà là test đúng.Câu chuyện đó đến giờ vẫn là một cột mốc trong sự nghiệp của mình. Đó là một bài học đến từ một lỗi tưởng chừng bé xíu, nhưng lại giúp mình trưởng thành rất nhiều trong cách làm nghề.Vậy mình đã làm gì để hiểu kinh doanh nhanh chóng?Mình không học thêm bất kỳ bằng cấp gì, cũng không cố trở thành BA mà mình chỉ đơn giản thay đổi một vài thói quen:Quan sát hành trình người dùng: xem họ đến đây để làm gì, đâu là bước khiến họ dễ bỏ cuộc nhất.Trò chuyện nhiều hơn với PO, BA và team Sales: những câu chuyện họ chia sẻ giúp mình hiểu sản phẩm thực tế hơn bất kỳ tài liệu nào.Theo dõi những KPI cơ bản: traffic, conversion, retention; chỉ cần ba số này đã giúp mình hình dung bức tranh kinh doanh.Càng ngày, automation càng được tiêu chuẩn hóa, AI hỗ trợ viết code và test case mạnh hơn. Nhưng AI không biết mục tiêu kinh doanh là gì, không có các số liệu kinh doanh thực tế, không hiểu người dùng cần gì, và càng không thể đánh giá tác động của một lỗi đến trải nghiệm thật.Mình tin rằng những người QA hiểu sản phẩm và biết nghĩ theo hướng giá trị kinh doanh sẽ khó bị thay thế nhất. Khi nắm được bối cảnh kinh doanh, mình không chỉ làm test, mà còn góp phần vào các quyết định sản phẩm.
categry-icon
Career Hack
Tester
Automation Test
3
162
user-avatar
Mai Khanh
03/12/2025

Cuối năm là thời điểm tốt nhất để nhảy việc – nếu bạn dám bỏ tư duy “giữ thưởng cho chắc”

Thưởng thì vẫn quý, nhưng tinh thần còn quý hơnTôi biết quan điểm này nghe hơi trái tai, đặc biệt với những ai luôn tin rằng “ráng đến Tết lấy thưởng rồi tính”. Nhưng càng đi làm lâu, tôi càng thấy một điều buồn cười: có rất nhiều quyết định lớn trong đời bị giữ lại bởi những thứ nhỏ xíu, như vài triệu tiền thưởng cuối năm. Tôi từng như vậy, níu một công việc mà mình đã không còn phù hợp chỉ để chờ thưởng, để rồi ngay khi qua Tết, tôi nhận ra mình vừa lãng phí ba tháng mệt mỏi chỉ vì một khoản tiền không đủ để mua lại năng lượng đã mất.Có những công việc khiến bạn mệt mỏi đến mức chính bản thân bạn không nhận ra mình đã thay đổi thế nào. Bạn dễ cáu hơn, ít ngủ hơn, sức sáng tạo thấp hơn, và tệ nhất là bạn bắt đầu nghĩ rằng “đi làm chắc phải vậy thôi”, trong khi đó đơn giản chỉ là môi trường không phù hợp nữa. Nếu bạn đang ở trong trạng thái đó và bạn có một offer tốt hơn, môi trường tốt hơn, đã tìm hiểu kỹ, đã cân nhắc cả đường dài, thì thật lòng: Tiếc thưởng để làm gì?Cuối năm là thời điểm mà thị trường… dễ thương hơn bạn nghĩĐiều khiến tôi tin rằng cuối năm là thời điểm tốt để nhảy việc là vì phần lớn mọi người… không ai muốn nhảy lúc này. Ai cũng nghĩ: “Thôi ráng chút nữa”, và chính cái tâm lý “ráng” đó làm thị trường tuyển dụng trở nên vắng vẻ hơn. Có năm tôi chuyển việc vào tháng 12, tôi deal lương còn dễ hơn cả lúc giữa năm, không phải vì tôi xuất sắc hơn, mà vì công ty đang gấp rút chốt headcount cho Q1. Họ cần người hơn tôi cần job. Vậy là bối cảnh tạo lợi thế.Tuy nhiên, đừng nhảy nếu bạn đang chạy trốn cảm xúc tạm thờiDù tôi ủng hộ nhảy việc cuối năm, tôi phải nhấn mạnh một điểu: đừng quyết khi bạn đang burn out. Nếu bạn vừa OT dài hạn, thiếu ngủ, hoặc chỉ vừa cãi nhau với lead xong, nhảy việc lúc này không phải là một lựa chọn tốt, vì vấn đề nằm ở cảm xúc, không nằm ở job.Nghỉ ngơi một chút, để đầu óc lắng lại, rồi hãy đánh giá. Nhảy việc mà chưa hiểu rõ mình muốn gì thì chỉ khiến bạn lặp lại tình huống tương tự ở công ty mới.Cuối cùng, thời điểm đẹp nhất để rẽ hướng luôn là…Tôi tin một điều: thời điểm “đẹp” nhất để nhảy việc không phải cuối năm, đầu năm hay giữa năm, mà là khi bạn biết rõ lý do mình muốn đi và bạn đủ sẵn sàng cho chặng mới. Cuối năm chỉ tình cờ là một thời điểm mà cơ hội nhiều hơn ta tưởng, và rủi ro thì không lớn như ta hay nghĩ mà thôi.Nếu tôi phải chia sẻ một lời khuyên: hãy để sức khỏe tinh thần, tương lai sự nghiệp và sự phát triển của bạn quyết định, chứ không phải khoản thưởng cuối năm. Tiền thưởng tiêu rồi sẽ hết, nhưng cảm giác mỗi sáng mở laptop mà không thấy nặng nề thì… vô giá lắm. Một năm làm việc trong môi trường phù hợp đáng giá hơn nhiều so với một khoản thưởng mà bạn sẽ quên sau vài tuần.
categry-icon
Career Hack
5
460

You've reached the end.

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