How to read a job description (and decide whether to apply)

Most posts have a list of requirements and a list of extras. The wording tells you which is which.

• Must-haves are written as requirements, qualifications or you have: three years of experience in Python, strong SQL.
• Nice-to-haves use words like bonus, preferred, a plus or familiarity with.

A strong candidate usually meets most of the must-haves and some of the extras. You do not need every line. Many people talk themselves out of a role because they miss one nice-to-have, while the person who gets the job missed a few too.

When a post asks for three to five years, the company is describing the level it has in mind. It is rarely a hard cutoff. Two years of very focused work can be worth more than four years of repeating the same task.

That said, read the gap honestly. If a role asks for ten years and you have one, it is probably a senior position and you will lose time applying. If you are one year short, it is worth a try.

The responsibilities section tells you what you will do on a Tuesday. Read it more carefully than the requirements.

Ask yourself whether you would enjoy that work. If the post mentions mostly bug fixing in an old codebase and you want to build new products, you have learned something valuable before applying.

Also notice what is missing. If a post for a developer never mentions code review, testing or how the team works, you can ask about it in the interview.

• Is it clear whether the role is remote, hybrid or in an office, and which time zones matter?
• Does it say how you apply and what happens after you do?
• Is the pay shown? A listed range is a good sign of an honest company, though many leave it out.
• Does it describe the team and what they build, or only a list of demands?

None of these is a deal breaker alone. Together they give you a sense of how carefully the company treats people.

• A huge list of unrelated skills for one person, such as frontend, backend, design, marketing and sales in one job. It usually means the company has not decided what it needs.
• Vague language with no real detail about the work.
• Promises of unlimited earning, guaranteed income or quick money.
• A request for money, or for personal documents, before any interview.
• Pressure to reply within hours.

If you spot one or two, ask questions before you go further. If you spot many, move on.

Once you decide to apply, copy the three or four most important requirements into a note. For each, find your best proof: a project, a result or a past job.

Then put that proof near the top of your CV and mention it in your cover note. Use the same words the post uses, as long as they are true for you. If it says PostgreSQL and you wrote Postgres, that is fine. If it says Kubernetes and you have never used it, do not claim it.

A short, specific application that matches the post beats a long general one every time.

A job post is one side of a conversation. If something is unclear, you can ask, either in the application or in the first call. Good employers are glad to answer.

• What would the first three months look like in this role?
• How is the work shared out, and who would I work with every day?
• What working hours and time zone overlap do you expect?
• How are tasks assigned and reviewed, and how often does the team meet?
• Is the role an employee position or a contract, and how is payment made?

The answers tell you far more than the post does. They also show the employer that you think carefully about the work, which is a quality every team wants.

Keep a simple record of every post you apply to, with the date, the version of your CV you sent, and any reply. It saves you from confusion when a company contacts you weeks later and you have forgotten what the role was.