Interviewing in general can be pretty awkward, and when someone isn’t trained or practiced interviewing, it can leave a lot of questions. How do I test this person’s skills? How do I test their decision-making abilities? Will they be able to work with our design philosophy? Do they know what they’re doing?
The approach that I like to take is very simple, and straightforward questions. Things like “How do you make a field required, but only once an Opportunity reaches the Contracting stage?”
When I ask a question like this, I’m looking for 4 things:
- Can the interviewee answer the question?
- Can the interviewee describe other solutions? And can they describe the benefits and caveats to the solutions they have proposed.
- Can the interviewee describe the impact of those changes to the data in Salesforce?
- How do those changes impact a user’s workflow?
Can the interviewee answer the question?
The first criteria is pretty typical. It’s a simple question, so an admin with a rudimentary understanding of the system should be able to answer it. Using the example question, we can say with confidence that you would use a validation rule to require the field be entered when the Opportunity stage reaches contracting.
This takes us to part two…
Can the interviewee describe other solutions?
Can the interviewee describe other solutions and the benefits or caveats to these solutions? There’s almost always a few different ways to solve problems in Salesforce, and an interviewee’s ability to describe these different options goes a long way toward understanding whether they know the “by-the-book” answer, or whether they understand the platform well enough to work around business rules or an environment’s own obscurities.
By extension of this, we want the interviewee to be able to understand the pros and cons of the proposed solutions. A validation rule handles this job perfectly, but has its own usability quirks. In my other post, I likened Validation Rules to a hammer, and that they’re often the first mechanism people run to for controlling input in lieu of other solutions. There are other options available, including:
- Using record types and page layouts to require input at different stages
- If the field is a pick list, we can use field dependencies and the required field checkbox to require selection after the contracting stage
- Apex can also be used for restricting/requiring input
- Utilizing proper field types that match the expected input and then using formula fields when we need to convert those values
Each of these has its own caveats:
- Record types is messy on the admin side and requires automation to convert between types
- Field dependencies really only works on picklist types
- Apex is much more complex and suffers from the same after-submission error messages that validation rules do
- And proper field typing requires you to be aware of the requirements before the field is created, or else a data migration is required. It also requires extra fields for the formulas if needed.
They also have their own benefits:
- With varying record types and page layouts you can change how information is presented and hide anything which is no longer relevant
- Field dependencies communicate expectations to the user up-front, rather than waiting for them to submit and requiring them to correct the mistake
- Apex can be infinitely more complex than the other solutions
- Proper field typing also communicates expectations to users up-front
It’s less important to know all of the solutions than to be able to recognize that other solutions exist, and be able to justify why you chose the solution you did.
Can the interviewee describe the impact of those changes to the data in Salesforce?
When a new field or automation is added to Salesforce, a pivotal question is whether the change will be a running change or if it also needs to be implemented retroactively. Understanding that a new validation rule which requires that a Closed Date cannot be set 1 week in the future has down-stream consequences is important.
Perhaps this business rule is new. Maybe there are a number of Opportunities out there which would not pass this validation rule. What happens then? What happens when a marketing resource changes an unrelated field on the Opportunity? Do we add an IsChanged expression to our formula so they don’t have to make the correction for the Sales Manager? Do we do a data load to clear out any Close Dates which are too far in the future? Or do we notify Sales in advance to update their close dates? And what happens if it’s not a close date, but another field instead where closed Opportunities might not pass the criteria going forward? If we have to data load or batch process them in the future, we may get blocked by this failing validation rule.
It’s once again far less important that the interviewee can come up with all these examples off-the-cuff, but important that they can talk through these and understands that every change and decision has consequences going forward.
How do those changes impact a user’s workflow?
The last piece is secretly one of the most important. In order to maintain a good relationship with the business and continue to grow your team, you have to be able to provide a tool that teams can use. Admins aren’t creating something they use day-to-day. They’re building something that the business users have to use day-to-day. That means considering how non-technical users will interact with the system, and ensuring that their experience is as easy as possible. Ensuring that the interviewee understands how their changes impact the user experience and how to mitigate and speed bumps that the change may create is critical to ensuring continued buy-in from the business and a happy, working relationship with the business going forward!
Example Interview Questions
I’ve gone ahead and written out some example questions, including the types of responses I look for in my other post, found here:
9 Example Admin Interview Questions
One thought on “How to Interview A Salesforce Admin”