How to get hired as a Salesforce developer in 2026-27

Salesforce Developer is at least four different jobs, and the posting tells you which

The title hides more variation than almost any other developer title. Two postings that both say Salesforce Developer can require different languages, different tooling and non-overlapping experience. Candidates lose months applying across all of them with one resume and wondering why nobody calls back.

The first job is core platform development. Apex, Lightning Web Components, SOQL, triggers, asynchronous jobs, Flows that call Apex, and the data and sharing model underneath. This is what Platform Developer I covers and what most people mean by Salesforce developer. If the posting lists Apex, LWC, SOQL and sandboxes, this is it.

The second is integration development. The Salesforce part is real but the centre of gravity sits outside it: REST and SOAP APIs, Bulk API 2.0 for large loads, Composite requests, Platform Events and Change Data Capture for outbound streaming, Named Credentials and External Credentials with OAuth, middleware such as MuleSoft or Boomi or a hand-built service, and the dreary realities of retry, idempotency and error reconciliation. Postings for this job name an external system. If you see SAP, NetSuite, Workday, Oracle or a payments provider in the requirements, you are reading an integration role wearing a Salesforce badge.

The third is industries and OmniStudio, which came from the Vlocity acquisition and underpins Health Cloud, Financial Services Cloud, Public Sector Solutions, Communications and Energy builds. The artefacts are OmniScripts, FlexCards, Integration Procedures and data mappers (long known as DataRaptors), plus a declarative style that experienced Apex developers often find alien. This is a genuine specialism with its own labour market, its own certification and generally better rates, because the supply of people who have actually shipped it is thin.

The fourth is Marketing Cloud development, and it is the trap. Marketing Cloud Engagement is a different product with a different stack: AMPscript, Server-Side JavaScript, SQL query activities in Automation Studio, Journey Builder, and data extensions instead of objects. Almost none of your Apex knowledge transfers. Salesforce has since built newer marketing editions on the core platform, which use Flow, Data Cloud and standard tooling, so the market now contains both worlds and the words Marketing Cloud in a posting no longer tell you which stack. Read the requirements before you apply.

Two more variants hire differently enough to name. ISV or product development means building a managed package for AppExchange, which adds package versioning discipline, namespace constraints, upgrade safety and the Salesforce security review, and it is the closest thing in the ecosystem to conventional product engineering. Admin-plus-developer hybrid roles, common in companies with one Salesforce person, want someone who will also run user administration, reports, data loads and a support queue. Those jobs are an excellent place to learn and a hard place to stay a developer, because support demand expands to fill the week. Ask directly in the interview what share of the week is support, and ask for a number.

Decide which of these you are applying for before you write a line of your resume, then build the resume for that one. A core platform resume that opens with Marketing Cloud terminology reads as unfocused to both audiences, and a claim across all four reads as a claim of depth in none.

• Core platform: Apex, LWC, SOQL, triggers, async, Flow. Gated by Platform Developer I.
• Integration: Bulk API 2.0, Platform Events, Change Data Capture, Named Credentials, OAuth, middleware, an external system named in the posting.
• Industries and OmniStudio: OmniScripts, FlexCards, Integration Procedures, data mappers. Thin supply, better rates, its own certification.
• Marketing Cloud Engagement: AMPscript, Server-Side JavaScript, SQL activities, data extensions. A different product, not a flavour of Apex.
• Newer core-platform marketing editions use Flow, Data Cloud and standard tooling, so read the requirements rather than the product name.
• ISV and product: managed packages, namespaces, upgrade safety, AppExchange security review.
• Admin plus developer hybrid: good learning, hard to stay technical. Ask what percentage of the week is support.

The certifications that actually matter, in what order, and when to stop

Salesforce is a certification-dense ecosystem and that produces a specific failure mode: candidates with eight credentials and no production access. The credentials are worth collecting in a particular order and then stopping, because past the second or third one the marginal interview you win from another exam is close to zero and the time is better spent shipping.

Platform Developer I is first and it is close to mandatory. Not because it proves you can build (it does not) but because it is the filter. Agency recruiters screen on it, implementation partners want certified headcount for their standing in the partner programme, and it is the one line on your resume anyone can verify in seconds on the public credential page. The exam covers the declarative model as well as code, which catches people out: a meaningful share of the questions are about what you should configure rather than program, about the data model, and about the order of execution. Build in a free Developer Edition org while you study. People who study only from question dumps pass and then fail the first technical screen, and the gap shows within a few follow-up questions.

The Salesforce Certified Administrator credential is the most underrated thing a developer can hold. It tells a hiring manager you know what the platform already does, which is exactly their worry when they interview a developer from a Java background. Teams have paid for a lot of custom Apex that a validation rule, a record-triggered Flow or a roll-up summary would have handled, and the manager reading your resume has probably inherited some of it. Platform App Builder makes a similar point and is the better choice if the roles you want sit close to the business.

