Your complete reference guide � from first read before training to quick-look revision on the job. Every concept, every framework, every worked example in one place.
?? How to use this document: Before your training session � skim through all sections to get familiar with the concepts. During training � follow along using the worked examples. After training � use the TSTE table, narrator framework, self-test, and glossary for revision and on-the-job quick reference.
A JD is your starting point � not the final truth. It describes the role. But it passes through many hands before it reaches you, and each hand can distort it.
A JD ? the complete picture of what the client needs. It is a document � created by HR, filtered by legal, and often outdated. Your job is to read it critically, not accept it literally.
Job Description (JD): Describes the role � skills, responsibilities, qualifications.
Job Requisition (Req): The business/financial approval to hire. Contains: client name, req number, budget, timeline, bill rate.
When a job order arrives in the VMS, it contains BOTH. Read the req header first � confirm title, location, duration, and rate � before spending time analyzing the JD.
The JD received from the client or MSP as-is. May contain client-identifying information, internal comments, garbled formatting, and HRIS export artifacts. Never share this with candidates.
Cleaned, formatted version � with client identifiers removed. Can be pushed to job boards and your company's Jobs page. Always use this version when sharing JDs with candidates via email.
Three things can make a JD misleading before it even reaches you. Spot these early � before you spend sourcing time chasing the wrong criteria.
Bullet points become paragraph walls. Special characters turn into symbols. Hiring manager comments get left in the body. The original structure disappears in the HRIS export.
Precise technical language gets replaced by corporate jargon during HR/legal review. "Must be able to query production databases" becomes "Strong analytical skills."
The Pareto principle: 80% of the role's value comes from 20% of listed requirements. But committees add nice-to-haves alongside the 3 things that actually matter.
This is a real example of what a VMS export looks like � and how a recruiter should reconstruct it.
The rule: If you could put the phrase on any resume for any industry � it is fluff. If you can't put it in a Boolean string � it's not a sourcing criterion.
How to apply: Count requirements (>8 = assume inflation), look for repetition, look for specificity, check for CAPS LOCK notes, then confirm with manager.
| Priority | Item from the Java Engineer JD | Why This Priority | Sourcing Action |
|---|---|---|---|
| ?? Deal-breaker | Spring Boot 2+ years | Hiring manager stated "NO EXCEPTIONS" in CAPS LOCK | Screen for this in the first 2 minutes of every call |
| ?? Core | Java 11+ � 5+ years | Appears in overview, responsibilities, AND requirements = genuinely important | Boolean keyword. Immediate disqualification if missing. |
| ?? Core | RESTful API design | Specific and repeated. Required to perform the job. | Boolean keyword + screening question |
| ?? Core | Microservices architecture | Specific and repeated. Required to perform the job. | Boolean keyword + screening question |
| ?? Nice-to-have | AWS (EC2, S3, Lambda) | Listed as "nice to have" in original. Genuine preference, not a deal-breaker. | OR group in Boolean. Don't filter out candidates who lack this. |
| ?? Nice-to-have | Docker / Kubernetes, Jenkins CI/CD | Listed as "preferred" � can be learned on the job | OR group in Boolean. Positive signal, not a requirement. |
| ? Ignore | Bachelor's degree in CS or related | Listed as "preferred" � client will waive for strong candidates | Clarify with manager. Do not screen out on education alone. |
| ? Ignore | Excellent communication skills, Other duties as assigned | Boilerplate. Not searchable. Not a disqualifier. | Assess on call � never Boolean. |
Before analysis, extract every field from the JD. If a field is blank or ambiguous � flag it to your manager. Never source blind.
Blank location + no confirmed rate + unclear shift = you cannot screen a single candidate properly. Always fill these gaps first, before opening any job board.
| # | Field | Why It Matters to You as a Recruiter | If Missing � Ask Your Manager |
|---|---|---|---|
| 01 | Client | Industry context, culture, and household name factor. Look up the client before sourcing. | Is this confidential? What can I tell candidates without naming them? |
| 02 | Title | Drives Boolean title variations. "Software Engineer II" = "Mid-level Developer", "Java Developer", etc. | Is there a level (junior/mid/senior)? Alternative titles the hiring manager uses? |
| 03 | Location | Commute radius for onsite; time zone for remote. Compact licence relevance for healthcare. | Onsite, hybrid, or fully remote? If hybrid � how many days on-site? |
| 04 | Duration | Governs urgency, logistics, and candidate commitment. 3-month vs 12-month attracts different people. | Extension or conversion to perm possible? Client's intent? |
| 05 | Pay / Rate | Your negotiation anchor. Know the max pay before your first sourcing call. Never source blind on rate. | What is the bill rate and the margin floor? |
| 06 | Shift Timing | Filters availability. Night-shift ICU list differs from day-shift. Remote: time zone alignment matters. | Core hours? Any standby or on-call requirements? |
| 07 | Temp to Perm | Changes the conversation. Contract-to-hire opens passive candidates who'd decline a pure contract. | Defined conversion path? Trial period length and trigger conditions? |
| 08 | Hard Skills | Your PRIMARY sourcing criteria � the MUST HAVEs. Missing a key hard skill = immediate disqualification. | Which are deal-breakers vs preferred? Minimum experience level per skill? |
| 09 | Soft Skills | Culture fit indicators. Used in screening, not sourcing. You cannot Boolean-search for "self-starter." | What does team culture look like? How does the hiring manager describe ideal fit? |
| 10 | Tools | Version-specific and often NON-SUBSTITUTABLE. AWS ? Azure. Confirm specific tools before sourcing. | Required or preferred? Is training provided on proprietary tools? |
| 11 | Certifications | Mandatory in many fields. Missing a required cert = automatic rejection at submission. | Required day 1 or can it be in progress? Which body issues it? |
| 12 | Education | Often aspirational. Clients say "degree required" but waive it for strong hands-on experience. | Equivalent experience acceptable? Minimum they'll actually consider? |
| 13 | Deal-breakers | The 1�3 requirements causing automatic rejection. Confirm before sourcing � saves hours. | Of all requirements listed, which 3 cause immediate rejection? |
| 14 | Missing Info | Blank location, rate, or shift = you cannot screen properly. Always fill gaps first. | Flag ALL blanks before sourcing. Do not source blind � period. |
Skim through without stopping. Get mental notes of what sections are present: overview? responsibilities? tools? certifications? Don't read � survey.
Read every sentence. Next to each, write a 5-word-or-less remark: "core task," "vague fluff," "specific tool," "legal padding."
Bold the required skills and tools. Italicize preferred/nice-to-have skills. Now you have a clean sourcing map.
These three categories drive three completely different parts of your process. Confusing them is one of the most common mistakes freshers make.
After you've broken down the JD, you analyse it. This is what transforms you from a keyword-matcher into a recruiter who actually understands the role.
What does the client do, and how does this role help them do it? A recruiter who understands the business can pitch the role in the language of impact � not just job duties.
Why does this req exist? Every open role exists because something is missing. Knowing what it is shapes your candidate pitch and tells you the urgency level.
Close the JD and write 3�5 sentences describing a day in the life of this person. If you can narrate it, you understand the role well enough to find the right candidate.
Build the Title/Skills/Tools/Education table before opening any job board. This is the bridge from JD analysis to Boolean search.
| Req Type | What It Means | Urgency | Candidate Pitch Angle |
|---|---|---|---|
| Growth Req | Client is expanding � needs more hands | Lower | "Join a growing team" � good for candidates considering stability |
| Backfill Req | Someone left � work is piling up | High � need yesterday | Emphasize immediate impact. Candidate should ask why the person left. |
| New Capability | Client needs a skill they don't have internally | Urgent AND specific | Emphasize uniqueness. No one on the team can do what they're being hired to do. |
| Project Req | Short-term need for a specific project phase | Deadline-driven | Clear scope, defined timeline � good for contractors preferring project-based work |
Close the JD. Write 3�5 sentences describing a typical day. If you can't answer any of these 7 questions � go back to the JD. If the JD doesn't answer it � ask your manager.
Alex is a mid-to-senior Java engineer working remotely from EST hours. Their day starts with a 9am standup with an 8-person agile squad � a quick sync on sprint progress, blockers, and deployment status. The team runs 2-week sprints, so Alex has a clear delivery cadence.
The core of their day is feature development: building microservices in Java using the Spring Boot framework � specifically the real-time payment processing module. They write REST API endpoints, test them, and integrate with the existing payment infrastructure. Most of their code runs in AWS (Lambda for event-driven functions, EC2 for services, S3 for storage). They use Jenkins for CI/CD.
Alex owns features end-to-end. This is not a ticket-and-hand-off team � they design, build, test, and deploy. High autonomy. They report to a senior engineering manager but work independently. Communication happens mostly async via Slack and Confluence documentation.
Build this table before opening a single job board. This is Step 4 of your analysis. The next module (Boolean Search) will use this as its direct input.
Each row = one category. Each cell includes what's in the JD + what you research as alternatives. The "Research" row is what freshers most often skip � and it's what separates good searches from great ones.
| Category | From the JD | Variations & Alternatives (research these) |
|---|---|---|
| T � Title | Java Software Engineer | Software Developer Application Developer Java Developer Backend Engineer Java Backend Developer Software Engineer II Engineer II (Java) |
| S � Skills | Java 11+ � Spring Boot � REST APIs � Microservices | Core Java J2EE Jakarta EE Spring Framework Spring MVC Web services API development SOA Distributed systems |
| T � Tools | AWS (EC2, S3, Lambda) � Docker � Kubernetes � Jenkins | Amazon Web Services Container orchestration K8s Helm GitHub Actions CircleCI GitLab CI CI/CD pipelines |
| E � Edu/Exp | 5+ yrs Java � BS Computer Science preferred | Bachelor's CS Software Engineering IT / MIS Equivalent experience Self-taught + portfolio |
| Preferred | AWS � Docker � Kubernetes � Jenkins � Agile/Scrum | Group into ONE OR group in Boolean: (AWS OR Docker OR Kubernetes OR Jenkins OR Agile OR Scrum) |
| Research | What do Java Spring Boot developers also use? | Spring Boot 2.x / 3.x Spring Security Spring Data JPA Hibernate Maven Gradle JUnit Mockito Lombok |
Search "Java Spring Boot developer resume" on LinkedIn right now. Note what other skills appear on those resumes. That vocabulary � the words developers actually use for the skills the JD describes � goes into your Research row and gives you better Boolean results than just copying the JD verbatim.
See the full framework applied to three real JDs � from entry level to mid-level, across different domains. Each is fully broken down across all stages.
Caution issues: None major. Well-structured JD for an entry-level role.
Potential fluff to ignore: "Eager to learn and grow," "fast-paced environment" � good culture signals, but not screening criteria.
Top 3 Deal-breakers:
| Field | From JD |
|---|---|
| Client | Not named. Internal employees of an unspecified company. |
| Title | Help Desk Support Specialist � entry level |
| Location | Dallas, TX � Onsite (commute matters) |
| Duration | Full-time permanent (not contract) |
| Pay / Rate | Not listed � FLAG to manager before sourcing |
| Shift | Mon�Fri, 9am�6pm CST (clear) |
| Hard Skills | OS troubleshooting (Windows + macOS), basic networking, ticket logging |
| Soft Skills | Communication, customer service, patience |
| Tools | Windows 10/11, macOS, MS Office 365, ServiceNow/Jira/Zendesk, TeamViewer/AnyDesk |
| Certifications | CompTIA A+ preferred (not required day 1) |
| Education | BS in CS/IT or related � or equivalent training |
| Deal-breakers | Basic OS knowledge, communication ability, ability to follow SOPs |
| Missing Info | Pay/Rate � must clarify before making any sourcing calls |
Sam starts their shift at 9am by logging into the ticketing system and checking the queue of open support requests from internal employees. Most mornings begin with a wave of password resets and account lockout tickets � the most common issues at any corporate help desk. They work through tickets in priority order: urgent (production systems down) before routine (software install requests).
When calls or chats come in, Sam follows a standard troubleshooting SOP: identify the issue, attempt a fix, document the steps taken and outcome in the ticket. If the issue can't be resolved at Level 1, Sam escalates to the Level 2/3 team with a clear handover note. Throughout the day, Sam may also walk a new employee through an Office 365 setup or install antivirus tools on a laptop remotely using TeamViewer.
Communication is constant � friendly, clear, non-technical language for users who aren't IT-savvy. The role is reactive and repetitive, but Sam gets satisfaction from resolving issues quickly and keeping end users productive.
| Category | From JD | Research/Variations |
|---|---|---|
| Title | Help Desk Support Specialist | IT Support Technician � Desktop Support � Technical Support Specialist � Level 1 Support � Service Desk Agent � IT Help Desk Analyst |
| Skills | OS troubleshooting, ticket logging, basic networking | Windows troubleshooting � macOS support � TCP/IP basics � Wi-Fi troubleshooting � remote support � SOP documentation |
| Tools | Windows 10/11, macOS, MS Office 365, ServiceNow / Jira / Zendesk, TeamViewer / AnyDesk | Remote desktop � VPN � Active Directory (common co-occurrence) � SCCM � AnyDesk � Bomgar |
| Edu/Exp | BS CS/IT or equivalent � 0�1 yr experience | Internship acceptable � Academic IT projects � CompTIA A+ (preferred) � Equivalent training |
| Preferred | CompTIA A+, ticketing system experience, networking basics | (CompTIA OR "A+" OR ServiceNow OR Zendesk OR Jira OR networking) |
Stage 1 � Caution Check: Well-structured JD. Minor fluff: "ideal candidate," "detail-oriented." Key domain flag: HIPAA compliance is non-negotiable � this is a regulatory requirement, not a soft preference. Typing speed (50 WPM) is a measurable, testable requirement.
Deal-breakers: (1) Data entry experience in healthcare/insurance, (2) Typing speed =50 WPM with accuracy, (3) HIPAA awareness / ability to handle confidential patient data
Stage 2 � Key Fields: Remote (US-based only � time zone matters for team coordination), Contract 6 months + possible extension, Pay not listed (flag), no shift mentioned (flag � are productivity targets hourly or daily?)
Stage 3 � Day in the Life: Jordan logs into the VPN and EMR system at shift start, opens their daily work queue of patient records or claims documents. They pull a batch, verify completeness before entering � checking that all required fields are present and legible. If a document is missing information, they flag it per SOP and move to the next. Data is entered into the EMR (Epic, Cerner, or similar), validated against existing records, and marked complete. Throughout the day, Jordan tracks their personal accuracy rate and volume against daily targets. The role is methodical, compliance-focused, and accuracy-intensive � a candidate who rushes will fail here.
Stage 4 � TSTE Highlights:
Stage 1 � Caution Check: This JD describes your own future role � excellent for understanding what you'll be doing. Key deal-breakers: (1) End-to-end US recruitment experience, (2) US work authorization knowledge (H1B, GC, USC, etc.), (3) Strong communication in US English for candidate and client interactions. Possible fluff: "strong communication skills" � translate as: ability to conduct professional phone screens and draft client-facing submission summaries in clear US English.
Domain note: The roles listed (Software Engineer, QA, DevOps, Data Engineer) are IT roles � this recruiter must be able to read and understand technical JDs. This is exactly why your training on JD breakdown matters.
Stage 3 � Day in the Life: You start your night shift (aligned to US time zones) by checking the VMS for new job orders. You review JDs across different IT domains � reading them critically, breaking them down, and confirming deal-breakers with your manager. You run Boolean searches on Dice, Monster, LinkedIn, and internal databases to source qualified candidates. You call candidates to screen for technical fit, work authorization status, communication skills, and pay expectations. Qualified candidates are formatted and submitted to the client with a summary note. You track submissions, client feedback, and interview status throughout the day. Your performance is measured by submittals, interviews, and placements.
Stage 4 � TSTE:
Learn these from a reference document � not from a failed placement.
Reading the JD for 90 seconds and opening LinkedIn. You will source the wrong people and waste 3+ hours on incorrect candidate profiles.
The JD says 12 skills are required. Sourcing for all 12 means finding no one. Always confirm the true 2�3 deal-breakers with your manager first.
The most valuable signal in a poorly formatted JD is the hiring manager's own comment. "MUST HAVE SPRING BOOT � NO EXCEPTIONS." Never skip it.
"Self-starter" in a Boolean string returns irrelevant results. Soft skills are for screening calls, not for sourcing on job boards.
Starting sourcing without a confirmed pay rate, location type, or shift means your first 10 calls are just collecting data you should have had upfront.
Recruiters who can't narrate the role submit technically-qualified candidates who are wrong for the team, the culture, or the work style. The placement fails.
"PhD required" often means "Master's preferred." Always clarify with manager before filtering out candidates on education alone.
Going into Boolean without title variants and skill alternatives means a narrow search pool. The TSTE table takes 10 minutes and saves hours of sourcing time.
Answer these before your training session (to check your pre-read comprehension) and again after (to test retention). Click an option to check your answer.
Check off each concept as you feel confident with it. Use this for revision planning.
Use this when you encounter any of these terms in training, in the VMS, or on the job.