How to read a tech job posting

A posting is not a specification. It is a wish list written by several people who did not talk to each other. Learning to read one properly is the difference between applying to five roles and applying to fifty.

Here is a common and expensive mistake. Somebody finds a job they want, reads the requirements, counts eleven bullet points, matches seven of them, and closes the tab.

They have just declined to apply for a job they might well have got, on the basis of a document that was never intended to be read that literally.

Where postings come from

It helps to know how the thing in front of you was made. A typical posting is assembled from a previous posting for a similar role, a hiring manager’s notes about what the last person did, a recruiter’s attempt to make it searchable, and a template the company has used for years. Frequently nobody reviews the finished result against reality.

This is why postings ask for eight years of experience with a tool that has existed for four. It is not a trick. It is a document with several authors and no editor.

Sorting real requirements from aspirations

Requirements fall into roughly three tiers, and the posting rarely labels which is which.

Genuinely non-negotiable

• Legal and regulatory conditions. Work authorisation, security clearance, a license required by statute. These are not flexible and no amount of enthusiasm changes them.
• Named certifications where the role exists to satisfy a contract. Common in government-adjacent work and parts of security. If the client contract specifies it, the employer cannot waive it.
• Physical and logistical facts. On-site presence in a particular city, shift patterns, travel expectations.

Strongly preferred, and worth applying without

• Years of experience. Almost always a proxy for “we want someone who will not need constant supervision”. Demonstrated competence substitutes for it more often than people expect, and the number is frequently inherited from an older posting.
• A specific named technology where several comparable alternatives exist. If you know one well, learning the sibling is a matter of weeks and any competent hiring manager knows that.
• A degree, at companies that are not large enterprises. Worth testing rather than assuming.

Effectively decorative

Long lists of tools mentioned once, personality descriptors, and anything under a heading like “nice to have”. A posting listing fourteen technologies is describing an entire team’s stack, not one person’s knowledge.

Reading for the actual job

The most useful part of a posting is usually not the requirements at all. It is the responsibilities section, read carefully for what it reveals.

• “Wear many hats”, “fast-paced”, “first hire on the team”. Small team, wide scope, limited support. Excellent for learning quickly, hard if you need structure.
• “Own the roadmap for…” Real autonomy, and real accountability. Usually a genuine step up.
• A responsibilities list that reads like three different jobs. Either the team is understaffed or nobody has decided what the role is. Worth asking about directly in an interview.
• Heavy emphasis on process, documentation, and compliance. Larger, slower, more stable. Neither good nor bad, but very different daily texture from the first bullet.
• No mention of who you work with or report to. Ask. The answer tells you more about the job than the requirements did.

Applying like the document is what it is

Once you stop treating a posting as a test you either pass or fail, a few things follow.

1. Apply at roughly sixty percent match on the non-negotiables. If you meet the legal conditions and can do the core of the responsibilities, apply. The remaining gap is what interviews are for.
2. Mirror their vocabulary, accurately. If the posting says “incident response” and your experience is troubleshooting production outages, use their phrase — because it is the same thing, and because a filter may be matching on it. Never claim experience you lack; do name accurately what you have.
3. Answer the responsibilities, not the requirements. A short covering note explaining how you would approach the first item on their responsibilities list is worth more than a paragraph asserting you meet their bullet points.
4. Apply to the older postings too. A role that has been open for two months is a role where the ideal candidate did not materialise. That is frequently your opening.
5. Track your applications and read the pattern. If you never hear back, the problem is your application materials or the filters. If you get screened and then rejected, the problem is different and more fixable. These need different responses, and you cannot tell which you have without records.

One caution

None of this is license to overstate. Claiming skills you do not have wastes everybody’s time, and in technical interviews it surfaces within minutes. The argument here is narrower and it is worth stating precisely: apply when you genuinely could do the work, even where you do not tick every box — because the boxes were never an accurate description of the job.