Salesforce Certified JavaScript Developer I is the credential that changes how a resume reads. Half of it is a plain JavaScript exam with no Salesforce content, which is why it carries weight: it is evidence you understand asynchronous behaviour, scope, prototypes, modules and testing rather than evidence you followed an LWC tutorial. The other half is the Lightning Web Components Specialist superbadge, which is real work in a real org. Platform Developer II is the recognised senior credential and has historically paired an exam with superbadge work; look up the current requirements on the official credential page rather than trusting an article, because the structure has changed before.

Superbadges carry more weight than badges, and the gap is wide. A hiring manager who knows the platform knows that Apex Specialist, Advanced Apex Specialist, Lightning Web Components Specialist and Data Integration Specialist require working code in an org that gets validated against challenges, while a badge count can be farmed. Listing a Ranger rank and a four-figure badge count tells an experienced reader very little. Listing four named superbadges tells them you have written Apex that ran.

After those, let certifications follow the work rather than lead it. Sales Cloud or Service Cloud Consultant if you sit on implementation projects, Experience Cloud Consultant if you build portals or LWR sites, OmniStudio Developer for industries work, a CPQ or revenue credential if you land in that tooling, Data Cloud and the Agentforce-badged AI credentials if you move toward that work. Salesforce has renamed its AI credential line more than once (an AI Associate exam, then an AI Specialist exam, now badged around Agentforce), so find the current one in the official credential catalogue instead of chasing a name from a blog post.

Two mechanical points that cost people real opportunities. First, maintenance: a credential you let lapse shows as suspended on the public verification page, which is worse than never having held it, and the module that prevents it is free. Second, verifiability: anyone can check your credentials in seconds, so never round up. Write Platform Developer I, in progress if that is the truth. Overstating a Salesforce certification is one of the few resume lies in this market that gets caught before the interview rather than after.

• Order that works: Platform Developer I, then Administrator or Platform App Builder, then JavaScript Developer I, then stop and ship something.
• Study in a free Developer Edition org or a Trailhead Playground, not from question dumps. The technical screen catches dump-only candidates quickly.
• Name superbadges individually on the resume: Apex Specialist, Advanced Apex Specialist, Lightning Web Components Specialist, Data Integration Specialist.
• Drop the badge count and the Ranger rank from the resume body. They read as activity, not capability.
• Do the free maintenance module when the reminder arrives. A suspended credential is public and looks careless.
• Verify the current exam code, fee, question count and pass mark on the official exam guide before booking anything.
• Let later certifications follow the work you are already doing, not the work you hope to be given.

Where Salesforce developer demand actually sits in 2026-27, and how people actually get in

The honest shape of this market: large, mature, and no longer easy to enter cold. The window where a certification and a pile of Trailhead badges got a beginner a Salesforce job has closed. What replaced it is steady senior and mid-level demand, thin and competitive junior demand, and a decisive advantage for anyone already inside a company that runs Salesforce.

The work being funded is mostly not greenfield. It is consolidation and remediation of estates built fast over the preceding decade, which in practice means several migration programmes running across the ecosystem at once: Workflow Rules and Process Builder onto Flow, Aura components to Lightning Web Components, Classic habits and Visualforce pages to Lightning, and permissions off profiles and onto permission sets and permission set groups. Salesforce has blocked the creation of new Workflow Rules and Process Builders and has published retirement intentions whose dates have moved more than once, so check the current official retirement notice rather than quoting a month to an interviewer. For a job seeker the date is not the point. The point is that migration work is real, paid, unglamorous and an excellent place to build evidence.

The work carrying new budget is Data Cloud and Agentforce, plus the integration work underneath both. Be clear-eyed about what that means day to day: a large share of Agentforce projects are data projects with an agent at the end, and the developer hours go into data model, ingestion, identity resolution, grounding queries, permissions and testing rather than into anything resembling machine learning. That is good news for a Salesforce developer, because it is mostly the job you already do.

Revenue tooling is in transition. Salesforce has been steering new customers toward Revenue Cloud Advanced while an enormous installed base of Salesforce CPQ keeps running, which makes CPQ a maintenance and migration market rather than a dying one. Confirm the current product status before you build a specialism on it, and do not assume CPQ experience has stopped being valuable: large estates do not disappear on a vendor's slide schedule.

Who employs the volume matters as much as what the work is. Implementation partners and consultancies hire the most Salesforce developers, hire them continuously, weight the certification heavily, and will put you in front of clients early. End customers hire fewer in-house developers, pay less attention to certificates, interview harder on depth and judgement, and offer a calmer week. The contract market runs through staffing agencies, pays a premium, and demands that you be productive in an unfamiliar org almost immediately. Each of those is a different application strategy, and a partner is by a wide margin the easiest door for someone with less than two years of experience.

What has genuinely got harder is the bottom rung. Straightforward configuration work is both offshored and increasingly automated, remote hiring has made every junior posting a global competition, and few teams are funding a junior to learn on a client's project. The counterintuitive conclusion is that the fastest route in for most people is not a Salesforce developer job at all. It is a Salesforce-adjacent job at a company that runs Salesforce, followed by a sideways move.

