Subscribe now

Trong bài viết này, tôi sẽ đề cập đến 4 cách tiếp cận AI để giúp bạn thực sự làm chủ AI và trở nên khó có thể thay thế nhưng trên hết là sử dụng AI một cách có hiệu quả.

Cách 1: Hãy lười biếng đúng lúc

Hầu hết chúng ta mắc completion bias: chúng ta ám ảnh với việc “hoàn thành” công việc để nhận phần thưởng dopamine từ cảm giác đã xong. Vì thế, ta có xu hướng coi mọi việc đều quan trọng như nhau, cố gắng làm hết, gạch hết checklist.

Kết quả là ta bận rộn liên tục, nhưng năng lượng bị phân tán. Rất nhiều việc được hoàn thành, nhưng rất ít việc thực sự tạo ra tiến bộ. Ta mệt mỏi không phải vì làm việc khó, mà vì làm quá nhiều việc không đáng làm.

Chính vì thế bạn cần phân biệt được các giá trị ngắn hạn và giá trị dài hạn. Với những công việc mang lại giá trị ngắn hạn nhưng lại tốn thời gian thì hãy tận dụng AI. Dưới đây là một số công việc mà bạn đừng nên tự làm mà hãy giao cho AI.

Soạn thảo ban đầu

Thay vì ngồi nhìn vào trang giấy trắng mà không biết bắt đầu từ đâu thì hãy dùng AI để tạo bản draft đầu tiên cho email, báo cáo, hoặc ý tưởng. Sau đó bạn chỉnh sửa để thêm “hồn” cá nhân.

Mẫu hình AIM: Act (vai trò) → Input (dữ liệu đầu vào) → Mission (nhiệm vụ)

Prompt:

Please act in the role of [role]. Use this [input] and this is your [mission].”

Hoặc

Prompt:

Write a LinkedIn post about remote work. Use this specific post as a style guide.

Vì đa phần các bạn đều dùng tiếng Anh để làm việc với AI nên bài viết chỉ để ví dụ bằng prompt tiếng Anh nhưng bạn hoàn toàn có thể làm tương tự với tiếng Việt.

Nghiên cứu thông tin

Hoặc còn có tên gọi là “Deep Research” đây là một trong những thế mạnh lớn của AI nếu đem so sánh với con người.

AI đặc biệt mạnh ở đào sâu thông tin, tổng hợp dữ liệu phân mảnh và biến chúng thành insight có cấu trúc. Thay vì bạn mất hàng giờ Google, đọc report, lọc nhiễu và ghi chú rời rạc, AI có thể làm vai trò của một junior consultant + research analyst trong vài phút.

Không chỉ dừng ở việc “tóm tắt”, AI còn:

• So sánh nhiều nguồn và nhiều góc nhìn

• Nhận diện pattern và mối liên hệ giữa các xu hướng

• Đề xuất đâu là yếu tố cốt lõi, đâu là nhiễu

• Biến dữ liệu thô thành memo, slide, hoặc talking points sẵn dùng

Prompt:

Do deep research on trends on topic [topic]. Analyze and cross-reference all the trends to find the three most important ones and draft a one-page memo summarizing the findings.

hoặc

Prompt:

Here are the five of my previous posts. Write a new one based on my tone of voice on topic [topic].

Nói cách khác, AI không thay bạn suy nghĩ, nhưng nó giúp giảm thời gian cho khâu chuẩn bị và tăng thời gian cho khâu suy nghĩ chất lượng cao.

Phân tích sơ bộ

Hay còn gọi là “first-pass analysis”, AI giúp lọc nhiễu trước khi đào sâu vào vấn đề. Với dữ liệu không nhất quán (unstructured) như ghi chép rời rạc, nghiên cứu thô, bản ghi cuộc họp, phản hồi người dùng, draft báo cáo thì AI phát huy thế mạnh nhất ở vai trò phân tích vòng 1.

Thay vì bạn đọc từng dòng và tự hỏi “điểm nào đáng chú ý?”, AI có thể:

• Quét toàn bộ nội dung để nhận diện pattern lặp lại

• Chỉ ra trend nổi bật hoặc các điểm bất thường

• Phát hiện lỗ hổng lập luận, mâu thuẫn, hoặc phần còn mơ hồ

• Đánh dấu khu vực có đòn bẩy tác động cao nhất nếu được cải thiện

Prompt:

Do not refine my research report yet. List the top three most impactful areas of improvement after we analyze it. Tell me why you think so and suggest how we address each. Think step by step. Show me your thinking for each step.

