Salesforce Interview Questions Asked at Deloitte

Deloitte usually runs Salesforce hiring across two or three technical rounds. The first stays on data model and configuration. The second is a working session where the interviewer opens a shared screen and asks you to write SOQL and Apex while they watch. The 25 questions below come from candidates who sat those rounds. Two of them, the query for Accounts with no Contacts and the trigger that counts Contacts on an Account, appear in almost every panel, and they are where most candidates lose the offer. Each answer here carries the reasoning the panel listens for, not only the definition.

Data model, relationships and SOQL

How do you convert a Lookup relationship to Master-Detail? Are there any dependencies on data access, ownership, or sharing?

The conversion is allowed only when every existing child record already has a value in the lookup field. One blank and Salesforce blocks it. So the sequence is: export the child records, populate the blanks through Data Loader, then open the child object's field and use Change Field Type.

The dependencies are what candidates forget:

• Ownership goes away. A detail record has no Owner field. It inherits the owner of the master record.
• Sharing is inherited. Sharing rules and manual shares on the child are deleted. Access to the child follows access to the parent.
• Delete becomes cascade. Deleting the master deletes the details.
• The field becomes required, and a child object can hold at most two master-detail relationships.
• Converting back to Lookup works only after you delete every roll-up summary field on the master object.

If the child object holds zero records, none of this applies and the conversion is immediate. Say that, because it shows you have done it rather than read it.

Write a SOQL query to fetch all Accounts that do not have any Contacts associated with them.

SELECT Id, Name
FROM Account
WHERE Id NOT IN (SELECT AccountId FROM Contact WHERE AccountId != NULL)

The semi-join does the work. The inner query returns the Account Ids referenced by at least one Contact, and NOT IN keeps the Accounts outside that set.

WHERE AccountId != NULL is not decoration. A NOT IN comparison against a set containing a null behaves unpredictably and can return zero rows. Filtering nulls out of the inner query keeps the result correct. Deloitte panels look for that clause, because most candidates omit it and then cannot explain why their result came back empty.

Two things worth adding out loud. SOQL has no LEFT JOIN, so a semi-join is the only way to express "records with no related records". And this query is not selective, so on an org with millions of Accounts you would run it inside Batch Apex with a Database.QueryLocator.

Explain a data model for developing a B2B portal using Experience Cloud.

The backbone is Account, Contact and User. A partner company is an Account, every person who logs in is a Contact under it, and each of those Contacts is enabled as a User on a Partner Community or Customer Community Plus licence. The Account owner must hold a role first, because partner user roles are created beneath it.

On top sit the business objects: Opportunity and Order for deal registration, Case and Knowledge for support, Asset or Entitlement for what the partner already owns. Any custom object exposed in the portal needs a lookup to Account so sharing can be driven from it.

Our trainers see this used as a trap. The interviewer asks it, then goes five levels down: which object held the deal registration, why a Sharing Set and not a sharing rule, which licence, what you personally built. If the portal is on your resume and you only read about it, the answer collapses by level three.

What is the difference between Custom Metadata Types and Custom Settings?

The rule: configuration that belongs to a release goes into Custom Metadata, because it travels with the deployment and nobody keys it in again. Values that vary per user, or that Apex writes during a transaction, stay in Custom Settings. Integration endpoints and record type mappings are Custom Metadata. A flag such as "skip validation for the migration user" is a Hierarchy Custom Setting.

What the interviewer is actually checking

• Whether you know a master-detail conversion changes the security model, not just the field type.
• Whether you write a semi-join without hesitating, and can explain the null filter.
• Whether the Experience Cloud answer names licences and sharing mechanisms.
• Whether you pick Custom Metadata for anything that has to survive a deployment.

Apex and triggers

Write a Trigger to count the number of Contacts related to an Account and store it in a custom field on Account.

This is the flagship coding question in the Deloitte round.

trigger ContactTrigger on Contact (after insert, after delete) {

    Set<Id> accIds = new Set<Id>();

    if (Trigger.isInsert) {
        for (Contact c : Trigger.new) accIds.add(c.AccountId);
    }
    if (Trigger.isDelete) {
        for (Contact c : Trigger.old) accIds.add(c.AccountId);
    }
    accIds.remove(null);

    Map<Id, Integer> accCountMap = new Map<Id, Integer>();
    for (AggregateResult ar : [
            SELECT AccountId accId, COUNT(Id) cnt
            FROM Contact
            WHERE AccountId IN :accIds
            GROUP BY AccountId
    ]) {
        accCountMap.put((Id) ar.get('accId'), (Integer) ar.get('cnt'));
    }

    List<Account> accs = new List<Account>();
    for (Id accId : accIds) {
        Integer cnt = accCountMap.get(accId);
        accs.add(new Account(Id = accId, Contact_Count__c = (cnt == null ? 0 : cnt)));
    }
    update accs;
}

