# Reading a Job Description — Resume & GitHub Portfolio

Source: https://www.skillbyai.com/en/resume-portfolio/t-jd

> Map requirements to your real evidence.

## Match honestly, then emphasise

A job description tells you what the team values. Read it and separate **must-haves** from **nice-to-haves**, note the **technologies**, the **level** and the **kind of work** (product features, infrastructure, data, mobile). Then map each important requirement to **real evidence** from your experience or projects. Where you have a match, make it visible: move that bullet up, use the same standard name for the technology ("PostgreSQL" rather than an internal nickname) and mention it in Skills if true. Where you have no match, do not pretend; either leave it or show a related, honest strength. Applying when you meet many but not all requirements is common and reasonable.

## One honest story, adjusted for each role

Tailoring means emphasising your real, relevant evidence for a specific job, in a format software and people can read.

![Three ideas: mapping a job description, readable formatting, and managing resume variants.](assets/figures/resume-portfolio/section-4-map.svg) — Figure 4.1 — Job description mapping, simple formatting, and resume versions.

## A mapping table

Fictional job description and candidate.

```text
Job: Backend Engineer, fictional "Acme Payments"

Requirement (from JD)          Must/Nice  My evidence                         Action
-----------------------------  ---------  ----------------------------------  ---------------------
Java or Kotlin services        Must       2 yrs Spring Boot at Northwind      Move bullet to top
PostgreSQL, query tuning       Must       Added indexes, fixed slow report    Name "PostgreSQL"
Message queues                 Nice       RabbitMQ worker migration           Keep bullet
Kubernetes                     Nice       None in production                  Do not claim; skip
On-call / incident response    Must       Weekly on-call rotation, 1 year      Add a bullet

Gaps are fine. Claims you cannot back up are not.
```

## Use standard names

Write technologies by their common names and expand unclear acronyms once, such as "CI/CD (GitHub Actions)", so both people and search tools recognise them.

**Quiz:** A job lists Kubernetes as nice-to-have and you have never used it. What should you do?

- [x] Leave it off and emphasise your real strengths
- [ ] Add it to Skills because it is only nice-to-have
- [ ] Add it in white text so only software sees it
- [ ] Claim you used it at your last job

*Answer:* Leave it off and emphasise your real strengths. Tailoring emphasises truth; it never adds false claims.