The Cornerstone Hiring Screen

Every résumé for your open role says Cornerstone administrator. Some of those candidates ran the system: they made changes, broke things, fixed them, and were the person whose phone rang when a release landed badly. Others watched it run from the next desk over. The difference doesn’t show up on a résumé, and it usually shows up on the job about six weeks after the start date.

Nobody on your panel needs to know Cornerstone to tell them apart. You need six questions and one thing to listen for.

Listen for method. Ask any of these six and you’ll get one of two kinds of answer. Some candidates describe an outcome: what they did, that it worked. Others describe a sequence: first this, then this, and here’s why that step is in there. The second kind ran the system. Every step in their answer is scar tissue from a time the step wasn’t there, which is why a longer answer is usually the better one here. Count the steps.

Ask them in the order below. If you only have time for three, ask the first, fifth and sixth. Each comes with the terms a real answer tends to contain. You don’t need to understand every term; you need to notice whether any of them show up unprompted.

1. Making a change that reaches thousands of people

Ask: “Tell me about the largest learning assignment you’ve submitted. How many people did it reach, and walk me through everything you did before you clicked Submit, and everything you did while it ran.”

Push for the whole list. This is the question where you want them to run long.

A good answer is a checklist, and the number of steps in it is the signal. Listen for:

Generating the user list from their criteria and actually reading it before submitting, rather than trusting that the criteria mean what they think they mean. Most candidates skip this one.
Checking the count against what they expected, and knowing that the preview number comes from cached data, so a reorganization in the last day or so can make it lie.
Checking whether Assign New Occurrence is switched on or off. That one setting decides whether people who already completed the course are handed it again, and getting it wrong is how thousands of people are told to redo training they finished last year.
Reviewing the email configuration before submitting, because that’s the part that cannot be recalled.
Testing on a small group first.
Choosing the timing deliberately. Not a Friday afternoon, not the week a release lands.
Verifying the result afterwards in Reporting 2.0, against the actual learning records, rather than trusting the assignment summary screen.

Push hard on this one, because the stakes here are lopsided. A large assignment doesn’t process instantly: a few thousand people takes hours, and the count climbs while you watch. If it’s wrong, it isn’t a quiet mistake you fix on Monday. The emails have already gone. Thousands of people have been told they have mandatory training they don’t need, their managers are asking, and the fix is now a communications exercise: pull the assignment, work out exactly who was hit, and write to them individually to explain. That work lands on whoever pressed the button.

It’s also only partly reversible. Removing training from people’s learning records never removes completed ones. A recurring assignment has to be switched off before anything can be pulled back at all. And a custom email attached to an assignment keeps firing even after the assignment is switched off: one message per course per person, with no way to stop it after the fact. Thirty thousand emails is a real number, and the people who’ve caused it never forget.

The weak answer is a short one. Two steps and a shrug. Describing the wizard rather than the checks around it. Assuming a bad assignment can simply be undone. Confidence without a scar is the tell here.

2. Proving compliance to an auditor

Ask: “An auditor asks you for proof that everyone who was required to has completed their compliance training. Walk me through what you do first, and how you get to a number you’d put your name on.”

Note what this question doesn’t ask: how long it takes. Speed is the wrong thing to reward. Cornerstone holds far more data than any auditor is asking for, and a fast answer to the wrong question is worse than a slow answer to the right one. It looks defensible right up until someone checks it.

A good answer doesn’t open Cornerstone first. It goes back to the auditor with questions, because the scope is what determines whether the number means anything. Listen for them asking:

Which population, exactly? Headcount as of what date? Leavers? Contractors? People on parental leave or long-term absence? New joiners who haven’t hit their deadline yet?
Which date range, and is it the assignment date, the due date or the completion date that matters?
Latest version only, or any version? A course reissued mid-year splits completions across editions, and the two answers differ by a lot.
What if someone took it more than once? First completion, most recent, or every instance: three different numbers from the same data.
Do people marked Exempt count as compliant, or as gaps? That’s a policy question rather than a reporting one, and the auditor may have a view.
What does the evidence need to look like? A headline count, a named list of the gaps, or per-person proof with dates.

Only then do they build the report, and a strong candidate can tell you why each filter is set the way it is. The best ones sanity-check the output against something independent before sending it, and they know the small trap: run the report to yesterday, not today, because someone whose HR data refreshed this morning can come back with blank fields.

A weak answer goes straight to a report and gives you a number and a timeframe. There is a standard report, and it will produce something. Audits are failed on scope and exceptions, and this answer has thought about neither.