Why after insert and after delete. The count must reflect what is committed. In a before insert context the Contact has no Id and is not visible to a query, so the aggregate returns the old number. Delete has to be handled in the after context as well, reading Trigger.old, because Trigger.new is null on delete. Skipping the delete path is the most common failure here. The interviewer inserts three Contacts, deletes one, and watches your field stay at three.

Why AggregateResult and not a loop. The version most candidates write puts a query for Contacts per Account inside a for loop. With 200 Contacts across 200 Accounts that is 200 queries against a limit of 100, and the transaction dies with "Too many SOQL queries: 101". The GROUP BY version returns every count in one query regardless of batch size, and it loads one row per Account into heap instead of every Contact.

Why the Map. The aggregate returns counts keyed by Account Id, so building the update list is a single pass with no nested loop, and one update covers the whole batch.

Why iterate over accIds, not over the map. An Account whose last Contact was just deleted has no row in the aggregate result. Loop over the map and you never touch it, so its count stays stale. Looping over accIds and defaulting a missing key to zero fixes that, and a good interviewer tests exactly that case.

In production, move the body into a ContactTriggerHandler and add after update and after undelete. On update you must add both the old and the new AccountId to the set to handle reparenting.

Our trainers make the same observation every batch. Candidates define bulkification correctly when asked, then write the loop version when told to code. The panel only marks what you write.

What are wrapper classes in Apex, and in which real-time scenarios are they required?

A wrapper class is an ordinary Apex class whose members are other objects or primitives, used to carry a shape the platform does not give you.

public class ContactWrapper {
    @AuraEnabled public Contact record { get; set; }
    @AuraEnabled public Boolean isSelected { get; set; }
    @AuraEnabled public Decimal totalOrderValue { get; set; }
}

Real scenarios: a table where each row needs a checkbox, since a Contact has no "selected" field and you are not adding one for a UI concern; returning fields from two unrelated objects in one list; returning a payload plus a status so the component can show a partial success; shaping a JSON body for an integration whose structure does not match your objects.

For LWC the class and every property need @AuraEnabled and must be public. Miss that and the component receives empty objects with no error.

What are Apex and Trigger best practices in Salesforce?

• One trigger per object, since multiple triggers execute in an undefined order.
• No logic in the trigger file. It routes to a handler class and stays a dispatcher.
• Bulkify for 200 records, always.
• Never put SOQL or DML inside a for loop. Query once into a Map.
• Guard recursion with a static Boolean, since a DML inside a trigger refires it.
• Use Database.insert(records, false) where partial success is acceptable and read the SaveResult.
• Keep record type names, thresholds and endpoints in Custom Metadata, not string literals.
• Enforce sharing and field level security rather than relying on system mode.
• Write the test with 200 records.

What does bulkification mean in Salesforce? Explain with an example.

Bulkification means handling a collection of records in the same number of queries and DML statements as a single record. It matters because triggers fire in batches of up to 200, and Data Loader, Flows and integrations all arrive in bulk.

The version that fails:

for (Opportunity opp : Trigger.new) {
    Account a = [SELECT Id, Industry FROM Account WHERE Id = :opp.AccountId];
    opp.Industry__c = a.Industry;
}

The version that passes:

Set<Id> accIds = new Set<Id>();
for (Opportunity opp : Trigger.new) accIds.add(opp.AccountId);

Map<Id, Account> accMap = new Map<Id, Account>(
    [SELECT Id, Industry FROM Account WHERE Id IN :accIds]
);

for (Opportunity opp : Trigger.new) {
    Account a = accMap.get(opp.AccountId);
    if (a != null) opp.Industry__c = a.Industry;
}

One query, one pass, identical behaviour for 1 record or 200. The interviewer asks for the example because the memorised definition does not survive contact with a keyboard.

What are Governor Limits, and how do you handle them in Salesforce development?

Governor limits are per transaction caps the platform enforces because the org shares infrastructure with other tenants. Crossing one throws an uncatchable LimitException and rolls the transaction back.