AI không thay thế phán đoán của bạn, mà giúp bạn biết nên tập trung trí lực vào đâu.

Công việc lặt vặt

Rất nhiều thời gian làm việc của chúng ta bị tiêu tốn vào những việc:

• Không khó

• Không cần sáng tạo

• Không cần phán đoán chiến lược

Đây là những việc bắt buộc phải làm để công việc phía sau có thể tiếp tục.

Ví dụ:

• Format lại file, đổi cấu trúc bảng

• Dịch thuật, chuyển đổi ngôn ngữ

• Clean data, xoá trùng, chuẩn hoá giá trị

• Tabulate số liệu từ text, PDF, email, log

• Chuẩn bị input “cho đúng form” để công cụ khác xử lý

Prompt:

Reformat this data table into Excel-friendly format and clean duplicates.

Những việc này hiếm khi tạo ra lợi thế cạnh tranh, nhưng lại ngốn rất nhiều giờ làm việc sâu nếu làm thủ công.

Bước 2: đừng xử dụng AI như dùng máy tính

Sẽ thật là sai lầm nếu bạn chỉ dùng AI như việc dùng máy tính, ví dụ như 1 + 2 = 3. Nếu bạn hỏi cùng một câu hỏi thì AI sẽ luôn tạo ra những câu trả lời khác nhau. AI nhiều khi rất thích “chế tác” hay còn gọi là “hallucination”1 2 bởi chúng không bao giờ muốn trả lời là “Xin lỗi, tôi không biết”. Bên cạnh đó, chúng còn có tinh thần “chối biến” hay ít khi nhận mình sai cho đến khi bị bạn bắt gặp.

Điều này giống nguyên lý bất định Heisenberg trong vật lý lượng tử3: càng đo chính xác một thuộc tính, ta càng làm nhiễu thuộc tính còn lại. Trong bối cảnh dùng AI, việc uỷ thác quá nhiều cho công cụ có thể làm suy giảm chính tư duy phản biện của bạn.

Hãy luôn verify mọi thứ, đừng outsource critical thinking. AI rất mạnh để hỗ trợ, nhưng nếu mù quáng tin vào thì hậu quả giống hệt khi dùng Copilot mà không đọc lại code: trông có vẻ đúng, chạy được, nhưng lỗi thì rải khắp nơi.

Bạn có thể dùng prompt sau để giúp AI giảm nhiễu và tăng khả năng chính xác

Prompt:

Think step by step before answering: Analyze this data and explain your reasoning for each conclusion.

Cách này giúp “slow-down” AI lại, thay vì để nó đưa ra câu trả lời nhanh thì bắt nó phải suy nghĩ thật kỹ, lập luận thật chặt chẽ, phân tích rõ ràng các luận điểm thay vì chế đại ra cho xong câu trả lời.

Bước 3: Phải thường xuyên luyện tập não bộ

Chắc bạn cũng biết là nếu cơ thể chúng ta thiếu sự luyện tập thường xuyên thì các cơ quan của chúng ta sẽ suy giảm chức năng của nó.

Các bạn có biết là các phi hành gia thường không thể đứng được khi quay trở về trái đất? Không hẳn là vì do trọng lực trái đất quá lớn mà một phần nguyên nhân đến từ việc họ không thể tập luyện đều đặn trong môi trường không trọng lực. Chính vì thế để tránh việc này xảy ra, các phi hành gia luôn cố gắng tập luyện để các cơ không bị teo đi vì hiếm khi phải sử dụng trong môi trường ngoài không gian.

Bộ não của chúng ta cũng như vậy, nếu lười biếng và để AI làm hết thì não bộ của bạn dần dần sẽ suy giảm chức năng hoạt động. Khi đó, chúng ta dần lệ thuộc AI và không có khả năng phán đoán liệu câu trả lời của AI có còn đúng hay không.

Hãy coi AI như một coach trong phòng gym của bạn mà ở đó nó giúp bạn hiểu các bước trong luyện tập nhưng nó tuyệt đối không được tập thay bạn và bạn chính là người nâng tạ hay chạy trên máy.

Hãy thách đố AI giúp bạn nâng cao trình độ theo từng level, ví dụ như bạn có thể hỏi nó là “Tôi cần học [topic], giả sử tôi là học sinh cấp 2, hãy dạy cho tôi hiểu”. Sau đó hay nâng dần cấp độ lên. Tương tự bạn cũng có thể bảo nó dạy bạn theo kiểu bạn là người mới bắt đầu học về lĩnh vực nào đó.

Bước 4: hãy bước đi với tâm lý kẻ chưa biết