3. Handling a system update they didn’t schedule

Ask: “Cornerstone ships three releases a year, in March, July and November. The July release has just landed. Walk me through how you handled it, start to finish.”

The answer you want is a process, not a reaction. Listen for the sequence:

Reading the release material early, and reading past the headline notes to the New and Enhanced Permissions list and the Defect Fixes That Cause Functional Change list. The second is where a bug fix quietly alters something your users depended on.
Testing in Stage, the environment that receives release code about four weeks before real users get it, and requesting a copy-down (a refresh of Stage with current live data) before the testing window opens, because you can’t do it once testing is underway.
The permissions decision, which is the half most candidates skip. Every release adds new permissions, and someone has to decide who gets them and why. Listen for how that call was made: which roles genuinely needed the new access, what limits were applied, who approved it, and whether it was written down. A candidate who granted new permissions to a role because the release notes mentioned them has told you something important.
Governance. Was there a change process? A sign-off before anything reached live? A record of what was turned on and when? In a regulated environment this is the difference between a clean audit and a finding, and candidates who’ve worked under one talk about it naturally.
Communication. Who told the users something moved, and when?
What they checked afterwards to confirm nothing regressed.

Also listen for Feature Activation Preferences, the page where opt-in features get switched on, some of them permanently. Knowing which changes are forced and which are a choice is most of what managing a release you didn’t schedule actually involves.

A weak answer is “we read the release notes,” or naming Pilot as the test environment. Pilot is a permanent sandbox and doesn’t carry release code at all. There’s a second weak answer that’s more common and harder to spot: a candidate who tested carefully but had no process around who gets new permissions. That’s the half of release work that produces audit findings a year later.

One fairness note. “Nothing ever broke for us” is not disqualifying. Plenty of releases are uneventful. The tell isn’t whether something broke, it’s whether they can tell you where they went looking.

4. Diagnosing an access problem

Ask: “Tell me about a time someone could see something they shouldn’t have, or couldn’t see something they should. Walk me through how you found the cause, and how you knew your fix had worked.”

Good answers start with evidence, not a hypothesis. The sequence to listen for:

Getting specifics from the user first: a screenshot, the exact wording of any error, what they clicked, what they expected, and when it last worked. Candidates who’ve done this a hundred times ask for a screenshot reflexively, because half of these reports turn out to be a different problem than the one described.
Reproducing it with Proxy as User, logging in as that person to see exactly what they see rather than guessing from the administrator’s view. This is the step that separates the two kinds of candidate. The admin view and the user view routinely disagree, and diagnosing from the wrong one wastes a day.
Then working the layers in order. Roughly ten independent controls decide whether a person sees a course, and a strong candidate names three or four unprompted: does this person have the permission at all; what limits are attached to it, narrowing it to a division or location or a manager’s team; what availability is set on the course itself; and has the group used in that availability actually rebuilt yet. Groups refresh on a schedule, at most four times a day, so a correctly configured person can still be locked out for hours through nobody’s fault.
Using Permissions Constraints Details to see what someone’s permissions resolve to once all their roles are combined, rather than reading each role separately and working it out by hand.
Confirming the fix the same way they found the problem: proxying back in to check, and having the user log out and back in, because some changes don’t take effect until the next login.

A weak answer theorizes from the admin screen without ever reproducing the problem, or opens a support ticket as the first move. One honest exception: Proxy as User genuinely cannot be granted by an administrator, and enabling it requires a support case. That specific answer is correct. But if support is the first move on every question, you’re hiring a ticket forwarder.

5. Changing what a group of administrators can do

Ask: “Tell me about a time you had to change what a group of administrators could do, not one person but a group. Walk me through how you decided who should get what, how you made the change, and how you confirmed it took effect.”

This is the hardest question here and the one that separates candidates most reliably. There are three parts to a real answer, and weak candidates only have the middle one.

Design: how they decided who gets what. Listen for a method. Strong candidates map job function to access: what does this group actually need to do, what’s the minimum that allows it, who signed off. Weak candidates copy an existing administrator’s access and hand it out, which is the most common way permission sprawl starts and is almost impossible to unwind later.

Listen too for parent and child roles. Cornerstone lets roles inherit from one another, and a child role can only hold permissions its parent already has. That shapes the whole design, and it means removing a permission has to be done bottom-up, from the child first and then the parent. Candidates who have built a role hierarchy know this because it has blocked them mid-task.

