Careers · Engineering disciplines

Work on systems whose failure modes matter

Wavelink role briefs focus on the decisions, evidence and operating responsibility behind enterprise delivery. Opening status and working arrangements are shown conservatively until the company confirms them.

Enterprise engineering asks for more than framework familiarity. The work sits between business rules, existing systems, infrastructure, data responsibility and the people who must operate the result. Strong contributors make that boundary clearer. They can explain trade-offs, seek evidence before committing to a design, and leave code and operational material that another person can safely own.

The role briefs below describe disciplines the company may recruit for. They are substantive scopes, not live-employment claims. Each confirmed opening should later state its contract type, location or remote arrangement, reporting line, compensation process, application deadline and lawful eligibility requirements.

Opening statusRole availability has not yet been confirmed. These briefs support expressions of interest and must not be read as a promise of a current vacancy.

Role briefs

Disciplines shaped around production outcomes

Each brief names the work to be owned and the evidence a candidate can use to demonstrate judgment. No fixed year count is used as a substitute for capability.

Enterprise applications & integrationsAvailability to be confirmed

Senior Software Engineer

Design and deliver business-critical workflows, services and integrations that remain understandable under change and diagnosable in production.

ArrangementDelivery arrangement set with a confirmed opening

Work to own

Model domain rules, permissions, exceptions and audit evidence with product and operational owners.

Choose modular boundaries and interface contracts that match ownership, scale and failure consequences.

Implement APIs, background work and event flows with idempotency, timeouts, reconciliation and useful telemetry.

Review code and architecture, improve automated checks, and guide backward-compatible data and release changes.

Support incident diagnosis and convert production findings into safer design and documentation.

Useful evidence

A system or service you can explain from domain decision through deployment and operation.

Examples of migration, integration or concurrency risk you discovered and reduced.

Code, diagrams, decision records or technical writing that show how you communicate trade-offs.

Baseline capabilities

Strong practice in at least one production application language and its testing ecosystemRelational data modelling, transactions and safe schema evolutionHTTP, messaging or event-contract design and failure handlingAuthentication, authorisation, secrets and secure software-delivery fundamentalsCollaborative review and precise written technical communication

Illustrative first assignmentA likely first assignment would be a thin end-to-end slice through an existing workflow and integration boundary: clarify the rules, implement the path, expose failure evidence and document the decision. The exact assignment depends on the confirmed engagement.

Cloud platforms · reliability · operationsAvailability to be confirmed

Platform & SRE Engineer

Create repeatable infrastructure and service evidence that let application teams release, observe and recover production workloads safely.

ArrangementDelivery arrangement set with a confirmed opening

Work to own

Model workload, identity, network, state and supplier boundaries across cloud, private or hybrid environments.

Build reviewed infrastructure modules, delivery paths and policy checks that reduce configuration drift.

Define service indicators, capacity signals, alerts and dashboards around user-visible reliability.

Rehearse node, zone, link, dependency and restoration failures; turn results into runbooks and improvements.

Coordinate technical incidents and provider escalations with timestamps, correlation evidence and clear authority.

Useful evidence

An infrastructure or platform change you made repeatable and safer for other engineers.

A production incident or resilience exercise showing diagnosis, mitigation and follow-through.

Infrastructure definitions, operational tooling or written reliability analysis you can discuss in depth.

Baseline capabilities

Linux, networking, identity and container-platform fundamentalsInfrastructure as code, CI/CD and immutable artefact promotionMetrics, logs, traces and alert design tied to actionStateful-service backup, restoration and capacity considerationsCalm incident communication and rigorous post-incident reasoning

Illustrative first assignmentA likely first assignment would be to map one production service from deployment through user-visible health, identify missing operational evidence and automate a high-risk manual step. The exact assignment depends on the confirmed engagement.

Ingestion · governed data · analytics operationsAvailability to be confirmed

Data Platform Engineer

Build observable data paths that preserve provenance, tolerate replay and give analysts and operators a trustworthy account of freshness and quality.

ArrangementDelivery arrangement set with a confirmed opening

