Senior Software Engineer - PHP

To design and build the modular platform that will carry the business capability as we move off a forty-year-old system - working in PHP 8.3 with Slim, Doctrine and PostgreSQL - and to share ownership of it properly across a small team.

The stack

Backend - PHP 8.3 · Slim 4 · PHP-DI 7 · Doctrine ORM 2 & DBAL 3 · PostgreSQL 16 · Symfony Console, Cache, YAML · respect/validation

Front end - React 18 · React Router 6 · TanStack Query 5 · an internal component library · plain JavaScript

Quality - PHPUnit · PHP_CodeSniffer · Phan · Playwright · gated on every branch in GitHub Actions

Infrastructure - Docker · nginx & PHP-FPM · AWS · GitHub Actions to a container registry

Applications are assembled from libraries rather than handed to you by a ready-made framework: routes registered explicitly, dependencies injected through a container, Doctrine used as a data mapper with entities and repositories. A set of internal Composer packages sits underneath - authentication, permissions, queuing, customer lookups and more - and a new module is built on top of these rather than from nothing.

Background to the role

We are a fleet management company, recently been acquired by a blue chip bank. We have a bespoke system to run the company which is also forty years old, and the next few years are about moving off it.

The bank are introducing a new leasing platform. Some of what we do will migrate onto it. A great deal will not, and those gaps are what we will be building. The scope is business-wide and extensive: every operational area of the company has capability that will need rebuilding over the coming years.

To take one small illustration from one team: the new leasing platform can accept the concept of a penalty charge notice and invoice it to a customer. It cannot, however, take in and scan the physical paperwork, identify who was driving, run the correspondence and appeals, or handle the payment and refunds. This is a gap, and therefore a module we have built ourselves and put live this year - and it is one module, from one department, among many still to come.

We already run a growing estate of services in production, each with its own React frontend, all built to a single shared architecture with a set of internal libraries beneath them. The roadmap ahead is measured in years rather than months.

The team is small - two developers, two business analysts, a project manager. That is the unusual part of this job: the scope of a large programme with the autonomy of a very small team, and correspondingly real ownership of what gets built.

Example problems

The business areas vary enormously. The engineering shapes repeat, and these are the ones that come up again and again:

·Long-running business processes - cases that carry a state for weeks, branch on what they turn out to be, wait on other people or external systems, and have to be picked up by whoever is next. We drive these with a configurable workflow engine.

·Money that has to reconcile - charges, payments, refunds and fees held in a double-entry ledger and balanced against a finance system we do not control.

·Getting data in - documents and files arriving from outside, including scanned paperwork through OCR, matched against customers, vehicles and people.

·Integration with systems of record - largely file-based exchange and vendor APIs, where we are constrained to the interfaces someone else publishes.

·Designing new modules from high-level business requirements rather than from a specification handed to you. This is the majority of the work ahead., ·Financial systems, ledgers or reconciliation against an external system of record

·Doctrine ORM, or another data-mapper ORM such as Hibernate or Entity Framework - and able to explain how the unit of work behaves and when a change actually reaches the database. This is the single most important item on this list.

·Modern PHP 8, written to SOLID principles, in applications composed from libraries rather than inside one large opinionated framework

·PostgreSQL - schema design, query optimisation, migrations

·Automated testing as routine, not as a phase - PHPUnit or equivalent - together with static analysis and coding standards enforced in CI

·Git and pull-request review as a normal part of the working day

·Docker for local development and deployment

·Enough JavaScript and React to work confidently in the front ends. You do not need to be a React specialist, but roughly a fifth of the work is there and it cannot be avoided.