A job description is part specification, part wish list, and part text inherited from the last posting. Read it literally and you will either apply to everything or talk yourself out of roles you could do well. Read it the way the hiring manager meant it, as a rough sketch of a problem the team needs solved, and you can decide in a few minutes whether to apply and what your resume needs to show.
Read the level from the work, not the title
Titles are inconsistent across employers. A senior engineer at a services company, an SDE II at a product company, and a “Member of Technical Staff” at a GCC can describe similar work, while an “Analyst” or “Associate Consultant” at a services firm is often a hands-on developer. “Lead” sometimes means managing people and sometimes only technical ownership. Set the title aside and read three things instead:
- The verbs. “Implement”, “fix”, and “support” describe someone who takes defined work. “Design”, “own”, “drive”, and “mentor” describe someone expected to shape the work and help others do it.
- The scope. A feature, a service, a group of services, or a platform that other teams depend on.
- The reporting line. An engineering manager in a product team suggests roadmap work. A delivery or project manager on a client account usually means client calls, status reports, and coordination with an onshore team.
If the verbs and scope describe what you do now, or the next step up from it, the level fits, whatever the title says.
Separate the must-haves from the wish list
Most postings pour requirements and preferences into one list. Sort it using the wording:
- Hard requirements use “must”, “required”, or “minimum”, or sit under a heading such as “What you need”. They often appear twice, once in the responsibilities and again in the requirements.
- Preferences use “good to have”, “a plus”, “exposure to”, “familiarity with”, or “bonus”.
- Boilerplate such as “excellent communication skills”, “team player”, and “self-starter” appears in nearly every posting and tells you nothing about this one. Skip it.
Order carries meaning too. The first two or three technical items are usually the job; the tail of a long list is often copied from an older posting. A skill that shows up in the title, the responsibilities, and the requirements is the one you will be interviewed on.
How to read “X+ years”
Experience requirements come in three shapes, and each means something different:
- A minimum (“4+ years”) is a screening line. Recruiters sorting hundreds of applications apply it literally; hiring managers bend it for strong evidence.
- A range (“3–6 years”) has a floor and a soft ceiling. The floor is the screening line. The ceiling usually reflects the level and pay band the role is budgeted at, so if you are well above it, expect a conversation about whether the role is too junior for you.
- Years with one tool (“5 years of Kubernetes”) are usually judged more loosely than total experience, though an application form may ask for the number. Answer honestly, and let your bullets show depth with the tool rather than arguing about months. A demand for more years with a tool than it has been in wide use tells you the posting was written carelessly.
On uHired job cards, the experience shown is the minimum the posting states: a range such as 3–6 years appears as 3+, “No minimum” means the stated minimum is zero (as in “0–2 years”), and “Not stated” means the description never says. How matching works explains the rules, including how postings with several requirements are read. Treat “Not stated” as a reason to read the responsibilities closely, not as a sign that the role is junior.
What the responsibilities reveal about the team
Responsibilities give away the most about daily life in the role. Translate the phrases, and turn the vague ones into questions for the recruiter call.
| Phrase in the posting | What it usually means | What to ask |
|---|---|---|
| “Participate in on-call rotation” | You will handle production incidents out of hours | How often is each person on call, and how noisy are the alerts? |
| “Maintain and enhance existing applications” | Mostly legacy code, fixes, and small changes | How is time split between new work and maintenance? |
| “Work closely with onshore teams and clients” | A services or GCC model with overlapping hours | Which hours overlap, and who speaks to the client? |
| “Greenfield” or “zero to one” | A new product, little existing code, shifting requirements | How settled is the product direction? |
| “Own services end to end” | You build, deploy, monitor, and support what you write | Is there a separate operations or SRE team? |
| “Drive the migration to microservices” | A long migration with half-moved systems | How far along is it, and who chose the approach? |
Red flags worth skipping a posting for
- A wish list of unrelated stacks. Java, .NET, PHP, React, Angular, Android, iOS, and Salesforce in one posting is not one job. It is usually a consultancy collecting resumes for whatever requirement comes next, or a team that has not decided what it needs.
- A role you cannot picture. If after two readings you cannot say what you would build in your first three months, the team probably cannot either.
- No employer name. Agencies often keep the client confidential at first, which is normal. Ask for the name before sharing anything beyond your resume, and walk away if you still do not have it by the first interview.
- Contradictions. “Freshers welcome” above “minimum 3 years”, or an entry-level title with architect-level responsibilities. Either the posting is careless or the team is.
- Fees, deposits, or paid training. Stop and read the guide to spotting fake job offers.
Should you apply if you meet most of the requirements?
Usually, yes: postings describe an ideal candidate who rarely exists. Use a rule rather than a mood:
- List the hard requirements only.
- Mark each one: already on your resume, true but missing from your resume, or genuinely missing.
- Apply if no more than one or two items are genuinely missing and none of them is central: the main language, the core platform, or a location or work-authorisation requirement. Anything true but missing from your resume goes onto it before you apply.
- On experience, apply if you are within about a year of the stated minimum and your work matches the responsibilities. With half the minimum or less, look for the level below.
- Skip when the missing item is the job itself, such as a Kafka platform role when you have never run Kafka.
Preferences should never decide this. Missing a “good to have” is rarely why someone is rejected, though matching several can lift you up a shortlist.
A worked example: one posting, mapped to a resume
The posting below is invented for illustration, but it is typical of a mid-level backend role at a product company.
Example posting: Backend Engineer II, Payments Platform (Bengaluru, hybrid, 3–6 years)
- Design, build, and own Java or Kotlin services on Spring Boot.
- Build event-driven flows on Kafka, and make sure every payment is processed exactly once, even when messages are retried.
- Write and tune PostgreSQL queries.
- Participate in the on-call rotation.
- Mentor SDE I engineers through code reviews and design discussions.
- Good to have: payments domain experience, Kubernetes, AWS.
Reading it: “design, build, and own” and “mentor” place this a step above entry level, with design documents and code reviews expected. Spring Boot, Kafka, and PostgreSQL are the hard requirements. The real problem sits in the second line: duplicate payments when messages are retried, so expect interview questions on idempotency and retries. The last line is optional.
Now map it against your experience. The evidence below is an example for a candidate with four years at a product company.
| The posting asks for | Your evidence (example) | What to change on the resume |
|---|---|---|
| Spring Boot services | Four years on order-management services | Open your current role with this bullet |
| Kafka, exactly-once processing | Built a consumer that dropped duplicate events by order ID | Use the words “idempotent consumer” and “duplicate events”, which state the posting’s problem in its own terms |
| PostgreSQL tuning | Fixed slow reporting queries with indexes | Add the before and after, such as a query going from eight seconds to under one |
| On-call | Weekly support rotation | Add a line on incidents handled and a postmortem you wrote |
| Mentoring | Reviews pull requests for two juniors | Add it; it answers the level question |
| Payments domain (optional) | None | Leave it out rather than stretch |
Verdict: every hard requirement is met, the experience sits inside the range, one preference is missing, and the team’s central problem matches something you have built. Apply, and put the de-duplication work at the top.
What to do with the next posting you open
- Read the responsibilities before the title, and name the level in a word.
- Underline the hard requirements and cross out the boilerplate.
- Note the stated minimum experience and where you sit against it.
- Turn two responsibility phrases into questions for the recruiter screen.
- Check for red flags.
- Apply the decision rule above.
- If you apply, rewrite the three or four resume lines that answer the posting’s central problem; the ATS-friendly resume guide shows how.
- Save a copy of the description. Postings are often taken down before the first interview, and you will want to reread exactly what they asked for.