30 Accenture Salesforce Developer Interview Questions (2026)

Prepare for Accenture Salesforce developer interviews with 30 real questions, scenario answers, and what interviewers focus on in 2026.

Accenture Salesforce Developer Interview Questions: 30 Most Asked (2026)

Accenture Salesforce Developer interview questions lean practical. If you're preparing for one of these rounds, expect scenario-based problems, live coding, and follow-ups that test whether you understand why — not just what. This guide covers the 30 questions candidates report most often, split by experience level, with concise answers and the framing Accenture interviewers actually use. It also walks through the interview process so nothing catches you off guard.

How Accenture's Salesforce developer interview works

Stages and format

The typical pipeline has three stages:

• Online assessment — aptitude, logical reasoning, and sometimes a short coding exercise.
• Technical interview — one or two rounds, usually 45–60 minutes each. Live coding and scenario-based questions are standard. Candidates in Bangalore and Singapore have reported one-hour sessions focused entirely on LWC and Apex.
• HR / managerial round — culture fit, career goals, situational questions.

According to Glassdoor (April 2026, 97 ratings), 75% of candidates applied online, the process averages 19 days, and overall difficulty is rated Average with a mostly positive candidate experience. AmbitionBox data shows 56% of candidates wrap up in under two weeks.

What interviewers focus on

Accenture interviewers care about practical problem-solving more than textbook recitation. The recurring technical areas across candidate reports: Apex, LWC, triggers, SOQL/SOSL, Flows, integration patterns, data modeling, and the security model. If you can explain a design decision out loud while writing code, you're in the right mode.

Accenture Salesforce developer interview questions — fresher level

Fresher here means 0–2 years of experience. These questions test fundamentals, but Accenture still expects you to connect concepts to real scenarios — not just define them.

Q1: Explain Salesforce's MVC architecture. What they're really asking: Do you understand how the platform is structured, or do you just drag fields onto page layouts? Answer: Model = standard/custom objects and fields. View = Lightning pages, LWC, Visualforce. Controller = Apex classes, triggers, and standard controllers. In practice, keeping business logic in the controller layer (Apex) and out of the view (LWC) makes components reusable and testable.

Q2: When would you use an Apex trigger vs. an Apex class? What they're really asking: Can you separate event-driven logic from reusable business logic? Answer: Triggers fire on DML events (insert, update, delete) and should be thin — they call handler classes that contain the actual logic. Apex classes hold reusable methods, batch jobs, scheduled work, and service layers. The one-trigger-per-object pattern keeps things maintainable.

Q3: What's the difference between a workflow rule and a trigger? What they're really asking: Do you know when declarative tools are enough and when code is necessary? Answer: Workflow rules are declarative — field updates, email alerts, outbound messages, time-dependent actions. Triggers are code and can do anything Apex can do: complex logic, cross-object updates, callouts (via async). Use declarative first; reach for triggers when the requirement exceeds what Flows and workflow rules can handle.

Q4: SOQL vs. SOSL — when do you use each? What they're really asking: Can you pick the right query tool for the job? Answer: SOQL queries a single object (with relationships) and returns structured records. SOSL searches across multiple objects simultaneously using a text index — useful for global search scenarios. If you know the object and fields, use SOQL. If you're searching across objects by keyword, use SOSL.

Q5: What are governor limits and why do they exist? What they're really asking: Will your code survive a multi-tenant environment? Answer: Governor limits cap resource usage per transaction — 100 SOQL queries, 150 DML statements, 6 MB heap, etc. They exist because Salesforce is multi-tenant; one org's code can't be allowed to starve another's resources. Bulkification is the standard response: process collections, not individual records.

Q6: Role vs. profile — what's the difference? What they're really asking: Do you understand the security model well enough to configure it correctly? Answer: A profile controls object-level and field-level permissions — what a user can do. A role controls record-level visibility through the role hierarchy — what a user can see. Every user has exactly one profile. Roles are optional but critical for sharing rules and reporting rollups.

Q7: What does the @api decorator do in LWC? What they're really asking: Can you build components that communicate with their parents? Answer: @api marks a property or method as public, making it accessible from a parent component or from the Lightning App Builder. It's how you pass data into a child component and expose configurable properties for admins.

Q8: Walk me through LWC lifecycle hooks in order. What they're really asking: Do you know when your code runs relative to the DOM? Answer: constructor() → connectedCallback() → renderedCallback() → disconnectedCallback(). constructor initializes the component. connectedCallback fires when the component is inserted into the DOM — good for data fetching. renderedCallback fires after every render. disconnectedCallback is cleanup.

Q9: Why does SeeAllData=false matter in test classes? What they're really asking: Do you write isolated, reliable tests? Answer: SeeAllData=false (the default since API v24) prevents test methods from accessing org data. Tests should create their own data so they're repeatable and don't break when someone changes a record in production. Setting it to true is almost always a code smell.

