Senior Software Engineer - PHP
Marshall Resource Partners Ltd
SENIOR SOFTWARE ENGINEER
PHP Purpose 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. Bringing on one junior developer
, which is a real part of this role and not a line on a job description. Essential experience 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. Also valued Symfony
its conventions transfer here almost directly Workflow engines, state machines or long-running case management systems Financial systems, ledgers or reconciliation against an external system of record Document processing, OCR or data extraction Fleet, leasing, or another regulated environment If this is you and you want to know more, please send me your CV and we can talk more around the role / company.
TPBN1_UKTJ
PHP Purpose 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. Bringing on one junior developer
, which is a real part of this role and not a line on a job description. Essential experience 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. Also valued Symfony
its conventions transfer here almost directly Workflow engines, state machines or long-running case management systems Financial systems, ledgers or reconciliation against an external system of record Document processing, OCR or data extraction Fleet, leasing, or another regulated environment If this is you and you want to know more, please send me your CV and we can talk more around the role / company.
TPBN1_UKTJ
Reference: WJ-799_23707197