Senior Frontend Engineer — Scientific Applications

This role is suitable for a Senior Frontend Engineer with 8+ years of experience, strong React and TypeScript skills, and a background in complex scientific or data-intensive interfaces.

The person should be skilled in D3, custom SVG, graph layout algorithms, component libraries, testing, frontend architecture, and writing backend code in Python or a similar language when needed.

They should be familiar with owning frontend systems end to end, building live monitoring and workflow visualisations, handling asynchronous experiments and large result sets, improving technical quality, and translating scientists’ needs into clear interface solutions.

How would you architect a React and TypeScript frontend for live monitoring of long-running scientific experiments?

I would separate experiment state, transport state, and presentation concerns, using typed domain models and predictable state management. The UI should explicitly represent queued, running, partially completed, failed, and completed states, while updates arrive through WebSockets, server-sent events, or controlled polling.

How would you render and interact with a large directed workflow graph?

I would model nodes and edges independently from the rendering layer, use a graph layout algorithm appropriate to the workflow structure, and render efficiently with SVG or Canvas depending on scale. I would add viewport virtualization, memoized node components, and clear interactions for selection, dependency inspection, and error navigation.

When would you choose D3, a graph library, or custom SVG for scientific visualisation?

I would use an established graph or visualization library when its interaction and layout model matches the domain and reduces maintenance risk. I would choose D3 or custom SVG when the visualization needs unusual scientific semantics, precise control, or performance characteristics that existing components cannot provide.

How would you keep a React application responsive when inspecting very large result sets?

I would combine server-side filtering and pagination with virtualized tables or lists, incremental loading, and memoized rendering. Expensive transformations should be moved off the main thread or performed on the backend, and the UI should communicate loading, incomplete, and filtered-result states clearly.

How would you design frontend handling for partial results and failures during an experiment?

I would treat partial results as a valid domain state rather than as an error, displaying which stages completed and which are still pending. Errors should be associated with the relevant experiment or workflow node, include recovery or retry actions where possible, and preserve already available results.

What testing strategy would you introduce for a research-paced React codebase?

I would establish unit tests for domain logic and data transformations, component tests for interaction and state transitions, and a smaller number of end-to-end tests for critical experiment workflows. I would prioritize high-risk paths first, including graph interactions, asynchronous updates, failure recovery, and result inspection.

How would you lead a migration to the Constructor React component library?

I would inventory existing patterns, define migration boundaries, and introduce shared components through incremental replacement rather than a disruptive rewrite. I would document usage standards, add visual and interaction tests for key components, and track adoption and regressions throughout the migration.

How would you turn an ambiguous request from physicists into a concrete frontend solution?

I would first understand the experiment, the user’s decision-making process, and the meaning of each state or measurement. I would validate assumptions with examples or a lightweight prototype, agree on terminology and edge cases, and then translate the outcome into explicit interface behavior and acceptance criteria.

How would you decide whether to solve a frontend problem in Python or another backend service?

I would move computation to the backend when it involves large datasets, expensive scientific processing, shared business rules, or data that should not be transferred to the browser. I would keep lightweight presentation transformations in TypeScript and define a typed, versioned API contract between the layers.

How would you improve frontend reliability and review discipline while owning the interface layer?

I would establish TypeScript and component conventions, automated checks, focused pull requests, and reviews that cover correctness, accessibility, performance, and scientific semantics. I would make technical debt visible, prioritize it against user and operational risk, and monitor defects, test coverage, and review turnaround over time.

A research technology company is seeking a Senior Frontend Engineer to own the interface layer of a scientific platform used by physicists to run and monitor complex experiments. You’ll build interactive workflow graphs, live monitoring views, large-scale result inspection, and robust asynchronous workflows using React, TypeScript, D3, custom SVG, graph-layout algorithms, and occasional Python, while leading migration to the Constructor component library. This is a remote role within Europe with regular on-site presence in Bremen; salary details are not disclosed. Apply for end-to-end ownership, meaningful collaboration with scientists, technically challenging work beyond standard CRUD, and the opportunity to set frontend standards across a research-focused team.