64 lines
2.5 KiB
Markdown
64 lines
2.5 KiB
Markdown
# Recruiter-Side Application Heuristics
|
|
|
|
Use these rules for candidate-facing documents and answers: PDF summaries,
|
|
bullets, cover letters, form answers, LinkedIn messages, recruiter scripts, and
|
|
interview prep. They do not apply to internal evaluation reports unless a mode
|
|
explicitly asks for analysis.
|
|
|
|
## Recruiter-Side Risk Map
|
|
|
|
Before generating a CV, cover letter, form answer, recruiter script, or
|
|
interview prep, create a small internal risk map:
|
|
|
|
| Potential doubt | Evidence from CV/report | Candidate-facing fix |
|
|
|-----------------|-------------------------|----------------------|
|
|
| Can they do this stack? | Matching tools, systems, projects | Put the exact stack in truthful context |
|
|
| Are they senior enough? | Ownership, scope, tradeoffs, mentoring | Lead with senior behaviors, not tenure alone |
|
|
| Is the domain relevant? | Similar users, workflows, scale, constraints | Translate adjacent proof into the JD's language |
|
|
| Is there a logistics blocker? | Location, comp, work-auth, availability | Answer only where the form/recruiter asks |
|
|
| Is the application generic? | Weak or broad bullets | Rewrite around this role's concrete problems |
|
|
|
|
Use the map to reduce review risk. Do not print it unless the mode output
|
|
explicitly asks for analysis. Never invent evidence to close a doubt.
|
|
|
|
## Six-Second Clarity Gate
|
|
|
|
For every CV/PDF and cover letter, the top third must make the target fit
|
|
impossible to miss:
|
|
|
|
- target role/archetype
|
|
- strongest matching stack or domain
|
|
- one production or business outcome
|
|
- location/remote fit only when appropriate for that document
|
|
- portfolio/case-study link when available and relevant
|
|
|
|
If a recruiter must infer fit from scattered bullets, rewrite the summary and
|
|
first experience bullets.
|
|
|
|
## Business-Value Bullets
|
|
|
|
Prefer:
|
|
|
|
`Action + system/scope + tool/approach + outcome + proof`
|
|
|
|
Good patterns:
|
|
|
|
- `Resolved [problem] in [system], improving [business/system effect].`
|
|
- `Built [capability] with [tools], enabling [user/team outcome].`
|
|
- `Migrated [old] to [new], reducing [risk/cost/latency/debt].`
|
|
- `Improved [metric] from [before] to [after] by [technical action].`
|
|
|
|
Avoid weak starts when stronger ownership is true: "helped", "assisted",
|
|
"responsible for", "worked on", "participated in".
|
|
|
|
## ATS Reality Check
|
|
|
|
Optimize for parseability and human review, not "ATS hacks":
|
|
|
|
- exact JD keywords only in truthful context
|
|
- no hidden text
|
|
- no keyword stuffing
|
|
- no white-font tricks
|
|
- no decorative layouts that break parsing
|
|
- no skills or metrics not present in the user's sources of truth
|