How to Pass a Salesforce Architect Interview: Product vs. SI vs. In-House

💬 In plain words: The title "Salesforce Architect" means completely different things depending on who is interviewing you. Consulting firms (SIs) care about how well you present to clients and whiteboard architecture trade-offs. Product companies (ISVs) care about deep code quality and AppExchange package thinking. In-house enterprise teams care about your operational maturity—how you will fix their messy legacy org. You must prepare for the format, not just the technical topics.

📌 Example: Take the exact same technical topic, like Apex Triggers. A Product Company will hand you a block of code and ask you to find the bugs (e.g., SOQL in a loop, no bulkification). An SI consulting firm will ask you to draw a system architecture on a whiteboard to explain to a CIO why you chose Apex over Flow. An In-House team will ask you, "Our org has 50 conflicting triggers and deployment is broken. What is your 90-day plan to fix it?" Same knowledge base, three totally different performances.

🏢 Understanding the Interview Formats

Different types of companies structure their interviews to test the skills they value most. Knowing what they care about is half the battle.

• Services and SI Firms (Consultancies): These interviews are heavy on scenario design and client simulation. Expect whiteboarding, narrating your trade-offs out loud, sizing/estimation questions, and behavioral depth. They want to know: Can we put you in front of a demanding client?
• Product Companies and ISVs: These interviews are highly technical. Expect live coding or code-reading exercises. They test your ability to build a feature that scales across thousands of orgs. They look for deep knowledge of limits, bulkification, CRUD/FLS enforcement, and writing secure Apex or Lightning Web Components (LWC).
• In-House Enterprises: These teams will test you on their specific problems. Expect questions about inheriting messy orgs, integrating with legacy ERPs, release management, and team governance. They want to know: Can you safely run and govern our internal platform?
• Startups: Startups value breadth over depth. Because you might be the only Salesforce person in the building, expect rapid-fire questions covering everything from basic Admin tasks to complex API integrations.

🧠 Core Takeaway: Match the grader. SI firms grade client talk. ISVs grade code and packaging. End-user companies grade org surgery. Prepare for the grader, not the title.

🧭 The 360 Card: Company Types

Rule: Same foundational knowledge, completely different weighting. You must adapt your rehearsal to the company type.

Gain: You rehearse the right skills (e.g., drawing architecture diagrams vs. reading code aloud) instead of preparing evenly for an interview that won't be evenly weighted.

Price: You have to do your research. You must ask the recruiter exactly what format the technical round will take before you agree to it.

Limits: Trying to use a generic preparation strategy will lead to a painful mismatch in the room that you cannot recover from.

Best Practice: When interviewing for an in-house role, research their world first. Know their industry, guess their likely ERP, and estimate the age of their Salesforce org. Lead the interview by demonstrating day-to-day operational judgment.

💬 Core Q&A & Interview Prep

Q: How does your preparation change if the interview is at a product company versus a services firm versus an in-house team?

🎯 Say this first: "While the foundational Salesforce knowledge is the same, the rehearsal format changes entirely based on the company type."

For a Product Company, I drill code fluency. I practice reading unfamiliar Apex aloud and spotting planted bugs—like SOQL in loops, missing bulkification, and unhandled nulls. I practice narrating my thought process while writing a trigger handler live, focusing heavily on package-grade thinking: enforcing CRUD and FLS everywhere.

For a Services Firm (SI), I drill system design and communication. I practice whiteboarding, estimating effort with ranges, and defending architectural trade-offs out loud as if I were speaking to a client.

For an In-House Team, I research their specific industry and tech stack. I prepare to discuss operational judgment, release governance, and how to safely repair a legacy org. In all cases, I always ask the recruiter for the exact round structure beforehand so I can tailor my preparation.

🔗 Follow-Up Questions

Q1: In a live code-reading round, they show you an Apex trigger and ask, "What is wrong with this?" What is your method for answering?

I read the code aloud in three distinct passes, narrating exactly what I am doing so the interviewer can hear my thought process.

• Pass One (Intent): I state what the code is trying to achieve (e.g., "This looks like it recalculates totals on a Contact change").
• Pass Two (The planted bugs): I run down the classic checklist. I look for SOQL or DML inside loops. I check if Trigger.new is handled in bulk. I look for missing null checks, unguarded recursion, hardcoded IDs, and missing with sharing declarations.
• Pass Three (Design): I critique the architecture (e.g., "This logic belongs in a handler class, not directly in the trigger body, and it needs a bulk test class").

The win condition here isn't just finding the bugs in silence—it's verbalizing your professional review checklist.

Q2: A startup interviewer hits you with rapid-fire questions covering Admin work, Developer work, and Release Management all in one round. How do you handle the extreme breadth?

I answer honestly, mapping my responses by "zones." For topics in my strong zones, I give deep, technical answers. For related zones, I explain the core principle and detail how I would verify the specifics. For unknown zones, I simply state, "I don't know that offhand, but here is exactly how I would find out." Startups are testing if one person can own the entire platform—and true ownership includes knowing your own limits. The best move is to flip the question and ask, "What is currently on fire in your org?" Turning an interview into a working session about their real problems is how you win the role.

⚠ INTERVIEW TRAP: Never try to fake an answer in a technical interview, especially regarding limits or security. If you don't know, confidently state how you would find the documentation. Guessing incorrectly on core platform limits is an instant red flag for an architect.