Đây là một mindset mà nó sẽ giúp bạn có thể học tốt mọi vấn đề. Trở ngại lớn nhất của nhiều học sinh giỏi ở một môi trường mới là họ tự cho mình là giỏi và không giữ một thái độ ham học hỏi. Qua thời gian nó sẽ làm bạn ngày càng yếu đi.

Một tổng hợp phân tích 19 nghiên cứu với gần 34.000 người đạt thành tích cao trong nhiều lĩnh vực gồm cờ vua, thể thao Olympic, âm nhạc, khoa học cho thấy rằng người đạt đỉnh sớm ở tuổi thiếu niên hiếm khi là người đứng đầu ở tuổi trưởng thành. Cụ thể, chỉ khoảng 10%4 những người nổi bật sớm tiếp tục đứng ở top khi trưởng thành, và những người xuất sắc ở tuổi trưởng thành thường không phải là những thần đồng khi còn nhỏ.

Chính vì thế khi sử dụng AI bạn cũng hãy thử giả định mình là kẻ khờ ham học hỏi. Ví dụ như bạn có thể hỏi “Hãy giải thích khái niệm [ABC] theo cách đơn giản. Giả sử tôi là đứa trẻ chỉ 10 tuổi”. Lúc này bạn sẽ dễ dàng tiếp cận vấn đề hơn. Tiếp đó bạn có thể đào sâu hơn nếu muốn.

Kết luận: AI amplify, không replace.

Đừng dùng AI để lười đi, hãy dùng nó để ám ảnh với những việc có đòn bẩy cao như những thứ tạo giá trị dài hạn. Mình từng thấy dev ngồi chờ vì Copilot bị lỗi; đó không phải tối ưu, mà là lệ thuộc.

Dù bạn làm business hay viết code, cách dùng đúng là:

• Delegate các việc lặp lại, cơ học cho AI

• Giữ lại phần sáng tạo, phán đoán và tư duy hệ thống cho con người

Khi làm được điều đó, bạn không chỉ làm nhanh hơn, mà còn nguy hiểm hơn theo nghĩa tích cực: hiểu sâu hơn, quyết định tốt hơn. AI lúc này là đồng mình chứ không phải mối nguy.

Bạn nghĩ sao?

Đã từng thử delegate kiểu này chưa? Comment bên dưới hoặc share nếu thấy hữu ích.

Stay smart. 🚀

Một câu trả lời có thể quyết định cả cuộc phỏng vấn

Bạn đã từng ngồi trước màn hình Zoom và bị hỏi: “Bạn đã từng dùng Kubernetes trong production chưa?”

Trong khi thực tế, bạn chỉ mới deploy vài service trên Minikube vào cuối tuần trước.

Nếu trả lời thẳng rằng bạn chưa từng dùng trong production, cuộc phỏng vấn rất có thể kết thúc bằng một nụ cười lịch sự và một email từ chối sau đó. Nhưng nếu bạn trả lời rằng mình đã làm việc với Kubernetes trong một số dự án cá nhân, quen với orchestration, deploy và monitoring, thì cuộc trò chuyện thường sẽ tiếp tục.

Sự khác biệt ở đây không nằm ở việc bạn có gian dối hay không. Nó nằm ở cách bạn kể câu chuyện về trải nghiệm của mình.

Khi phỏng vấn không phải là bài kiểm tra sự trung thực

Phỏng vấn thông thường là một trò chơi tín hiệu bởi lẽ recruiter và hiring manager không có đủ thời gian để kiểm chứng từng chi tiết kỹ thuật.

Theo LinkedIn Talent Solutions, trung bình một recruiter chỉ dành khoảng 6 đến 8 giây để scan một CV trước khi quyết định có đọc tiếp hay không. Trong khoảng thời gian đó, họ không tìm người trung thực nhất. Họ tìm người trông có vẻ phù hợp nhất với nhu cầu hiện tại.

Bản thân tôi với nhiều lần ở vai trò người phỏng vấn thì thường bị đặt dưới áp lực về thời gian: “Tốn ít thời gian nhất nhưng có thể lựa chọn được người phù hợp nhất”. Là một quản lý trong lĩnh vực IT thì phỏng vấn ứng viên không phải là “scope of work” mà chỉ là phần “addons” khi mà team cần scale up hoặc thay thế (backfill) nhân sự ra đi. Chính vì thế tôi luôn có gắng tìm cách tránh phung phí quá nhiều thời gian vào các buổi phỏng vấn để vẫn có thể tập trung thời gian vào các công việc khác của team.

