JD Của Bạn Có 20 “Must-Have.” Vị Trí Thật Chỉ Cần 4.
JD của bạn liệt kê 20 must-have nhưng vị trí thật chỉ cần 4. Cách phân tích JD để giữ đúng tiêu chí quan trọng và thôi đuổi mất ứng viên giỏi nhất.

Knoot Admin
October 01, 2026
Content
Vì sao JD càng dài, ứng viên giỏi càng ít?
Mọi thứ "bắt buộc" nghĩa là không gì bắt buộc
Bạn dán ba công việc vào một req
Ứng viên giỏi tự loại mình
Không ai audit danh sách — họ thừa kế nó
Kịch bản quen: "Senior Backend, 18 yêu cầu"
Cách phân tích JD để giữ lại đúng tiêu chí quan trọng
Giữ — thiếu nó là không làm được việc ngày đầu
Dạy được — học được trong quý đầu
Bỏ — có mặt chỉ vì copy hoặc cho "oai"
Gắn trọng số cho nhóm Giữ
Knoot Angle

Mở bản JD gần nhất bạn vừa đăng ra. Đếm số dòng trong mục "Yêu cầu".
Nếu con số đó là 15, 18, hay 20 — bạn không viết JD. Bạn viết một danh sách mơ ước.
Và đây là phần ít ai chịu nói ra: mỗi dòng bạn gắn mác "bắt buộc" đang âm thầm đuổi đi đúng những người lẽ ra sẽ nhận việc. Ứng viên giỏi nhất đọc 20 gạch đầu dòng, thấy mình thiếu 3, rồi đóng tab. Ứng viên trung bình thì cứ apply đại.
Thế là bạn ngồi lọc một pipeline đầy người sai, và tự nhủ "thị trường năm nay yếu".
Thị trường không yếu. Bản JD của bạn đang lọc nhầm người.
Vì sao JD càng dài, ứng viên giỏi càng ít?
Một bản JD dài không làm bạn trông kỹ tính hơn. Nó làm bạn mất đúng nhóm người bạn cần nhất.
Mọi thứ "bắt buộc" nghĩa là không gì bắt buộc
Khi 20 dòng đều "required", không dòng nào được ưu tiên.
Bạn không biết hiring manager thật sự cần gì. Ứng viên cũng không. Và bước screening sau đó chấm điểm trên một bộ tiêu chí không có trọng số.
Bạn dán ba công việc vào một req
JD đòi một người quản lý dự án, thiết kế hệ thống, tự estimate, mentor junior, lại còn thành thạo bốn công cụ.
Bạn không mô tả một vị trí. Bạn mô tả ba người.
Kiểu ứng viên đó tồn tại — nhưng họ không apply vào req của bạn.
Ứng viên giỏi tự loại mình
Người đủ tự tin để nhìn thấy mình thiếu ba dòng là đúng người bạn muốn gặp.
Họ cũng là người rời đi đầu tiên.
Người ở lại và bấm "apply" bất chấp thường là người ít đọc kỹ nhất.
Không ai audit danh sách — họ thừa kế nó
Bản JD này là bản copy của JD năm ngoái.
Năm ngoái là bản copy của năm trước nữa. Qua mỗi đợt, hiring manager thêm một dòng ("biết Figma càng tốt"), nhưng chẳng ai bỏ dòng nào đi. Danh sách cứ phình ra, như một kho Excel không ai dọn.
Kịch bản quen: "Senior Backend, 18 yêu cầu"
JD liệt kê 18 dòng: Java, Spring Boot, Kafka, K8s, AWS, CI/CD, 5 năm fintech, "biết Rust là lợi thế", tiếng Anh C1…
200 CV đổ về trong ba ngày. 160 cái mismatch ngay dòng đầu.
Bạn mất cả buổi sáng để loại. Shortlist cuối cùng: 3 người "tạm an toàn".
Hiring manager nhìn xong: "Chưa ai đủ tầm."
Vấn đề không nằm ở ứng viên. Nó nằm ở 18 dòng kia — không ai biết dòng nào mới thật sự quan trọng.