Handling them means bulkifying so query count is independent of record count, replacing nested loops with Map lookups to protect CPU time, moving past 50,000 records into Batch Apex with a Database.QueryLocator, selecting only the fields you use to protect heap, and checking Limits.getQueries() in code that runs in an unknown context.

What is the difference between with sharing and without sharing in Apex?

with sharing makes the class respect the running user's record level access, so sharing rules, role hierarchy and org wide defaults apply to its queries. without sharing ignores them. inherited sharing takes the caller's mode, and runs with sharing when entered directly from LWC, Aura, REST or Visualforce.

Two clarifications mark out a strong candidate:

• These keywords control record level access only. They do nothing for object permissions or field level security. For those you use WITH USER_MODE on the query, Security.stripInaccessible(), or describe checks.
• A class with no keyword is not safe by default. It inherits its caller's mode, so the same class behaves differently depending on where it is called from. inherited sharing is the right choice for a shared service class because the intent is explicit.

Use without sharing deliberately, and document why.

Explain the differences between Future, Queueable, Batch, and Scheduled Apex.

Batch Apex is the only one built for volume. It splits the start() query into scopes, usually 200 records, and each execute() gets fresh governor limits. Scheduled Apex is a clock rather than a processing model, and in practice its execute() starts a batch job. Use Queueable over Future for anything new, since it accepts object parameters, returns a job Id and chains.

What are best practices for writing Test Classes in Salesforce?

• Annotate with @isTest so the class does not count toward the org code size limit.
• Create your own data, centralised in a TestDataFactory, with @testSetup so it is built once per class. Avoid SeeAllData=true.
• Wrap the code under test in Test.startTest() and Test.stopTest(), which gives fresh limits and forces async jobs to finish before your assertions run.
• Assert something. Coverage without assertions passes deployment and catches nothing.
• Test with 200 records to prove bulkification, write negative tests, and use System.runAs() for a restricted profile.
• The deployment gate is 75 percent org wide coverage, with every trigger holding some coverage.

What the interviewer is actually checking

• Whether you write the aggregate version of the trigger under time pressure, not just describe it.
• Whether you handle the delete path and the Account whose count drops to zero.
• Whether you can quote the SOQL, DML and CPU limits without a screen in front of you.
• Whether you know with sharing does not cover field level security.
• Whether your tests assert outcomes or only chase the coverage number.

Flows versus triggers

Explain the different types of Flows available in Salesforce.

Within Record-Triggered Flows, the split that matters is fast field updates before save, which write to the record in memory with no extra DML, and actions and related records after save, which run once the record is committed.

Can the requirement of counting Contacts on an Account be achieved using Flow instead of Trigger? Explain how.

Yes, and say yes before you say "but".

Build a Record-Triggered Flow on Contact, after save, on create. Add a Get Records element on Contact filtered by AccountId equals {!$Record.AccountId}, read the count of the returned collection into a variable, then an Update Records element that writes Contact_Count__c on the Account. Deletion needs a second Flow on the delete trigger, since one Record-Triggered Flow handles one condition set.

Two additions keep the answer from sounding naive. If the relationship were master-detail, neither option is right, because a Roll-Up Summary field does it with no automation at all, and that is what the panel wants first. And a Flow cannot run an aggregate query, so Get Records pulls back real Contact records and hits collection limits. On an Account with 40,000 Contacts the Apex COUNT(Id) version has no such problem, and the trigger also handles reparenting on update in one place.

When should you prefer Flow over Trigger, and when should Trigger be preferred over Flow?

Salesforce's own guidance is declarative first, code when declarative cannot do the job at the required scale. What loses marks is "trigger is always better because it is code", and equally eleven Record-Triggered Flows on Account with no explanation of the order they run in.

How can a Flow be invoked from Lightning Web Components and from Apex?

From LWC, embed the flow with the base component and listen for completion.

<template>
    <lightning-flow
        flow-api-name="Create_Support_Case"
        flow-input-variables={inputVariables}
        onstatuschange={handleStatusChange}>
    </lightning-flow>
</template>

get inputVariables() {
    return [{ name: 'recordId', type: 'String', value: this.recordId }];
}

handleStatusChange(event) {
    if (event.detail.status === 'FINISHED') {
        // read event.detail.outputVariables
    }
}

The related but different case is an LWC placed inside a Screen Flow. There you import from lightning/flowSupport and fire FlowAttributeChangeEvent to push a value into a flow variable, or FlowNavigationNextEvent to move the flow on.

From Apex, instantiate the interview and start it.

