Questions to Ask in a Salesforce Administrator Interview

The questions

Open any question to see why it works.

1. 1

   Walk me through the org you administer today: how many users, how many custom objects, how old is it?

   This one question sets the scale for every answer that follows. Running a 60-user org built last year and a 4,000-user org with fifteen years of accumulated fields are different jobs, and a candidate who cannot give rough numbers has probably worked tickets in the org rather than owned it.

2. 2

   Which clouds and editions have you worked in?

   Sales Cloud, Service Cloud, Experience Cloud and the industry clouds share a platform and very little else day to day. Edition matters too, since features a candidate relies on may simply not exist in what you have licensed, and finding that out in week two is expensive.

3. 3

   What is the last thing you built that people actually use every day?

   Administrators accumulate a graveyard of unused fields and dashboards, so adoption is the honest measure. Listen for how they know it is used: a report on usage, a request to extend it, or just an assumption.

4. 4

   How do you decide between a validation rule, a flow, and asking a developer for code?

   You are testing judgment about maintainability, not trivia. A strong answer mentions who will support it after they leave, order of execution, bulk behaviour and limits. A weak answer is a preference stated with no conditions attached.

5. 5

   Tell me about a flow that broke in production. What happened and how did you find out?

   Everyone has one. What matters is the detection path: whether they heard about it from error emails they had configured, from a monitoring habit, or from an angry sales director three days later. That path is the same one they will use in your org.

6. 6

   How do you handle a request that is easy to build but a bad idea?

   Administrators who say yes to everything are how orgs end up with 300 fields on one object. Ask for a specific instance where they pushed back, what they proposed instead, and whether the requester ended up satisfied, because refusing without offering an alternative is its own failure mode.

7. 7

   You inherit an org where half the users are on modified profiles. How do you get to a clean permission model?

   This is the most common real-world mess and the answer shows whether they have actually done it. Look for sequencing: audit what is in use, move to permission sets and groups gradually, verify with a login as, and keep a rollback. Anyone proposing a rebuild in one weekend has not lived through it.

8. 8

   Walk me through how a change gets from your sandbox to production.

   You are listening for a repeatable process rather than a tool name. Ask which sandbox types they use, whether anyone reviews before deployment, how they handle configuration that does not travel well, and what they do when a deployment fails at five on a Friday.

9. 9

   How do you test something you cannot fully replicate outside production?

   Sandboxes rarely have real data volumes or real integrations. Good answers involve partial copies, seeded test records, feature toggles, staged rollout to one team, and a documented way to switch it off. A candidate who tests in production should be able to explain how they contain the blast radius.

10. 10

    How do you approach data quality: duplicates, stale records, fields nobody fills in?

    Ask what they actually removed rather than what they would recommend. Deleting or hiding an unused field is politically harder than adding one, and administrators who have never done it tend to leave orgs heavier than they found them.

11. 11

    Describe a data load that went wrong.

    Everyone who has loaded data has broken something: duplicated ten thousand records, fired automation they forgot about, overwritten owners. What you want is whether they had an external ID, a backup and a plan to reverse it, or whether recovery meant a support case and a bad week.

12. 12

    How would you update 200,000 records without causing problems?

    The answer should mention batching, accounting for automation that will fire, running in a sandbox first, timing it outside business hours, and watching for row lock errors. A candidate who reaches straight for a mass update in the middle of a Tuesday is describing small-scale experience.

13. 13

    A user says the system is slow and broken. How do you get to something you can act on?

    This is really a support question. Look for a habit of reproducing the issue themselves, checking whether it is one user or many, checking profile and browser, and getting a record ID. Administrators who escalate straight to support without triage create a lot of noise.

14. 14

    What reporting do you build for a sales rep, and what do you build for an executive?

    The two audiences want opposite things: a rep wants a working list they can act on today, an executive wants a trend and a number that reconciles with the board deck. A candidate who describes the same dashboard for both has probably never had either group complain to them.

15. 15

    How do you handle three platform releases a year?

    Ask what they did about the most recent one specifically. Good answers include reading release notes with an eye to what is being retired, testing in a preview sandbox, and telling users what will look different before it does. Vague enthusiasm about staying current is not an answer.

16. 16

    What have you retired or deleted in the last year?

    Administrators are measured on what they build and quietly judged on what they let accumulate. Someone who has decommissioned a report folder, an unused package or an old automation is thinking about cost of ownership rather than ticket count.

17. 17

    How do you document your work, and who reads it?

    The second half is the real question. Documentation nobody reads is a hobby. Look for something lightweight and located where the next person will actually look: descriptions on fields and flows, a change log, a short runbook for the integrations.

18. 18

    How do you work with developers or an implementation partner?

    Administrators sit between business users and technical builders, and the handoff is where projects fail. Ask how they write a requirement, whether they review user stories, and what they do when a partner delivers something that technically matches the spec but does not work for users.

19. 19

    Sales leadership wants a new required field added mid-quarter. What do you do?

    A required field changes every integration, data load and API call that touches that object. Look for whether they think past the click: existing records, automated processes, mobile users, and whether the underlying need could be met by a page layout or a validation rule with a narrower scope.

20. 20

    What would you want to look at in your first month here?

    The strongest candidates ask for read access to the org rather than answering blind, then name concrete artifacts: the permission model, the automation inventory, the top ten reports by usage, open tickets, and who the loudest and quietest user groups are. Generic first-90-days language means they have not thought about your situation.