JD được viết để tìm ra người phù hợp, không phải người hoàn hảo

JD (Job Description) thường được viết như một danh sách lý tưởng: 5 năm kinh nghiệm Golang, thành thạo AWS, từng scale hệ thống triệu user.

Tuy nhiên, dữ liệu từ Stack Overflow Developer Survey cho thấy hơn 60% developer đang làm công việc hiện tại không đáp ứng đầy đủ tất cả yêu cầu được ghi trong JD ban đầu. Điều này cho thấy JD phần lớn chỉ là “wish list”, không phải điều kiện cứng.

Nếu bạn nói rằng mình mới code Go một năm rưỡi, CV của bạn có thể bị loại ngay từ vòng screening. Nhưng nếu bạn nói rằng mình đã làm việc với Go khoảng ba đến bốn năm, bao gồm cả side project và tự nghiên cứu, bạn gửi đi một tín hiệu khác. Bạn mở ra cơ hội để bước tiếp và chứng minh năng lực thật.

Trình bày khéo là chuẩn ngầm trong phỏng vấn Tech

Phần lớn engineer không bịa ra một con người hoàn toàn khác trong phỏng vấn. Họ chỉ trình bày kinh nghiệm theo hướng có lợi hơn cho mình.

Có người tính cả thời gian tự học, làm pet project và freelance vào tổng số năm kinh nghiệm. Có người biến “từng thử” thành “đã làm việc với” khi nói về một công nghệ mới. Có người dùng “chúng tôi” để đặt bản thân vào bối cảnh của một hệ thống lớn hơn, dù vai trò thực tế chỉ là một phần nhỏ.

Theo khảo sát của The Interview Guys với nhóm ứng viên ngành công nghệ, khoảng 40% đến 45% ứng viên thừa nhận họ đã phóng đại mức độ kinh nghiệm của mình ít nhất một lần trong phỏng vấn. Phần lớn trong số đó vẫn hoàn thành tốt công việc sau khi được nhận, nhờ học bù rất nhanh trong giai đoạn onboarding.

Trung thực tuyệt đối có thể trở thành bất lợi

Phỏng vấn không thưởng cho sự khiêm tốn quá mức. Khi bạn liên tục nói rằng mình không biết, chưa làm hoặc chưa đủ giỏi, bạn rất dễ bị gắn mác junior, dù năng lực thực tế hoàn toàn đáp ứng công việc.

Theo nghiên cứu của Google ReWork, performance sau khi onboard có mối tương quan yếu với số năm kinh nghiệm được khai báo, nhưng lại có tương quan mạnh với khả năng học và giải quyết vấn đề. Điều này lý giải vì sao nhiều người vẫn thành công dù ban đầu chưa đáp ứng đủ JD.

Một chút phóng đại hợp lý giúp bạn vượt qua các bộ lọc ban đầu, bước vào vòng coding hoặc system design. Đó mới là nơi bạn có cơ hội dùng kỹ năng thật để tạo khác biệt.

Có những ranh giới không nên vượt qua

Storytelling không đồng nghĩa với gian dối vô trách nhiệm.

Những công nghệ dễ bị kiểm chứng sẽ lộ ngay trong live coding. Những dự án, công ty hay bằng cấp không có thật sẽ bị phát hiện qua background check. Theo báo cáo của HireRight, hơn 30% ứng viên bị phát hiện có thông tin không chính xác trong hồ sơ, và đây là một trong những nguyên nhân phổ biến nhất dẫn đến offer bị hủy.

Nguyên tắc hợp lý nhất là nói đủ để được vào phòng phỏng vấn, nhưng phải chứng minh được khi đã ở trong phòng.

Ở vị trí nhà quản lý tôi thường đặt những câu hỏi liên quan đến sự từng trải hay kinh nghiệm, ví dụ như “Khi sự cố này xảy ra thì em/anh sẽ làm gì?”. Những câu hỏi như vậy là dạng mở giúp tôi có thể nhìn được ứng viên đã từng trải qua những vấn đề tương tự hay chưa, không nhất thiết là tôi muốn câu trả lời 100% hoàn hảo nhưng tôi cần câu trả lời tư sự trải nghiệm thực tế của ứng viên.

Cách trình bày khiến bạn trông đáng tin

Thay vì khẳng định cứng, bạn có thể dùng những cách diễn đạt linh hoạt hơn. Bạn có thể nói rằng mình đã làm việc khá nhiều với một công nghệ, quen thuộc với một hệ thống, hoặc đã áp dụng nó trong vài dự án.

