Salesforce technologies are ever changing and the demand for skilled professionals seems never ending, so whether you’re just getting into Salesforce development, or are as much of a veteran as SaaSy, one thing remains true when looking for that next role in your career and that is acing the job interview.
Going into your job interview with a good understanding of the platform (which of course should deepen based on the seniority of the role!) is a great way to get an advantage over other candidates. Below is a series of questions I’ve personally used in the past when interviewing candidates of all skill levels, which I’m sharing in hopes of helping out anyone with a potential interview to better understand the types of questions and expectations a technical interview may have.
The Lightning Frameworks
1. What are the different programming models available for Lightning components?
There are 2 different programming models available for Lightning components. The first is utilising the Aura framework to build out Aura components, the second is utilising the newer Lightning Web Components (LWC) framework.
2. Why would you choose one programming model over the other?
Lightning Web Components should be the go-to approach for development due its increased performance, ease of development and alignment with modern web standards. However, there are some scenarios where Aura components are still required, as of Summer ’21, these include building community templates and URL accessible components, although LWC is quickly reaching feature parity.
3. How can we develop these components/what tools must we use?
Aura components can be developed directly in Salesforce using the developer console, although third party IDEs (such as VSCode using SFDX) greatly improve developer efficiency.
LWCs can only be developed using third party tools, which Salesforce recommends VSCode and their extension pack.
4. How do the two programming models coexist?
Aura components can contain and utilise LWCs, including communicating with them via events and component methods. However, the opposite is not true, an LWC cannot be composed of Aura components, and they can only ever be its parent.
Code can also be shared between Aura and LWC components using an ES Module.
5. Where can we use Lightning components?
Lightning components can be used in a myriad of places, from drag and drop components making up Lightning App Builder pages, to quick actions launched via buttons on record detail pages. Components can also be exposed as tabs or URL addressable for extra customisation.
Alongside the most common places mentioned above, there are some more niche places Lightning components can find themselves, including:
- The Utility Bar
- Outlook and Gmail integrations
- Flows
- Visualforce pages
- External web pages
- Pre-chat snap-ins
Development Basics
6. What data types can we use within Lightning components?
Within Aura components we can use any of the basic data types, e.g. String, Boolean, Date, Object etc and arrays of those datatypes. We can also define Aura attributes to hold SObjects and move advanced datatypes such as functions, Apex defined datatypes and we can define an attribute which can store other components.
In LWC, things are a lot more straightforward, since we do not need to define data types on our attributes. This means that an attribute of an LWC can hold any JavaScript data type – for example, we can hold all the standard data types, functions, HTML Nodes, Promises and anything else that we may require.
7. What does the “this” keyword signify?
The “this” keyword can be found in both Aura and LWC, and their uses are quite similar. Within LWC, the keyword can be used to access any component property or method – since “this” points to calling context of the current code – which in most cases will be from within the LWC.
In Aura however, the “this” keyword does not point to the component context, instead we use the keyword from within our helper to reference other helper methods – this works for the same reason as in LWC, since the calling context is our helper.
8. How can we express data into our HTML markup?
If we wish to express data within our HTML markup we need to use bind expressions. The syntax differs between LWC, as do the capabilities.
In Aura we use can use one of two syntaxes, “{!v.value}” and “{#v.value}”. The first enables two way data-binding (i.e. if you update it in one location, the other is also updated) and the second is for one way binding.
In LWC, we have a single syntax to follow, simply by using “{value}”.
Alongside simply displaying pieces of data, we can also use conditionals and iterations to manipulate the final markup. For simple “if” logic we can use “aura:if” in Aura and “if:true”/“if:false” in LWC. For displaying arrays, we can use “aura:iteration” in Aura or “for:each” in LWC, both of which work similarly by taking a piece of markup contained within them and repeating it once for each item in the array.
9. How can we make our components admin configurable?
Both Aura components and LWCs can expose component properties into the Lightning App Builder and Experience builder screens for further customisation by admins as they see fit. We can also further limit where our components appear, preventing record-based components from appearing on the incorrect object pages.
For Aura components we have a design resource file, which is where we define these. We do so by specifying a “design:attribute” for each “aura:attribute” we wish to be customised. We can also use “sfdc:objects” to limit the objects which the component can be used on.
For LWC, we define our customisable properties from within the “.js-meta.xml” file which is found inside all LWC component folders. We do this by defining “property” tags within “targetConfigs” tags. LWC offers us far more flexibility than Aura does, allowing us to define individual properties to be exposed based on the target context (i.e. record page vs app builder page). Also, as within Aura, we can define which objects the component should be limited to using “objects” tag.
10. How can we reuse code between our components?
To share code between Aura components, we create a service component. This is an Aura component which uses “aura:method” to expose the pieces of code which are to be shared. This component can then be included in other components and the shared pieces of code called.
For LWC, the process is simpler, we can create EcmaScript Modules. These are essentially JavaScript files which use the “export” keyword to export specific functions or variables we have defined. These can then be imported in the same manner we import Salesforce modules and freely used by our component.
User interaction and Events
11. How can we respond to user interactions?
Regardless of the framework used the answer remains the same, events. However, how we define how to handle these events differs slightly by framework, but both are required to define event handlers.
In Aura, we define handler code within our component’s controller. We can then tell our component to listen to and then run our code when the events are fired in several different ways. The simplest is to add an inline event handler on to the component that fires it. The second way is to add an “aura:handler” tag. Both expect to be pointed towards an action in the controller which handles the event.
Handling events in LWC is a much simpler affair than within Aura components since the events are standard JavaScript events. We can either use inline event handlers on the elements which fire it (or possibly even its ancestors if more appropriate!) or add event handlers to our component dynamically through JavaScript.
12. What are the different phases of events?
Events have two phases, Bubbling and Capture. The bubbling phase is where the event travels up the DOM to the very top, notifying event listeners on the way. This means the first event handlers to run are those on the innermost elements (e.g. closest ancestors). With capturing, the inverse is true, the event travels down from the top of the DOM, calling the outermost event handlers first.
By default, events fired by Lightning components bubble up and are only handled by its parent component, regardless of the phase.
Aura Application events also have a third phase, called the Default phase. In this phase the event handlers are called non-deterministically.
13. How can we configure event propagation?
When declaring events in LWC, we can provide additional parameters in the constructor of the CustomEvent to customise its behaviour. There are two parameters we can define which change the behaviour of the event, these are “bubbles” and “composed”. As the name suggests, bubbles allows the event to follow the standard bubbling behaviour and travel up through the DOM, by default in LWC this value is false. Composed, on the other hand, states that the event may pass through the shadow boundary and traverse the entire DOM tree up to the root, by default this is also false and only has an effect if bubbles is also set to true.
In Aura, we don’t explicitly define the event propagation behaviour, instead we can specify the phase to handle on the event handler instead.
14. How can we manage our events to improve the User Experience?
In situations where an event can be frequently fired based on a user interaction, it’s important we handle those events in a specific way so as to not cause a detrimental impact to the user’s experience. A good example for this is a search bar which filters a list when a user types into it, if we were handling the ‘onchange’ event, we would end up filtering after every keypress and this would cause the search to appear sluggish to the user. Instead what we want to do is set a timeout after every keypress, if the user continues to type within a small time frame (say 500ms), we simply cancel the previous timeout and start a new one. Now we only take the performance hit when we know the user has done something valid and the filtering appears smooth. This technique is called debouncing.
Component Styling
15. What is SLDS?
Salesforce Lightning Design System, or SLDS for short, is the framework behind the look and feel of Salesforce Lightning. It includes design guidelines for how components should work from a user experience point of view alongside HTML blueprints for components (including some that don’t exist as base lightning components). The most frequently used part of it, however, is the style sheets it provides which allow us to easily implement consistent styles within components.
16. How can we apply custom styles?
When the style classes provided by SLDS don’t meet our requirements, we are still able to provide our own styles to achieve what we need in both Aura and LWC. The process is pretty similar in both frameworks: we create a CSS file which matches the name of the component in its folder and place our styles there. In LWC, the styles of our components are completely encapsulated and don’t overflow into other components. In Aura we prefix all our styles with ‘.THIS’, but our styles can affect child components.
17. What is Flexbox and Grid in CSS?
Flexbox and Grid are two similar CSS layout modules, both of which can be used to build components with complex layouts and mobile responsiveness. We can define an element to be a container of a grid or a flexbox which allows fine control over the sizes and behaviours of its child elements. For the most part we can simply use the ‘lightning-layout’ base component to define a flexbox and then ‘lightning-layout-item’ to define its flexible children. For more complex positions we would want to define the classes ourselves and use a grid rather than a flexbox for a 2-dimensional layout.
18. How can we share styles between components?
CSS styles can be shared via static resources between both Aura and LWC, with components requiring the styles simply importing them with the Platform Resource Loader (in LWC) or ‘ltng:require’ (in Aura).
For LWCs, we can improve on this by instead using CSS modules. These are simply an LWC component which only includes a CSS file. This can then be imported into another component’s CSS file by using ‘@import c/myCssComponentName’.
The Wire Service and Lightning Data Service
19. What is the wire service?
The wire service is a data provisioning service which streams new data as it becomes available. It supports reactive variables, allowing new data to be provisioned as the context changes. The source of the data can either be from a Salesforce module, or a developer defined Apex class.
20. How can the wire service be used with Apex?
As with all Apex to be used within any Lightning component, the methods must first be set to be “Aura Enabled”, using the Apex annotation “@AuraEnabled”, exposing the method to the Lightning components. Furthermore, the annotation must be expanded to state that it is cacheable like “@AuraEnabled(cacheable=true)”. This annotation disables all DML operations, meaning the method only returns data, never mutates it. The method can then be imported into the LWC, like any other, and used as a wire adapter.
21. What is the Lightning Data Service?
The Lightning Data Service (LDS) is a set of Salesforce provided components, wire adapters and functions. It’s purpose is to manage data on our behalf, allowing us to easily read and write records and to reflect those changes in all other components utilising the LDS, be they standard Salesforce components, or our own custom ones built on top of this technology.
22. How can we use the User Interface API?
The UI API exposes a couple of wire adapters and several JavaScript functions we can utilise within our components as needed. This could be getting the page layout details for a specific object, or getting dependent picklists for a record type, all while respecting the sharing and permissions of the running user.
23. What benefits are there to using the UI API?
The main benefits to using the UI API are the same as using the LDS, we get cached data for improved performance and ease of data management, ensuring all our components are displaying the correct data. Alongside these, there is the added benefit of reducing the amount of Apex code written, e.g. we no longer need to write controller methods for simple record updates.
24. Why wouldn’t we want to use the UI API?
As good as the LDS and UI APIs are, there are some scenarios where we cannot use them, for example if we are working with groups of records, we would need to write our own custom Apex methods for retrieving data. However, that doesn’t mean we must use one or the other, for example, if we were required to update a single record from the list we retrieved via Apex, the UI API can satisfy that requirement.
25. Why wouldn’t we want to use the wire service?
The wire service is great at provisioning data to the client and keeping that cached, but when we are required to create or update records, the wire service offers us nothing to do so, since its purpose is entirely the provisioning of data. Another scenario is when we would like to trigger our Apex from a button, or some other user action. In both these scenarios, utilising imperative Apex is a much better choice, due to the increased level of control.
Debugging and Development
26. What tools can we use to ease our development?
There are several tools Salesforce provides for us to assist in development regardless of whether we are developing Aura components or LWC. The most notable of which is the SFDX extensions for VSCode, which provide us an IDE experience, far better than that of the Developer Console.
27. How can we debug our components?
There are several different ways we can approach component debugging, the fastest and most simple is to simply provide console logging statements to log variables throughout code execution, however this is an extremely limited approach and there are far better ways to debug our components. The first step is to enable “Lightning Debug Mode” to remove minification and provide better error messages. Alongside this, we can use our browsers debugging tools to provide breakpoints to examine the precise execution of code within our components, review variables at run time, and step through our code to better understand what’s going on and find what’s going wrong.
Bonus Questions
The following series of questions have no right or wrong answer but are a great way for an interviewer to understand how you work on a more detailed level. They give you a completely open platform to discuss and really flex those developer muscles, a great opportunity to make yourself stand out!
28. Tell me about a previous project you have worked on.
A very open-ended question for sure! The purpose of this question is to give you an open platform to discuss your previous pieces of work. Ideally, pick something recent that relates to the interviewer’s industry that you’re proud of. Don’t worry if you can’t match those criteria exactly! If you’ve trying to get your first developer role, think of past projects to go through that shows off your skills – if you’re new to Salesforce, it doesn’t even need to be a Salesforce project, for example if you were doing projects to help practice your skills, those are a great talking point.
29. What were the challenges you faced in that project?
Think back about the project and talk about what you found the most challenging aspects and why. Following this up with how you overcame them (be it some clever coding, or simply going to a senior for assistance) can really show off some of the soft skills us developers need to use. Don’t worry about the specifics of how you overcame those challenges, instead focus more on the journey and the learnings from that.
30. In hindsight, what would you do differently?
Be honest and open here, if you didn’t think something went well raise it and explain what you wish you’d done instead. The point of a question like this is to show that you can learn and improve from previous experiences, so take a little time to reflect on previous projects!
Summary
Hopefully, the above questions have provided a bit of an insight into the mind of a technical interviewer. These questions are not an extensive list, and every interviewer will have their own style and pool of questions to draw from.
These may range from the more technical ones, which are a good chance to show off your understanding of the platform and the different toolsets on offer when we develop (e.g. the Lightning Data Service), to ones with an intention to better understand how you think, approach a challenge and you as a person (e.g. the bonus questions, my personal favourite!).
Check out some of our other Salesforce interview questions below…
- 30 Salesforce Admin Interview Questions & Answers
- 30 Salesforce Developer Interview Questions & Answers
- 50 Most Popular Salesforce Interview Questions & Answers
Comments: