This month, CyRise Elevate was joined by guest advisor Hugh Williams. Hugh spent several years in the US working in technical executive roles at Google, eBay and Microsoft, and is currently Melbourne Business School’s first Melbourne Enterprise Professor.
Hugh is an advisor to many companies, including Domain (AUS) and Doordash (US), is on the Board of the State Library of Victoria, and is a Venture Partner at Rampersand. He has been a CEO of his own start-up, and also co-founded CS in Schools, a philanthropic venture that helps teachers teach coding in secondary schools.
In addition to his business and charitable achievements, Hugh also has serious technical credentials as well, with a PhD in Computer Science from RMIT University and more than 120 published works, including over 33 US patents.
Below is an edited conversation from our latest CyRise Elevate session, where we invited Hugh to share his wisdom on hiring incredible tech teams.
What are the key characteristics that you look for in candidates when you’re interviewing?
I worked at Microsoft for quite a while, and they loved using the Lominger Competencies. It’s a long list of characteristics of people, things like humor, charisma, integrity, empathy. If we went to an interview or training at Microsoft, feedback would be based around these competencies. They also use them to evaluate people as they moved up the job ladders, and where you were on the scale, etc. And now I’ve become a huge advocate of these competencies too – they are so useful.
The four that really matter if you’re hiring a software engineer are:
- Intellectual horsepower – is the person off-the-charts smart?
- Are they good problem solvers? Because that’s what computer science is: solving problems.
- You want people who are action-oriented. People who just want to start, go do stuff, build things.
- People ought to be driven for results. They want to deliver, they want to change the world.
And of course – you don’t want people who are deficient in integrity, or collaboration, or the other competencies. All of the competencies matter. But, we want magic with those four: intellectual horsepower, good at problem solving, action-oriented and being results-driven.
So, if you’ve got somebody who’s a computer scientist, and well above average on those four competencies, then that’s the kind of person that is likely to succeed at Microsoft. And that’s all I’ve ever done when I’ve worked for any company since. Anytime I get a chance to do advisory work, help hire a CTO, whatever it is that I’m doing… I’m like right, I’m just gonna figure these four things out.
So, if you were hiring – developers, engineers, security people – what type of questions would you ask to test on problem-solving?
Get them to write some code. Ask them a coding question. Make them write real code, in a real language. I really don’t care what language… we can all learn new languages – they come and go. I grew up writing Pascal, but things just change. So long as it’s a real programming language. Not in pseudocode – actually write code. So the problem solving, I think, is fairly straightforward. Solve a hard problem by writing code.
How do you know if someone has intellectual horsepower?
I think intellectual horsepower is sort of related to problem-solving – it overlaps. My big test for this is: was it a fun and engaging experience, where I learned something as an interviewer? It’s like a spidey sense you get.
For instance, the conversation is going fast, they grab thoughts, they run with them, they create interesting new knowledge, and I come out of the interview going, ‘that was really interesting, I’m glad I spent that hour with them. I feel like I’m a bit smarter, having hung out with that person, I like the way they think, they asked really good questions.’
So I think at some level, you have a sort of spidey sense about intellectual horsepower. You want to work with people smarter than you. I think that’s the essence of it.
How do you know if someone is action-oriented? That can be a really hard one to pick up on, whether a person is inclined to really get in and do stuff?
It is the hardest, but again, I think through experience, you can feel it. So let’s imagine we’re doing some kind of college interview and I say to you:
‘There’s a deck of cards with 52 cards in it, and I want you to write a function called ‘Shuffle’ that takes, as an input, an array of 52 cards that are in some order, and I want you to write a function that shuffles the cards and returns that array that’s being shuffled.’
That’s one of my standard questions for someone who just finished uni. If you were the candidate, there’s two ways you could respond;
Approach A – You can grab the whiteboard marker and jump at the whiteboard. You can go, ‘oh, cool, an interesting question, I’m just gonna make a couple of assumptions here… are these reasonable?’. That sort of enthusiastic approach.
Approach B – Or, you can respond with, ‘I don’t know, I mean, there’s library functions for shuffling and stuff, right? Why would anybody want to write a shuffle thing? It’s a pretty old-fashioned question… you know, I haven’t thought about this sort of stuff for a while.’
Or perhaps they’ve got like, 16 clarifying questions: ‘What is a card? Is there always 52 cards? What if somebody wanted to shuffle four cards…’.
Essentially, they’re not launching at the whiteboard going, ‘Oh, man, this is fun. Let’s go.’ They’re pushing back, inferring my questions are stupid, not making any assumptions, wanting things over-explained. So that’d be the college level version of it, I think, is like: do they launch at the whiteboard?
And the more mature version of it, say for the senior engineer manager type, might perhaps be asking them something more complex, and maybe it’s not a coding question at all. You’re looking at: Do they lean forward and engage? Are they excited by the conversation? Do they want to solve this, and move the state of knowledge further forward?
The metaphor would be: did they lean in or do they lean out?
And occasionally, you’re going to ask a question where they’re just kind of stumped and stuck. And you might think that the person isn’t action-oriented, but they’re just stuck, you know, and so sometimes you’ll have to come at it from multiple angles… give them something else to try to figure out.
So those would be my clues. Are they a whiteboard pen grabber? Or are they a leanback?
Your final characteristic – about being driven for results. This is a tricky one, because sometimes when you interview people, they attribute their success as being part of a team. How do you discern here, if they are actively driving results?
Yep. This is one where I always ask people what they’re most proud of. So if they just finished college, I’ll ask what was the assignment that they most enjoyed, and why.
If they’re a bit further in their career, I say they’ve had an amazing career… and ask, ‘When you think back, what are you most proud of?’
And then what I’m listening for is: Did this person ship things that mattered out to customers? Did we do something where we were concerned about the outcome – or where we were concerned about the process?
Say we’re talking to college students, and I ask ‘What’s your favorite assignment?’, and they respond with something like:
“We worked as a group in the final year on an industry project… we were lucky enough to work at XYZ Company. And we actually solved this really important problem for them, that saved them an enormous amount of money and allowed them to make more widgets with a higher margin. And we got that done in six weeks. And I think it could be something that really changes how they work with their customers.”
The opposite would be them doing something esoteric and complicated, and not really finishing it. Like, ‘I did an assignment where I implemented this thing, and it was interesting, and it worked, and we got it in on time.’
So I think you can just kind of tell: what do people talk about when they reflect on what they’ve done? Is it stuff that had an impact, or is it the process of doing things?
Another way to look for being driven for results, is that you can read it in resumes. Have people listed bullet points under their job title… like, being in charge of a process. Or is it like, ‘we delivered XYZ, more money, more users, more efficient, more reliable, safer, etc.’
What’s a book we should all read?
I like Getting Things Done, it’s oldie but a goodie. You don’t have to read the whole book… It gets a bit boring after the first five chapters.
What’s a food or dish we should all try?
Bakso. It’s an Indonesian food, like a hot soup with meatballs. Do it with all the sauces – hot sauce, soy sauce, and sweet sauce (kecap manis).
What’s a podcast that you’re listening to?
I’ve been listening to this one a lot while I do the mowing: Rockonteurs. It’s interviews with famous musicians and producers – it has great stories and I even learn a few management lessons along the way.
What sort of music do you listen to?
I buy a lot of vinyl records, I’ve got about 1,000 records in my collection. What’s on my turntable now is ‘Under the Midnight Sun’ – The Cult’s new album. It’s fabulous.
Thanks Hugh for chatting with us at CyRise Elevate.
Connect with Hugh: LinkedIn | Twitter
CyRise Elevate is our membership and development program for ambitious cybersecurity leaders. We’re currently recruiting members for our new CyRise Elevate tribes for GRC and technical security leaders and have limited spots available in our CyRise Elevate tribes for senior security leaders in scale-up organisations.
If you know an ambitious security leader you think might be a good fit, we’d love to meet them. For our new tribes, the perfect candidate is someone who has strategic responsibilities. Is that you or someone you know? Send us an email at [email protected] and we can send you some more information.