Map<String, Object> inputs = new Map<String, Object>{ 'recordId' => acc.Id };
Flow.Interview.Create_Support_Case f = new Flow.Interview.Create_Support_Case(inputs);
f.start();
String result = (String) f.getVariableValue('outcomeMessage');

State the constraint: only autolaunched flows start from Apex. A Screen Flow needs a user interface and cannot run inside an Apex transaction.

What the interviewer is actually checking

• Whether you reach for a Roll-Up Summary before building automation at all.
• Whether you know a Flow cannot run an aggregate query.
• Whether you can name the before save and after save split in Record-Triggered Flows.
• Whether you know Apex starts autolaunched flows only.

Lightning Web Components

Explain decorators in Lightning Web Components.

There are three, imported from lwc.

• @api makes a property or method public. A parent sets it, a change re-renders the child, and it is how App Builder and Experience Builder pass configuration in.
• @track is needed only when you mutate an object or array in place. Since Spring '20 all fields are reactive, so reassigning already triggers a re-render. @track on a primitive tells the panel you learned LWC from an old tutorial.
• @wire connects a property or function to a Lightning Data Service adapter or an Apex method.

import { LightningElement, api, wire } from 'lwc';
import getContacts from '@salesforce/apex/ContactController.getContacts';

export default class ContactList extends LightningElement {
    @api recordId;
    @wire(getContacts, { accountId: '$recordId' }) contacts;
}

The $ prefix makes the parameter reactive, so the wire runs again when recordId changes.

In the @wire decorator, can we use any other properties apart from data and error?

No. The object the wire service provisions has exactly two properties, data and error, and only one is populated at a time. Everything else lives inside data.

What you can vary is the shape around it. Wire to a function rather than a property when you need logic on arrival, and it receives { data, error } as its argument. Store the whole provisioned result, not just data, because refreshApex() needs it. And read LDS records with getFieldValue(record, FIELD) instead of walking data.fields.Name.value by hand.

wiredResult;

@wire(getContacts, { accountId: '$recordId' })
wiredContacts(result) {
    this.wiredResult = result;
    if (result.data) { this.contacts = result.data; }
    else if (result.error) { this.contacts = undefined; }
}

handleRefresh() { return refreshApex(this.wiredResult); }

What is the difference between imperative Apex calls and @wire in Lightning Web Components?

Use @wire for read only data that should load with the component and stay cached. Use imperative for anything that writes, anything a user triggers, and anything where you need the result before deciding what to do next.

The point our trainers repeat applies here. Candidates know the syntax of both and cannot say when each one runs. The panel asks "your wire is not firing, what do you check", and the answer is whether the Apex method is cacheable, whether the reactive parameter actually changed, and whether data is still undefined on first render.

When should Lightning Data Service be used instead of Apex?

Lightning Data Service, meaning lightning-record-form, lightning-record-edit-form and the lightning/uiRecordApi adapters such as getRecord and updateRecord, is the first choice for single record work.

Use it when you are reading or writing one record on one object, when you want field level security and sharing applied automatically with no Apex to audit, and when you want the shared client cache so two components showing the same record stay in sync instead of each issuing a query. It also consumes no SOQL governor limits, because nothing runs in an Apex transaction.

Go to Apex when you need multiple objects in one call, an aggregate query, server side logic before the return, DML across objects in one transaction, a callout, or an object the UI API does not support.

How do you use Lightning Web Components in Experience Builder?

Expose the component in its meta file.

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>62.0</apiVersion>
    <isExposed>true</isExposed>
    <targets>
        <target>lightningCommunity__Page</target>
        <target>lightningCommunity__Default</target>
    </targets>
    <targetConfigs>
        <targetConfig targets="lightningCommunity__Default">
            <property name="cardTitle" type="String" label="Card Title"/>
        </targetConfig>
    </targetConfigs>
</LightningComponentBundle>

lightningCommunity__Page allows the component onto a page. lightningCommunity__Default makes it configurable, so the properties declared in targetConfig appear in the builder's property panel for an admin to set.

What breaks in practice: guest and community users need explicit Apex class access on their profile, or the component renders and the data silently never arrives. Do not assume recordId is injected, pass it as a property. Use lightning/navigation rather than hardcoded URLs, because community URLs carry a site prefix. Third party scripts need a CSP Trusted Site entry.

How do you handle errors in Apex and Lightning Web Components?