Q10: What is a future method and what are its parameter constraints? What they're really asking: Do you understand async Apex basics? Answer: A future method (@future) runs asynchronously — useful for callouts from trigger context or long-running operations. Parameters must be primitive data types or collections of primitives. You can't pass sObjects directly because the data might change between invocation and execution.

Accenture Salesforce developer interview questions — experienced (4+ YOE)

Experienced rounds are scenario-heavy. Expect to write code, explain trade-offs, and defend your design choices in real time.

Q11: Walk me through how you'd build an LWC form that submits data to Salesforce. What they're really asking: Can you wire up a real component end-to-end? Answer: Create an LWC with input fields bound to tracked properties. On submit, call an imperative Apex method (not @wire — you want explicit control over when the call fires). The Apex method performs DML and returns a result. Handle success with a toast notification and error with a try-catch in the Apex plus a catch block in the JS promise chain.

Q12: How would you restrict component access to specific users using custom metadata? What they're really asking: Can you build configurable, admin-friendly gating without hardcoding? Answer: Create a custom metadata type that stores allowed user emails or profile names. In the LWC's connectedCallback, call an Apex method that queries the custom metadata and compares against the current user's context. If the user isn't in the list, hide the component or show a restricted message. Custom metadata is deployable and doesn't count against SOQL limits in the same way.

Q13: How do you handle errors in LWC using wrapper classes and toast messages? What they're really asking: Is your error handling production-grade or just try-catch-log? Answer: The Apex method returns a wrapper class with a success boolean, a message string, and the data payload. The LWC checks the success flag — on failure, it displays the message in a lightning-toast with variant="error". This pattern gives you structured error communication without relying on AuraHandledException alone.

Q14: Lightning Message Service vs. pub-sub model — when do you pick each? What they're really asking: Do you know how to communicate between unrelated components? Answer: LMS works across the entire Lightning page — even across Aura and LWC boundaries and across different DOM trees. It uses a message channel defined in metadata. The pub-sub pattern (custom JS module) is lighter and works within a single LWC app or page context. Use LMS when components live in different regions of the page or when Aura components are involved. Use pub-sub for tightly scoped, same-app communication.

Q15: Give me a real use case for platform events vs. LMS. What they're really asking: Can you distinguish between UI messaging and system-level event architecture? Answer: Platform events are for cross-system, asynchronous communication — an external system publishes an event, Salesforce subscribes and processes it via trigger or Flow. LMS is strictly UI-layer, same-page communication. If the event needs to survive a page refresh or come from outside Salesforce, it's a platform event. If it's two components on the same record page talking to each other, it's LMS.

Q16: When would you use dynamic SOQL? What they're really asking: Can you build flexible queries safely? Answer: Dynamic SOQL (Database.query()) is useful when the object, fields, or filter conditions aren't known at compile time — for example, a generic search component that works across multiple objects. Always use String.escapeSingleQuotes() or bind variables to prevent SOQL injection. Prefer static SOQL when the query structure is fixed.

Q17: Batchable vs. queueable Apex — what are the trade-offs? What they're really asking: Do you pick the right async pattern for the job? Answer: Batchable processes large data sets in chunks (up to 50M records) with start/execute/finish phases. Queueable is simpler — one execute method, supports non-primitive members, and can chain jobs. Use batchable for bulk data operations with governor-limit-friendly chunking. Use queueable for smaller async work that needs object references or job chaining.

Q18: How do you prevent recursive triggers? What they're really asking: Have you dealt with this in production, or just read about it? Answer: Use a static boolean variable in a handler class — set it to true on first entry, check it before re-executing. Alternatively, use a static Set<Id> to track already-processed record IDs. The static variable resets per transaction, so it won't block future transactions.

Q19: Write a trigger that counts related invoices on an Account. What they're really asking: Can you write bulkified trigger logic under pressure? Answer: After insert/delete/undelete on Invoice__c, collect the parent Account IDs from Trigger.new (and Trigger.old for delete). Run an aggregate SOQL query: `SELECT Account__c, COUNT(Id) cnt FROM Invoice__c WHERE Account__c IN :accountIds GROUP BY Account__c`. Loop through the results and update the Account's Invoice_Count__c field. Single query, single DML — bulkified.

Q20: REST vs. SOAP API — when does an Accenture project use each? What they're really asking: Do you understand integration patterns in a consulting context? Answer: REST is the default for most modern integrations — lightweight, JSON-based, works well with web and mobile clients. SOAP is used when the external system requires WSDL-based contracts or when you need built-in WS-Security. In Accenture projects, legacy enterprise systems (SAP, older ERPs) often mandate SOAP; newer microservices and cloud apps use REST.

Q21: How do you pass a user's email to a future Apex callout? What they're really asking: Do you know the parameter constraints of @future methods? Answer: Future methods only accept primitive parameters. You can't pass UserInfo.getUserEmail() directly as a context object — instead, pass the email string as a parameter: `@future(callout=true) public static void doCallout(String userEmail)`. Capture the email before invoking the future method and pass it explicitly.

