--- title: "Reading a Salesforce job description honestly" url: "https://trailassembly.com/reading-a-job-description/" topic: "Career and Certification" published: "2026-09-21T11:46:59+00:00" updated: "2026-09-23T09:12:28+00:00" --- # Reading a Salesforce job description honestly **Straight answer:** most Salesforce job descriptions are wish lists assembled from other job descriptions, so read them for the two or three requirements that repeat in different words — those are the real job. Apply when you meet roughly half of what is listed. The certification list is nearly always softer than it looks. The years-of-experience number is usually the hardest line to move. ## Why they read the way they do A description is typically written by a hiring manager under time pressure, edited by a recruiter optimising for search, and approved by someone who wants to appear thorough. Each pass adds requirements and none removes any. The result describes a person who does not exist, which everybody involved knows and nobody says. The useful reading skill is separating what was decided from what was accumulated. ## What actually signals the real job **Repetition across sections.** If integration appears in the summary, in the responsibilities, and in the requirements, the job is about integration. Something mentioned once in a bullet near the bottom is decoration. **The first two responsibilities.** These are usually written first and reflect the actual need. By bullet eight the author is padding. **Specificity.** “Experience with Salesforce” is filler. “Experience migrating from Classic to Lightning in an org with heavy Visualforce” is someone describing their Tuesday. Specific requirements are real requirements. **What is conspicuously absent.** A senior developer role with no mention of testing, code review or deployment tells you something about the engineering culture. So does an admin role with no mention of stakeholders. ## Translating the common phrases | It says | It often means | | --- | --- | | “Wear many hats” | The team is small; you will do everything | | “Fast-paced environment” | Shifting priorities, limited planning | | “Greenfield opportunity” | Genuinely good, or nothing exists and nobody has decided anything | | “Work closely with the business” | Requirements gathering is your job | | “Passionate about the platform” | Sometimes culture, sometimes unpaid evenings | | “Legacy modernisation” | Considerable technical debt, and honesty about it | | “Self-starter with minimal supervision” | Little onboarding or mentorship | None of these is automatically bad. “Wear many hats” at a thirty-person company is accurate and can be a good job. At a company of five thousand it means the team is under-resourced. Context decides. ## The requirements, ranked by how negotiable they are **Years of experience — hardest.** Not because it measures anything, but because it is often a filter applied before a human reads your application. Demonstrably equivalent experience helps and you need to get past the filter first, usually through a referral. **Certifications — softer than they look.** Frequently listed because the recruiter needed a concrete criterion. “Certification required” often means “or convince us you know it”. Certifications matter most for partner consultancies, where partner tier depends on counting them. There they are genuinely non-negotiable. **Specific technologies. Depends on centrality.** A named product in the job title is real. One in a list of twelve is not. **Industry experience. Usually soft.** Sometimes real in heavily regulated sectors, more often a preference someone typed. **Degree requirements. Mostly vestigial.** In this ecosystem particularly, where a large share of excellent practitioners arrived from other careers. ## The half rule Apply if you meet about half the listed requirements and the core two or three. This is not optimism. It is calibration against how the documents are written. A list of fifteen requirements was never a description of one person. The well-documented asymmetry is that some people apply at thirty percent and others wait until they meet everything, and the second group is disproportionately made up of people who would have got the job. If you are inclined to wait until you qualify completely, that inclination is costing you interviews. ## The questions that reveal the actual role Save these for the interview, and ask them plainly: - “What does the org look like: how many users, how much custom code, what is the state of the automation?” - “Why is this role open?” New team, growth, and backfill are three different jobs. - “What would success look like in the first six months?” A vague answer means nobody has decided. - “Who decides what gets built?” This tells you where you sit and how much of your time will be negotiation. - “How do changes reach production?” The answer tells you the engineering maturity faster than any other question. The last one is the highest-yield question in a Salesforce interview. “Change sets, deployed by the admin on Friday evenings” and “pull requests, CI validation, quick deploy” describe very different working lives. ## Signals worth taking seriously **Good:** a named manager who is technical, a description that admits current problems, specific technologies that cohere, a stated approach to deployment or testing. **Worth probing:** an enormous requirements list, a title mismatched to the seniority described, “Salesforce” as one of six platforms in a single role, no mention of anybody else doing this work. That last one deserves attention. A description implying you are the entire Salesforce function needs a direct question about support, cover and escalation. Being the sole admin is a legitimate job and it should be a choice rather than a discovery. ## Frequently asked ### Should I apply if I lack a required certification? Usually yes, unless it is a partner consultancy where certification counts are contractual. Say in the cover note when you plan to sit it. ### Do cover letters matter here? A short, specific one referencing the actual org problem in the description does. A generic one does not, and may be worse than none. ### How do I tell a real greenfield from a vacuum? Ask who the executive sponsor is and what has already been decided. A real greenfield has a sponsor and a budget. A vacuum has a hope. ### Is a salary range being absent a red flag? It is increasingly unusual where disclosure is required, and it correlates with a wide internal band. Ask early rather than at offer stage. ### What if the title is below my experience but the work is right? Titles vary enormously between companies in this ecosystem. Judge the work, the scope and the money, and ask directly what the progression looks like. --- *Reference: This article describes hiring practice in the Salesforce ecosystem from general industry observation and contains no employer-specific or confidential information.* --- Source: https://trailassembly.com/reading-a-job-description/ Trail Assembly — independent Salesforce write-ups.