Job title matching

Job title filters in people search are keyword matching, not a search engine for jobs. They match tokens, expand a curated set of synonyms, and never forgive typos. Once you know the rules, the surprises stop: the query that returned 5 people returns 2,600, and the query that timed out stops timing out.

What it does

Three title filters reach the API, all with the same matching core:

• Job title filter (jobTitleV3, and the per-company jobs entries): every word in your query must appear somewhere in the person's title, in any order, unless you pick another match mode. "Engineer Software" matches "Software Engineer".
• Exact mode (exact: true on a plain title rule): the title must equal your string after trimming and lowercasing. Nothing else.
• Keywords filter (keywordsV2): each term is a phrase that must appear in one piece, words adjacent and in order, inside a profile field you enable.

Titles match current roles only by default. To match past roles, set the employment status filter or use a jobs entry scoped to past tenure.

No typo tolerance, anywhere

Title matching, keyword matching, and exact mode all match spelling exactly: "Enginner" matches nothing. Normalize your input first; the job-title typeahead (job title synonym expansion) helps here.

Synonyms expand in both directions

A curated acronym map expands at query time, both ways, on normal title matching: CTO matches "Chief Technology Officer", and "Chief Technology Officer" matches profiles titled CTO. MTS matches "Member of Technical Staff". The common families are covered: C-suite, SWE variants (including swe), VP, sdr, bdr, tpm, sre, devops.

Synonyms do not apply to phrase mode, prefix mode, stemming, the keywords filter, or exact equality. Stemming expands word forms instead of the synonym map — the two do not stack on the same rule.

Match modes

Plain title rules take mode. Omit it and you get normal.

{
  "searchParams": {
    "jobTitleV3": {
      "anyOf": [
        { "type": "plain", "term": "engineering manager", "mode": "phrase" }
      ]
    }
  },
  "pageSize": 25
}

Prefix is per word, not a substring of the whole title. eng matches titles that contain a word starting with "eng"; it does not match "reengineering". Send mode: "prefix" when you mean it. A * inside the term (eng*ineer) is stripped, not treated as a wildcard.

Stemming

Set stemming: true on a plain rule to also match morphological variants: manager matches "managers", engineer matches "engineers" and "engineering". Stemming replaces synonym expansion on that rule rather than stacking on top of it.

It can over-match. product manager with stemming on can also surface titles built from the same roots (including "production" / "management" forms you probably did not mean).

{
  "searchParams": {
    "jobTitleV3": {
      "anyOf": [
        { "type": "plain", "term": "engineer", "stemming": true }
      ]
    }
  }
}

Inputs and outputs

A title rule in plain form:

{
  "searchParams": {
    "jobTitleV3": {
      "anyOf": [
        { "type": "plain", "term": "software engineer" }
      ]
    },
    "country3LetterCode": { "noneOf": ["IND"] }
  },
  "pageSize": 25
}

Exact equality:

{
  "searchParams": {
    "jobTitleV3": {
      "anyOf": [
        { "type": "plain", "term": "member of technical staff", "exact": true }
      ]
    }
  }
}

Exact mode compares after trim and lowercase only. Punctuation and stop words are preserved: exact "VP of Engineering" does not match "VP, Engineering".

What matching ignores, and what it doesn't

These rules apply to normal, phrase, and prefix matching (not to exact equality):

• Case does not matter. CTO and cto are the same query.
• Accents do not matter. señor and senor match the same titles.
• Punctuation is a word break, not part of the token. VP, Engineering is two words, same as VP Engineering. Hyphens usually split too (co-founder is co and founder).
• Word order is ignored in normal mode and enforced in phrase mode.

Exact equality keeps punctuation, spacing, and stop words as you typed them.

What is not supported

Title matching is not a mini query language. These do not do anything special; they are literal characters in the term:

• Quoted strings ("head of sales"). Quotes stay in the string. For ordered matching, use mode: "phrase".
• +word / -word require/exclude syntax. Exclude with noneOf on the title filter, or negate on a keywords clause.
• Mid-string or leading wildcards (*geering*, *engineer). Only a trailing * in prefix mode is sugar for "starts with".
• Substring matches inside a word in normal mode. engin is a different token from engineer unless you set mode: "prefix".

Combination rules: functional and cartesian

Two rule shapes generate title lists for you before matching runs. Generated titles then match like normal plain titles (token-AND, synonyms). They do not take mode, stemming, or exact.

Functional rules combine a seniority axis with keyword axes using our own smart templates: { "type": "functional", "seniority": ["c-suite"], "keywords": ["marketing"] } expands to "Chief Marketing Officer" and related forms. Omit keywords and only the seniority titles match (c-suite covers Founder, CEO, CTO, and friends). Each functional rule generates at most 75 titles; a keyword that already carries its seniority word passes through unchanged.

Cartesian rules multiply out keyword sets you supply. Give keywordArrays two or more arrays and every combination across the arrays becomes one title:

