Frontend Engineer
Confirmed on the employer's own hiring board on Oct 14, 2026. First seen by Alion on Sep 17, 2026. Restate scores B on the Alion truth index.
The Opportunity
We're looking for a Frontend Engineer to own the product experience across Restate's UI.
Our UI is where developers end up when something is running, stuck, or has already gone wrong. It's a live window onto a distributed system that keeps moving while you're looking at it. The data is large, it changes under you, and the person reading it is usually in a hurry. That makes it a different job from most frontend work.
You won't be doing this alone. You'll work closely with our design engineers, the wider product team, and the founding team.
Why Restate
Durable runtimes are becoming the next foundational infrastructure layer, especially for AI. Restate’s vision is to make durable execution efficient and lightweight to run.
Restate is built by a team of world-class engineers - the creators of Apache Flink, leaders from Meta's messaging infrastructure, and senior engineers from AWS and Confluent.
AI-native companies like Replit as well as Fortune 500 enterprises rely on Restate in production for their core applications.
With a fresh $20M Series A fundraise by top tier investors and strong traction, we’re just getting started and are looking for people who share our vision and work ethos.
What you’ll do
The scope includes but is not limited to:
Own the frontend end-to-end: Architect, build and ship the product UI, from whiteboarding with engineers through to the production code you'll go on maintaining.
Show what the system is actually doing: Execution timelines, retries, queues, state, failures. People come here to work out what happened, often while under pressure, and the UI has to get them there quickly.
Build for data at scale: Large result sets, live updates, filtering and search that hold up. That includes the charts and timelines sitting on top of the data, which have to stay honest as the volume grows.
Make it fast: Restate is a low latency runtime and the UI should feel like one. Rendering cost, data loading and perceived latency are design decisions here, not a cleanup pass at the end.
Keep it safe to operate: A lot of what this UI renders comes out of our users' own services, and its controls stop, retry and delete real work. Untrusted content, auth, and destructive actions all need more care than they would on an average frontend.
Push the interaction model further. Keyboard navigation, deep links, state that survives a refresh. We're not where we'd like to be here, and we'd like the next person to care about it.
Grow the shared component library, so the product stays coherent as it gets bigger, and so other people can build on it without asking first.
Work closely with design and engineering. Skip the traditional handoff, iterate together, from first sketch to shipped.
The profile
Someone with strong opinions and shipped work that backs them up. You'll have a lot of autonomy and direct access to the founding team, and you should be willing to push back when we're wrong.
Must-haves:
React and TypeScript. Several years of it, on an application big enough to get messy.
Performance. You've profiled and fixed slow rendering, long lists, wasted re-renders, bundle size. Ideally you can point at numbers either side of the fix.
Data-intensive interfaces. Datasets bigger than the viewport. Pagination, virtualization, filtering, search, and charts built on real data rather than a tidy sample.
Data fetching and client state. Caching, invalidation, polling and streaming, optimistic updates, and a sensible answer for when a request comes back slower than the user moves.
Security. Much of what we display comes from someone else's code, so rendering untrusted content safely matters. So do auth and sessions, and some care about what ends up in the dependency tree.
Information design. What to show, what to put one click away, what to leave out. Dense views that still read clearly.
Accessibility. Semantics, focus management, keyboard navigation, assistive technology.
Reading beyond the frontend. API specs, queries, backend code. You don't have to write the backend, but you should be able to read it and work out what's going on.
Testing. Unit and end-to-end, plus the judgement to know which tests are worth keeping.
AI literacy. You use it daily to go faster, and you can tell when the output needs throwing away rather than patching.
Nice to haves:
Prior work on developer tools, observability, or infrastructure products. You know what good looks like for this audience because you've been part of it.
Data visualization: timelines, traces, graphs, time series with more data points than pixels.
Building or maintaining a design system in production, including the part where you keep it coherent two years later.
Multi-tenant SaaS: environments, roles, quotas, usage.
Willingness to open a PR on the back end when a feature needs an endpoint that isn't there yet.
Not a fit:
You expect a finished design to hand off, or heavy direction. You'll work closely with design, but you should turn up with your own view on interaction and information design.
You'd rather stay above the API layer. A fair amount of this work starts below it.
You want to run an engineering team rather than be the senior IC doing the work yourself.
You're not interested in the technical subject matter. Our surface area is wide, and the role lives or dies on translating it.
Engagement, location, and travel
Location: remote in Europe preferred; US remote for exceptional candidates
Travel: minimal; occasional team offsites.