Professional experience at Talan on a Santander engagement. This is a high-level account; internal data, implementation details and performance figures are omitted.
The problem
A completed Spark job establishes that execution finished. It does not establish that every join, mapping and aggregation reflects the intended reporting requirement. In financial reporting, that distinction makes data correctness an engineering concern throughout the pipeline.
My contribution
My work included implementing extraction configurations and ETL stages, adding reporting records, resolving transformation defects and working with stakeholders to refine requirements. One area involved correcting duplication in snapshot processing.
I also contributed documentation, code reviews, knowledge sharing and end-of-month reporting support.
How I approach the work
- Translate a requirement into an explicit transformation and expected output.
- Check record grain, join cardinality and aggregation behaviour.
- Validate the business result alongside technical execution.
- Document decisions so that future changes can be reviewed in context.
The engineering judgement
A join can be valid SQL while changing the grain of the output. A mapping can be technically consistent while reflecting the wrong interpretation of a requirement. These are reasons to make assumptions visible and involve reporting stakeholders in validation.
Outcome and perspective
The work delivered reporting transformations and extraction configurations and addressed identified defects. I do not publish internal benchmarks or claim a quantified reduction in reporting risk.
The lasting lesson: correctness needs an explicit definition, testable examples and shared understanding of what each record represents.