Mở đầu — vì sao bài này quan trọng
Có một sự thật hơi phũ mà ít ai nói thẳng với bạn khi mới vào nghề: kỹ năng đặt câu hỏi tốt là một trong những thứ phân biệt rõ ràng nhất giữa một junior "khó chịu" và một junior mà cả team ai cũng muốn giúp đỡ.
Bạn đã từng gặp cảnh này chưa? Bạn nhắn vào channel dev: "Anh ơi, code em bị lỗi, anh xem giúp em với." Rồi im lặng. Ba mươi phút sau senior mới rep: "Lỗi gì em? Ở đâu? Em thử gì rồi?" Bạn phải trả lời từng câu, qua lại năm bảy lượt tin nhắn, tốn của cả hai người nửa buổi sáng — chỉ để senior nhận ra vấn đề thực ra rất đơn giản. Cuộc trao đổi lẽ ra chỉ cần một tin nhắn.
Trong ngành tech, câu hỏi không chỉ là cách bạn lấy thông tin. Nó là một chữ ký về năng lực tư duy của bạn. Khi bạn đặt một câu hỏi rõ ràng, có ngữ cảnh, thể hiện rằng bạn đã tự thử — người đọc lập tức hiểu rằng bạn là người suy nghĩ có hệ thống. Ngược lại, một câu hỏi mơ hồ, lười biếng sẽ ngầm báo hiệu điều ngược lại, dù bạn có giỏi đến đâu.
Đáng buồn là văn hóa "RTFM" (Read The Fucking Manual — tự đi đọc tài liệu đi) và những phản hồi kiểu "Google đi em" đã làm hỏng rất nhiều môi trường tech. Nó khiến người mới sợ hỏi, và khi sợ hỏi thì họ hoặc là kẹt hàng giờ một cách vô nghĩa, hoặc là đoán mò rồi tạo ra bug. Bài học hôm nay không dạy bạn "đừng hỏi". Nó dạy bạn cách hỏi sao cho câu hỏi của bạn trở thành thứ mà người khác thấy vui khi được trả lời — và biến việc hỏi từ một điểm yếu thành một siêu năng lực nghề nghiệp.
Khái niệm cốt lõi
"RTFM" là toxic — nhưng "làm sao để hỏi tốt?" là câu hỏi vàng
Phản ứng "RTFM" xuất phát từ một sự thật có thật: rất nhiều câu hỏi đáng lẽ người hỏi có thể tự tìm ra trong 30 giây. Nhưng cách phản ứng đó lại sai, vì nó tấn công người thay vì cải thiện câu hỏi. Cái chúng ta muốn học ở đây là làm sao để câu hỏi của bạn không rơi vào nhóm đáng bị RTFM ngay từ đầu.
Nguyên tắc nền tảng: một câu hỏi tốt là câu hỏi mà người trả lời có thể trả lời ngay, không cần hỏi lại bạn thêm điều gì. Mỗi vòng hỏi-đáp qua lại (round-trip) là một lần bạn làm gián đoạn công việc của người khác. Trong môi trường async — làm việc từ xa, lệch múi giờ — mỗi round-trip có thể tốn nửa ngày. Mục tiêu của bạn là nén tối đa thông tin cần thiết vào một lần hỏi.
Công thức của một câu hỏi tốt
Một câu hỏi kỹ thuật chất lượng thường có đủ bốn thành phần, có thể nhớ bằng chữ CAGE:
- C — Context (Ngữ cảnh): Bạn đang cố làm gì? Trong hệ thống nào, môi trường nào (production, staging, local)? Phiên bản nào?
- A — Attempt (Đã thử gì): Bạn đã thử những cách nào, và mỗi cách cho kết quả ra sao? Điều này chứng minh bạn không lười và giúp người khác không gợi ý lại thứ bạn đã loại trừ.
- G — Goal vs. Got (Kỳ vọng vs. Thực tế): Bạn mong điều gì xảy ra, và thực tế điều gì đã xảy ra? Kèm error message chính xác, log, screenshot.
- E — Environment cụ thể: OS, phiên bản ngôn ngữ/framework, cách tái hiện lỗi (steps to reproduce).
> ❌ "Anh ơi API em gọi bị lỗi, giúp em với."
> ✅ "Em đang gọi endpoint POST /orders trên môi trường staging (Node 18, axios 1.6). Em kỳ vọng nhận về 201 nhưng nhận 401 Unauthorized, dù em đã gắn Bearer token vào header (em đã log token ra và nó không rỗng). Em đã thử: (1) gọi lại token mới — vẫn 401; (2) test cùng token bằng curl thì lại 200. Em nghi axios đang strip header nhưng chưa rõ vì sao. Đây là đoạn config axios của em: [link]."
Câu thứ hai có thể được trả lời ngay trong một lượt. Câu đầu tiên tốn năm lượt.
XY Problem — cái bẫy nguy hiểm nhất khi đặt câu hỏi
Đây là khái niệm quan trọng nhất của bài này, và là thứ khiến ngay cả senior cũng thường xuyên vấp phải.
XY Problem xảy ra khi: bạn có vấn đề thật là X, bạn tự nghĩ ra giải pháp là Y, rồi bạn đi hỏi về cách làm Y — mà không bao giờ nhắc đến X. Kết quả: người trả lời tốn công giúp bạn làm Y, trong khi Y có thể là một hướng đi hoàn toàn sai, và vấn đề X của bạn lẽ ra có cách giải quyết đơn giản hơn nhiều.
Ví dụ kinh điển: một bạn hỏi "Làm sao để lấy 3 ký tự cuối của tên file trong Bash?" (đó là Y). Mọi người nhiệt tình chỉ cách cắt chuỗi. Nhưng hóa ra vấn đề thật (X) của bạn là muốn lấy phần mở rộng của file — mà phần mở rộng không phải lúc nào cũng dài đúng 3 ký tự (.jpeg, .md, .tar.gz). Nếu bạn hỏi thẳng X ngay từ đầu, ai đó đã chỉ bạn dùng công cụ tách extension chuẩn, và bạn tránh được cả một loạt bug về sau.
Cách phòng chống XY Problem: Luôn kể tại sao bạn cần điều đó. Thêm một câu: "Em đang cố làm X, và em nghĩ cách Y có thể giúp — nhưng em không chắc đây có phải hướng đúng không." Câu này mở đường cho người trả lời chỉ ra rằng có thể bạn không cần Y chút nào.
Hỏi công khai (public by default)
Một nguyên tắc văn hóa quan trọng trong tech: ưu tiên hỏi ở channel công khai thay vì nhắn tin riêng (DM). Vì sao? Vì câu hỏi và câu trả lời của bạn trở thành tài liệu cho người tiếp theo gặp đúng vấn đề. Một câu hỏi hay được lưu lại trong channel có thể tiết kiệm thời gian cho hàng chục người sau này. Hỏi riêng một người vừa tạo áp lực lên đúng người đó, vừa "chôn vùi" tri thức.
Tình huống thực tế
Tình huống 1 — Junior tại một startup fintech ở TP.HCM và cái bẫy XY Problem
Minh, một backend developer mới ra trường, làm tại một startup fintech khoảng 25 người ở Quận 1. Anh được giao task xử lý import file giao dịch từ ngân hàng. Minh nhắn vào channel #backend:
> "Anh chị ơi, làm sao để đọc file Excel .xlsx trong Python mà nhanh hơn không ạ? File em đọc bằng openpyxl mất 40 giây, chậm quá."
Cả team lao vào tối ưu: người gợi ý dùng pandas, người bảo thử thư viện python-calamine, người khác nói bật chế độ read_only. Minh thử hết, xuống còn 25 giây, vẫn thấy chậm. Mất gần hai tiếng của bốn người.
Cuối cùng một senior tên chị Lan hỏi ngược: "Khoan, mà em đọc file Excel để làm gì? Nguồn file này ở đâu ra?" Minh trả lời: file do ngân hàng gửi qua API mỗi ngày. Chị Lan hỏi tiếp: "API đó có trả về định dạng CSV hoặc JSON không?" Có — ngân hàng có endpoint trả CSV, chỉ là bạn dev cũ trước đó chọn tải bản Excel. Đọc CSV mất... 0,3 giây.
Vấn đề thật (X) là "đọc dữ liệu giao dịch nhanh". Minh đã tự nhốt mình vào giải pháp Y ("đọc Excel nhanh hơn") và chỉ hỏi về Y.
Bài học: Nếu Minh mở đầu bằng ngữ cảnh — "Em cần load dữ liệu giao dịch ngân hàng gửi hàng ngày để xử lý, hiện em đang đọc file Excel nhưng chậm" — thì ngay câu hỏi đầu tiên đã lộ ra rằng vấn đề nằm ở lựa chọn định dạng file, chứ không phải thư viện đọc. Luôn nói tại sao, không chỉ cái gì.
Tình huống 2 — Câu hỏi mơ hồ vs. câu hỏi có cấu trúc tại một team remote
Tại một công ty product làm outsourcing cho khách Singapore, team dev ở Đà Nẵng làm việc async với tech lead ở Singapore lệch một tiếng nhưng thường online lệch nhau nhiều hơn. Hùng gặp lỗi deploy và nhắn:
> "Anh ơi deploy bị fail rồi, anh check giúp em."
Tech lead lúc đó đang họp, ba tiếng sau mới thấy. Anh phải hỏi lại: "Fail ở step nào? Log đâu?" Hùng lúc này lại đang ăn trưa. Cứ thế, một vấn đề lẽ ra 10 phút kéo dài gần cả ngày làm việc — chỉ vì mỗi round-trip tốn vài tiếng do lệch thời gian online.
Lần sau, sau khi được góp ý, Hùng đổi cách:
> "Deploy service payment-gateway lên staging bị fail ở step docker build (không phải step deploy). Error: COPY failed: no such file or directory: ./dist. Em đoán do thư mục dist chưa được build trước khi Docker copy. Em đã thử chạy npm run build local thì ra thư mục dist bình thường. Đây là link CI log đầy đủ: [link]. Em nghĩ có thể CI thiếu step build trước docker — anh xem giúp em có phải không ạ?"
Tech lead đọc xong, reply đúng một câu: "Chuẩn rồi, thêm npm run build vào trước bước docker trong file ci.yml, anh đã comment ở dòng 34." Xong. Một round-trip duy nhất.
Bài học: Trong môi trường async/remote — vốn ngày càng phổ biến ở Việt Nam khi làm cho khách nước ngoài — một câu hỏi tốt không chỉ lịch sự, mà là tiết kiệm hàng giờ đồng hồ thực tế. Nén thông tin vào một lượt là kỹ năng sống còn.
Tình huống 3 — Khi "hỏi công khai" cứu cả team
Một team 12 người tại một công ty SaaS ở Hà Nội có thói quen mọi người hay DM riêng cho anh Tuấn — người rành nhất về hệ thống authentication. Mỗi tuần anh Tuấn nhận cả chục DM hỏi cùng một kiểu câu về lỗi token hết hạn. Anh trả lời đi trả lời lại, mệt mỏi, và tri thức đó không đọng lại ở đâu cả.
Team quyết định đổi luật: mọi câu hỏi kỹ thuật phải hỏi ở channel #dev-help công khai, kèm cấu trúc CAGE. Sau hai tháng, điều thú vị xảy ra: khi ai đó gõ "token expired" vào ô tìm kiếm của channel, họ tìm thấy ngay 5-6 câu hỏi cũ đã được giải đáp đầy đủ. Số DM tới anh Tuấn giảm 70%. Quan trọng hơn, những junior khác bắt đầu tự trả lời được cho nhau, vì câu trả lời đã nằm sẵn ở đó.
Bài học: Hỏi công khai biến mỗi câu hỏi thành một viên gạch tài liệu. Nó phân tán gánh nặng khỏi một cá nhân và làm cả team thông minh hơn theo thời gian.
Hướng dẫn từng bước
Đây là quy trình bạn nên chạy trong đầu trước khi gõ câu hỏi:
Bước 1 — Tự thử trong một khoảng thời gian có giới hạn (timebox). Dành 15–30 phút tự tìm hiểu: đọc error message thật kỹ, đọc docs, search Google/Stack Overflow, hỏi AI. Đừng kẹt quá lâu (quá 30–60 phút mà không tiến triển thì hỏi ngay — kẹt cả buổi mới là lãng phí thật sự).
Bước 2 — Xác định vấn đề thật (X), không phải giải pháp bạn tưởng tượng (Y). Tự hỏi: "Rốt cuộc mình đang cố đạt được điều gì?" Viết X ra một dòng riêng.
Bước 3 — Gom bằng chứng. Copy error message đầy đủ và chính xác (đừng gõ lại từ trí nhớ, đừng chụp mờ). Chuẩn bị log, phiên bản môi trường, và các bước tái hiện.
Bước 4 — Viết theo cấu trúc CAGE. Context → Attempt → Goal vs Got → Environment. Kèm luôn lý do (X) để tránh XY Problem.
Bước 5 — Định dạng cho dễ đọc. Dùng code block (```) cho code và log, đừng dán code trần vào chat. Đặt câu hỏi cụ thể ở cuối: "Em nên kiểm tra hướng nào?" thay vì "Sao nó lỗi vậy?".
Bước 6 — Chọn kênh công khai phù hợp và đúng người/nhóm liên quan, thay vì DM một người.
Bước 7 — Sau khi được trả lời, đóng vòng lặp (close the loop). Reply lại: "Cảm ơn anh, đúng là do X, em đã fix bằng cách Y." Điều này vừa lịch sự, vừa hoàn thiện tài liệu cho người sau.
Lỗi thường gặp & mẹo
Lỗi 1 — "Nó không chạy" mà không nói "không chạy" nghĩa là gì. Không chạy là crash? Là kết quả sai? Là treo? Là báo lỗi gì? Luôn mô tả triệu chứng cụ thể.
Lỗi 2 — Chụp màn hình lỗi thay vì copy text. Screenshot không search được, không copy được để thử. Với error message dạng chữ, hãy dán text, dùng code block. Screenshot chỉ dùng cho lỗi giao diện trực quan.
Lỗi 3 — "Anh có rảnh không?" rồi im lặng chờ. Đừng hỏi meta ("Em hỏi được không?") rồi dừng lại chờ phản hồi mới hỏi tiếp — đó là thêm một round-trip vô nghĩa. Hãy hỏi thẳng luôn nội dung; nếu người ta rảnh họ trả lời, không thì họ trả lời sau.
Lỗi 4 — Giấu ngữ cảnh vì sợ "câu hỏi dài quá". Câu hỏi đủ ngữ cảnh luôn tốt hơn câu hỏi ngắn cụt. Người trả lời thà đọc thêm vài dòng còn hơn phải hỏi lại.
Lỗi 5 — Đặt câu hỏi "đóng" khi cần câu hỏi "mở" và ngược lại. Nếu bạn muốn xác nhận nhanh, hỏi đóng ("Cách này đúng không anh?"). Nếu bạn đang mắc kẹt về hướng đi, hỏi mở ("Anh sẽ tiếp cận vấn đề này thế nào?"). Chọn sai kiểu sẽ không lấy được thứ bạn cần.
Mẹo 1 — "Rubber duck" trước khi hỏi người. Rất nhiều lần, chỉ cần viết câu hỏi ra thật đầy đủ, bạn đã tự tìm ra đáp án ngay trước khi bấm gửi. Việc buộc mình diễn đạt rõ ràng chính là một công cụ debug.
Mẹo 2 — Dùng AI làm vòng hỏi đầu tiên. Trước khi làm phiền đồng nghiệp, hỏi AI với đầy đủ ngữ cảnh CAGE. AI trả lời tức thì, không phán xét, và giúp bạn thu hẹp vấn đề — để khi hỏi người, bạn hỏi được câu chất lượng cao hơn.
Mẹo 3 — Nêu giả thuyết của bạn. "Em nghĩ nguyên nhân là X vì..." cho người trả lời một điểm bám để xác nhận hoặc bác bỏ, nhanh hơn nhiều so với việc họ phải phân tích lại từ đầu.
Bài tập thực hành
Bài 1 — Viết lại câu hỏi tệ. Lấy câu sau và viết lại theo cấu trúc CAGE (tự bịa ngữ cảnh hợp lý): "Web em load chậm quá, mọi người biết vì sao không?" Mục tiêu: viết một phiên bản mà người đọc có thể bắt đầu giúp ngay trong một lượt.
Bài 2 — Săn XY Problem. Nhớ lại lần gần nhất bạn hỏi ai đó một câu kỹ thuật. Tự trả lời: câu hỏi đó là X (vấn đề thật) hay Y (giải pháp bạn đã tự chọn)? Nếu là Y, hãy viết ra X thật đằng sau nó.
Bài 3 — Timebox có kỷ luật. Lần tới khi kẹt, đặt hẹn giờ 30 phút. Ghi lại những gì bạn thử trong 30 phút đó. Khi hết giờ, biến chính danh sách "đã thử" đó thành phần Attempt trong câu hỏi. Bạn sẽ thấy câu hỏi tự nhiên trở nên chất lượng.
Bài 4 — Đóng vòng lặp. Trong tuần này, mỗi lần được ai đó giúp giải quyết vấn đề, hãy reply công khai một dòng tóm tắt nguyên nhân và cách fix. Quan sát xem điều đó thay đổi cách team nhìn nhận bạn ra sao.
Tóm tắt
- Câu hỏi là chữ ký năng lực của bạn. Một câu hỏi rõ ràng khiến người khác vui vẻ giúp bạn và tin tưởng vào tư duy của bạn.
- "RTFM" là toxic, nhưng câu hỏi lười biếng là có thật. Mục tiêu không phải là đừng hỏi, mà là hỏi sao cho không cần ai phải hỏi lại bạn.
- Dùng cấu trúc CAGE: Context, Attempt, Goal-vs-Got, Environment. Nén đủ thông tin vào một lượt để tiết kiệm round-trip — đặc biệt quan trọng trong môi trường async/remote.
- Cảnh giác với XY Problem: đừng chỉ hỏi về giải pháp Y bạn tự nghĩ ra; luôn kể vấn đề thật X và lý do bạn cần nó. Đây là nguồn gốc của phần lớn thời gian bị lãng phí.
- Hỏi công khai theo mặc định để câu hỏi trở thành tài liệu cho người sau và giảm gánh nặng lên một cá nhân.
- Timebox việc tự thử, gom bằng chứng chính xác (copy text, không chụp mờ), nêu giả thuyết của bạn, và đóng vòng lặp sau khi được giúp.