Backend engineer

The role

We’re looking for an experienced backend / full stack engineer to join our engineering team. Our aim is that the person we hire will ultimately lead this area, allowing me (Martyn, CTO) to focus elsewhere.

Over the next 12 months key challenges could involve improvements to our core event sourcing infrastructure (and possible move to Crystal), supporting the delivery of new frontend features, and exploring a new approach to managing and gaining insight from our ontology and clinical data. Take a look at what we focused on in 2022.

Backend context

Our backend stack comprises a small number of services exposing Twirp (gRPC-like) interfaces to each other, designed around our primary domain concerns:

• Consent – consent episodes and patient data
• Ontology – our resource of clinical data
• Integration – the joy of interfacing with hospital systems
• Auth – keeping everything safe

These services are written in a mixture of Ruby and Crystal. We started experimenting with Crystal in late 2021 and at this point we’re pretty committed to writing new code in Crystal where possible, while slowly migrating existing Ruby services. Our frontend applications are written in Elm and communicate with backend services via GraphQL, critically adding type safety to this interface.

Although we don’t use a functional programming language on the backend (yet?), our approach is certainly informed by it. For example, our canonical data model for consent data example is an immutable sequence of ‘events’ which is projected to derive the current state.

Taking a data-centric approach to clinical data (our ‘ontology’) has been critical in enabling us to tackle the messy complexity of medicine and allowed us to scale to ~2,000 core procedures as well as complex combined procedures. We’ve developed a significant amount of custom tooling to make managing the ontology tractable, but there is interesting work to be done in this space.

We build all services as Docker containers and deploy to a simple (no k8s) environment on GCP which is fully automated using Terraform. We take the view that ops should be as simple as possible and that innovation should happen elsewhere.

We don’t believe in a strict separation between frontend and backend roles and so would also welcome applications if you’re looking for a more full stack role. Our elm engineer job description from 2023 shares some of the context of how we are using Elm on the frontend.

The ideal candidate will…

• have at least 5 years engineering experience.
• have strong engineering design sensibilities, likely gained by writing code using multiple languages and frameworks.
• appreciate simplicity and clean abstractions.
• be experienced writing Ruby (or Crystal!)

We would be particularly excited if you…

• have an interest in functional programming.
• have built systems based on an event sourcing approach.
• have built or experimented with data analysis or machine learning.
• are a PostgreSQL whizz.
• have a love for terraform and all things ops.

Our approach to engineering

Our general engineering ethos is to take our time, build it properly, and to sweat the details.

We believe that it’s critically important to find a simple design; that working code is not enough and that the future complexity cost of compromise after compromise is simply not a good trade-off. Simplicity also means communicating changes clearly and treating the git history as a communication medium. Often simplicity also means minimising dependencies.

We’re not afraid to make unusual technology choices – for example our use of Elm and Crystal – when we believe these are better than other mainstream choices (mainstream != good). But equally, boring is often best and we try to avoid jumping on each passing fad.

Although Concentric may be ‘enterprise software’, we aim for it to be anything but. We prioritise good design, we don’t charge zillions for custom integration (it’s included in the fixed cost), we do our best to avoid special-snowflake customisations, and we don’t deploy on-prem. We simply write good software, and deploy responsibly after a thorough internal QA roughly every 2 weeks. So far this is working pretty well for us.

If this approach resonates, we’d love to hear from you.

How to apply

To apply please send a CV and and covering letter by email to Martyn (CTO). Equally, if you’d prefer an informal chat first, we’d welcome that, please do just get in touch.

In terms of process, we’ll be filtering applications as they come in so we’ll be in touch in a few days to let you know if we think we might be a match or not. The plan is then to do a tech test, followed by a final interview if appropriate.

Polite note to say we won’t be engaging with recruiters or agencies for this role.