Staff+ Software Engineer

Natter

Get hot jobs first on Telegram

New positions appear faster in our channel

Location: Remote
Job Type: full-time
Work Format: 🌍 Remote
Salary: Not specified
Posted: November 10, 2026

Job Description

About Natter

🗣 Natter harnesses the power of AI and video to give everyone a voice.

In early April 2026, Natter announced its Series A. $23M total raised to define the enterprise conversation intelligence category.

Natter is already being used by some of the world’s largest companies including ServiceNow, Accenture, Philip Morris, Lego, PwC, Mondelez, Cox Enterprises, SAP, Miro, Deloitte, Synopsys and many more.

Natter’s conversational AI platform allows tens of thousands of users to simultaneously share ideas and feedback through real-time video conversations. Its uniquely scalable tech allows anyone with a smartphone to, literally, have a say on the most important decisions - ranging from workplace strategy to new product offerings.

We partner with some of the world’s largest and most complex enterprises (Fortune 500 and equivalent), and are currently growing our team from 30 to 60 employees.

The Role

This is one of the most senior technical roles at Natter. You’ll be accountable for the technical direction of our platform: what we build on, how it scales, and how we get there without slowing down. You’ll join a strong engineering team and work closely with product and engineering leadership.

We’re hiring at Staff or Principal level. The level is set at offer, based on the scope you’ve demonstrably operated at.

This role is for engineers who have already set technical direction for a platform or organisation, designed systems that others build on for years, and made a whole engineering team measurably better. This isn’t a stepping stone into Staff, and it is not an architecture role detached from code. You’ll be among the strongest hands-on engineers on the team, and you’ll be expected to prove it.

What You’ll Own

Technical strategy. Help define the multi-year technical direction for the platform, tie it to business outcomes, and turn it into a roadmap the team can execute against. We have strong engineers working on this, and you’re expected to join and push together.
The hardest systems. Personally lead the design of our most critical and highest-risk systems, such as our AI conversation pipeline, data architecture, and multi-tenant platform, from first principles through to production at scale.
The highest-stakes decisions. Make and defend the decisions that are expensive to reverse, including build vs. buy, data models, service boundaries, and platform choices. Your design docs will set the standard for how we decide things.
Engineering standards. Own the bar for reliability, security, observability, performance, and cost across the entire platform, and hold the team to it.
The engineering organisation. Contribute to how we hire, level, and grow engineers. Mentor senior engineers into Staff-level contributors, and own the technical hiring bar.
Product direction. Be a genuine partner to product and engineering leadership. Bring technical insight that improves what we build.
Enterprise trust. Be the technical face of Natter for our largest clients in security reviews, architecture deep dives, and high-stakes incidents.
Code. Stay hands-on in the critical path. Build prototypes to de-risk decisions, code the hardest pieces yourself, and be the person the team turns to when something is badly broken.

Non-Negotiables

Operated at Staff level or above. You’ve been formally recognised at Staff, Principal, or equivalent, or you’ve been the senior technical lead at a startup with clearly equivalent scope. Your impact reached across multiple teams or the whole engineering organisation.

Set technical direction that stuck. You authored a technical strategy or major architectural direction, drove alignment across engineers and leadership without formal authority, and saw it delivered.
Designed systems at real scale, and lived with them. You were the lead designer of production systems handling significant load, data, or complexity, and you stayed long enough to own the consequences: migrations, re-architectures, incidents, and the decisions you’d now reverse.
Led through serious incidents. You’ve owned production incidents with real business impact, from response through root cause to systemic fixes.
Made other engineers better at scale. You can point to engineers you grew into senior or Staff roles, and to standards or practices you introduced that outlasted your direct involvement.
Exceptional written communication. Your design docs and strategy documents change minds. We will read your writing before we meet you.
Still a top-tier hands-on engineer. You write production code regularly and well. Deep expertise in at least one domain (distributed systems, data infrastructure, or frontend architecture) and enough fluency across the stack to make sound calls anywhere in it.
Deep AWS and infrastructure experience. Production cloud architecture, infrastructure-as-code, CI/CD, and observability at scale.

Strong Signals

Built and operated AI/LLM-powered products in production, including evaluation, latency, cost, and reliability trade-offs.
Enterprise B2B SaaS at scale: multi-tenancy, SSO, data isolation, and compliance (SOC 2, ISO 27001, GDPR).
Event-driven and streaming architectures (e.g. Kafka) in production.
Took a platform and engineering team through a rapid growth phase at a startup.
Public technical work, such as talks, writing, or meaningful open-source contributions.

This Role Isn’t for You If...

You’re a strong Senior engineer looking for your first Staff role. We’d love to hear from you for other openings, but not this one.
You haven’t written production code regularly in the last two years.
You need a detailed spec, a stable roadmap, or a large supporting team to be effective.
Your experience is mainly in a narrow specialism, and you haven’t owned broad technical direction.

The Stack

Languages: Kotlin, TypeScript, Python, Rust
Frontend: React
Data: Postgres, DynamoDB, Kafka
Infra & Compute: ECS, EKS, Lambda
IaC: AWS CDK

We care about fundamentals over specific languages, but you’ll be expected to become credible across this stack quickly.

What We Offer

Top-of-market Staff+ salary, depending on level and significant equity
Direct influence on the technical direction of the company, working alongside the CEO and leadership team
Remote-first working, with a private office in Temple/Strand, London for collaboration and team lunches
Quarterly international team offsites
6 weeks paid annual leave

The Process

Our process typically takes three weeks:

