How to read a tech job description (and when to apply anyway)

Most tech job descriptions are written as wish lists. A hiring manager writes down everything the ideal candidate might know, a recruiter adds the company's standard paragraphs, and the result asks for ten years of a framework that is six years old.

Read them that way and you will talk yourself out of roles you could get. Read them carefully and they tell you a lot: what the team actually needs, how senior the role really is, and sometimes what the job will be like day to day.

Separate the must-haves from the wish list

Start by sorting the skills into two piles.

• Required: usually under "Requirements", "Must have" or "What you'll need". These are the skills the team will test in interviews, so they matter most.
• Preferred: under "Nice to have", "Bonus points" or "Preferred qualifications". Few candidates have all of these, and teams know it.

Then look at what is repeated. A skill that appears in the summary, the responsibilities and the requirements is central to the job. One that appears once, in a long list, is often there because it was in the last description.

Apply when you meet the core of the role

You rarely need every requirement. If you have most of the required skills, and the ones you are missing are things you could pick up quickly (a related framework, a cloud provider you have not used, a tool your current team does not use), apply.

Be more careful when you are missing the core of the job. A backend role built around Go and Kubernetes is a stretch if you have neither, however well you match the rest.

A good rule: if you could explain in an interview how you would close each gap within your first few months, the gap is not a reason to skip the role.

What "years of experience" really means

Years are a rough proxy for the scope of work a team expects. "3+ years" usually means "has shipped features independently and handled production issues"; "8+ years" usually means "has led designs and mentored others".

If your experience covers that scope in fewer years, apply, and make the scope obvious on your resume: what you owned, the scale you worked at, and what changed because of your work. If you have many more years than asked, check the title and pay as well; the role may be more junior than you want.

Red flags in a job description

• No mention of the team or the product. It is hard to judge a role when you cannot tell what you would build.
• A very wide stack for one role. Frontend, backend, mobile, DevOps and data in a single job often means one person doing the work of a team.
• "Must be comfortable with a fast-paced environment" next to very long hours, weekend work or on-call with no rotation.
• Bonds or long notice periods, such as a service agreement to repay training costs if you leave early. Read these terms before you accept an offer.
• No pay range, where you would expect one. It is not a reason to skip a role, but ask early in the process.

Make the description work for you

Once you decide to apply, use the description to tailor your resume. Put the required skills you have near the top, in the same words the posting uses, because recruiters (and applicant tracking systems) look for them. Back each one with a line about what you did with it.

Brightspark does part of this sorting for you: it reads each job's requirements, compares them with the skills on your profile, and shows which ones you have, which are close, and which you are missing, so you can see at a glance which roles are worth your time.