Q22: How do you query custom metadata records in Apex? What they're really asking: Do you use custom metadata correctly in code? Answer: Query them like any other object: `SELECT MasterLabel, Field__c FROM My_Custom_Metadata__mdt WHERE DeveloperName = 'SomeValue'`. Custom metadata queries don't count against the 100-SOQL governor limit, which makes them ideal for configuration data that needs to be accessed frequently in code.

Q23: How do you handle exceptions in a Flow? What they're really asking: Can you build fault-tolerant declarative automation? Answer: Use fault paths on DML and action elements. When a fault occurs, the flow follows the fault connector to a fault handler — typically a screen element showing the error or a custom Apex action that logs the error and sends a notification. Always add fault paths on any element that can fail; an unhandled fault terminates the flow silently for the user.

Q24: How do you apply dynamic styling in LWC? What they're really asking: Can you handle conditional UI without hacking the DOM? Answer: Use a getter that returns a class string based on component state: `get cardClass() { return this.isActive ? 'slds-box active' : 'slds-box'; }`. Bind it in the template with `class={cardClass}`. Define the CSS classes in the component's .css file. Avoid direct DOM manipulation — let the reactive framework handle re-renders.

Q25: What are Aura queue actions and when are they relevant? What they're really asking: Do you understand the Aura framework's action lifecycle? Answer: In Aura, server actions are enqueued with `$A.enqueueAction(action)` and batched by the framework. Actions in the queue are sent to the server in a single request when possible, reducing round trips. This matters when you have multiple server calls on component init — the framework optimizes them. In LWC, this is handled differently (@wire and imperative calls), but understanding the Aura model matters when maintaining legacy components.

CPQ specific questions (bonus round)

Some Accenture Salesforce Developer roles include CPQ scope. If the job description mentions CPQ, expect a few of these.

Q26: What is a CPQ price rule and when does it fire? A price rule evaluates conditions on quote lines and applies price actions (set price, discount, markup) automatically. It fires during the quote calculation sequence — after product rules but before the final price is committed.

Q27: What is a product rule in Salesforce CPQ? Product rules enforce selection logic — validation rules (block invalid combos), selection rules (auto-add/remove products), and alert rules (warn the user). They fire when a user adds or configures products on a quote.

Q28: How does CPQ handle discounting? CPQ supports multiple discount layers: additional discount (manual), contracted pricing, volume discounts (discount schedules), and partner discounts. Discounts are applied in a defined waterfall sequence during calculation.

Q29: What is a quote template and what can it include? A quote template defines the PDF output of a quote — sections, line columns, subtotals, terms and conditions, and dynamic content via template sections. It's configured declaratively in the CPQ setup.

Q30: How do you test CPQ configuration changes without breaking live quotes? Use a sandbox with CPQ installed and a representative data set. Test price rules, product rules, and discount schedules against existing quote scenarios. Validate calculation results before deploying to production. CPQ config is metadata-driven, so it deploys via change sets or CI/CD pipelines.

Accenture Salesforce developer interview questions — behavioral / HR round

The HR round is standard at Accenture. Expect culture-fit and situational questions:

• Why Accenture? — Tie your answer to the scale of their Salesforce practice and the variety of client projects.
• Describe a time you debugged a complex Apex issue under deadline pressure. — Use a specific example with a clear outcome.
• How do you handle conflicting requirements from a client vs. your tech lead? — Show that you escalate with data, not opinions.
• Where do you see yourself in three years in the Salesforce ecosystem? — Mention certifications, architecture track, or domain specialization.
• How do you stay current with Salesforce releases? — Trailhead, release notes, community groups, and hands-on experimentation in a dev org.

For scenario questions, use the STAR format: Situation, Task, Action, Result. Keep each answer under two minutes. Specifics beat generalities — name the technology, the timeline, and the measurable result.

How to prepare — practical steps

• Review Trailhead modules for LWC, Apex, integration patterns, and the security model. Accenture interviewers expect you to know the platform, not just your IDE.
• Practice writing triggers and Apex classes by hand. Live coding is common. If you can't write a bulkified trigger without autocomplete, practice until you can.
• Study the security model end to end — profiles, roles, permission sets, sharing rules, org-wide defaults. It comes up at every level.
• Run mock scenario interviews. Practice explaining your design decisions out loud — not just writing code, but narrating why you chose that approach. Verve AI's Interview Copilot lets you run mock Salesforce developer interviews with real-time feedback, which is useful for rehearsing scenario answers before the actual Accenture round.
• Read the latest Salesforce release notes. Interviewers notice when you're aware of recent platform changes.

For 56% of candidates, the entire Accenture process wraps up in under two weeks. Prepare early, practice the scenarios that actually come up, and walk in knowing the format. The questions above are what real candidates report — not textbook filler.