Quick answers to key questions

Short answers to the questions above, so you can revise quickly before an interview.

Security, Apex and triggers

• With sharing and without sharing. A class declared with sharing respects the sharing rules of the running user. A class declared without sharing ignores them and can see all records. inherited sharing uses the setting of the calling class. Always declare the keyword on purpose instead of relying on the default.
• Before and after triggers. Use a before trigger to validate data or change fields on the record being saved, because no extra DML is needed. Use an after trigger when you need the record Id or want to create or update related records.
• Data security model. Access is controlled in layers. At the org level there are login hours, IP ranges and password policies. At the object level, profiles and permission sets give create, read, edit and delete access. At the field level, field-level security controls visibility. At the record level, OWD, role hierarchy, sharing rules, manual sharing and teams decide which records a user can see.

Trigger: update AccountEmail__c from a Contact

Collect the Accounts of the Contacts that have a new or changed email, query those Accounts once, and update only the ones where AccountEmail__c is empty.

trigger ContactEmailTrigger on Contact (after insert, after update) {
    Map<Id, String> emailByAccount = new Map<Id, String>();
    for (Contact c : Trigger.new) {
        if (c.AccountId != null && c.Email != null) {
            if (Trigger.isInsert || c.Email != Trigger.oldMap.get(c.Id).Email) {
                emailByAccount.put(c.AccountId, c.Email);
            }
        }
    }
    if (emailByAccount.isEmpty()) return;

    List<Account> toUpdate = new List<Account>();
    for (Account a : [SELECT Id, AccountEmail__c FROM Account
                      WHERE Id IN :emailByAccount.keySet()]) {
        if (String.isBlank(a.AccountEmail__c)) {
            a.AccountEmail__c = emailByAccount.get(a.Id);
            toUpdate.add(a);
        }
    }
    update toUpdate;
}

SOQL on a hierarchy of objects (A to F)

• From F up to A (child to parent). Use dot notation through the lookup fields. SOQL allows up to 5 levels, and A is 5 levels above F, so it fits. For example SELECT Id, Name, E__r.Name, E__r.D__r.Name, E__r.D__r.C__r.Name, E__r.D__r.C__r.B__r.Name, E__r.D__r.C__r.B__r.A__r.Name FROM F__c. The relationship names depend on your fields.
• From A down to F (parent to child). Use nested subqueries on the child relationship names. Recent API versions allow several levels of nested subqueries, so check the limit for the API version you use.

Lightning Web Components

• Public properties and methods. A property or method marked with @api is public. A parent component can set a public property through an HTML attribute and can call a public method from its JavaScript. A child should not change its own public property directly, because the parent owns that value.
• Shadow DOM. It keeps the DOM and CSS of a component private, so styles do not leak in or out and other components cannot reach into its markup by accident.
• Lifecycle hooks. constructor, connectedCallback (component added to the page), render, renderedCallback (after rendering), disconnectedCallback (removed) and errorCallback.
• LWC and Aura. LWC is built on standard web components and modern JavaScript, so it is faster and easier to learn. Aura is Salesforce own older framework. You can place an LWC inside an Aura component, but not the other way round.
• Lightning datatable. A base component that shows records in rows and columns. It supports sorting, row selection, row actions, inline editing and infinite loading.
• Events in LWC. A child talks to its parent with a custom event. Events have bubbling and capturing behaviour controlled by the bubbles and composed settings. Application events belong to Aura. In LWC, unrelated components communicate through Lightning Message Service.