Khi bị hỏi sâu vào phần mình chưa làm nhiều, bạn có thể chuyển hướng sang những gì mình làm tốt nhất, đồng thời thể hiện sự sẵn sàng học thêm và tinh thần cầu tiến.

Theo nghiên cứu nội bộ của Amazon được trích dẫn trong các tài liệu về hiring, khả năng học nhanh trong 6 tháng đầu quan trọng hơn việc ứng viên đã biết sẵn bao nhiêu công nghệ trước khi vào công ty.

Kết Luận

Trong môi trường phỏng vấn software engineer cạnh tranh, trung thực tuyệt đối trên giấy tờ đôi khi lại là bất lợi. Bạn không cần hoàn hảo ngay từ đầu. Bạn chỉ cần đủ phù hợp để được trao cơ hội, rồi dùng năng lực thật để giữ lấy nó.

Sự nghiệp bền vững vẫn phải xây trên kỹ năng thực tế. Nhưng ở giai đoạn phỏng vấn, storytelling chiến lược có thể là chìa khóa mở cánh cửa đầu tiên.

Bạn đã từng trình bày khéo trong phỏng vấn chưa. Chia sẻ bên dưới, giữ ẩn danh cũng được.

Ngoài ra nếu bạn đang áp dụng kỹ thuật nào liên quan đến AI mà giúp bạn tăng khả năng nhận được offer thì hãy chia sẻ dưới phần bình luận nhé.

Nếu bạn thấy bài viết này hữu ích, hãy subscribe Substack để nhận thêm những góc nhìn thực tế về career tech.

Tôi có một lịch hẹn cho buổi “Screening Call”. Nếu bạn chưa biết thì “Screening Call” là cuộc gặp mà các nhà tuyển dụng (gọi tắt NTD) dùng để trao đổi và nắm bắt sơ lược về ứng viên cũng như năng lực của họ. Đây không phải là buổi phỏng vấn chuyên sâu và thường sẽ gói gọn trong 30 phút đổ lại. Và thực tế, NTD cũng đã setup một event đúng 30 phút trên lịch cho buổi nói chuyện này của chúng tôi.

Diễn biến: Khi “Sàng lọc” biến thành một cuộc “tra khảo” dài hơi

Tôi bắt đầu buổi meeting bằng việc vào sớm 1 phút (lúc 8:59 am). Sau khi chờ một hồi không thấy ai, tôi bắt đầu hơi lo lắng. Thông thường, tôi sẽ kết thúc buổi gặp nếu phải chờ đợi hơn 10 phút mà không thấy đối tác xuất hiện. Đến khoảng 9:04 am thì NTD cũng vào meeting và chia sẻ lý do vào trễ, nên tôi cũng vui vẻ bắt đầu buổi gặp.

Lúc này, NTD cũng giới thiệu và nhấn mạnh lại đây là buổi Screening chứ không phải một buổi phỏng vấn. Đến đây thì tôi cảm thấy khá rõ ràng, nghĩa là sau vòng này tôi sẽ phải thực hiện thêm vài vòng phỏng vấn nữa và vòng này đơn giản là để thu thập thông tin cơ bản.

Thế nhưng, hành trình sau đó nhanh chóng đi chệch khỏi quỹ đạo. Tôi và NTD bắt đầu trao đổi về lịch sử nghề nghiệp của mình, chỉ có điều là NTD bắt đầu hỏi sâu hơn rất nhiều về công việc của tôi. Tiếp theo đó là những câu hỏi mà có thể nói là chỉ có trong buổi phỏng vấn chuyên sâu mới hỏi. Vì đây đều là những câu hỏi mở nên không thể trả lời ngắn gọn được.

Rất nhiều lần tôi cảm thấy bối rối vì mục đích ban đầu của buổi meeting. Nhưng là người làm việc chuyên nghiệp, tôi cũng không tiện từ chối hay cắt ngang mạch trao đổi. Sau nhiều câu hỏi, tôi nhìn lại đồng hồ thì bây giờ đã là 10:30 am. Tức là thay vì kết thúc vào lúc 9:30 am, buổi meeting này đã kéo dài thêm đúng 1 giờ đồng hồ nữa.

Cũng may mắn là cuộc họp khác của tôi chỉ bắt đầu vào lúc 11 am vì thực ra tôi cũng đã liệu việc meeting có thể kéo dài hơn 30 phút, nhưng thật tình mà nói, tôi đã không nghĩ nó dài đến tận 1 tiếng 30 phút.

Chúng tôi chia tay bằng việc nhận ra chúng tôi “không thuộc về nhau”:

