Read Between the Lines: Hidden Signals in a Job Description

When I moved from geology into cloud engineering, I read job descriptions like shopping lists. I counted the tools I knew, counted the ones I didn't, and decided whether to apply based on the score. It took me far too long to realise the tools list was the least interesting part of the advert. The real information was in plain sight: the size of the company, how they described their stack, the regulations they mentioned in passing, and the partners they bragged about in the “About us” paragraph most people skip. Exercises are built in, and your answers save in your browser as you go.

Signal 1: Company size and stage

The same job title means very different jobs depending on who's hiring.

• **Startup (roughly under 50 people):** a “Cloud Engineer” is often the whole infrastructure function. Look for “wear many hats”, “first infrastructure hire”, “build from the ground up” or “own our AWS environment”. They need breadth, speed and judgement, and care less about exact tools than about sensible decisions made without sign-off.
• **Scale-up (roughly 50 to 500):** look for “establish”, “standardise”, “mature our practices” or “improve reliability”. The company grew fast and now has mess to clean up. They want structure: infrastructure as code, CI/CD, monitoring and documentation.
• **Enterprise:** the language shifts to “governance”, “change management”, “stakeholders”, “cross-functional teams”, “ITIL” or “ServiceNow”. The role is narrower and deeper, and much of it is working within process rather than moving fast.

How it changes your application: for a startup, lead with ownership: a project you built end to end, the trade-offs and why. For a scale-up, lead with improvement: “I took X and made it repeatable, cheaper or more reliable.” For an enterprise, lead with how you work with others, document and handle change safely. Same skills, different story.

Signal 2: The stack tells you what problem they're hiring for

Don't just check whether you know the tools. Ask what the combination says about where the company is.

• **Terraform, GitHub Actions, ArgoCD, Kubernetes and Datadog together** suggest a mature platform team. They want someone who can work inside established patterns and improve them.
• **“On-premises”, “VMware”, “data centre exit” or “legacy” alongside AWS or Azure** usually means migration work, which rewards patience, planning and people skills as much as technical depth.
• **Two or three cloud providers** can point to acquisitions or integration headaches.
• **Older tooling** (Jenkins, hand-written CloudFormation, lots of scripting) might mean you'd be the one modernising it. That's an opportunity if you frame it that way.

Notice the order too. The first two or three technologies listed are usually what the team uses every day. Anything under “nice to have” is often a wish list, or a hint at where they want to go next.

Signal 3: Compliance requirements

This is the signal most applicants skip, and one of the most revealing. ISO 27001, SOC 2, PCI DSS, GDPR, FCA regulation or NHS data standards tell you the company lives under audit. Everything needs a paper trail, changes go through approval, and access is tightly controlled. Logging, encryption and tagging aren't extras. They're the difference between passing and failing an audit.

Cyber Essentials tells you who the company sells to. Since October 2014 it has been mandatory for suppliers of government contracts involving personal information or some ICT products and services, and for Ministry of Defence projects it's mandatory whatever the contract covers [5][6]. If you see it, the company is probably in, or selling into, the UK public sector supply chain.

Security clearance is where many applicants waste an evening tailoring a CV for a role they can't take. Check residency first. SC normally requires five years' UK residency and DV ten [2][3]. NHS England adverts note this can sometimes drop to three years' continuous residency, with extra overseas checks for the previous two [4]. You usually don't need to hold clearance already, but if you can't meet the requirements after an offer, the offer is withdrawn.

How it changes your application: you don't need to have worked somewhere regulated to show you think like someone who could. Talk about least-privilege IAM, encryption at rest and in transit, centralised logging, tagging policies and documented decisions in your own projects. One line such as “designed with audit in mind: all access logged via CloudTrail, resources tagged by owner and environment” sets you apart from applicants who only describe what they built, not how safely they built it.

Mini-activity: the Cyber Essentials Check

