Salesforce developer screening questions for recruiters

Salesforce resume lines are easy to inflate, so the first screen should confirm that the candidate writes Apex code that holds up under real data volumes and knows when a Flow would do the job without code. Plan on about 20 minutes, with a follow-up question on every example, because a conversation about a real org is much harder to fake.

What does a Salesforce developer do?

Salesforce is the customer relationship management (CRM) platform many companies use for customer records, sales deals and support cases. A Salesforce developer writes custom code on top of it, mostly in Apex (Salesforce's own programming language, similar to Java) and Lightning Web Components (the JavaScript framework for the screens users see), and connects Salesforce to other systems. The Bureau of Labor Statistics has no Salesforce-specific page; its software developers page describes the general job as designing "computer applications or programs."

Which skills should you check at each level?

Ask which Salesforce products the client uses (for example Sales Cloud, Service Cloud or Experience Cloud). Experience in one doesn't always carry over.

What screening questions should you ask a Salesforce developer?

Where you know the client's objects and integrations, use them in the wording.

Tell me about the last trigger you wrote. What did it do, and how did it handle a large data load?

Salesforce limits how many database queries and record changes a single transaction can make (these are called governor limits), and code that ignores them tends to fail the first time a big batch of records arrives.

Strong answer: talks about "bulkifying" the trigger: handling records as a list, with no queries or updates inside a loop, and one trigger per object that calls a handler class. They mention a data load or integration that sent thousands of records at once.

Weak answer: describes the trigger's logic for one record and has no answer when you ask what happens if 10,000 arrive together.

When would you build something in Flow instead of Apex?

Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025 and points customers to Flow, so many teams are deciding what lives in Flow and what lives in code.

Strong answer: Flow for straightforward record updates, approvals and guided screens; Apex for complex logic, heavy volumes or careful error handling. They mention who maintains it afterward, since admins can edit Flows.

Weak answer: "Flow is for admins, I always code," or the opposite, with no reasoning.

How do you test your Apex code?

Every Salesforce developer writes test classes. You want to know whether they test behavior or only chase a coverage number.

Strong answer: tests create their own data, check results with assertions, cover bulk and failure cases, and fake outside calls (mocking) instead of calling real systems.

Weak answer: writes tests that run the lines so coverage passes, without checking any result.

Tell me about an integration between Salesforce and another system you built.

Strong answer: names the other system, which way the data moved, REST or SOAP, how login credentials were stored, and how failures and retries worked.

Weak answer: "I used an API," with nothing on authentication or errors.

Your Apex code shows a user records or fields they shouldn't see. What went wrong?

Apex can run with more access than the user who triggered it, so this checks whether the candidate thinks about security in code.

Strong answer: the code ran in system mode, for example in a class marked without sharing, so it ignored what the user is allowed to see. They declare classes with sharing unless there's a reason not to, enforce field and object permissions (for example with user-mode queries or Security.stripInaccessible), and test as a normal user with System.runAs.

Weak answer: assumes Salesforce applies the user's permissions to Apex automatically.

How do you move changes from a sandbox to production?

Strong answer: describes source control with Git and the Salesforce CLI or a release tool, testing in a sandbox with realistic data, and a plan for rolling back. In smaller orgs, using change sets with a clear checklist is a reasonable answer.

Weak answer: makes changes directly in production.

Tell me about a time you pushed back on a requirement because of what it would do to the org.

This one is for senior candidates.

Strong answer: a specific trade-off, such as performance, record locking or a messy data model, what they proposed instead and how it turned out.

Weak answer: has never pushed back on anything.

What red flags should you note?

• Claims years of Apex but can't explain governor limits.
• Their example code puts queries or record updates inside a loop.
• Every example is point-and-click configuration for a role that needs Apex. That may be an admin applying for a developer job.
• Can't name which Salesforce products or which org size they worked in.
• Lists certifications you can't confirm. Trailhead lists the developer credential as Salesforce Certified Platform Developer, and Salesforce has a page to verify certifications.

None of these is a verdict on its own. Write it down and ask about it, and read how to spot a proxy interview if you think a different person is answering.

How do you run this screen with Simplehire?

Create the role with the skills the client confirmed as its required skills, for example Apex, Lightning Web Components, SOQL, Flow and REST integrations. The candidate follows the interview link and talks with our AI interviewer in the browser, and the screening report comes to you before anything goes to the client.

Use Basic ($2 per screen, about 15 minutes) for junior first screens. Use Adaptive ($3, about 20 minutes) for most client submissions: it adds follow-up questions on the candidate's answers and a per-answer AI assessment, which is where a rehearsed trigger story gets tested. Use Advanced ($5, about 30 minutes) for senior or architect-level roles. It goes deeper on strong answers and adds an optional coding round, scored separately, if the client wants to see code.

The report opens with a verdict, then Skills demonstrated X/Y and the Areas to probe in your own call. You can accept or overrule the verdict. Like every screen, it runs with proctoring: enforced full-screen mode, flagged or restricted copy and paste, and timestamped tab switches. You can add an ID check for remote contractors.

No credit card is needed for the 25 free Basic screens each month; pricing has the details. For related roles, see the Salesforce administrator, ServiceNow developer and Java developer questions.