• NTD thấy tôi không phù hợp với vị trí đang tuyển.

• Tôi thấy NTD không phù hợp với mình vì họ đang không tôn trọng thời gian.

Thực ra đây cũng là một công ty lớn nên tôi khá bất ngờ khi cách họ làm việc giống như không có kế hoạch từ trước. Rõ ràng, đây là một trải nghiệm không lấy gì làm vui vẻ khi mà tôi đã mất nhiều hơn thời gian mình sẵn sàng bỏ ra.

Hệ quả dưới góc nhìn tâm lý và kinh doanh

Việc NTD kéo dài thời gian vô tội vạ không đơn thuần là sự “nhiệt tình”, mà là biểu hiện của một quy trình quản trị thiếu hụt, gây ra những hệ quả vô hình:

• Phá vỡ “Hợp đồng tâm lý” (Psychological Contract): Trong tâm lý học tổ chức, mối quan hệ giữa ứng viên và công ty bắt đầu ngay từ lần chạm đầu tiên. Việc vi phạm cam kết về thời gian chính là vết nứt làm sụp đổ niềm tin về một môi trường làm việc chuyên nghiệp.

• Chi phí cơ hội và Trải nghiệm ứng viên: Theo nghiên cứu của CareerBuilder, có đến 78% ứng viên dựa vào trải nghiệm phỏng vấn để đánh giá mức độ công ty coi trọng nhân viên. Một khảo sát từ LinkedIn cũng chỉ ra rằng thái độ tôn trọng thời gian là yếu tố hàng đầu giữ chân ứng viên tiềm năng ngay cả khi họ không trúng tuyển.

Tại sao NTD thất bại trong việc kiểm soát thời gian?

Khoa học quản trị chỉ ra hai nguyên nhân chính dẫn đến tình trạng “lạm phát phỏng vấn”:

1. Quy luật Parkinson (Parkinson’s Law): Quy luật này phát biểu rằng: “Công việc luôn tự mở rộng ra để lấp đầy khoảng thời gian được ấn định cho nó”. Nếu NTD không kỷ luật, buổi nói chuyện sẽ tự động lan man cho đến khi một trong hai bên buộc phải dừng lại.

2. Thiên kiến xác nhận (Confirmation Bias): Khi NTD chưa tìm thấy bằng chứng đủ thuyết phục để “chốt” hoặc “loại”, họ có xu hướng hỏi thêm với hy vọng tìm được câu trả lời mình mong muốn, thay vì tuân thủ cấu trúc đã định.

Giải pháp khoa học để tối ưu hóa phỏng vấn

Bản thân tôi cũng nhiều lần ở vai trò NTD nên tôi hiểu rõ áp lực phải khai thác đủ thông tin. Tuy nhiên, thay vì làm việc “bản năng”, chúng ta có thể áp dụng các phương pháp đã được kiểm chứng:

• Phương pháp “Phỏng vấn cấu trúc” (Structured Interview): Chuẩn bị một bộ câu hỏi đồng nhất và ấn định số phút tối đa cho mỗi phần. Điều này giúp NTD nắm quyền điều phối, thay vì bị cuốn theo dòng câu chuyện của ứng viên.

• Kỹ thuật “Time-Boxing” (Đóng hộp thời gian): Chia nhỏ 30 phút thành các “hộp” cố định: 5 phút giới thiệu - 15 phút câu hỏi then chốt - 5 phút ứng viên hỏi - 5 phút kết thúc.

• Nguyên tắc “Xin phép trước khi chiếm dụng”: Khi không còn nhiều thời gian nhưng có câu hỏi muốn hỏi thêm, tôi luôn chủ động hỏi: “Chúng ta chỉ còn 5 phút, bạn có thể dành thêm bao nhiêu phút cho buổi này hay cần kết thúc đúng giờ?”. Nếu ứng viên bận, tôi sẽ ưu tiên câu hỏi quan trọng nhất hoặc hẹn một buổi phỏng vấn ngắn khác vào dịp khác.

Lời kết

Sự chuyên nghiệp không đo bằng việc bạn hỏi khó bao nhiêu, mà đo bằng mật độ thông tin (Information Density) bạn thu thập được trong đúng khoảng thời gian đã hứa. Việc tôn trọng thời gian của đối tác chính là cách tốt nhất để xây dựng thương hiệu tuyển dụng bền vững.

Có lẽ trong những lần tới, tôi sẽ chủ động ngắt lời NTD sớm hơn để làm rõ mục đích buổi họp, tránh làm mất thời gian của đôi bên. Còn bạn, bạn đã gặp tình huống tương tự hay chưa?