The scheme covers five technical control areas [7]. Take one of your projects and tick each area you can already explain in one line. The unticked ones are your next improvements, and the ticked ones are a security story in the language that employer already uses.

• FirewallsWhat's exposed to the internet, and what isn't? Security groups, NACLs, WAF.
• Secure configurationDefaults changed, unused services off, infrastructure defined in code.
• User access controlLeast-privilege IAM, no shared root credentials, MFA on.
• Malware protectionScanned images, GuardDuty or equivalent, trusted sources only.
• Security update managementHow patches and dependency updates get applied, and how often.

Signal 4: The level of specialism

Look at how many domains the duties cover, and at the verbs. If one role asks for networking, security, Kubernetes, data pipelines, cost optimisation and on-call support, either it's a small company that needs a generalist, or the advert was written by committee. Both are worth knowing before you apply.

Titles that don't match duties aren't just a theory. Some NHS England adverts openly state that the successful candidate will be hired under a different title, chosen to attract the right skills [4]. In the private sector it's rarely said that plainly, so read the duties, not the heading.

Signal 5: Partners and who the customer is

If the company calls itself an AWS Partner, a Microsoft Solutions Partner, a consultancy or a managed service provider, it's a client-facing role, even if the advert never says so. That matters for two reasons.

Firstly, partners must keep a minimum number of certified people to hold their tier. If you hold one of those certifications, you're not just a skilled hire. You're part of how they keep their partner status. Secondly, you'll be working with clients: explaining technical decisions to non-technical people, estimating work, writing clearly and sometimes joining sales conversations.

Vendor partnerships such as HashiCorp, Datadog or Snowflake tell you which tools are strategic to the business, not just used by it. How it changes your application: put certifications near the top, and include at least one example of explaining something technical to a non-technical audience, such as a workshop, documentation for others or a demo.

A few more quiet signals

• “Fast-paced” and “on-call” together often mean firefighting. Ask about incident volume in the interview.
• Who the role reports to (a CTO, a Head of Platform or an IT Manager) tells you how technical your manager is and how you'll be judged.
• Product company or services company tells you whether you'll build one thing deeply or many things quickly.
• Repeated words show what the hiring manager cares about most. If “reliability” appears four times, that's your theme.

Activity 1: The Three-Highlighter Read

Pick a real advert you're considering. Paste it into a document and highlight it in three colours: yellow for anything about size, stage or customers; blue for compliance, security, regulation or process; green for every verb in the duties (build, maintain, improve, support, own, migrate). Then fill in the sentence below. If you can't, read the advert again. That sentence is the centre of your application.

Activity 2: The Signal Scorecard

For the same advert, tick each signal where you'd honestly score yourself 2 or 3 out of 3. A low score isn't a reason not to apply. It's the gap your application must address directly, or the thing to work on before the next one.

Turning signals into positioning

Once you know the problem, positioning gets simpler. You're not trying to look impressive. You're trying to look like the answer.

Building the skills that aren't on the tools list

Most rejected applicants I speak to aren't short on technical ability. They're short on proof of what companies struggle to hire for: communication, judgement, documentation, ownership and business awareness. You can build these deliberately, and you don't need a job to start.

• **Documentation.** A proper README for every project, and try an architecture decision record: a record of a significant choice, its context and its consequences [8]. One page on a decision, the alternatives and why is exactly what regulated and enterprise teams need.
• **Communication.** Explain a project to someone non-technical and notice where they get lost. Better, run a study group, lab walkthrough or meetup talk.
• **Business and cost awareness.** Add a monthly cost estimate to each project, and what you'd change to halve it. Hiring managers rarely see junior candidates think about money.
• **Security thinking.** Before calling a project finished: who can access it, what's logged, what happens if a credential leaks? Then run the Cyber Essentials Check above.
• **Ownership and incident handling.** When something breaks, write a short post-incident review: what happened, how you found it, how you fixed it, what you changed. That document is interview gold.
• **Collaboration.** Contribute to someone else's project, or volunteer for a charity or small business. Working inside someone else's constraints is a different skill.

