Originally published in Building LloydsDirect.

Early on in most interviewing journeys is a call with the hiring manager. But what is a hiring manager and what’s the purpose of this call?

We’ve written about how we interview software engineers at LloydsDirect. This post focuses on the call with a hiring manager. While I’m speaking from my own experience hiring software engineers and engineering managers, the advice applies to other product roles at LloydsDirect and tech companies in general.

At LloydsDirect, this is a 30-minute video call with the hiring manager. The hiring manager is someone with role-specific knowledge. For software engineers, this will be an engineering manager or the head of engineering.

Before this call you may have already had a call with a talent partner. They will have covered many of the basics about the company and the role, such as salary expectations, company values, and other aspects of working there.

What the call is about, in two bullet points

The purpose of this call is to:

1. For us to learn more about you, your experience and interests, and what you’re looking for in your next role
2. For you to learn more about us, how we develop products, how we’ve set up our teams, and what our engineering culture is like

Success for this call is clarity. We’ll know whether your skills and aspirations fit with the role, and you’ll know whether this is the right opportunity for you.

As ever with interviewing, if, after this call, it turns out that this role isn’t right for you, this isn’t a bad outcome! Discovering that the role or company isn’t a good fit for you at this point saves everyone’s time — and potential heartache down the line.

As a hiring manager my goal is to present LloydsDirect and the role in a truthful but appealing light. It’s important to note that I’m not trying to gauge your core technical competencies at this stage. (As if I could do this in a 30-minute video call!) I’m mainly seeking to understand whether your interests and experience match what we’re looking for and whether you’d be able to succeed and thrive at LloydsDirect.

Will the hiring manager be your direct boss? Maybe, but not necessarily. This is a good question to ask on the call!

Questions you’ll likely be asked

• How did you come to be a software engineer?
• What are you looking for in your next role?
• What would your dream job be like?
• What interests you about LloydsDirect and the role?
• What are your go-to languages, frameworks and tools?

How much should you tailor your answers to match the company and job? In answering questions about yourself and what you want, I’d recommend you don’t. You should think about these ahead of the call, but telling me untrue things that you think I want to hear can backfire in two ways: firstly, you might guess wrong, and, secondly, what if you do get the job and it turns out to be a terrible fit?

How to prepare for the call

There’s not that much to prep for a screening call, really. The usual advice applies: read the job description carefully, find out what you can about the company and note down any questions that spring to mind. Actually, be sure to prepare a few questions even if none “spring to mind.” If you don’t ask any questions throughout — especially when I ask if you have any, which we always do in our interviews — it sounds like you’re not interested in the role.

In addition to this, good interviewing/meeting etiquette applies: silence your phone (I’m assuming we’re on video call on your computer here), try to be in a quiet place where you feel comfortable and the internet connection isn’t too ropey.

If the doorbell rings or your dog starts barking while we’re on the call, I will understand that you need to attend to this for a few moments. But if your phone rings in the middle of our call, it comes across as being unprepared. If you are waiting for an urgent call (like if your partner is about to go into labour), then do let me know at the beginning of our call.

A few words about enthusiasm

Enthusiasm is one of those things that goes a long way in an interview. But enthusiasm is also tricky: for one, it’s a byproduct rather than an end goal. Secondly, not everyone expresses their enthusiasm in the same way. If I expected everyone to be enthusiastic in the same way I’d miss out on a lot of great candidates, maybe even the majority of great candidates.

People are enthusiastic when they are engaged and motivated. And motivation is key to high performance. If you get your sense of achievement from solving deep, technical problems, and the job doesn’t involve any of this work, you are unlikely to be happy or engaged in the long run.

This is why there are so many questions in interviews like:

• What do you like about being a software engineer?
• What work are you proudest of?
• What gives you a sense of achievement?

All of these questions are meant to uncover and poke that deep vein within you that’s responsible for getting you excited and giving you a sense of achievement.

This works both ways, by the way. If you know what kind of work is your jam, you can and should ask questions to figure out if the job has this kind of work.

So should you slap on a goofy grin and wave your hands about in your interview? (This is how I look when I’m enthusiastic.) Yes, if that’s what comes naturally to you. But if this isn’t how you’re wired, don’t try to be someone you’re not. Fake enthusiasm can come across as, well, fake. Just be yourself — your focused and interested self.

What does LloydsDirect do? How do we do it?

Researching companies can be difficult. While you can find out what a company says about itself, this doesn’t always tell you what it’s like to work at a company. I’m going to try to give you a glimpse of why we exist, what we do, and how we work.