That sideways move has a reliable shape and it is worth following deliberately rather than hoping. Get hired as an administrator, business analyst, support or QA person on a Salesforce team, or as a developer anywhere inside a company that runs Salesforce. Then volunteer for the three things nobody else wants: the Flow migration backlog, the integration that keeps failing overnight, and the deployment process. Within a year you have production code, a release pipeline and an integration story, which is the exact content of a Salesforce developer interview. People who do this get the title at their own employer or clear a partner interview easily. People who apply cold from outside with a certification and tutorial projects mostly do not.

• Funded work in 2026-27 skews to migration and remediation: automation onto Flow, Aura to LWC, Visualforce and Classic to Lightning, profiles to permission sets.
• New budget sits with Data Cloud, Agentforce and the integration work underneath. Most of the developer effort there is data and permissions work, not modelling.
• Salesforce CPQ estates are a maintenance and migration market as new customers are steered to Revenue Cloud Advanced. Check current product status before specialising.
• Implementation partners hire the most developers and weight Platform Developer I most heavily. They are the easiest door under two years of experience.
• End customers hire fewer in-house developers, interview deeper, and care more about what you shipped than what you passed.
• Contract work pays a premium through agencies and expects productivity in an unfamiliar org in week one.
• The reliable entry route is sideways: admin, analyst, QA, support or general developer at a company that runs Salesforce, then claim the Flow migration, the broken integration and the deployment pipeline.
• Do not plan on a cold junior Salesforce developer hire. Plan on being the internal candidate.

The Apex work to show, and the Apex that gets you failed

Apex is Java-like enough that experienced developers underestimate it, and it is the multi-tenant constraints that fail them. Every technical screen in this ecosystem probes the same small set of things, because those are the things that break production orgs. Knowing them cold is most of the technical round.

Governor limits first, as actual numbers rather than as a concept. One hundred SOQL queries in a synchronous transaction and two hundred asynchronously, fifty thousand records retrieved by SOQL, one hundred and fifty DML statements, ten thousand records processed by DML, ten seconds of CPU time synchronously and sixty asynchronously, six megabytes of heap synchronously and twelve asynchronously, and one hundred callouts in a transaction with a cumulative timeout budget. Candidates who recite the limits but cannot say what they do about them are only halfway. The answers that land are specific: queries and DML hoisted out of loops, maps built by key instead of nested iteration, selective SOQL filtered on indexed fields, aggregate queries instead of pulling rows to count them, and work pushed into Batch Apex or Queueable when the volume cannot fit a single transaction.

Bulkification is the single most common reason a take-home exercise is rejected. A trigger receives up to two hundred records per invocation and your code has to handle all of them with the same number of queries it would use for one. Write the query once with an IN clause over a set of identifiers, build a map, loop over the map in memory, collect the records you intend to change into a list, and issue one DML statement at the end. Interviewers show candidates a trigger with a SOQL query inside a for loop specifically to see whether they spot it unprompted. Spotting it without being asked is a strong signal; missing it is usually fatal.

Trigger discipline is the next layer. One trigger per object, no logic in the trigger body, a handler class with explicit methods for each context, a dispatch pattern that is consistent across the org, and deliberate recursion control because an update inside a trigger can fire that trigger again. You should be able to walk the order of execution out loud: before-save record-triggered Flows, before triggers, system validation, the save to the database that is not yet committed, after triggers, assignment and auto-response rules, workflow-era automation, after-save record-triggered Flows, escalation rules, roll-up summary recalculation with parent and grandparent recalculation, criteria-based sharing, then commit, then post-commit work such as email and queued asynchronous jobs. The reason this question is asked constantly is that nearly every mysterious production bug in a mature org lives somewhere in that list.

Asynchronous Apex is where mid-level candidates separate from juniors, and the separator is choosing rather than knowing. Future methods are the oldest and weakest option: fire and forget, no chaining, no return value, and not callable from a future or batch context. Queueable gives you a job identifier, chaining, typed member variables and callout support, and is the modern default for deferred work. Batch Apex is for volumes that need processing in chunks with a configurable scope and optional state across executions. Schedulable is for cadence. Platform Events are for decoupling and for cases where a callout has to happen after a commit. Transaction Finalizers let you attach follow-up logic to a Queueable that failed, which is the kind of detail that signals you have operated this code rather than only written it.

Security is where competent developers most often lose an interview, because Apex runs in system context by default and will happily ignore the sharing rules and field permissions the business spent months designing. Know the difference between with sharing, without sharing and inherited sharing, and why inherited sharing is the right default for a class that may be called from several places. Know that modern Apex can run database operations in user mode (AccessLevel.USER_MODE on Database methods, WITH USER_MODE on SOQL), which largely replaces the old hand-written checks against object and field describe results, and know Security.stripInaccessible for filtering what you are about to write or return. If you have been through an AppExchange security review, say so, because that review is the strictest enforcement of these rules anywhere in the ecosystem.

