A candidate can hold an Application Architect badge, a System Architect badge, and still fail at the actual job. Salesforce's own Architect Review Board doesn't run a multiple-choice test for the top-tier Certified Technical Architect (CTA) credential — per Salesforce's official Trailhead certification guide, candidates get a multi-page business scenario, roughly two hours to design a complete solution, and a panel of three to four CTAs who challenge every decision they make. That's the bar the certification body itself uses to separate real architects from people who passed a few exams.
Most hiring panels for Salesforce Architect roles never come close to that bar. They ask about Apex governor limits, accept a textbook number, and move on. The five questions below test the same thing the CTA board tests: architectural judgment under pressure, not recall. Each comes with a weak answer, a strong answer, and the one follow-up that exposes the gap between them.
Question 1: "Design a sharing model for 200 sales reps across 12 regions, where regional managers need cross-region visibility but reps stay siloed — and a 30-day external auditor needs read access to one region's data."
This question tests whether a candidate thinks about sharing as a system, not a setting. Most candidates can name the building blocks: organization-wide defaults, role hierarchy, sharing rules. Few think through what happens when the access requirement has an expiry date attached to it.
Weak answer: "I'd set org-wide default to Private and let the role hierarchy handle manager visibility."
That's true, but incomplete. It says nothing about the external auditor, who almost certainly shouldn't get a full Salesforce license at full cost for 30 days of access.
Strong answer: The candidate sets Account and Opportunity org-wide defaults to Private, uses role hierarchy for the manager rollup, and handles the auditor separately — a criteria-based sharing rule or a manually shared record scoped to one region, on a lower-cost license type since a full internal license is the wrong tool for 30 days of read access. Most importantly, they explain how access gets revoked on day 31: a scheduled flow or a tracked removal task tied to an end date, not a calendar reminder.
The follow-up that exposes the gap: Ask what happens to the auditor's access after 30 days. A candidate who hasn't thought about offboarding hasn't really designed a sharing model — they've described one half of it.
This is exactly the kind of gap our recruiters probe for during CLIQHR's Interview Service sessions, where a working architect sits in on the technical round instead of a generalist recruiter guessing at the right follow-up.
Question 2: "A nightly batch job has run fine for two years. After the account base tripled, it now fails with CPU time limit exceeded. Walk me through how you'd fix it."
Apex governor limits are per-transaction, not per-org. A candidate who answers by reciting the actual limit numbers — the synchronous and asynchronous CPU time ceilings — is demonstrating memorization, not diagnosis. Tripling the account base doesn't change the limit; it changes how much work each transaction does, which is a different problem entirely.
Weak answer: "I'd increase the batch size in Database.executeBatch so it processes faster." This usually makes the problem worse, not better, since a larger scope size per batch execution means more records processed inside the same per-transaction CPU ceiling.
Strong answer: The candidate starts with debug logs to find the exact line consuming the CPU time, not a guess. They check for SOQL queries or DML statements sitting inside a loop — the most common cause of a job that scaled fine until data volume crossed a threshold. The fix might be a smaller batch scope, a Queueable chain for the expensive logic, or eliminating a nested query that used to return ten rows and now returns three hundred. Diagnosis comes before the fix, every time.
The follow-up that exposes the gap: Ask what they'd check first, before changing a single line of code. A candidate who jumps straight to a configuration change is guessing.
Question 3: "Three Salesforce orgs are merging after an acquisition. What's your migration sequence, and what's the first thing that breaks after cutover?"
This is a sequencing and dependency-mapping question disguised as a data migration question. The "what breaks first" half is the part that separates candidates who have lived through a real org consolidation from candidates who've only read about one.
Weak answer: "I'd export everything with Data Loader and import it into the target org." This treats consolidation as a data transfer problem, when the harder issues are duplicate detection, automation conflicts, and integration dependencies.
Strong answer: The candidate sequences reference data before transactional data — accounts and contacts before opportunities and cases — using an external ID field to prevent duplicate accounts when the same customer exists in two source orgs. They freeze workflow rules, flows, and triggers in the source orgs during cutover so records don't fire duplicate automation mid-migration. And when asked what breaks first, they don't say "data quality." They say integrations: every API connection and middleware configuration still pointing at a decommissioned org's endpoint stops working the moment that org goes dark, often silently, until someone notices a sync failure days later.
The follow-up that exposes the gap: Ask what breaks first. A candidate who immediately names integrations and authentication endpoints has done this before. A candidate who talks only about data cleanup hasn't.
Question 4: "A client wants real-time inventory sync between Salesforce and an on-prem ERP. Do you build it natively, buy an AppExchange package, or bring in middleware like MuleSoft?"
This question has no correct answer until the candidate asks a few questions of their own. That's the point. A candidate who names a tool before asking anything is pattern-matching from a past project, not architecting for this one.
Weak answer: "MuleSoft is the standard for this kind of integration, so I'd use MuleSoft." True often enough to sound credible, wrong often enough to matter — middleware earns its license cost when multiple systems share an integration layer, not when there's a single ERP connection to manage.
Strong answer: The candidate asks how real-time "real-time" needs to be — sub-second, near-real-time, or an acceptable five-minute batch window — and whether the ERP exposes a usable REST or SOAP API versus only flat-file exports. Then they lay out the trade-off: native Apex callouts and Platform Events work for low transaction volume and simple logic but become a maintenance burden as rules pile up. An AppExchange package shortens the timeline if the ERP is a common one like SAP or NetSuite with an existing connector. Middleware like MuleSoft or Dell Boomi earns its cost when this is one of several integrations the client will need over time.
The follow-up that exposes the gap: Count the clarifying questions before the tool name comes out. Zero is a red flag.
Question 5: "Tell me about a time a stakeholder demanded something you knew would create unmanageable technical debt. What did you do?"
Most recruiters skip this question, which is a mistake — the CTA Review Board weighs communication and the ability to defend a design under challenge as heavily as raw technical depth. An architect who can't push back on a stakeholder in a low-stakes interview almost certainly won't push back when the stakes are a production deadline.
Weak answer, version one: "I built what they asked for." No pushback, no trade-off conversation.
Weak answer, version two: "I told them it was a bad idea and refused to build it." Sounds principled, but usually means the candidate won an argument instead of solving a business problem.
Strong answer: The candidate names the trade-off in business terms — cost, delivery time, future maintenance burden — rather than jargon the stakeholder can't evaluate. They propose an alternative that delivers most of the business outcome at a fraction of the long-term cost, and describe what happened when the stakeholder still said no: they built the requested solution, documented the technical debt explicitly, and flagged when it would need revisiting. No quiet workarounds.
The follow-up that exposes the gap: Ask whether the stakeholder was part of that trade-off conversation, or whether the candidate just absorbed the decision and built it anyway.
Score the answers, not the vocabulary
Recruiters and founders evaluating this role rarely have a Salesforce background themselves, and that's fine — the follow-up questions above work whether or not you understand Apex syntax. Use the scorecard below to capture what each candidate actually said, then compare notes across candidates before making a decision.
| Question | What it really tests | Red flag | Green flag |
|---|---|---|---|
| 1. Sharing model with a temporary external user | Sharing architecture + offboarding discipline | Stops at role hierarchy, ignores license cost and access expiry | Names the right license type and how access gets revoked |
| 2. Batch job failing after scale-up | Diagnostic process under governor limits | Recites limit numbers, jumps to a fix before diagnosing | Starts with debug logs, checks for SOQL/DML in loops first |
| 3. Multi-org consolidation sequence | Migration sequencing + integration dependency awareness | Frames it purely as a data export/import task | Names integrations and auth endpoints as the first failure point |
| 4. Build vs. buy vs. integrate | Integration judgment + total cost of ownership thinking | Names a tool before asking a single clarifying question | Asks about volume and API availability before recommending anything |
| 5. Pushing back on technical debt | Stakeholder communication + ability to defend a design | Either caved silently or "won" the argument with no compromise | Framed the trade-off in business terms, kept the stakeholder in the loop |
What this means for how you staff the role
FAQ
