Salesforce developer screening questions: Apex, Lightning Web Components, governor limits, Summer '26 security and certifications

Salesforce developer screening questions should establish what the candidate has built in code on the platform (Apex classes and triggers, Lightning Web Components, integrations and asynchronous jobs) and whether they work comfortably inside the platform's rules: governor limits, the 75 percent test coverage needed to deploy, sharing and field-level security, and the Spring, Summer and Winter releases. As of November 2026, Salesforce's Summer '26 release made Apex database operations in API version 67.0 run in user mode by default and turned WITH SECURITY_ENFORCED into a compiler error, so a developer who is current can tell you what that changed in their org. Platform Developer and Platform Developer II are common, verifiable certifications, but they show exam knowledge, not code in production.

If the role is mostly configuration, Flow and user support, use the Salesforce administrator screening questions, which cover org scope, Flow, permissions, data loads and the administrator credential. This page is for the person who writes code. For contract developers, add the terms and conversion questions in IT contractor screening questions.

Which Salesforce developer job is it?

Ask the hiring manager which clouds the org runs, how changes are deployed (Salesforce CLI and source control, DevOps Center, change sets), the share of work that is code versus configuration, and which certifications the client or partner agreement actually requires.

Which certifications and platform rules should you check?

• Platform Developer. The exam guide describes 60 scored questions plus up to five unscored, 105 minutes and a 68 percent passing score, for a candidate who generally has one to two years of developer experience and at least six months on the Lightning Platform. It is a prerequisite for Platform Developer II.
• Platform Developer II. The exam guide describes 60 scored questions, 120 minutes and a 70 percent passing score, for a candidate with two to four years of developer experience, including at least one year of hands-on design and deployment on the platform. LWC-heavy roles sometimes add the JavaScript Developer credential.
• Maintenance and verification. Salesforce's maintenance article says every certification needs one maintenance badge a year, and missed badges make the certifications they maintain expire. Check status on Trailhead's credential verification page.
• Governor limits. Salesforce's help article on the "Too many SOQL queries: 101" error says SOQL is capped at 100 queries per transaction context, that Salesforce cannot raise the limit, and that the fix is to bulkify code and move queries out of loops.
• Test coverage. The help article on Apex unit testing says at least 75 percent of Apex must be covered by unit tests to deploy to production, and every trigger needs at least one line of coverage.
• Summer '26 security defaults. Salesforce's Summer '26 architect highlights (June 8, 2026) say that in API version 67.0 database operations run in user mode by default, classes without an explicit sharing declaration default to with sharing, WITH SECURITY_ENFORCED becomes a compiler error, and triggers still always run in system mode.

Knockout questions

Apex, limits and security questions

1. "Tell me about a trigger you wrote. How did you make sure it worked when thousands of records were loaded at once?"
   • Strong answer: one trigger per object calling a handler class, collections and maps instead of per-record queries, one query outside the loop, recursion control, and a test that inserts records in bulk.
   • Red flags: a query or DML statement inside a loop, or "it worked when I tested one record."
2. "When did you hit a governor limit, and what did you change?"
   • Strong answer: names the limit (SOQL queries, CPU time, heap size), what caused it (often a data load firing automation) and the fix: bulkified code, selective queries, moving work to Queueable or Batch Apex.
   • Red flags: has never hit one, in a large org, or asks Salesforce to raise it.
3. "How do you choose between Flow, synchronous Apex and asynchronous Apex?"
   • Strong answer: a reasoned line based on volume, complexity, callouts and who will maintain it, with an example of each, including when they chose a Flow over code.
   • Red flags: everything in triggers, or no view on when admins should own the logic.
4. "How do your classes enforce sharing and field-level security, and what did the Summer '26 change mean for your code?"
   • Strong answer: declares with sharing or inherited sharing deliberately, uses WITH USER_MODE or user-mode DML, tests as a non-admin user, and knows that API version 67.0 changed the defaults and removed WITH SECURITY_ENFORCED.
   • Red flags: without sharing everywhere "because it is easier," or has never heard of field-level security.
5. "Tell me about an integration you built. What happened when the other system was down?"
   • Strong answer: named credentials instead of stored passwords, callouts from an asynchronous context, retries and logging, events or Change Data Capture where they fit, and a real outage story.
   • Red flags: credentials hard-coded in Apex or custom settings.
6. "Walk me through a Lightning Web Component you built."
   • Strong answer: what it did for users, how it got data (wire adapters, Lightning Data Service or Apex), error and empty states, Jest tests, and keyboard and screen reader checks.
   • Red flags: only Visualforce or Aura, for a role built on LWC, without saying so.

Testing, deployment and release questions

How does Salesforce developer experience get overstated?

• Admin with some Apex. Edited a few lines of existing code. Ask what they wrote from scratch.
• The certification stack. Many credentials in a short time with little work history. Ask for one production change per certification the client cares about.
• Partner work as ownership. "Built the integration" when a partner did. Ask what they owned after go-live.
• An installed package as an integration. Ask who wrote the code that moved the data.
• Coverage as quality. "95 percent coverage" with tests that assert nothing. Ask what a failing test caught.
• One component as LWC experience. Ask how many components they built and who used them.

A 15-minute phone-screen flow

1. Minutes 0 to 2: the org, clouds, deployment method and the code versus configuration split.
2. Minutes 2 to 5: knockouts 1 to 5, and note certifications to verify after the call.
3. Minutes 5 to 10: the bulk trigger question and the governor limit story. Write down limits, volumes and fixes in their words.
4. Minutes 10 to 13: the sharing and security question and one integration or LWC question.
5. Minutes 13 to 15: rate or salary expectations (see salary expectation questions), notice and next steps.

Scoring

What to put in the submittal

Salesforce developer: [name]
Code vs configuration, last 2 years: [e.g. 70/30]
Clouds coded for: [Sales / Service / Experience / industry cloud / other]
Apex: [triggers, batch, queueable], governor limit story [one line]
Security: [sharing approach, user mode, API version of current code]
LWC: [components built, who used them], Jest tests [yes or no]
Integrations: [systems, direction, named credentials, failure handling]
Deployment: [CLI and source control / DevOps Center / change sets]
Certifications: [names], verified on Trailhead [date]
Candidate's own gap: [e.g. "no managed packages; little LWC testing"]

Lawful phrasing

Ask about clouds, code and certifications, not about age, graduation year or how "fresh" someone's skills feel; see the age discrimination guide. Ask the sponsorship question the same way of every candidate and do not ask about citizenship or national origin. If you use a coding exercise, give everyone the same one, tell them how it is scored and offer accommodations on request. If you are not a developer yourself, how to interview for technical roles as a non-technical recruiter covers follow-ups for answers you cannot judge, and illegal interview questions lists what to avoid. This page is not legal advice.