Senior Engineer 1

Builds products ensuring they take adequate steps to protect sensitive data, e.g.

• Databases have encryption at rest
• Sensitive data is masked or in restricted indexes in Splunk
• Data is retained only for as long as it is needed
• Dummy/fictional data is used in staging environments and in tests
• Suppliers don't get access to data unless they have gone through the Procurement Management Application process

Implements appropriate observability and monitoring when building a solution, e.g.

• When adding a new dependency to a system, adds a healthcheck to monitor the dependency's state
• Adds logging that is well-structured and captures useful information about the state of a system
• Builds a Grafana dashboard that visualises normal and abnormal operation of a system

Evaluates third-party software to use in projects, e.g.

• Can choose between similar Node libraries evaluating code quality, ease of integration, future maintenance, and security concerns
• May be involved in evaluating paid-for third party supplier code

Leads on fixing live incidents in production, e.g.

• Takes proactive action when an incident is reported on a system they support and resolves it satisfactorily
• Responds to critical issues raised in #ft-tech-incidents taking the initiative to fix them and reports back

Understands the security attack vectors for their area of technology and mitigates against them, e.g.

• Uses Snyk.io on projects
• Sanitises user input to mitigate against XSS attacks
• Applies security patches to an operating system
• Protecting public API endpoints
• Articulates security risks/benefits when evaluating third party software
• Uses Fastly WAF to protect from malicious requests

Makes pragmatic decisions about technical trade-offs within their project, e.g.

• Knows when to stop work on a feature that has fulfilled the requirements vs. spending an extra week on making it perfect but delivering little additional value
• When pressed for time, focuses on ensuring test coverage of the most critical system functionality
• Manages technical debt, understands consequences of technical debt vs the cost of fixing it and acts accordingly
• Can explain when something is worth refactoring even when it will impact the speed of delivery

Delivers high quality code and solutions, e.g.

• Refactors solutions to improve clarity and maintainability

Encourages others to deliver high quality code and solutions, e.g.

• Implements tooling to enforce high standards
• Reviews pull requests fairly & critically in such away that team members produce better code

Regularly and independently debugs and fixes bugs regardless of origin, e.g.

• Picks up and debugs an urgent issue that comes in to the team, despite having not written the code originally

Builds software or services considering resilience, performance and failure modes, e.g.

• Combines multiple data sources in a feature, caching, polling etc as appropriate to cope with problems in downstream services
• Adds healthchecks to a system that detect different ways in which it can fail

Chooses the appropriate tool, technology or software for a task, e.g.

• If starting a new project, uses tools already understood by the team unless there is an agreed good reason to change

Builds and works with systems involving multiple, independent technical parts, e.g.

• Adds data sources to or optimises performance of a data pipeline
• Publishes a new origami component that uses other components
• Implements a CDN / gateway that routes to a suite of underlying microservices
• Designs and implements a build pipeline

Considers the technical direction of their group or the wider department when coming up with technical solutions, e.g.

• Understands how their work feeds into their group's tech strategy
• Can articulate and justify the total cost of ownership of their technical solutions
• Follows their group's Engineering Principles when building technical solutions

Communicates technical concepts clearly and adapts that communication to the audience, e.g.

• Explains their work in standups knowing which technical details to leave out to make the message meaningful to everyone in the room
• Teaches more junior engineers
• Creates diagrams to document how the different parts of systems interact
• Presents their own work clearly to stakeholders

Facilitates productive discussions with clear outcomes, e.g.

• Runs meetings with clear agendas and outcomes
• Obtains wide feedback on technical proposals and takes ownership of seeing it through

Contributes to hiring process, e.g.

• Participates in hiring panels or technical interviews
• Attends recruitment events
• Publicly shares links to open roles
• Goes for coffee with potential hires to talk about what working at the Financial Times is like
• Shares our work publicly, (through blogging, speaking, etc) to show the kinds of work we do here
• Reviews CVs
• Reviews tech tests

Prioritises technical work for the team (usually with others)

Breaks down large complex technical proposals into discrete tasks, e.g.

• Creates the user stories for the ticket with a delivery lead

Communicates team/work's status upwards to a Principal or Technical Director

Where appropriate, builds on other teams' work to solve problems, e.g.

• Uses origami components to style a web page
• Uses Biz Ops as a source of system data rather than creating a new system registry

Moves blockers to enable more junior engineers to work, e.g.

• Reviews pull requests
• Suggests someone to talk to eg “[X] knows the most about [technology Y], you could ask them”

Tackles simple cross team technical issues, e.g.

• Notices a tool used by lots of teams has broken, identifies the problem and fixes (or reports it to the owner of the tool)

Actively seeks the views of other teams to help guide work, e.g.

• Attends cross team meetings
• Asks other teams for input and opinions on decisions that affect them

Improves delivery process and encourages others to do the same, e.g.

• Updates the scrum process to fit the changing needs of the team
• Champions technical issues that affect delivery such as release cycles, dealing with tech debt and bug fixes
• Encourages other engineers to participate in agile team rituals

Manages, prioritises and communicates own workload

Influences a community of practice, e.g.

• Is an active member of a Guild
• Answers questions in the #engineering Slack channel
• Gives a tech talk (internally or externally)
• Writes a blog post
• Shares industry relevant content/links with team members that may be interested

Is an ambassador for their team across FT technology, e.g.

• Positively represents their team in interactions with other people by seeking to understand their perspectives, values and needs
• Consistently contributes to their team being positively perceived by stakeholders (or by other engineering teams to which they provide support)

Contributes to the personal development of more junior people, e.g.

• Is a line manager or mentor
• Is a designated buddy to a new starter
• Regularly meets up with more junior peers to provide guidance
• Pairs with more junior team members
• Writes blog posts to share knowledge
• Gives talks at meet-ups or conferences to share knowledge

Shows technical leadership, e.g.

• Is a tech lead
• Runs, or is on the organising team for a Guild
• Leads on large features, stories or projects

Shares knowledge with others internally, e.g.

• Gives a workshop on Git
• Runs a regular 101 session for the rest of the business
• More informal knowledge sharing through mentorship

Actively fosters an inclusive team culture, e.g.

• Celebrates good work publicly and encourages the team to do the same
• Spots problems between team members and helps to resolve them or escalate them as appropriate
• Models inclusive behaviour to the rest of the team