Work to own

Trace source ownership, capture semantics, retention, consent or access constraints and downstream decision use.

Implement batch or event-driven ingestion with schemas, checkpoints, replay, deduplication and quarantine paths.

Create transformation tests, reconciliation controls, lineage and freshness indicators for governed datasets.

Design storage and serving models around workload, cost, latency and residency constraints rather than tool preference.

Work with application, analytics and operational teams to define metric contracts and resolve data incidents.

Useful evidence

A production data path you can explain from source capture to consumer and backfill.

Examples of data-quality, ordering, schema or scale failures and how you made them observable.

Pipeline code, data models, tests or technical analysis that demonstrates careful handling of state.

Baseline capabilities

SQL and data modelling across transactional and analytical use casesA production programming language for ingestion and transformation workWorkflow orchestration, messaging or stream-processing fundamentalsSchema evolution, lineage, quality checks and access controlPerformance and cost reasoning across storage and compute boundaries

Illustrative first assignmentA likely first assignment would be to establish a source-to-metric contract for one operational feed, including replay behaviour, reconciliation and freshness evidence. The exact assignment depends on the confirmed engagement.

Process discovery · acceptance · delivery evidenceAvailability to be confirmed

Delivery & Business Systems Analyst

Turn operational work, policy decisions and exceptions into a shared system boundary that engineers and client owners can inspect and accept.

ArrangementDelivery arrangement set with a confirmed opening

Work to own

Trace representative transactions with users, product owners, operators and dependent institutions.

Document actors, decisions, data authority, exception paths, controls and unresolved policy questions.

Shape outcomes into testable increments with acceptance evidence and dependency owners.

Facilitate reviews, capture decisions and maintain traceability between operating need and delivered behaviour.

Plan migration, training and handover activities with the people who will operate the new process.

Useful evidence

A complex process or policy area you clarified without erasing important exceptions.

An example where your analysis changed scope, sequence or architecture before costly implementation.

Process maps, acceptance scenarios, decision logs or concise writing that helped different disciplines align.

Baseline capabilities

Structured interviewing and workshop facilitationProcess, data and decision modellingClear acceptance scenarios and precise written communicationComfort working with APIs, data flows and operational constraintsDependency, risk and decision tracking across organisational boundaries

Illustrative first assignmentA likely first assignment would be to trace one high-friction workflow through its normal, exception and reconciliation paths and turn that evidence into an agreed first delivery slice. The exact assignment depends on the confirmed engagement.

Candidate evidence

Show how you think about work that reached reality

A useful application gives enough context to assess your judgment without disclosing a former employer’s confidential information.

Explain the system and your boundary

Describe the users, operating need, constraints and the part you personally owned. State what was already decided, what you influenced and who made the final decision.

Use anonymised diagrams or rewritten examples when source material is confidential

Distinguish individual contribution from team outcome

Name the production or acceptance evidence you observed

Describe a consequential trade-off

Choose a decision where two reasonable options existed. Explain the failure consequence, evidence available at the time, choice made and what later changed your understanding.

Include an assumption that proved wrong or remained uncertain

Describe how the decision was recorded and reviewed

Avoid presenting a tool choice as the complete architecture

Demonstrate operational ownership

Show how the work was released, observed, supported or transferred. If it never reached production, explain how you established that the result was ready for the next owner.

Discuss tests, telemetry, migration or recovery where relevant

Explain how users or operators gave feedback

Identify a follow-up improvement you would make now

Indicative process

A selection path designed around evidence

The sequence below is a proposed candidate experience for these role briefs. The company must confirm the actual stages, timing and decision owners for each opening.

Process statusIndicative only — a confirmed opening may use fewer stages or a different sequence, and should publish that process before applications are assessed.

Context review
Working discussion
Evidence exercise
Team decision

Context reviewRole fit, relevant evidence and basic engagement constraints

Working discussionA real engineering or delivery decision explored with peers

Evidence exerciseA bounded, role-relevant exercise with expectations stated in advance

Team decisionDocumented assessment, references where applicable and clear outcome communication