How to Read a Tech Job Posting: What’s Negotiable?

You find a job posting that looks almost perfect. The company is exciting, the role sounds like a natural next step, and the tech stack is one you know well. Then you hit the requirements list and somewhere between “5+ years of experience” and “familiarity with Kubernetes, Terraform, and three cloud providers,” you close the tab.

Sound familiar? That moment of self-rejection (quiet, instantaneous, and almost automatic) is one of the most expensive career mistakes developers make. And it’s almost always based on a misreading of what job postings actually mean.

Understanding how to read a tech job posting is a skill. One that most candidates were never taught. This guide will give you a framework for decoding the language of job descriptions so you can stop disqualifying yourself based on wish lists written by hiring committees and start applying strategically.

The Uncomfortable Truth About Job Postings

Before diving into tactics, it helps to understand how most job postings are actually written.

In most companies, a job posting is assembled by at least two or three different people: a recruiter who manages the process, a hiring manager who describes the role, and sometimes a team lead or department head who adds their own wish list. These inputs are rarely reconciled or prioritized. The result is a document that often represents the perfect candidate who doesn’t exist, not the minimum bar for the person who will actually get hired.

Job postings are also frequently copied and modified from previous postings, templated from HR libraries, or written by people who haven’t done the day-to-day work of the role in years. The “required” section is often more aspirational than literal.

A study frequently cited in hiring circles found that men apply for a job when they meet about 60% of the qualifications, while women tend to apply only when they meet 100%. Developers (particularly those earlier in their careers or from non-traditional backgrounds) often fall into the same 100%-or-nothing trap.

The cost of that trap is enormous: missed opportunities, stunted career growth, and the slow erosion of confidence that comes from never hearing “yes” because you never asked.

Required vs. Preferred: The Most Important Distinction Nobody Reads

Almost every job posting is divided into two types of requirements, even if they’re not always labeled clearly:

Hard requirement: The genuine non-negotiables. Without these, your application is unlikely to move forward regardless of everything else you bring.

Soft requirements: Desired qualities, nice-to-haves, or aspirational traits. These represent the ideal candidate, not the minimum viable one.

The problem is that companies often label both categories as “required” (or list everything in a single undifferentiated block) which makes it nearly impossible to know what actually matters.

Here’s how to tell them apart.

How to Identify the Real Non-Negotiables

Genuine hard requirements tend to share certain characteristics. Look for these signals:

Legal or compliance-driven requirements Things like security clearances, professional licenses, geographic restrictions, or right-to-work status. These are almost always true non-negotiables, they exist because of external constraints, not internal preferences.

Core technical fundamentals tied to the product If a company’s entire backend is written in Go and the job is a backend engineering role, Go experience is likely a real requirement. If the product is a mobile app and the role is iOS engineering, Swift isn’t optional. The key is whether the requirement is architectural, baked into what the team actually builds, rather than merely preferred.

Domain expertise with no viable learning curve Some roles require specific knowledge that genuinely can’t be learned quickly on the job, deep security expertise, regulatory compliance in highly specialized industries (healthcare, fintech, aerospace), or years of research in a narrow academic field. If the gap would take years to close, it may be a real barrier.

Years of experience as a proxy for seniority level This one is complicated. “5+ years” rarely means they’ll reject a 4-year candidate, it’s usually a proxy for seniority level and complexity of experience. More on this below.

The Years of Experience Problem (And Why You Should Ignore the Number)

Few things cause more unnecessary self-rejection than years-of-experience requirements. And they’re one of the most poorly written parts of any job posting.

Here’s what “5+ years of experience with React” almost never means: we will count your years and reject you if the number is too low.

Here’s what it usually means: we expect a certain depth of production experience, the ability to make architectural decisions, and comfort working without significant hand-holding.

The distinction matters enormously. A developer with 3 intensive years of React experience, building complex production applications, leading front-end architecture decisions, mentoring junior teammates, often has more relevant depth than someone with 5 years of maintaining a single legacy codebase.

What to do instead of counting years: Ask yourself honestly whether you have the depth of experience the role implies. Can you speak fluently about the hard problems in that domain? Have you shipped real things with that technology? Have you encountered and worked through edge cases, performance issues, or architectural trade-offs?

If the answer is yes, apply. If you’re genuinely early in your learning curve with the core technology, the experience requirement is the least of your obstacles..

Reading the “Nice to Have” Section Strategically

The preferred or nice-to-have section of a job posting is valuable not as a checklist, but as a map of what the team cares about and where it’s heading.

When you see a cluster of related tools or technologies in the preferred section, say, Terraform, Pulumi, and CDK all listed together, it tells you the team is deepening its infrastructure-as-code practices and likely moving toward more DevOps ownership. You don’t need to know all three. But knowing one well and being able to speak intelligently about the others signals that you understand the direction.

Similarly, a preference for “experience with distributed systems” or “familiarity with event-driven architecture” isn’t asking you to be an expert, it’s asking whether you’ve been exposed to these paradigms and can engage with the team on their level.

The 70% rule: If you genuinely meet 70% or more of the combined required and preferred qualifications, and the role is something you’re excited about, apply. The worst realistic outcome is silence, and that costs you nothing.