Large data volumes are a senior topic that a junior can learn cheaply and then stand out with. A SOQL filter that is not selective against a large object throws an error rather than running slowly, and the row threshold where that bites is low enough that real orgs hit it constantly. Be able to talk about the Query Plan tool, custom indexes and skinny tables as things requested through Salesforce support rather than toggled yourself, record ownership skew and why tens of thousands of records owned by one integration user slows everything around them, Big Objects for archive, and chunking strategies in Batch Apex. Very few candidates raise ownership skew unprompted, and the ones who do get remembered.

Finally, tests. Salesforce blocks a production deployment below seventy-five percent org-wide coverage and requires triggers to have coverage, and that rule has produced an entire genre of worthless test: a loop that inserts records, no assertions, coverage satisfied. Say out loud that coverage is a deployment gate and not a quality measure. Then show the real practice: a test data factory, no reliance on org data, positive and negative cases, a bulk case at two hundred records, assertions on outcomes with messages, Test.startTest and Test.stopTest around the behaviour under test, mocked callouts through HttpCalloutMock and Test.setMock, System.runAs for permission scenarios, and custom metadata or custom settings instead of hard-coded identifiers so the tests pass in every org. That paragraph, delivered concretely, is worth more in an interview than any certification you hold.

• Recite limits with remedies attached: 100 SOQL sync and 200 async, 50,000 rows queried, 150 DML statements, 10,000 rows DML'd, 10 seconds CPU sync and 60 async, 6 MB heap sync and 12 MB async, 100 callouts.
• Bulkify for 200 records: one query with an IN clause, a map keyed for lookup, in-memory iteration, one DML at the end.
• One trigger per object, logic in a handler class, explicit recursion control, and the order of execution walkable out loud including before-save and after-save Flows.
• Choose async deliberately: Queueable as the modern default, Batch for volume, Schedulable for cadence, Platform Events for decoupling and post-commit callouts, Finalizers for failure handling.
• Default to inherited sharing, run database operations in user mode, and use Security.stripInaccessible rather than hand-rolled permission checks.
• Know the large-volume vocabulary: non-selective query errors, Query Plan, custom indexes and skinny tables through support, ownership skew, Big Objects.
• Say that 75 percent coverage is a deployment gate, not a quality bar, then describe assertions, bulk tests, mocked callouts and a test data factory.
• No hard-coded record type, queue or profile identifiers. Custom metadata types or custom settings, every time.

The Lightning Web Component work to show, and when not to build one

Lightning Web Components is where developers with a front-end background have an advantage and where platform-only developers quietly struggle. LWC is standard web components with a thin platform layer, so the fundamentals are plain JavaScript: modules, classes, template rendering, events, asynchronous behaviour and testing. That is exactly why JavaScript Developer I is a credential hiring managers respect.

The strongest thing you can demonstrate is restraint. The best answer to most LWC requirements is a standard component or a Lightning record form, configured rather than coded. A developer who builds a custom edit screen with hand-rolled field markup has just signed up to maintain field-level security, layout changes, validation messages, accessibility and mobile rendering that the platform would have handled. Interviewers at end customers ask this on purpose: given a requirement to show and edit a few fields, what would you build. The answer that passes starts with the record form and reaches for a custom component only where behaviour genuinely needs it.

Data access is the next discriminator. Know when to use Lightning Data Service and the UI API through wire adapters such as getRecord (cached, shared across components, respects field-level security without you writing anything) versus wired Apex versus imperative Apex. The rule of thumb that holds up: Lightning Data Service for single-record reads and writes, wired Apex for reactive lists and anything needing a query, imperative Apex for anything with a side effect or triggered by a user action. Be able to say why a wired Apex method needs the cacheable annotation and what that implies about refreshing data, because stale caches cause a large share of real LWC bugs. Know refreshApex for wired Apex, and notifyRecordUpdateAvailable for telling Lightning Data Service a record changed underneath it; getRecordNotifyChange is the deprecated predecessor, and naming the current one correctly is a small signal that you have written LWC recently.

Component composition and communication come up in every front-end round. Parent to child through public properties and public methods, child to parent through CustomEvent, unrelated components through Lightning Message Service, which is also the bridge to Aura and Visualforce in orgs that still have them. Know that events do not cross the shadow boundary unless you configure them to, and know why you should think twice before you do. Know that Lightning Web Security replaced Locker Service for LWC and what that changed about using third-party JavaScript libraries, because someone will eventually ask you to put a charting library on a record page.

Testing is the fastest way to look senior, because so few candidates do it. Jest through the Salesforce LWC Jest tooling, with wire adapters mocked, Apex calls mocked, assertions against rendered output rather than internals, and the tests running in continuous integration. A repository with real Jest tests reads as professional in a way no amount of resume prose achieves. Add ESLint with the Salesforce LWC configuration and Prettier with the Apex plugin, and your repository looks like a team's rather than a tutorial's.

