Job description to validated JSON

The problem you will solve

A careers team receives pasted descriptions in different formats. Build a small extraction tool that separates employer facts from inference. It must preserve unknown values instead of inventing a salary, location or experience requirement. This is a parsing exercise, not an automated hiring or candidate-ranking system.

Before you start

Python dictionaries, HTTP requests and basic unit tests.

Suggested tech stack

• Python
• Pydantic
• JSON Schema
• FastAPI
• pytest

Data plan

Write 30 fictional job descriptions: 10 straightforward, 10 incomplete and 10 containing conflicting or distracting text. Hand-label expected fields before running a model; reserve 10 as an untouched test set.

Hardware and cost

CPU-only validation and a regex baseline work locally. An optional hosted or local language model adds inference cost; record its name and settings. Do not upload confidential employer material.

Define the input and output

Use this illustrative contract as a starting point, then specify required fields, validation and error responses in your own implementation. It is not a complete API schema.

Input: {"text":"Remote AI Engineer. Python required."}
Output: {"title":"AI Engineer","work_mode":"Remote","skills":["Python"],"salary":null,"evidence":{"title":"AI Engineer"}}

Your five build milestones

Finish and test one milestone before extending the system. Keep an experiment log with the decision, the alternative you rejected and the evidence behind the choice.

1. Define the contract

   Create a schema with nullable salary and city fields, a fixed work-mode enum and source snippets for factual values. Add tests that reject incorrect types and unrecognized fields.

2. Build a non-model baseline

   Parse headings and explicit skills using deterministic rules. Save raw text and expected output separately so a later prompt change cannot silently change the answer key.

3. Add bounded extraction

   If using a model, mark the description as untrusted data, request schema-shaped output and validate it outside the model. Set an input-length limit and allow at most one repair attempt.

4. Test and expose

   Run the frozen test set, then add a POST endpoint or command-line entry point. Return validation errors clearly; do not silently publish partly valid records.

5. Document the failures

   Publish three redacted before/after examples, a field-level score table and cases where salary or location must stay unknown. Explain why valid JSON alone does not establish factual accuracy.

How to evaluate your project

Set your acceptance criteria before looking at the final test results. The checks below are proposed experiments, not measured outcomes or a guarantee that a particular model will pass.

• Report exact-match accuracy separately for title, work mode and city; report skill precision and recall against your labels.
• Count invented non-null values and invalid JSON separately. Include missing-location and prompt-injection cases.
• Measure end-to-end latency over repeated runs, with model loading reported separately. These are your measurements, not promised results.

Save your test cases, run command, dependency versions and results together. Compare on identical inputs, retain failures in the denominator and report sample sizes. If a change improves one metric but harms another, explain which trade-off fits your use case.

Failure modes worth demonstrating

• Treating a company headquarters as the job location.
• Accepting a schema-valid but unsupported salary or following instructions embedded in the description.

Optional extension

Add a review queue for conflicting fields and compare whether evidence snippets make manual correction faster.

Turn the build into portfolio evidence

Your repository should let another person understand the problem and reproduce the core evaluation without needing your private credentials.

• A README with problem, intended user, architecture, setup commands and a small input/output example.
• A permitted sample dataset, its origin or generator, a frozen test split and a single evaluation command.
• A results table comparing your baseline with your final approach, including failures and sample counts.
• A short demo or screenshots, a limitations section and one decision you would change with more time.
• Environment-variable names without secret values, a dependency list and attribution/license notices for any reused code or datasets.

Resume framing

Describe this as a personal or educational project. State what you implemented, how you tested it and what your measured results were. Replace placeholders with your own evidence; do not claim employer impact, production traffic or accuracy you did not measure.

Built job description to validated json using Python, Pydantic, JSON Schema; evaluated against [baseline] on [N held-out cases], documented [measured result] and [important limitation].

Be ready to explain your decisions

• Why is JSON validity different from extraction correctness?
• Which missing fields should block publication, and why?

Answer with a concrete failure from your implementation, the options you considered, your measured evidence and the limitation that remains.

Google documentation and GitHub references

The project scope, milestones and evaluation plans above are original AIJobFever educational material. These official Google resources offer background or implementation examples; they are not finished implementations of this blueprint. No Google endorsement is implied. Review repository licenses, supported platforms and current costs before reusing code or provisioning services.

• Google: structured output documentation ↗