Activity 3: The Proof Bank

Tick each heading where you already have at least one real example, even a small one. Any unticked heading is your focus for the next month.

• DocumentationA README, an ADR, a runbook someone else could follow.
• CommunicationA session you ran, a write-up, a demo.
• CostA monthly estimate and one saving you made or could make.
• SecurityIAM, encryption, logging decisions you can explain.
• OwnershipSomething that broke, and what you changed afterwards.

Writing your own CV (without handing it over to AI)

I understand the temptation: paste in the job description, get a polished CV back, done. But recruiters aren't rejecting CVs because AI touched them. Across the major 2025–2026 surveys, what gets applications rejected is generic, impersonal content [10]. The problem is scale.

There's a second cost. At interview you'd be defending sentences you didn't write, about work described in a way you'd never describe it. Your CV should sound like you on a good day. Here's a simple process.

• Step 1: Start from your Proof Bank, not a blank page.Every bullet comes from something real you wrote down.
• Step 2: Use one formula: what you did, how, and why it mattered.“Automated deployments for a containerised web app using GitHub Actions and ECS, cutting release time from 30 minutes to under 5.” No number? Use the outcome.
• Step 3: Keep a master CV and tailor 20%.Change the summary, reorder bullets so your three signals come first, mirror their language. Don't rewrite from scratch.
• Step 4: Read it out loud.If you'd never say it, rewrite it. If you can't talk about a line for two minutes, cut or simplify it.
• Step 5: Use AI as an editor, not an author.Ask it to check spelling, flag vague bullets, or spot parts of the advert you haven't addressed. Critique, not rewrite.

AI can help you edit, but it can't supply your evidence.

Activity 4: The Two-Column Match

Draw two columns. On the left, the three signals you picked from the advert. On the right, the CV bullet that proves each one. Any empty row on the right is exactly what to fix before you hit submit.

Activity 5: The Stranger Test

Give your CV to a friend, ideally not in tech, for 30 seconds. Take it back and ask: “What do I do, and what kind of company would hire me?” If their answer doesn't match the role you're applying for, your positioning needs work, not your skills.

The shift that changes everything

When you stop reading adverts as checklists and start reading them as a company describing its problems, three things happen. You apply to fewer roles, but better ones. Your applications stop sounding like everyone else's. And by interview, you already know what they're worried about, so you can address it before they ask.

Sources

1. [1]AWS Services Partner Tiers (official). aws.amazon.com/partners/services-tiers
2. [2]GOV.UK, National security vetting clearance levels. gov.uk/government/publications/united-kingdom-security-vetti
3. [3]Scottish Government candidate guide, pre-employment checks (SC and DV residency periods). gov.scot/publications/recruitment-candidate-guide/pages/pre-
4. [4]NHS England job advert (SC residency, and advertised vs hired title). findajob.dwp.gov.uk/details/17052354
5. [5]Cyber Essentials and government contracts (iHASCO). ihasco.co.uk/?p=6161
6. [6]Cyber Essentials and MoD contracts (Akita). akita.co.uk/?p=11188
7. [7]Cyber Essentials five control areas (Presencis). cdn.presencis.com/regulations/cyber-essentials/documents/
8. [8]AWS Prescriptive Guidance, ADR process. docs.aws.amazon.com/prescriptive-guidance/latest/architectur
9. [9]CV-Library survey of 1,000+ UK candidates and 233 recruiters, reported by JobAdvisor. jobadvisor.link/2026/09/study-jobseekers-are-writing-cvs-for
10. [10]Generic content as the rejection trigger (Phrasly). phrasly.ai/blog/do-hiring-managers-check-for-ai-in-cover-let
11. [11]AI résumé statistics 2026, including the MIT/NBER randomised trial (JobCannon). jobcannon.io/blog/ai-resume-statistics-2026