Two things get a component rejected in production and candidates forget both in interviews: accessibility and performance. Salesforce customers include large public-sector and regulated organisations with real accessibility obligations, so labels on inputs, keyboard operability, focus management, sensible heading structure and not conveying meaning by colour alone are requirements rather than refinements. Build with the base Lightning components and SLDS and most of that comes free. On performance, understand that a record page with a dozen components each issuing its own query is slow for reasons you control: avoid a query per rendered row, lean on Lightning Data Service caching, lazy-load what is not visible, and keep the component tree shallow.

Know the legacy landscape honestly, because you will work in it. Aura components are not where new work goes but they are present in thousands of orgs, and Aura-to-LWC migration is live paid work right now. Visualforce still drives plenty of print and PDF output and a lot of pages nobody is funding a rewrite for. Experience Cloud sites are their own skill: the LWR runtime, guest user permissions, which are a recurring source of real security incidents, and theming. If the posting mentions a portal or a community, read it as Experience Cloud and expect questions about guest access.

• Default to standard components and Lightning record forms; build a custom component only where behaviour requires it, and be able to say why.
• Lightning Data Service for single-record reads and writes, wired Apex for reactive lists, imperative Apex for actions with side effects.
• Know cacheable Apex, refreshApex and notifyRecordUpdateAvailable (not the deprecated getRecordNotifyChange), because stale data is the most common LWC bug in production.
• Composition: public properties and methods downward, CustomEvent upward, Lightning Message Service across the page and to Aura or Visualforce.
• Lightning Web Security replaced Locker Service for LWC; know what that means for third-party libraries.
• Jest tests with mocked wire adapters and Apex, asserting on rendered output, running in continuous integration.
• Accessibility is a requirement in this customer base: labels, keyboard operability, focus management, heading structure, base components and SLDS.
• Experience Cloud is a distinct skill, and guest user permissions are a real security surface. Expect questions if a portal is mentioned.

Release engineering: what separates a Salesforce developer from a power user

This is the area with the widest gap between what candidates present and what employers need. Plenty of people can write a trigger. Far fewer can get it into production safely, repeatedly, alongside four other people's work, with a way back if it breaks. In 2026 the release pipeline is a first-class interview subject, and a candidate whose only answer is change sets is interviewing for a job that existed five years ago.

The baseline toolchain is the Salesforce CLI, now the sf command set, which replaced the older sfdx executable. Be comfortable authorising an org, retrieving and deploying metadata in source format, running a validation-only deployment with tests, creating and seeding a scratch org from a definition file, and using source tracking. If you have never created a scratch org, do it this week. It is the clearest line between developers who treat the org as a database they log into and developers who treat metadata as source.

Version control is not optional and the structure matters. Source format rather than metadata format, a branching model somebody can explain, pull requests a human reviews, and a destructive changes manifest for deletions, which is the step teams forget until a field that should have gone lingers in production for a year. Delta deployments matter in large orgs because a full deployment running all local tests can take hours, and asking how your prospective team scopes and times a production deployment is a question that signals you have done this.

Packaging is the senior topic here. Unlocked packages let you ship a bounded set of metadata with a version number and declared dependencies, org-dependent unlocked packages exist for orgs too entangled for the clean model, and managed packages are for products distributed through AppExchange with namespaces and upgrade guarantees. Most customer orgs still deploy from a monolithic repository, so even knowing why you would package anything puts you ahead of the field.

Code quality tooling is cheap to add and reads as maturity. Salesforce Code Analyzer and the Apex ruleset in PMD catch SOQL inside loops, missing sharing declarations, unused variables and hard-coded identifiers. ESLint with the Salesforce LWC configuration catches front-end errors. Prettier with the Apex plugin ends formatting arguments. Wire all of that into continuous integration so a pull request fails on its own rather than a reviewer nagging. A candidate who can say I added the Code Analyzer to our pipeline, it flagged this many violations in the first run, and here is what we fixed first is describing an outcome, which is what interviews reward.

Know the sandbox landscape, because it constrains everything. Developer and Developer Pro sandboxes carry metadata only and refresh frequently, Partial Copy carries a sampled dataset on a longer cycle, Full Copy carries everything on a much longer cycle and is the only realistic place to rehearse a data-heavy release or reproduce a performance problem. Sandbox seeding is a genuine engineering problem, and masking or anonymising production data for a sandbox is a privacy obligation rather than a nicety. Have an opinion on how you would do it.

Finally, the release calendar. Salesforce ships three major releases a year, named Spring, Summer and Winter for the following year, so a Winter release lands in the autumn before the year in its name. Developers are expected to read the release notes, test in the sandbox preview window, and know what is deprecated before it breaks something. API version hygiene belongs here too: Salesforce retires old API versions on a published schedule and the version number advances every release, so somebody has to know which versions your integrations and your classes still declare. Being the person who reads the release notes and circulates the three things that affect your org is a cheap reputation to build, and it answers the interview question about how you keep current with something better than blogs and webinars.

