Codewalnut backend resume shortlisting skill

CodeWalnut backend resume shortlisting

Use this workflow as decision support for a human hiring team. Evaluate only job-relevant evidence in the resumes. Do not use or infer age, gender, caste, race, religion, disability, marital/family status, nationality, photographs, or other protected/personal traits. Do not penalize names, addresses, employment gaps, graduation dates, resume aesthetics, or non-native writing. Omit phone numbers, email addresses, street addresses, and unrelated personal details from outputs.

Load the company calibration

Before evaluating candidates, read:

1. references/historical-patterns.md for the patterns learned from prior decisions and their limits.
2. references/rubric.md for evidence levels, category weights, tier gates, and tie-breaking.
3. references/input-handling.md for uploaded, folder, Drive, duplicate, scan, and failure handling.
4. references/output-format.md for the required Markdown and JSON structures.

Treat these references as a coherent rubric. The historical examples calibrate judgment; they are not lookup rules and candidate names never affect a decision.

Workflow

1. Establish the input set

• Resolve every uploaded PDF, PDF in the supplied folder, or PDF reachable through the supplied Drive source.
• Build a manifest before scoring. Record source filename, page count when available, duplicate status, extraction status, and any access/read error.
• If a Drive folder is inaccessible, state the exact blocker and ask for connector authorization, a public link, a ZIP, or direct uploads. Never silently score only the accessible subset.
• Deduplicate identical files, but report every duplicate filename in the intake summary.

When local paths and pypdf are available, scripts/extract_resume_text.py can create page-aware extraction JSON. Native PDF tools are equally acceptable.

2. Read each resume completely

• Extract text page by page and inspect the rendered pages when extraction is empty, suspiciously short, scrambled, or missing visible sections.
• Read all pages. Do not stop after the skills list or first matching keyword.
• Create an internal evidence sheet for each candidate covering role chronology, production work, projects, technologies, system behavior, testing, delivery, ownership, and measurable outcomes.
• Distinguish what the candidate demonstrated, supported, merely claimed, or did not show using the evidence levels in the rubric.
• Treat a skill-list mention such as “Kafka,” “Kubernetes,” “DDD,” or “TDD” as weak evidence until a work/project bullet explains how it was used.
• Treat precise but implausible or internally inconsistent claims as verification questions, not accusations. Lower confidence rather than inventing a fact.

3. Evaluate engineering substance

Score the seven categories in references/rubric.md. Look for mechanisms and consequences, not vocabulary:

• What did the candidate own and ship?
• What scale, latency, reliability, security, data-integrity, or operability problem existed?
• How did data flow through the system?
• How did consumers behave on duplicate, poison, delayed, or replayed events?
• How were tenant boundaries, API compatibility, schema evolution, audits, tests, and deployments handled?
• Is the candidate primarily a backend engineer, or is Spring Boot incidental to frontend/full-stack work?

Functional equivalents count. For example, a transactional outbox, immutable change history, deduplication key, materialized read model, or contract compatibility policy may demonstrate a target capability even when the resume never uses the company’s exact term.

Do not assume absent resume detail means absent ability. Record it as “missing or unverified,” reduce the relevant evidence score, and propose an interview question.

4. Apply tier gates and rank

• Sum the category scores to 100, then apply the core-backend gate, evidence caps, and tier thresholds from the rubric.
• Rank by demonstrated fit first, then evidence quality, architecture/reliability depth, testing discipline, production ownership, and platform maturity.
• Raw years of experience, employer prestige, degree prestige, writing polish, and keyword count are not tie-breakers.
• “Best Shortlisted” is exceptional and is never forced. Assign at most one candidate in a batch, and only when the Best gate and clear-margin rule are met.
• If two candidates are effectively tied, say so. Do not manufacture precision from one-point score differences.

5. Produce auditable outputs

Return the full Markdown report described in references/output-format.md. When the environment is writable, also save:

• shortlist_report.md
• shortlist_results.json

Use scripts/validate_evaluation.py shortlist_results.json when the JSON file is created. Fix validation failures before delivery.

Every candidate—including rejected candidates and unreadable files—must appear in the report. For each evaluated candidate include:

• recommendation and score;
• evidence confidence;
• concise rationale;
• demonstrated strengths with page/source citations;
• weaknesses relative to this role;
• missing or unverified requirements;
• concrete interview/verification questions.

6. Quality check

Before finishing, verify:

• discovered PDFs = evaluated PDFs + unreadable/blocked PDFs + true duplicates;
• no candidate was omitted;
• every positive claim is traceable to resume evidence;
• skill-list mentions did not receive production-level credit;
• rejections explain the job-related gap without insulting language;
• no protected/personal trait or contact detail influenced or appears in the recommendation;
• ranking, scores, tiers, and prose agree;
• the report explicitly says a human should make the final employment decision.