Technical leadership conversation with Head of Engineering (45 mins): your scope, your impact, and how you operate.
Engineering conversation with one of our engineers: your way of working, stack, interests. We’ll get geeky.
Take home assignment (1.5 hours): Prove that you can turn in high caliber work.
Deep dive (1.5 hours): a deep-dive walkthrough of a system you led. Expect us to probe every decision, failure mode, and trade-off or an open-ended design problem.
Cross-functional panel (1 hour) with product leadership: strategy, influence, and disagreement.
Final conversation with the CEO, plus references. We’ll ask to speak with people who worked with you at Staff level.

If you need any adjustments or support during the application process, please let us know.

🎯 Who is this job for?

This role is suitable for a Staff or Principal-level Software Engineer with organisation-wide technical leadership experience, rather than a Senior Engineer seeking their first Staff role. Required skills include hands-on production coding, distributed systems or data infrastructure expertise, AWS and infrastructure-as-code, CI/CD, observability, system design, technical strategy, incident leadership, mentoring, and exceptional written communication. The ideal candidate should be familiar with designing and operating large-scale AI, data, event-driven, multi-tenant SaaS, and cloud platforms, making high-impact architectural decisions, improving engineering standards, and partnering with product leadership and enterprise clients.

💬 Potential Interview Questions

How would you design a multi-tenant conversation intelligence platform that supports tens of thousands of concurrent users while maintaining strict tenant data isolation?

I would define clear tenant boundaries in the data model, authorization layer, storage policies, and processing pipelines. I would combine tenant-aware access controls, encryption, resource quotas, partitioning where appropriate, and automated isolation tests, while designing for independent scaling of real-time ingestion, AI processing, and query workloads.

How would you architect an event-driven AI conversation pipeline using Kafka, AWS compute services, and LLM providers?

I would use Kafka topics to decouple ingestion, transcription, enrichment, evaluation, and persistence, with explicit schemas, idempotent consumers, retry policies, and dead-letter handling. ECS or EKS would handle sustained workloads, Lambda would suit lightweight event processing, and the design would include backpressure, observability, provider fallbacks, and cost controls.

What strategies would you use to make an LLM-powered product reliable, observable, and cost-efficient in production?

I would establish offline evaluation datasets, production quality metrics, regression tests, prompt and model versioning, and human review for ambiguous cases. Reliability and cost would be managed through batching, caching, model routing, token budgets, timeouts, retries, rate limits, and monitoring latency, error rates, quality, and spend by tenant and workflow.

How would you choose between Postgres and DynamoDB for different parts of this platform?

Postgres is preferable for relational integrity, complex queries, transactional workflows, and flexible reporting, while DynamoDB suits high-scale key-value access with predictable access patterns and low operational overhead. I would base the decision on consistency requirements, query patterns, scale, partition-key design, migration needs, and operational cost rather than team preference.

How would you design Kafka consumers to handle duplicate events, ordering requirements, failures, and replay?

Consumers should be idempotent using event identifiers, deterministic writes, or transactional outbox and inbox patterns. I would define ordering only where business-critical, use partition keys deliberately, commit offsets after durable processing, isolate poison messages through dead-letter queues, and retain sufficient history to support controlled replay.

Describe how you would build secure AWS infrastructure using CDK across ECS, EKS, Lambda, and managed data services.

I would define reusable CDK constructs with least-privilege IAM, private networking, encrypted storage, managed secrets, security groups, centralized logging, and environment-specific configuration. Infrastructure changes would go through automated CI/CD, policy checks, preview or diff review, drift detection, and staged deployment with rollback mechanisms.

How would you approach reliability and observability for a platform processing real-time video and AI workloads?

I would define service-level objectives for ingestion availability, processing latency, completion rate, and data durability, then instrument traces, structured logs, metrics, and business events across the entire pipeline. Dashboards and alerts should identify user impact, queue lag, saturation, dependency failures, and cost anomalies, with runbooks and tested recovery procedures.

How would you safely migrate a large production data model or service boundary without disrupting enterprise customers?

I would use an incremental migration with compatibility layers, dual reads or writes where necessary, backfills, validation checks, and feature flags. The migration would have explicit success criteria, observability, rollback or forward-fix plans, tenant-by-tenant rollout, and a clear process for reconciling inconsistencies.

Tell us how you would respond to a high-severity incident involving data loss, elevated latency, or cross-tenant access risk.

I would first establish incident command, contain the impact, protect affected data, and communicate clearly with stakeholders while avoiding speculative fixes. After recovery, I would lead a blameless root-cause analysis, quantify customer impact, address systemic causes, and track preventative actions through completion, including security and compliance follow-up where required.

How would you set technical direction and gain alignment across engineering, product, and leadership when a decision is expensive to reverse?

I would frame the decision around business outcomes, constraints, risks, and measurable success criteria, then document alternatives, trade-offs, and reversibility in a concise design document. I would seek input from affected teams, run prototypes for uncertain assumptions, make the decision explicit, and create an execution roadmap with ownership and review points.

📋 Job Summary

Natter is a fast-growing, Series A AI and video company building a scalable conversational intelligence platform used by leading global enterprises. As a Staff+ Software Engineer, you’ll set technical strategy, lead critical systems across AI pipelines, data architecture, and multi-tenancy, raise engineering standards, mentor senior engineers, and stay hands-on in production code. The stack includes Kotlin, TypeScript, Python, Rust, React, Postgres, DynamoDB, Kafka, ECS, EKS, Lambda, and AWS CDK. This is a full-time, remote-first role within GMT ±3 hours, offering top-of-market salary based on level, significant equity, six weeks’ paid leave, and international team offsites—an exceptional opportunity to shape the technology and engineering culture of a well-funded company at a pivotal growth stage.