David, can you share a bit about your story at Hymans and your background?

I’ve been at Hymans for 10 years, working as a Technical Architect. I’m responsible for control structure of applications and application families within the Private Sector and Defined Benefit pensions world. Before I was at Hymans, I was working in diagnostic cardiology for eight years. And before that - in a company that specialised in geographical information systems.

Could you tell me a little bit about the Tech here at Hymans?

Like many that are building software, we’ve got a lot of web applications to deliver our features, all accessible through web browsers. Consequently, our team includes dedicated front-end developers focused on optimising user interfaces. Supporting these applications are a multitude of financial models written in languages such as C#, F#, and Python. Much of our work revolves around sophisticated financial actuarial models, which form the foundation of our solutions. Additionally, we incorporate analytical tools to allow for dynamic adjustments and insightful analysis of these models. These capabilities are seamlessly integrated into the browser interface, catering to a diverse user base, including consultants and trustees of defined benefit pension schemes. Users leverage these modelling capabilities to assess contribution patterns, funding levels, and asset-liability alignment, enabling informed decision-making.

Can you share a bit about our recruitment process for a developer?

When someone applies for a role, we’ll look through their CV and see how well they match with the opportunities available. If it’s a good match, we'd set up an informal conversation with someone already in a role they’re applying for. That's just a chance for the candidate to get a sense of whether or not Hymans is right for them, before they've expended any effort yet or gone further down the process. Then, we have the clinical challenge. This is a technical test where we supply some code that is deficient; we expect the candidate to take that code and improve it. It's an attempt to simulate the development work. Once they've gone through that, we'd review the results of their submission, and if it looks good, we’ll invite them to a technical interview, followed by a non-technical session with an HR representative. 

With regards to the clean code assessment, what's the rationale for using that? As it is quite a contentious subject in the market, I am keen to get your view?

We get that question a lot from recruiters. To some, it just appears to be an impediment to getting a flow of candidates through. But we've found that there's just not a strong enough correlation between what you see on a CV and someone's coding ability. So, we give them an opportunity to write some code and for us to see that, but we do it in a way that keeps the stress level as low as possible. For example, we give them the task to work out at home in their own time, rather than coming into the office with someone standing over them. We've found that candidates, even though we're asking for a few hours of their time, which is a big ask, seem generally positive about the clinical challenge.

Why do you think Hymans values the code challenge so much?

We’re very keen on clinical principles, on code quality, ensuring that our code bases are maintained properly, and that they can be evolved. And, as I say, it's very difficult to get a sense of how important it is to someone without asking them to demonstrate that. And so that's where the clinical challenge just really shines. It gives us a very good basis on which to assess how they approach a problem and to see their style, design skills and clean code knowledge.

For those successful in getting through the clean code, how does the technical interview look?

We try to keep stress levels down and give candidates the best opportunity to show their skills, so we don't want to surprise them in the interview with something they've not seen. The clinical challenge is excellent for that - we can have a conversation about something they're intimately familiar with rather than presenting them with something new. We’ll go through what they've written and what they've submitted. We'll ask about their thought processes, the order in which they did things, what they found difficult, any weaknesses that they would highlight, and their strengths.

In the second half of the technical interview, we'd talk through their CV and their experience. We’d also try to get a sense of where they want to fit in - are they interested in front-end development mainly, or back-end or full-stack? Or is there a particular type of technology that they're interested in or passionate about? It gives us a chance to talk about that and see how well they would fit into the teams and the opportunities that we've got available.

What happens in the final stage interview with HR?

The final stage is more competency-based. We look at different behaviours and competencies and how they align with our values, and discuss a bit more about their career aspirations and their motivations.

It’s also a chance to cover their notice period, any contractual issues, the HR process, etc. These are often questions we get asked in the technical interview but aren’t equipped to answer!