Must-Have vs. Advantage: Read Job Postings Like a Parser

A real posting from our catalog lists five technologies. Its icons used to lead with TypeScript and React — the globally popular tags. But read the actual text:

"5+ years of professional C++ development experience" — a must.

"Full-stack development experience (TS/React/Java)" — an advantage.

The posting is a C++ role wearing a full-stack costume. If you filtered by React, you would waste an application; if you are a C++ engineer, you might have scrolled past your best match.

The grammar of requirements

Across thousands of postings, requirement language is surprisingly consistent. It falls into three registers:

Hard signals — this is a filter. "a must", "must have", "required", "mandatory", "you have", and the years pattern — "N+ years of X". In Hebrew postings: חובה. Miss one of these and your application is usually filtered before a human reads it.

Soft signals — this is a tiebreaker. "an advantage", "a plus", "nice to have", "preferred", "bonus", "would be great". In Hebrew: יתרון. These decide between two otherwise-equal candidates; they never decide the whole application.

Silence — read the room. Skills mentioned without any qualifier. Sometimes they are core (check the responsibilities section — if the day-to-day is built on it, treat it as a must). Sometimes they are just context the writer assumed.

More examples from the catalog

"Experience with Kubernetes required; familiarity with service meshes a plus." — Apply if you know K8s, even with zero mesh experience.

"Must be fluent in Python. Go or Rust an advantage." — A Python role. Do not let "Rust" scare you off.

"Strong SQL and data modeling. Bonus: dbt, Airflow." — The bonuses are how you stand out, not how you qualify.

The pattern holds across languages and seniorities: the verbs around a skill matter more than the skill itself.

How the parser actually decides

ApplyDjin now classifies every skill on every vacancy by these signals. For each skill mention we look at the surrounding sentence for a hard marker, a soft marker, or neither, in both English and Hebrew, and we assign a demand level. Then we reorder the skill tags by the posting's own priorities: hard requirements first, unmarked context second, explicit nice-to-haves last — overriding global popularity. The C++ role above now leads with C++, because the posting does. The icons finally match the intent.

The candidate playbook

Apply on musts, not on vibes. If you match every hard requirement and none of the advantages, you are still a strong candidate. The reverse — all the advantages, a missing must — is not.

Years are negotiable, verbs are not. "5+ years of C++" with 3 strong years is worth a shot; "must have production Kubernetes experience" with none is a stretch you should acknowledge rather than hide.

Advantages belong in the cover letter, not the lead. Mention them to break a tie, but never open with "I do not have X, but I do have this nice-to-have". Lead with the musts you hit.

When in doubt, weight the responsibilities section. What you will do every day outranks the wish-list. A skill that appears in both the requirements and the responsibilities is a real must, whatever word sits next to it.

What recruiters see

From the other side of the table, the demand markers are not decoration — they are the screening rubric. A recruiter or an applicant-tracking system usually filters on the hard requirements first and only then reads for the nice-to-haves. Understanding that order is the whole game: you are not trying to impress on every axis, you are trying to clear the filter and then win the tiebreak. Read the posting the way the parser does, and you stop applying to the wrong roles and start recognizing the ones that were written for you.

---

The demand classifier runs on every posting in ApplyDjin, in English and Hebrew, and reorders skill tags across the whole catalog.