• Use the sf CLI: authorise, retrieve, deploy, validate-only with tests, create and seed a scratch org, use source tracking.
• Metadata in Git in source format, reviewed pull requests, and a destructive changes manifest for deletions.
• Know why delta deployments exist and ask in the interview how the team scopes and times a production deployment.
• Understand unlocked, org-dependent unlocked and managed packages, even if your current org deploys a monolith.
• Put Salesforce Code Analyzer or PMD, ESLint and Prettier in continuous integration so pull requests fail on their own.
• Know the sandbox types and what each is for, and treat sandbox seeding and data masking as real engineering.
• Read the release notes every cycle, test in the sandbox preview window, and track which API versions your integrations and classes declare.
• Never answer a pipeline question with change sets alone. Say what you have used, what you would move to, and why.

The resume, the Trailblazer profile, and where to send them

Salesforce resumes have a recognisable failure pattern: a wall of platform nouns, a certification list, a badge count, and no evidence that anything shipped. Recruiters in this ecosystem screen fast and often cannot tell an admin from a developer, so the top third of the page has to do two jobs at once: get past a keyword filter and tell a technical reader almost immediately that you write code.

Open with a two-line summary naming the specialism, the years, the clouds you have actually worked in and the credential. Then a credentials line with the certifications and named superbadges. Then experience. Skills sections belong lower, should be ranked honestly, and should not list every product Salesforce sells. A flat list claiming Sales Cloud, Service Cloud, Experience Cloud, Marketing Cloud, CPQ, Data Cloud and Field Service at equal depth reads as a claim of depth in none, and the interview finds out in three questions.

Describe each role with the context a technical reader needs: the size of the org in users, the scale of the objects that mattered in records, how many developers and admins were on the team, the release cadence, and who the stakeholders were. One hundred users with a million cases is a different job from eight thousand users with ten thousand accounts, and without that context nobody can calibrate a single bullet you write.

Then write the bullets as outcomes with mechanisms, not as a technology inventory. Nobody is impressed by forty Apex classes. Replaced thirty-eight Workflow Rules and six Process Builders with nine record-triggered Flows and one Apex handler, removing a recursion defect that had been corrupting opportunity stage history, is the shape of a sentence that gets a call, with your own counts in place of those. So is cut nightly order synchronisation from four hours to twenty minutes by moving from row-by-row DML to Bulk API 2.0 with a reconciliation report. So is took a portal from a failing accessibility audit to a passing one.

The artefacts that do the most work on a Salesforce developer resume: a named integration with the external system, the API and the pattern (Platform Events outbound, Bulk API 2.0 inbound, JWT bearer authentication through a Named Credential), a migration you completed with a before-and-after count, a large data volume problem you fixed with the mechanism named, a package or pipeline you introduced, and anything that improved deployment safety. Link a public Trailblazer profile, which is verifiable and which hiring managers in this ecosystem genuinely click. Link one repository that is real work rather than a tutorial.

What gets skipped or counted against you: badge counts, Ranger rank in the body, proficient in Salesforce as a skill, a screenshot of a Lightning page, Trailhead projects presented as a portfolio, a soft-skills paragraph, long undifferentiated tool lists, and any claim about a certification you do not currently hold in good standing. Also skip clever formatting. Columns, text boxes and graphics break the parsers agency recruiters run, and in a market where staffing firms handle a large share of Salesforce hiring, a resume that parses badly disappears without anyone deciding to reject it.

Two tailoring notes. For contract applications, lead with the clouds, the integrations and your availability date, because an agency is matching a requirement list and a start date. For a first developer role coming from administration, do not hide the administration: name the Apex, the components and the pipeline work you did while holding an admin title, and put them above the user administration duties. The transition from admin to developer is the most common path into this role and hiring managers read it as normal, provided your bullets prove the code was yours.

Then send it somewhere specific rather than into a job board. Salesforce publishes a consulting partner directory on AppExchange that filters by country, region and specialism, and an evening with it produces a concrete roster of employers near you who hire Salesforce developers continuously. Apply on their own careers pages, because partner recruiters read their own pipeline first and the aggregator copy of the same posting is often stale. Register with the specialist Salesforce agencies as well, including the one that publishes the ecosystem salary survey, because a large share of hiring here and most of the contract market runs through them. One honest conversation with a specialist recruiter tells you more about local rates and which clouds local employers actually run than a month of reading posts.

The part that converts is the community. The Trailblazer Community has local user groups and developer groups that meet regularly, and the people who make hiring decisions at partners and end customers attend them. A ten-minute walkthrough of something you built at a developer group is one of the highest-return hours available to a job seeker in this ecosystem, because it demonstrates what a resume can only assert. TDX is the developer-focused Salesforce conference and Dreamforce is the large one, both with virtual options and recruiting activity around them. Salesforce has also run a Talent Alliance connecting newly certified people with partner employers, and there are long-standing routes into the ecosystem for military veterans and spouses; programmes like these change name and eligibility, so confirm what is currently running on Salesforce's own site before planning around one.

Then apply like someone with evidence. Link the repository, name the org you built in, and say in the first two lines which of the four jobs described earlier you are applying for and what you shipped. A partner recruiter reading fifty applications is looking for a reason to pass one to a technical interviewer, and a link to a package in source format with tests is that reason.