Cách phân tích JD để giữ lại đúng tiêu chí quan trọng
Trước khi mở đợt tuyển, soi từng dòng yêu cầu qua một câu hỏi duy nhất:
Nếu một ứng viên có mọi thứ trừ dòng này, bạn còn muốn phỏng vấn họ không?
Nếu câu trả lời là "có", dòng đó không phải must-have. Đơn giản vậy thôi. Dùng câu hỏi này, mỗi dòng trong JD sẽ rơi vào một trong ba nhóm: Giữ – Dạy được – Bỏ.
Giữ — thiếu nó là không làm được việc ngày đầu
Đây mới là must-have thật.
Thiếu nó, không ai cứu được. Mục tiêu: 3–5 dòng, không hơn.
Với một vị trí Backend, "viết được API production bằng một ngôn ngữ OOP" là Giữ. "Đúng 5 năm trong fintech" thì chưa chắc.
Dạy được — học được trong quý đầu
Đây là nice-to-have thật sự. Đừng gate ở nhóm này.
Một người giỏi học Kafka trong hai tuần. "Kinh nghiệm với công cụ X" gần như luôn thuộc nhóm này.
Gạt chúng xuống nhóm "ưu tiên", đừng để chúng loại người ngay từ đầu.
Bỏ — có mặt chỉ vì copy hoặc cho "oai"
Những dòng không ai nhớ vì sao có.
"Ưu tiên tốt nghiệp đại học top." "Đam mê công nghệ." "Chịu được áp lực cao."
Cắt. Chúng không lọc được gì ngoài sự tự tin của ứng viên.
Gắn trọng số cho nhóm Giữ
Sau khi phân ba nhóm, đừng coi mọi must-have nặng như nhau.
"Viết được code sạch" nặng hơn "có chứng chỉ AWS". Gắn cho mỗi dòng một %. Giờ bạn có một bộ tiêu chí để chấm, thay vì một danh sách để hù dọa.
Cả quy trình này chạy được bằng một file Google Sheet. Không cần công cụ gì cao siêu — chỉ cần chịu khó cắt.
Knoot Angle
Trong tuyển dụng, bản JD không chỉ là mẩu tin đăng tuyển. Nó là bản hợp đồng ngầm giữa bạn và hiring manager về việc "người phù hợp" trông ra sao. Khi bản hợp đồng đó mơ hồ, mọi bước sau đều lệch theo.
Đó là lý do Knoot có module JD Analyzer.
Nó đọc bản JD của bạn và tự tách thành ba nhóm — must-have, nice-to-have, bonus — để bạn thấy ngay đâu là tiêu chí thật. Mỗi tiêu chí có một trọng số, và bạn toàn quyền chỉnh lại hoặc ghi đè: AI gợi ý, bạn quyết định. Bộ tiêu chí đó trở thành đầu vào cho bước screening phía sau, nên không CV nào bị chấm điểm "mù". Nó còn chỉ ra cả những mâu thuẫn nằm sẵn trong JD — tiêu đề ghi "junior" nhưng yêu cầu lại đòi 7 năm kinh nghiệm.
Một bản JD là danh sách mong muốn. JD Analyzer biến nó thành bộ tiêu chí bạn thật sự tuyển được.
Đừng bắt ứng viên giỏi vượt ải 20 dòng yêu cầu. Hãy biết chắc 4 dòng nào mới thật sự quan trọng.
Content
Vì sao JD càng dài, ứng viên giỏi càng ít?
Mọi thứ "bắt buộc" nghĩa là không gì bắt buộc
Bạn dán ba công việc vào một req
Ứng viên giỏi tự loại mình
Không ai audit danh sách — họ thừa kế nó
Kịch bản quen: "Senior Backend, 18 yêu cầu"
Cách phân tích JD để giữ lại đúng tiêu chí quan trọng
Giữ — thiếu nó là không làm được việc ngày đầu
Dạy được — học được trong quý đầu
Bỏ — có mặt chỉ vì copy hoặc cho "oai"
Gắn trọng số cho nhóm Giữ
Knoot Angle