Dần dần nhiều người bắt đầu có suy nghĩ là chúng ta không cần thiết phải thuê developer để phát triển phần mềm, và rồi chỉ cần AI là có thể dễ dàng tạo sản phẩm cho riêng mình.

Trong bài viết này, tôi muốn đi sâu thêm vào các góc nhìn xoay quanh chủ đề này. Để đảm bảo tính khách quan vì bản thân đã từng nhiều năm đảm nhiệm ở vai trò developer, tôi sẽ cố gắng đưa ra những ví dụ tường mình nhất có thể xoay quanh chủ đề này.

Vibe Coding

Khái niệm

Đây là một khái niệm mới xuất hiện và được sử dụng rất nhiều và thường xuyên nhằm mô tả việc có thể phát triển phần mềm dễ dàng dưới sự trợ giúp của AI.

Tôi tổng hợp một số giải thích về thuật ngữ này như sau

• Vibe coding is an AI-assisted software development technique.1

• “Vibe coding” is a new and loosely-defined term in software development that refers to the practice of prompting AI tools to generate code rather than writing code manually.2

• The phrase vibe coding is becoming a tech trend, referring to AI-assisted programming using tools like Claude Code, Cursor, and Codex3

Vậy ta có thể tạm hiểu là Vibe Coding là một cách phát triển phần mềm mà ở đó người ta dùng AI làm trợ lý code thông qua việc ra lệnh (prompting) thay vì tự code.

Tại sao Vibe Coding hấp dẫn như vậy?

Nếu như ngày xưa việc phát triển sản phẩm phần mềm đòi hỏi phải có chuyên gia phát triển phần mềm (hay cách gọi khác là Developer) thì giờ đây bạn chỉ cần biết dùng một số công cụ AI như Claude Code hay Cursor thì bạn có thể tạo ra một sản phầm phần mềm.

Từ bảng so sánh trên thì sức hấp dẫn của vibe coding nằm ở chỗ nó giúp tiết kiệm chi phí và không yêu cầu hiểu rõ hoặc nắm bắt các kiến thức về lập trình. Từ đó giúp những người không có nhiều kiến thức về coding hoặc đã bỏ nghề một thời gian dài có thể dễ dàng tạo ra sản phẩm phần mềm.

AI giúp tạo sản phẩm tốt trong thời gian ngắn?

Đây là một trong những câu hỏi lớn mà chúng ta cần đi tìm lời giải. Nếu trong quá khứ việc tạo ra sản phẩm tốt đòi hỏi quá trình làm việc nghiêm túc trong một thời gian dài thì nay liệu có thể trở thành hiện thực trong thời gian ngắn với AI?

Tôi thậm chí còn thấy một nữ developer (được cho là từ đội ngũ phần mềm của Google) chia sẻ như sau trên nền tảng X.

Theo cổ thì Claude Code (CC) đã giúp cổ xử lý vấn đề mà đội ngũ của cổ làm trong năm ngoái chỉ trong một giờ.

Ở chỗ này, ta sẽ dễ có cảm giác lâng lâng là AI giống như công cụ toàn năng giúp cắt ngắn thời gian xử lý vấn đề một cách khủng khiếp. Nhưng … bạn cần nhìn rõ thêm rằng có nhiều điều cần phải mổ xẻ thêm ở đây.

• Cô ấy sẽ không thể mô tả chính xác vấn đề nếu chưa trải nghiệm nó.

• Sản phẩm AI xây dựng cho cổ có thể tương đồng về tính năng nhưng chưa chắc về chất lượng.

Đấng cứu tinh của dân làm business?

Tôi còn thấy một số bài viết được chia sẻ khác về những người business với hiểu biết hạn chế về coding lại có thể xây dựng được sản phẩm trong vài ngày.

Dạo gần đây, ngày càng nhiều người không am hiểu về code đã chia sẻ rằng mình chỉ mất vài ngày là build được app. Và rồi không cần thiết phải thuê developer làm gì cho tốn chi phí.

Nhưng chia sẻ này chắc chắn sẽ tác động không nhỏ đến thị trường lao động của dân IT vốn dĩ đã vô cùng khắc nghiệt giai đoạn hậu Covid. Khi mà các công ty đã mạnh tay cắt giảm nguồn lao động dư thừa mà đã được tuyển dụng một cách rầm rộ thời điểm trước và trong dịch Covid.

Bản thân nhiều bạn làm developer chắc chắn sẽ mất ăn mất ngủ dài vì việc này. Tôi đã từng trải qua nhiều năm tháng làm developer nên cũng khá quan ngại nếu điều này xảy ra.