• Two-line summary, then credentials with named superbadges, then experience. Skills lower and honestly ranked.
• Give org context in every role: users, record volumes on the objects that mattered, team size, release cadence.
• Write outcomes with mechanisms and your own real numbers. Replaced thirty-eight Workflow Rules with nine Flows beats wrote Apex and Flows.
• Name integrations with the external system, the API and the authentication pattern.
• Link a public Trailblazer profile and one real repository in source format.
• Cut badge counts, Ranger rank, proficient in Salesforce, tutorial screenshots and soft-skills paragraphs.
• Single column, no text boxes or graphics. Agency parsers lose decorated resumes silently.
• Coming from administration, foreground the code, the components and the pipeline, and keep user administration below them.
• Build a target employer list from the Salesforce consulting partner directory on AppExchange, then apply on each partner's own careers page.
• Register with the specialist Salesforce agencies, including the one that publishes the ecosystem salary survey. They control much of the contract market.
• Join the local Trailblazer Community user group and developer group, and offer a ten-minute talk on something you built.
• Read twenty local postings for your target title and count the requirements. That count decides your second skill and your resume keywords.

How the loop actually runs, and what the technical round really tests

Three employer types run three different processes, and it is worth knowing which one you are in before the first call.

At an implementation partner or consultancy the loop is typically four stages over one to three weeks. An internal recruiter or resourcing manager screens for certifications, years on the platform, which clouds you have shipped, notice period and sometimes willingness to travel to a client site. A developer or technical architect runs the technical screen. There is usually a practical exercise, either a short take-home in a Developer Edition or scratch org or a live pair exercise. Then a practice lead or delivery manager runs a client-facing round, and that round is not a formality: in a consultancy you will be in front of a paying client within weeks, and candidates get rejected for being technically strong and unable to explain a decision to a non-technical stakeholder.

At an end customer the loop is usually a recruiter screen, a hiring manager call about scope and team shape, a technical interview with the platform lead or architect, a practical or code review exercise, and a design or scenario round. Expect a panel that includes an admin or business analyst, and expect them to be testing whether you will respect what the platform already does. This is where the declarative-first question appears most sharply, and where a candidate who proposes Apex for everything loses.

In the contract market the process is often two stages in a week: an agency screen that is mostly matching keywords and your rate, then a single technical interview with the client in which you have to be convincingly productive from a standing start. Contract technical screens are unusually specific because the client has a live problem. Expect to be asked what you would do in your first week in an org you have never seen, and have a real answer: read the object model and the automation inventory, check Setup for the Apex jobs and the Flow trigger inventory, look at the failing jobs and the error logs, find out how deployments happen, and find out who owns the integrations.

The technical screen itself is predictable, which is a gift. The reliably recurring questions are governor limits and what you do about them, how you structure triggers and control recursion, the order of execution, how you choose between Flow and Apex, when to use Future, Queueable, Batch and Platform Events, how sharing and field-level security interact with Apex, what makes a SOQL query selective, how you test and what makes a test worth having, LWC data access and component communication, and how code gets from your machine to production. Prepare one concrete story for each, drawn from work you actually did. Nine prepared answers, each with a mechanism in it, is a passing technical screen.

Two formats deserve specific preparation. The first is the code review, where you are handed thirty lines of bad Apex and asked what is wrong. Have a scan order: query or DML inside a loop, missing bulk handling, hard-coded identifiers, no sharing declaration, no field-level security consideration, swallowed exceptions, no null handling, logic in the trigger body, a test with no assertions. Say what is wrong, then say which one you would fix first and why, because the ranking is the part that shows judgement. The second is the design round, where the question is open: we have five million records and a nightly sync from an ERP, how would you build it. Ask clarifying questions before you start, then answer in a fixed order: volumes and growth, synchronous or asynchronous, the API you would use, error handling and reconciliation, the sharing and visibility consequences, how you would monitor it, and what happens when it fails at 2am. Jumping straight to an answer is the failure mode here, not getting the answer wrong.

Expect behavioural questions with a platform flavour and prepare the real ones: a time you pushed back on a requirement, a time your deployment broke production and what you did, a disagreement with an admin about whether something should be code, and how you handled inheriting an org built badly. That last one is nearly universal now, because so much of the available work is remediation. The answer that lands describes what you measured first, not what you rewrote.

Ask questions that reveal the job, and treat them as evidence rather than politeness. How do deployments work and how long does a release take. How many Apex classes and triggers are in the org, and how many Flows. What is the test coverage and how much of it asserts anything. Which integrations exist and which one breaks most often. Who decides Flow versus Apex. Is there an architect, and who approves a data model change. How much of the week is support and how much is build. If it is a consultancy, how many clients at once and how is utilisation measured. A candidate who asks about the Flow trigger inventory has clearly worked in a real org.