Language That Signals Flexibility (If You Know What to Look For)

Certain phrases in job postings are deliberate signals of flexibility, even if they don’t look like it at first glance:

“Equivalent experience”. Almost always means a degree isn’t strictly required. Bootcamp graduates, self-taught developers, and career changers: this phrase is written for you.

“Familiarity with” or “exposure to”. Significantly softer than “proficiency in” or “deep expertise in.” These are honest nice-to-haves.

“Experience with X or similar”. The “or similar” is doing enormous work here. If you’ve used a comparable tool or worked in an adjacent domain, you qualify by the posting’s own terms.

“Preferred” / “ideal candidate will have” / “bonus points for”. These are optional by definition, regardless of how long the list is.

“We’re looking for someone who can grow into”. This is a direct signal that they expect a learning curve and are willing to invest in development.

“Fast-paced environment” or “wear many hats”. Less a requirement, more a culture signal. Worth noting for your own assessment of fit, but not a qualification.

Language That Signals the Opposite: Real Red Flags

Not all flexible language is positive. Some job posting patterns signal genuine rigidity, or worse, a dysfunctional hiring process worth avoiding:

An impossibly long requirements list. A posting that demands expertise across 15 different technologies, frameworks, and domains isn’t describing a role; it’s describing a fantasy. These postings often reflect unclear internal alignment about what the team actually needs. Proceed with caution, and use the interview process to understand what truly matters day-to-day.

“Rock star,” “ninja,” or “10x developer”. Dated language that often reflects a culture of overwork dressed up as excellence. These aren’t requirements, but they’re meaningful culture signals.

Vague responsibilities combined with highly specific requirements. When a job description can’t clearly articulate what you’ll actually be doing but is extremely prescriptive about what you need to know, that disconnect often reflects internal dysfunction. Ask pointed questions in your interview.

No salary range in markets where it’s legally required. In jurisdictions with pay transparency laws, omitting a range can signal non-compliance or a culture of opacity around compensation.

How to Apply Even When You’re Not a Perfect Match

The decision to apply is only half the battle. Applying in a way that addresses the gap honestly and confidently is the other half.

In your cover letter or opening message: Don’t pretend the gap doesn’t exist and don’t lead with an apology for it. Acknowledge it briefly, then pivot immediately to what you bring that’s relevant. Example: “While my production experience with Kubernetes is still developing, I’ve architected containerized deployments using Docker Compose and have been actively studying Kubernetes through hands-on projects, and I’m confident that with your team’s environment, that gap closes quickly.”

That’s honest. That’s confidence. And it’s far more compelling than either ignoring the gap or leading with “I know I don’t fully meet your requirements, but…”

In your portfolio and application materials: Let your work answer the questions your resume can’t. If you don’t have years of experience with a technology, a well-documented project that uses it can often carry more weight than a line on a CV.

In the interview: If you get the call, the gap was already not disqualifying. Now your job is to demonstrate the depth of what you do know, the quality of how you think and learn, and the kind of teammate you’d be. Companies hire people, not requirement checklists.

The Questions Worth Asking in the Interview

Once you’re in the room (virtual or otherwise) you have the opportunity to clarify exactly what’s truly required and what isn’t. These questions accomplish that while also signaling your seriousness:

• “Of all the requirements listed, which are the most critical for success in the first 90 days?”
• “What does the onboarding process look like for someone who’s strong in [your strengths] but developing in [the gap area]?”
• “Are there aspects of the role where you’d expect someone to grow into over time, versus things they’d need to hit the ground running on?”
• “What does a successful first year look like for this role?”

These questions do double work: they give you genuine information about the role’s real requirements, and they show the interviewer that you think in terms of outcomes and growth rather than just task execution.

When to Actually Walk Away

Not every gap should be bridged. There are times when the honest answer is that a role isn’t the right fit, and recognizing that early saves everyone time.

Walk away (for now) if:

• The core technology is genuinely foundational to the role and you have no experience with it whatsoever, not just limited experience, but zero
• The seniority level is more than one significant step above where you currently are, and the role shows no interest in growing someone
• The gap in domain knowledge (compliance, regulation, specialized industry expertise) is years wide and the company isn’t structured to close it
• Your honest self-assessment says you’d be starting from scratch in almost every dimension the role requires

This isn’t self-rejection, it’s self-awareness. The goal is to apply boldly when the gap is addressable, not to apply indiscriminately. A considered “not yet” is always better than an exhausting process that ends in misalignment for both sides.

Final Thoughts

The language of job postings is imprecise by nature. It’s written under time pressure, by committees, to describe roles that will inevitably evolve, and it’s almost never a precise description of the minimum bar for success.

When you learn to read between the lines, to distinguish the genuine constraints from the aspirational wish list, to find the flexibility signals buried in bureaucratic language, to understand that years of experience is a proxy and not a gate, you stop letting a document make career decisions on your behalf.

The most qualified candidate isn’t always the one who applies. But the one who applies is always ahead of the one who didn’t.

Read the posting. Apply your judgment. Then hit send.

Know a developer who talked themselves out of applying for their dream job? Share this with them, they probably needed to hear it.