On the Apex side, wrap risky work in try/catch and throw AuraHandledException with a message written for a user, since an unhandled exception reaches LWC as a generic internal server error. Define custom exception classes such as public class IntegrationException extends Exception {} so callers can catch the specific failure. In triggers use record.addError('message') to block one record and let the rest of the batch continue. Log through a Platform Event published immediately, because that record survives the rollback that erased everything else.

On the LWC side:

import { ShowToastEvent } from 'lightning/platformShowToastEvent';

async handleSave() {
    try {
        await saveContact({ contact: this.contact });
        this.dispatchEvent(new ShowToastEvent({ title: 'Saved', variant: 'success' }));
    } catch (error) {
        this.dispatchEvent(new ShowToastEvent({
            title: 'Error',
            message: error.body ? error.body.message : error.message,
            variant: 'error'
        }));
    }
}

For wired calls, handle the error property. Implement errorCallback(error, stack) in a parent so a child's render error does not blank the page. Use a reduceErrors utility, because Apex errors, page errors and validation errors arrive in different shapes.

What the interviewer is actually checking

• Whether you know fields are reactive without @track on current API versions.
• Whether you can explain why a wire is not firing.
• Whether you reach for Lightning Data Service before writing Apex for a simple edit form.
• Whether you have actually shipped a component to a community, which the guest user Apex access point reveals at once.

Security, deployment and performance

What are the best practices to be followed while creating Profiles in Salesforce?

• Start from Minimum Access - Salesforce, not from a clone of System Administrator. Build up, never trim down.
• Keep in the profile only what a profile alone can do: login hours, IP ranges, default record types, page layout assignment and the licence.
• Put everything incremental into Permission Sets, grouped into Permission Set Groups with muting for exceptions. That is the direction Salesforce itself is taking, and it lets one profile serve many roles.
• Create as few profiles as possible. One per department becomes a maintenance problem within a year.
• Never grant Modify All Data or View All Data to solve a visibility problem. Sharing rules and Sharing Sets exist for that.
• Review with the Field Accessibility tool rather than by reading the profile page.

What common deployment issues have you faced in Salesforce, and how did you resolve them?

This is scored on specificity. A generic answer reads as someone who has never run a release.

The answer that lands is one specific incident told in order: what the deployment was, what error appeared, what you checked, what you changed, what happened next. Our trainers call this Situation, Approach, Reason, Result. It replaces the rambling "basically in our project we had one requirement" opening that makes a panel stop listening.

How do you optimize performance in Apex and Lightning Web Components for large data volumes?

In Apex, make queries selective by filtering on indexed fields, which means Id, Name, OwnerId, CreatedDate, SystemModstamp, external Id, unique and lookup fields, plus any custom index you request through support. Avoid filters that defeat the index: leading wildcards, !=, NOT and null comparisons on unindexed fields. Select only the fields you use, because every extra field costs heap. Replace nested loops with Map lookups, since a nested loop over two large lists is the usual cause of "Apex CPU time limit exceeded". Past 50,000 records move into Batch Apex with a Database.QueryLocator, which streams in chunks and resets limits per chunk. Avoid OFFSET for deep paging, since it caps at 2,000, and page on a sorted Id or CreatedDate boundary instead.

In LWC, never return ten thousand rows to the browser. Page the data, or use lightning-datatable with enable-infinite-loading. Mark read only Apex methods cacheable=true so the client cache serves repeat calls. Move computation into getters rather than the template, and keep expensive work out of renderedCallback, which runs on every re-render. Debounce search inputs. Send a narrow payload, because a wrapper class with the six fields the table shows beats returning full sObjects.

What the interviewer is actually checking

• Whether you build permissions upward from Minimum Access.
• Whether your deployment story names a real error and a real fix.
• Whether you know which fields are indexed and what makes a query non-selective.
• Whether you think about payload size and caching, not only about Apex.

Closing

The pattern across all 25 questions is the same. Deloitte panels do not test whether you can define a wrapper class or recite a governor limit. They test whether you can write the aggregate trigger with the delete case handled, explain why the null filter belongs in the semi-join, and describe one deployment that went wrong and what you did about it.

Prepare in that order. Take each question here, write the code in a Developer Org, break it on purpose with 200 records, and fix it. Then rehearse one real example for every claim on your resume, structured as Situation, Approach, Reason, Result. A panel that goes four questions deep on a single resume line is looking for the point where the story runs out.

For structured practice on the Apex, trigger and LWC material these rounds go into, our Salesforce training in Pune with placement support covers the same ground with live project work and mock interview rounds run the way the panels run them.