The Real Selection Problem
A hiring manager posts a Linux SysAdmin role. Forty applications arrive. Thirty-two list "proficient in bash scripting." Six list "expert." Four list "advanced." None of those words mean anything verifiable. The hiring manager schedules phone screens, spends three hours, and still cannot tell who can actually write a cron job, rotate logs, or diagnose a runaway process at 2 a.m.
The job description created that problem before a single application was submitted. It asked for adjectives. It got adjectives back.
This post is about writing IT job descriptions that filter for demonstrated capability instead of self-reported fluency. The changes are structural, not cosmetic.
Why Standard IT Job Descriptions Fail
Most IT job descriptions are assembled from three sources: a previous posting that was "close enough," a vendor certification list someone found online, and a bullet-point wish list from the hiring manager. The result is a requirements section that reads like a certification catalog and a responsibilities section full of passive constructions: "responsible for," "assists with," "supports the team in."
Candidates who are skilled at job searching recognize these patterns immediately. They mirror the language back. A candidate who has never touched a firewall rule can write "managed network security policies" if that phrase appears in the posting. The description trained them to do exactly that.
There is a second failure mode: the description is technically accurate but describes the role at the wrong altitude. Listing "TCP/IP" as a required skill for a mid-level network engineer tells a qualified candidate nothing about what the job actually demands. It also tells an unqualified candidate exactly what phrase to include.
Start With Outcomes, Not Inputs
The most effective job descriptions describe what a person in the role will produce or resolve, not what they should already know. This is a meaningful distinction.
Instead of: "Proficient in network troubleshooting"
Write: "Diagnoses and resolves Layer 2/3 connectivity failures in a mixed Cisco/Juniper environment, typically within a two-hour window, with documentation in the ticketing system."
The second version does several things the first does not. It names the environment. It implies a time constraint. It requires documentation behavior. A candidate reading it either recognizes that scenario from experience or knows they do not. A resume writer reading it has a much harder time manufacturing a convincing response.
Apply the same logic to every major responsibility. Ask: what does success look like in the first 90 days? What does a bad day in this role require the person to handle? What does a good week produce? Write those answers into the description.
Replace Certification Lists With Skill Signals
Certifications are not useless, but listing them as requirements without context selects for people who test well, not necessarily people who operate well. A CompTIA Security+ holder who has never stood up a SIEM is not the same as someone who has, regardless of what their transcript says.
A more useful approach: describe the technical context and let the certification be a supporting signal rather than a gate.
Instead of: "CompTIA Network+ required"
Write: "Comfortable reading packet captures, interpreting VLAN configurations, and explaining routing decisions to non-technical stakeholders. Network+ or equivalent experience."
"Equivalent experience" is not a loophole. It is an honest acknowledgment that a self-taught engineer who has built and broken home labs for five years may outperform a certification holder who passed an exam and stopped there. The description should invite both to apply and let the assessment process sort them.
Write the Environment, Not Just the Stack
Candidates make better decisions, and hiring teams get better applicants, when the description is honest about the operating environment. This means naming the scale, the pace, the team structure, and the failure modes.
"Fast-paced environment" is noise. "On-call rotation covering 200-node infrastructure, escalation path to senior engineer, expected response time under 15 minutes" is signal. One tells the candidate nothing. The other tells them whether they want the job and whether they are ready for it.
Include the tools in use, not as a requirements list but as context: "We run Ansible for configuration management, Grafana and Prometheus for observability, and Terraform for infrastructure provisioning. You do not need to be expert in all three on day one, but you will use all three within 60 days." That sentence attracts people who are comfortable learning under pressure and deters people who need a fully stable environment before they contribute.
The Requirements Section: Necessary Versus Nice-to-Have
One of the most common job description errors is treating every requirement as equally weighted. When twelve items appear in a single bulleted list with no hierarchy, candidates cannot tell what is essential and hiring managers cannot defend a screening decision.
Separate requirements into two explicit categories: what someone must be able to do on day one, and what they are expected to develop within a defined period. This structure is honest, it sets expectations for the candidate, and it gives the hiring team a defensible rubric for screening.
Keep the "must have on day one" list short. If it has more than five or six items, the team is describing a unicorn, not a hire. Long must-have lists also discourage qualified candidates who match eight of ten criteria from applying, because the list signals that anything less than a perfect match is unwelcome.
Build the Description Around the Assessment
The most durable fix is to design the job description and the skills assessment together, so the description previews what candidates will actually be asked to demonstrate. If the role requires diagnosing a misconfigured SSH service, say so in the description: "We assess candidates on practical terminal scenarios relevant to the role. Expect tasks involving service configuration, log analysis, and basic scripting."
This does two things. It signals to experienced candidates that the process is rigorous and fair. It signals to resume writers that the process will not reward polished language alone. Both signals are useful.
Platforms like OpsTicket, a product of IT Custom Solution LLC, exist precisely for this alignment: candidates work through real terminal scenarios scored against a deterministic rubric, producing a verifiable result that either supports or contradicts what the resume claims. When the job description and the assessment speak the same language, the entire hiring process becomes more efficient and more honest.
A Short Checklist Before You Post
- Does every responsibility describe an outcome or action, not a trait?
- Is the technical environment named specifically enough that a qualified candidate can picture the work?
- Are certifications listed as signals rather than gates?
- Are requirements separated into must-have and develop-within-90-days?
- Does the description mention how candidates will be assessed?
- Have you removed every adjective that a candidate could self-apply without evidence ("strong," "excellent," "proven")?
The Takeaway
A job description is the first filter in a hiring process. If it selects for people who write well about work, the rest of the process inherits that bias. Rewrite responsibilities as outcomes, name the environment honestly, separate requirements by weight, and tell candidates how they will be assessed. The description will be shorter, less impressive-sounding, and significantly more useful.
If you want to think through how to align your job descriptions with a practical skills assessment process, the team at IT Custom Solution is available for a brief conversation. Reach out here and describe what you are hiring for.