Execution: the trap sitting in the middle of it. Security roles have no bulk path: no import file, no spreadsheet upload, no published interface for editing roles at scale. Everything is by hand, one role at a time. And the behavior is counterintuitive in a way that catches almost everyone once. Adding or removing a permission from a live role takes effect immediately for everyone already in it. But changing a limit reaches nobody already holding the role. Those people keep their old access until each of them is individually removed from the role and added back. There is no button that pushes it through.

Someone who has done a real role cleanup volunteers this without being asked, usually with a number attached, because it turns a ten-minute edit into a week of work.

Also worth hearing: what happens when someone holds the same permission through two different roles, and the choice between combining the limits, replacing them, or leaving them alone. Replacing can silently widen access rather than narrow it, if the incoming role carries no limit. And the Default Role for Every User, which cannot be switched off and which every person in the system holds, so editing it is never a small change.

Verification. The Security Role Audit Report shows who changed which role, when, and what the old value was. Strong candidates also spot-check a sample of real users afterwards rather than trusting the save.

A weak answer is “I edited the role and it was done.” That’s wrong in a way that has consequences: it describes someone who changed a limit, saw it save, and assumed it applied, while a group of administrators quietly kept access they were supposed to lose. It stays invisible until an auditor finds it.

If a candidate tells you this work is slow, manual and easy to get wrong, believe them. They’re right, and they’ve done it.

6. Making the system do something new, without help

Ask: “Once a month you need to find everyone overdue on a required course and act on that list: move them into a group, update a field, flag them. Your IT team says nothing outside Cornerstone. No scripts, no middleware, nobody moving files by hand. Can it be done, and how?”

Save this one for last. It’s the only question here with a right answer: it can be done, entirely inside the platform, and very few administrators know how.

The construction is a loop. Schedule a report to deliver automatically to your Cornerstone file server on a recurring basis, then point a scheduled import feed at that same folder to collect the file and load it back in. The report goes out, the data comes back in, and nobody touches a file.

A good answer gets to that shape and can name what makes it work. Each of these is a place it fails silently:

The report is built with calculated fields to match the import template exactly. This is the technique the whole thing rests on, and the part that separates people who’ve built it from people who’ve heard of it. The importer will not reshape anything, so the report has to emit the precise columns the template expects, named the way it expects them, which means constructing those columns rather than just selecting existing fields.
Delivered files carry a timestamp in the filename, so the feed matches on a filename prefix rather than an exact name.
The two schedules have to be sequenced so the report has landed before the feed runs, with margin for delivery lag.
The feed consumes the file when it runs, which is what stops files accumulating. Two files landing before a single run will stall it.
Delivery is tied to the report’s creator. If that person is deactivated, the whole chain stops, and nothing announces it.

The best answers reach the failure modes before you ask. Someone running this in production knows it breaks quietly rather than loudly, and can tell you what they watch to catch it.

A weak answer comes in two shapes. One is “you’d need a developer,” or “you’d need middleware,” from an administrator who has only ever operated the parts of Cornerstone that have a button. The other is a vague yes: gesturing at reports and imports with none of the mechanics, which is folk wisdom repeated from a forum rather than something they built.

Candidates who can build this are rare. They’re also the ones who stop asking IT for things.

How to use these

Count the steps. On every question here, the person who ran the system gives you a sequence and the person who watched gives you a result. When an answer sounds good but short, ask “and what did you check before that?” Then ask it again. Two layers down is where the difference lives.

Watch for one failure mode in yourselves, too. These questions are more technical than most interview questions, which means a confident wrong answer can beat a correct hesitant one when you’re going from memory an hour later. Write answers down close to word for word rather than grading them in the room, and compare notes before anyone anchors the group.

And when a candidate answers all six well, move fast. Good Cornerstone administrators get hired quickly.

One last thing. These six questions are, quietly, a map of the role itself: changes that reach everyone at once, audit evidence, updates arriving on someone else’s schedule, access problems, the administrative work the platform won’t help with, and what it will do once someone knows how to ask. Whoever you hire owns all of it from day one.

Keep this page after the interviews. It’s a fair checklist for asking, six months in, how the role is really going.

GroveDeck is an independent firm with no candidate to sell you. We run Cornerstone for companies as an ongoing managed service, and the work behind questions five and six (role redesigns, release governance, building automation inside the platform without scripts or middleware) is most of what we get called in for. Some teams take that instead of filling the role. Either way, this page makes your interviews sharper.

If you’d like a second read on an answer a candidate gave, send it over. No pitch.

Six questions that tell you who really ran Cornerstone