Góc nhìn cá nhân

Không đơn giản như thế

Tôi thấy AI là công cụ mạnh mẽ có thể thay đổi bộ mặt nên công nghiệp phần mềm. Nhưng để nói là AI sẽ thay thế developer thì tôi tin chuyện này vẫn còn rất xa vời.

Những gì các bạn thấy chỉ là những sản phẩm mang tính prototype hoặc POC nhằm kiểm tra ý tưởng, thu thập đánh giá người dùng để cải tiến ý tưởng. Hoặc nhiều người sẽ dùng để đi gọi vốn cho startup của mình.

AI mạnh trong tay người giỏi

Để AI có thể build được sản phẩm tốt nó cần rất nhiều chi tiết được chỉ định bởi người dùng. Cụ thể hơn, chúng ta sẽ thấy nhiều người với vai trò mới là Prompt Engineer, đây là những người giúp tạo, chỉnh sửa và cải tiến câu lệnh.

Nếu bạn đưa ra những câu lệnh chung chung thì chỉ nhận lại những sản phẩm tồi. Chính vì thế khúc mắc ở đây vẫn nằm ở người ra lệnh cho AI.

Chỉ những bạn có kiến thức lập trình tốt thì mới dễ dàng mô tả cụ thể vấn đề cần giải quyết cho AI. Nếu không có, bạn sẽ dẫn AI đi tùm lum và không mang lại hiệu quả.

Lỗi thời

Đây là lỗi phổ biến với mọi LLMs (large language model) hiện nay. Nếu bạn chưa biết LLM là gì thì có thể hiểu nôm na là AI giỏi khi mà LLM tốt.

Việc huấn luyện AI đòi hỏi phải có nguồn dữ liệu vô cùng lớn. Chính vì thế AI không dễ được huấn luyện trên dưới liệu mới nhất.

Thay vào đó, AI thường sử dụng những dữ liệu lỗi thời. Bạn có thể dễ dàng kiểm chứng điều này khi đưa vấn đề cho các AI phiên bản cũ. Chúng sẽ đưa ra các cách giải quyết lỗi thời và thậm chí không còn phù hợp.

Lúc này nếu không phải là developer thì bạn sẽ không phân biệt được chất lượng từ code của AI.

Bảo mật

Chính việc AI chỉ được huấn luyện với dữ liệu trong một khoảng thời gian nào đó nên nó hoàn toàn có thể tạo ra các sản phẩm dính đầy lỗ hổng bảo mật.

Nếu không có kỹ năng trong lập trình bạn hoàn toàn có thể xây ra các ứng dụng dễ dàng bị tấn công và ăn cắp dữ liệu.

Lúc này nếu người dùng của bạn xài ứng dụng đó và bị mất cắp dữ liệu thì rủi ro pháp lý của bạn là hoàn toàn có thể xảy ra.

Sửa lỗi

AI cần liên tục cập nhật trạng thái của code để hiểu lỗi. Nhưng trong quá trình xử dụng tôi nhận thấy vấn đề là AI thường tạo ra lỗi hoặc không thể xử lý lỗi một cách triệt để vì nó thiếu cái nhìn tổng quan.

AI được tạo ra nhằm xử lý nhanh vấn đề dẫn đến nó chưa đủ chiều xâu để hiểu về các business logic hoặc rule trong lập trình dẫn đến thiếu ngữ cảnh để sửa lỗi.

Vậy nếu bạn gặp lỗi mà AI không sửa lỗi được thì bạn sẽ phải làm sao nếu bạn không biết code?

Lời kết

Dành cho dân Business

Hãy chỉ sử dụng AI để xây dựng sản phẩm MVP và tạm ngưng suy nghĩ là có AI rồi không cần tuyển lập trình viên nữa.

Theo tôi, điều này còn khá xa vời và việc cần đội ngũ lập trình vẫn là điều cần thiết.

Dành cho dân Developer

AI mở ra thách thức nhưng cũng mở ra cơ hội. Cái bạn cần là học cách sử dụng nó để tăng hiệu quả công việc.

Tránh lạm dụng quá đà vì lâu dần sẽ tăng sự lệ thuộc. Tôi từng thấy có một bạn trong team ngồi chơi cả ngày rồi khi tôi hỏi thì bạn biện minh là hôm nay GitHub Copilot bị lỗi khiến bạn không làm việc được. Đây là ví dụ điển hình cho việc quá lệ thuộc vào các công cụ hỗ trợ lập trình.