A strict interpretation of "deliver business value" implies that your candidate needs to have worked on the right piece of software to begin with, and have an idea how their work actually affected the bottom line.
That kind of thing is mostly outside of anyone's control. If you ask your candidate to demonstrate how they've "delivered business value" in the past, you're basically asking them how lucky they were.
This sort of question is mostly asked to understand if you know/care how your work impacts the bottom line.
For my part, I worked on many things, and have no idea how it impacted the bottom line most of the time. I mean, I believe I had a positive impact most of the time, but don't ask me about the magnitude of that impact. I'm a programmer, not an accountant.
Besides, I do care about having a positive impact. It's just that most of my criteria are not directly measurable in $$$. Its' more about user happiness, maintainability, reliability… and some of those priorities may even be at odds with the bottom line (lack of quality is often an externality[1]).
It's more "Did something a manager considered useful."
Of course you get people who can invent or re-engineer processes that add huge amounts of book value, but they're rare.
Generally if you find someone more competent than average who also has business awareness, the business value will take care of itself. Especially if they're well managed.
Conversely you want to avoid devs with absolutely no business awareness at all. They'll spend all their time tinkering with the new hotness for the sake of it, and usefulness will not ensue.
" A traveler came upon three men working. He asked the first man what he was doing and the man said he was laying bricks. He asked the second man the same question and he said he was putting up a wall. When he got to the third man and asked him what he was doing he said he was building a cathedral."
I get that you're not an accountant. However, I want to know that you understand the impact of your work. Someone who understands the larger picture will be able to cogently argue why this technical debt or bug is more important than that technical debt or bug. It's also the job of product to understand it, but the best product teams I've been a part of have multiple team members who understand the business impact.
Sometimes, you'll be lucky and say that your feature contributed a million dollars to the bottom line. That's luck to some extent. However, I'm more interested that you understand the business context outside your individual work.
The industry is a complicated place with massive resources wasted on projects that go nowhere.
Honestly I'd be ok with an answer along the lines of "I got moved onto a project that, for $reason, had no chance of ever seeing the light of day. It was obvious why it wouldn't survive, but the business needed to keep it alive because $other_reason. Even though we never shipped, we met objectives $x and $y, we struggled with $z, and we learned quite a bit about $w. After the project was finally killed, we were able to apply what we had learned to other projects."
This at least demonstrates that the candidate understands how the project related to the business, how they can relate some of the technical aspects to business processes, how they acknowledge their failures, and how they extracted some success from a failure to apply to future efforts.
It allows us to have a conversation about different aspects of the project -- technical, business, interpersonal / political, etc.
I've been on projects across the spectrum from "never-shipped death march" to "mature cash cow", through various levels of team & management dysfunction, and I probably learned as much from the horrible failures as I have from the successes.
What can you tell me about your last job?
Well, I overhauled the configuration GUI.
How did that impact sales?
Err, I don't think it did. It's not a feature we showcase.
Did you at least made the product better?
Actually, no. It just made it more complex and brittle.
Wait, you made the product *worse*?
Could not help it, the execs insisted on XML compatibility.
Maybe they needed it?
No, we had total control over our configuration files.
Why didn't you tell them?
I did. They wouldn't listen.
Why not? You're the expert, you should have convinced them.
...
I mean, here we need people who can deliver business value.
Well, this time I couldn't. They wouldn't let—
How would you rate your communication skills?
Err, good I guess?
Yet you couldn't convince management?
...
If that line does not look like a strong "hire" signal to you, there's something wrong about you.
Anyway, I think the large majority of the people I've seen interviewing anybody (including me) would use it as a "no hire". I guess I wouldn't want to hire the large majority of people I've seen conducting an interview...
E.g. I’m pretty certain you’re not advocating for hiring developers who can’t have a civilised disagreement, yet you don’t list anything about collaboration or communication or ability to put team before self in pursuit of a common goal.
Hiring well is hard to do fairly and accurately. There’s no pithy shortcut that can be wrapped up in a blog post.
About the best I’ve managed to go in 15 years of hiring is recognise that i have biases and recognise that I’m not always that good at seeing my biases.
- the ability to code with quality
- the ability to learn and grow
- track record to deliver business value
In my experience, people are wasting too much resources on interviewing. And the process is never meant for more senior positions. Engineers don't like it, and the outcome cannot be falsified (what if we hire someone with a light weight process, would it turn out worse?) I am saying specifically about interviewing, as opposed to hiring in broader sense. What you want is a process that evolve with your demand/available resource, not hardcoding of 2 sessions of coding (oh and with shadowing, so to grow interview skills of the team, of course!), 1 session of architectural design, 1 experience deep dive, whatever. Is this topic something people are interested in though? I might try to write up the thinking behind our process