Why we exist

One in two adults in the UK take medicine regularly. The way many people get their medicine involves contacting their GP to get a prescription and then waiting a few days to visit their local pharmacy to pick up the medicine. (And even then, there’s no guarantee that their medicine will be ready for them!)

People’s experience will vary based on how good their local pharmacy is — some of them will call once the medicine is ready for pick-up. Some offer home delivery services themselves (this is usually a paid-for service).

It was to improve this painful process that LloydsDirect was started in 2015. The founders, who all take medicines regularly, asked themselves: “Why, in this day and age of Amazon and Uber, is getting your medicine such a pain?”

What we do

When I joined in October 2019, we had just under 50K nominated patients. Today, we have over half of a million nominated patients. We currently dispatch over 30,000 medicines a day from our Perivale dispensary.

The tools we use to do this are for the most part built in-house.

The way I sometimes describe us is that we’re the glue that joins together disparate, unconnected systems. From GP practices to NHS systems to medicine wholesalers to the Royal Mail.

As an example of this, each GP practice has a preferred way that they want to receive our patients’ requests. We send these via email, fax and IM1 (a protocol for communicating with GP software systems). While email is now the most common method, just over a year ago, the majority of all prescription requests were delivered via fax. And it was only two years ago that we stopped printing out requests and sending them in the post! We still accept paper prescriptions that are sent to us by post.

The challenges that we, as product developers, face are in designing systems that allow us to combine automation with human expertise. If you think about the journey from request to delivery, it is made up of a long chain where the links alternate between software and humans.

Another way to put it is that we build APIs for things that don’t have APIs. Have you heard about all the hackery that Monzo did to provide a more understandable banking experience? Our aim is to do this but for healthcare. Another analogy is Skyscanner. They got their start as a spreadsheet used to track cheap flights for the founders’ skiing trips. Much (if not the majority) of their flight and price data was gathered via web scraping, as many of the airlines (especially the cheap ones) didn’t provide programmatic access to their flights.

So while we have our fair share of very hard technical problems to solve (any given picking combination runs in the millions), much of what we do requires a balance of technical ability, systems thinking and plain old human empathy.

How we work

We have intentionally small teams. This means that our engineers work across the stack and get to be involved in areas they find interesting. The trade-off — or, as some might say — the downside, is that our engineers aren’t particularly specialised. We don’t have dedicated front-enders or mobile developers or devops engineers or even testers.

Because our teams are small, it means that we have to be focused. Again, this has its pros and cons. The upside is that everyone on the team is involved in deciding and defining what work we do. The downside is that there are always many things that we don’t do.

Each product team is founded on a business goal and they have autonomy to figure out the best way to achieve their goal. While the product manager sets the product strategy for the team, even this, along with shaping projects, is a collaborative effort.

Our product teams usually consist of three software engineers, a tech lead, a product designer, a data analyst, and a product manager. Some teams additionally have a content designer and a user researcher.

Our tech stack

We’ve written about our Go-based microservices approach before. Our internal and patient-facing apps are built using React and React Native, which connect to our backend services via a GraphQL API. Our services run on Kubernetes clusters on Google Cloud Platform.

There are a lot of moving pieces in our stack, but day-to-day the setup doesn’t require much engineer attention and has scaled well and proven stable. All our engineers can and do deploy code, and as often as they want. Small releases mean a smaller surface area to debug if we should notice something awry.

You don’t have to know it all

As our job ads try to make abundantly clear, we don’t require applicants to have any prior experience with our specific tech stack. We’ve found that experience in equivalent frameworks and languages is transferable. We believe that software engineers are capable of learning new technologies and approaches, and the more diverse experience our engineering team has, the more diverse our thinking will be.

Obviously, having a proven track record with our tech stack makes it easier for us to evaluate a candidate. But given that an interview is only a single point in time (compared to the days, months and years that someone might work with us), optimizing for this makes little sense.

If you are applying to work with us and don’t have experience in our stack (as is the case for most of our hires, historically), it doesn’t hurt to share your experiences learning new technologies or how your current expertise would be transferable to our tech stack. In the end, all we expect is an interest in learning!

Now you have no excuse

Given what I’ve told you about the business and how we work, the stakes have gone up: if you want to blow me away in your screening call, I want to hear what questions reading this provoked in you. What’s missing in my description? What particularly resonates with you? What are you suspicious/excited/confused about?

If the way we work sounds interesting to you, check out our open positions.