{
  "searchParams": {
    "jobTitleV3": {
      "anyOf": [
        {
          "type": "cartesian",
          "keywordArrays": [
            ["senior", "staff", "lead"],
            ["software", "platform", "infrastructure"],
            ["engineer"]
          ]
        }
      ]
    }
  }
}

Three by three by one generates nine titles: "senior software engineer", "staff platform engineer", "lead infrastructure engineer", and the rest of the grid. It is the right tool when the title space you want is a product of sets you can name, and you would otherwise paste the list in by hand.

Rules of the road for cartesian:

• Generated titles match like plain titles in normal mode: token-AND matching with synonyms, never exact, phrase, or prefix.
• Each rule caps at 500 generated titles. Combinations multiply fast; a 10 by 10 by 6 grid already exceeds the cap and gets truncated.
• Fan-out costs latency. The more titles a rule generates, the slower the search. Prefer the smallest grid that covers your intent, and count before you search.

Use plain anyOf lists when you already have the titles; use functional rules when seniority shaping is the job; use cartesian when the titles are a cross-product you would otherwise enumerate client-side.

When the keywords filter is the better tool

Title filters in normal mode match tokens anywhere in the title and expand synonyms, so they cast wide: "member of technical staff" also surfaces acronym forms like "Software Engineering MTS", and they cannot subtract seniority. Phrase mode on the title filter is the in-order alternative on titles only. The keywords filter is still the tool when the phrase might live in headline, summary, or another field you choose.

Say you want everyone titled "Member of Technical Staff" at two specific companies. The title filter returns only profiles whose titles carry those tokens literally. The keywords filter, scoped to current job titles, returns the full population:

{
  "searchParams": {
    "keywordsV2": {
      "clauses": [
        {
          "terms": ["member of technical staff", "member technical staff"],
          "operator": "OR"
        }
      ],
      "options": {
        "fieldsToSearchOver": {
          "currentJobTitles": true,
          "headline": false,
          "summary": false,
          "industry": false,
          "currentJobSummaries": false,
          "currentCompanyNames": false,
          "pastJobTitles": false,
          "pastJobSummaries": false,
          "pastCompanyNames": false,
          "interests": false,
          "skills": false,
          "education": false,
          "publications": false,
          "certifications": false,
          "articles": false,
          "patents": false,
          "courses": false,
          "projects": false,
          "volunteering": false,
          "languages": false
        }
      }
    },
    "currentCompanies": [
      { "linkedinOrgID": "11130470" },
      { "linkedinOrgID": "7936402" }
    ]
  },
  "pageSize": 25
}

Three rules make this work:

• Set every field explicitly. 18 of the 20 keyword fields default to on and omitted fields stay on; leaving summaries and headlines in scope can balloon the same query several-fold. Unknown field names are silently ignored, so a typo'd field stays at its default.
• Order words the way titles are written. "technical staff member" is a different, much larger phrase world than "member of technical staff". Include the stop-word-free variant ("member technical staff") in terms for recall.
• Subtract with a negated clause. Phrases match inside longer titles ("VP, Member of Technical Staff" still matches), so add a clause with negate: true for variants you do not want, such as "senior member of technical staff".

Run the count operation with identical parameters first (1 credit) to preview the result-set size, and give count and search generous client timeouts (60 to 120 seconds): phrase queries over many fields are the heaviest this endpoint family runs.

Using it effectively

• Count before you search. Run the count operation with the same parameters first; it costs a single count credit and shows how big the set is before you pay per result. For recurring versions of the same query, save it as a saved search; scheduled runs follow the same count, then search rules.
• Give phrase queries generous timeouts. Keyword-heavy queries over many fields multiply the work per page; 60 to 120 seconds is a safe client timeout for counts and searches like this.
• Want equality? Use exact mode. The plain title filter is containment: "Software Engineer" also returns every "Senior Software Engineer".
• Want ordered words without exact equality? mode: "phrase" — "engineering manager" still matches "Senior Engineering Manager", unlike exact: true.
• Want breadth? Expand, don't hope. Run the job-title synonym expansion on your seed title and feed the variants back as additional anyOf terms. Its suggestions are advisory: search doesn't automatically expand every suggested variant, so add the ones you want explicitly. Stemming is the other breadth knob, and it is coarser.
• Scope by company for team snapshots. Combine the keywords filter with a current-companies constraint (by LinkedIn org ID, domain, or URL) to get "everyone with this title at these companies" in one query.
• Watch current vs past. Title filters default to current roles only; past-title keyword fields only see roles that have ended.

Use cases

• Building a hiring pipeline for one exact title (exact mode, count first).
• Talent mapping across acronyms and variants (synonyms plus expanded variants).
• Catching "Engineering Manager" without "Manager of Engineering" (phrase mode).
• Prefixing a stem you don't want to enumerate (engin → engineer, engineering) now that prefix is available.
• Cleaning up an over-broad keyword query by switching fields off explicitly.

Operations

Search credits are charged per result returned; counts are 1 credit. See Billing for per-operation pricing, and Search for the rest of the filter surface.