Writing a Job Description in Hong Kong? Why the CVs You're Getting Are Wrong

HR Plus
Aug 19
4 min read

Every hiring manager has said some version of this: "we're getting applications, just not from the right people." The usual explanation is that the candidate pool in Hong Kong is thin for this role, or that people aren't reading the requirements properly, or that the platform is sending low-quality traffic.

Before accepting any of those explanations, it's worth asking a less comfortable question: what if the job description is doing exactly what it was written to do — and what it was written to do isn't what you actually need?

A useful first test, before rewriting anything: look at the last 5–10 applicants and check whether they matched the JD's stated requirements on paper. If most of them did, and the mismatch only became clear at interview, that's a strong signal the JD is filtering on the wrong signal — the paper match isn't predicting the real one.

A Job Description Is a Filter, and Filters Do What They're Built to Do

A job description isn't a passive summary of a role. It's an active filter. Every line either invites the right person in or lets the wrong person think they qualify. If the applicants coming in feel consistently off — overqualified, underqualified, or qualified on paper but wrong in the interview — that's not the candidate pool malfunctioning. That's the filter working, just filtering for the wrong thing.

This reframe matters because it changes where you look for the fix. "The market is thin" is a problem you can't act on. "The JD is filtering for the wrong signal" is a problem you can fix this week.

Three Ways a Job Description Filters for the Wrong Person Without Anyone Noticing

It filters for people who can match keywords, not people who can do the job. A requirements list built from years of experience, tool names, and certifications selects for candidates good at reading a requirements list — not necessarily candidates good at the actual work. Two people with identical bullet points on paper can be completely different performers, and a keyword-matched JD can't tell them apart before the interview stage, which means it isn't really filtering at all at the application stage. This is also why a longer, more detailed requirements list isn't automatically the safer choice — it filters more aggressively, but not always for the traits that matter. It often filters out strong candidates who don't check every box, while still letting through candidates willing to pad a CV to match.

It filters out the candidates who'd actually be strongest. This is the counterintuitive part. Candidates who are genuinely excellent at a role are often the ones most likely to self-select out of an unrealistic requirements list — they read "8+ years, 3 certifications, fluent in 3 languages" and correctly conclude the company wants someone who checks every box, which is rarely the same thing as someone who'd excel in the role. The applicants who do apply are disproportionately either people who don't read carefully, or people willing to inflate their CV to match — which is precisely the "wrong CVs" pattern hiring managers describe.

It filters for candidates who are OK with ambiguity, at the cost of everyone else. If a JD omits reporting line, team size, why the role is open, and what the first few months look like, it isn't neutral — it selects for candidates comfortable applying without that information, and screens out candidates (often the more senior, more selective ones) who want that clarity before spending time on an application. The company loses exactly the people it's usually most trying to attract.

Writing a Job Description in Hong Kong That Filters for the Right Fit

When we take on a search and the brief includes "the market for this role is difficult" or "we keep getting the wrong applicants," the JD itself is one of the first things worth examining — not as a formality, but because it's often carrying assumptions nobody intended to put there: a requirements list built by combining five people's wish lists, a role description copied from three years ago, or language that quietly assumes a specific background the company didn't mean to require. Reviewing the brief and the JD together, before sourcing even begins, is a normal part of how we scope a search — precisely because a misaligned JD wastes time on both sides once sourcing starts.

The fix is rarely "write more requirements to be safe." It's closer to the opposite — cutting the list down to what would genuinely disqualify someone in an interview, and replacing the rest with the information a strong candidate actually needs to decide whether this is worth their time. That said, a JD rewrite isn't automatically the answer every time applications miss the mark — sometimes the issue sits elsewhere, in compensation positioning, timing, or the platform used. But a JD review is a fast, low-cost thing to check before assuming the candidate pool itself is the constraint.