• Partner loop: recruiter screen, technical screen with a developer or architect, practical exercise, client-facing round. The client-facing round rejects strong coders.
• End customer loop: recruiter, hiring manager, technical with the platform lead, practical or code review, design round, usually with an admin on the panel.
• Contract loop: agency keyword and rate screen, then one client technical interview expecting week-one productivity.
• Prepare nine answers: limits, trigger structure, order of execution, Flow versus Apex, async choice, security and sharing, SOQL selectivity, testing, deployment.
• For the bad-code review, use a fixed scan order and then rank the fixes. The ranking is what shows judgement.
• For the design round, ask about volumes first, then answer in order: sync or async, API choice, error handling, visibility, monitoring, failure at 2am.
• Have a real answer for inheriting a badly built org, and lead with what you measured rather than what you rewrote.
• Ask about release time, the Flow and Apex inventory, real coverage, the flakiest integration, and who decides Flow versus Apex.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Salesforce Developer
• Salesforce development
• Apex
• Apex triggers
• Apex classes
• Trigger handler framework
• Bulkification
• Governor limits
• SOQL
• SOSL
• SOQL selectivity
• Query Plan tool
• Aggregate queries
• DML
• Lightning Web Components
• LWC
• Lightning Data Service
• UI API
• Wire adapters
• Imperative Apex
• Cacheable Apex
• refreshApex
• notifyRecordUpdateAvailable
• CustomEvent
• Lightning Message Service
• Lightning Web Security
• Shadow DOM
• Jest
• sfdx-lwc-jest
• ESLint
• Prettier
• Salesforce Lightning Design System
• SLDS
• Base Lightning components
• Aura components
• Visualforce
• Lightning Experience
• Experience Cloud
• LWR site
• Guest user access
• Accessibility
• Flow
• Record-triggered Flow
• Before-save Flow
• Screen Flow
• Flow Trigger Explorer
• Invocable Apex
• InvocableMethod
• Process Builder migration
• Workflow Rules migration
• Migrate to Flow
• Validation rules
• Custom metadata types
• Custom settings
• Permission sets
• Permission set groups
• Sharing model
• With sharing
• Without sharing
• Inherited sharing
• User mode Apex
• AccessLevel.USER_MODE
• WITH USER_MODE
• Security.stripInaccessible
• Field-level security
• CRUD and FLS
• Record ownership skew
• Large data volumes
• Skinny tables
• Custom indexes
• Big Objects
• Asynchronous Apex
• Queueable Apex
• Batch Apex
• Database.Batchable
• Schedulable Apex
• Future methods
• Transaction Finalizer
• Platform Cache
• Platform Events
• Change Data Capture
• Pub/Sub API
• REST API
• SOAP API
• Bulk API 2.0
• Composite API
• Apex REST
• Apex callouts
• HttpCalloutMock
• Test.setMock
• Named Credentials
• External Credentials
• OAuth 2.0
• JWT bearer flow
• Connected App
• External Services
• OpenAPI
• Salesforce Connect
• External objects
• MuleSoft
• Middleware integration
• Idempotency
• Error reconciliation
• Apex unit tests
• Test data factory
• Test.startTest
• System.runAs
• Code coverage 75 percent
• Salesforce CLI
• sf CLI
• Salesforce DX
• Scratch org
• Source tracking
• Source format
• Metadata API
• Unlocked package
• Org-dependent unlocked package
• Managed package
• Second-generation packaging
• Namespace
• Change sets
• Delta deployment
• destructiveChanges.xml
• Validation-only deployment
• DevOps Center
• Gearset
• Copado
• Flosum
• AutoRABIT
• GitHub Actions
• Continuous integration
• Salesforce Code Analyzer
• PMD Apex ruleset
• Developer sandbox
• Partial Copy sandbox
• Full Copy sandbox
• Sandbox seeding
• Data masking
• Release notes
• Sandbox preview
• API version
• Order of execution
• Recursion control
• Data model
• Record types
• Roll-up summary
• Agentforce
• Agent Builder
• Agent actions
• Agent topics
• Agentforce testing
• Prompt Builder
• Prompt templates
• Grounding
• Einstein Trust Layer
• Data Cloud
• Data streams
• Data lake objects
• Data model objects
• Identity resolution
• Calculated insights
• Zero copy
• Agentforce for Developers
• Code Builder
• Visual Studio Code
• Salesforce Certified Platform Developer I
• Platform Developer II
• JavaScript Developer I
• Salesforce Certified Administrator
• Platform App Builder
• OmniStudio Developer
• Superbadge
• Apex Specialist
• Advanced Apex Specialist
• Lightning Web Components Specialist
• Data Integration Specialist
• Trailhead
• Trailblazer profile
• Trailblazer Community
• OmniStudio
• OmniScript
• FlexCards
• Integration Procedures
• DataRaptor
• Salesforce CPQ
• Revenue Cloud Advanced
• Sales Cloud
• Service Cloud
• Field Service
• Health Cloud
• Financial Services Cloud
• Public Sector Solutions
• Marketing Cloud Engagement
• AMPscript
• Server-Side JavaScript
• AppExchange security review
• ISV
• Git
• Pull request
• Agile delivery
• Scrum
• Technical debt remediation

Mistakes that cost people this job

Questions people ask