Lead Software Engineer

SDE-3 - Platform

Backend Engineering | Distributed Systems | System Design

About Mstack

Mstack is building the world’s first AI-native chemical company.

We combine AI, scientific R&D, software and real-world manufacturing to dramatically shorten the time it takes to move from a chemical idea to commercial production. Our technology powers Chemstack AI, our chemistry intelligence platform, as well as a growing set of products across commerce, internal operations, automation, analytics and decision-making.

As Mstack grows, software is becoming the operating layer connecting our customers, scientists, commercial teams, supply chain and manufacturing ecosystem.

About the Platform Team

The Platform team builds the technology foundation that powers products across Mstack.

Some of our systems support Chemstack AI, including agentic workflows, enterprise applications and scientific tooling. But the Platform team works across a much broader problem space.

We are building systems for commerce, operational workflows, internal automation, metrics and decision-making, and shared capabilities that allow teams across Mstack to build products faster.

Our goal is not to create isolated applications. We want to build reusable engineering primitives, services and platforms that can support multiple products while remaining reliable, secure and easy to evolve.

The Role

• We are looking for an SDE-3 who is strong in backend engineering and enjoys solving difficult systems problems.
• You will design and build services that sit underneath critical products and workflows across Mstack. The problems you work on may involve distributed systems, asynchronous workflows, high-volume APIs, event-driven architectures, long-running jobs, data consistency, reliability and failure recovery.
• You will be expected to do more than implement a design handed to you. You should be able to take an ambiguous problem, understand the product and system constraints, design the architecture, reason through trade-offs, and take the system all the way to production.
• Systems design is core to this role. You should be comfortable thinking about what happens when traffic grows 10x, when dependencies fail, when a job runs for hours, when the same message is delivered twice, or when a system has to evolve without breaking existing users.

What You'll Do

Design backend systems

• Design services, APIs, data models and system boundaries for new products and platform capabilities.
• Work through trade-offs around consistency, availability, latency, throughput, maintainability and cost.
• Move comfortably from a product requirement to a concrete architecture and execution plan.Build distributed and asynchronous systems
• Design and operate systems involving queues, event streams, background jobs and workflow orchestration.
• Build systems where work may take seconds, minutes or hours and still needs to remain reliable across retries, crashes and deployments.
• Think carefully about idempotency, retries, ordering, concurrency, backpressure and failure recovery.Own systems end to end
• Take ownership from design through implementation, testing, deployment and production operations.
• Be responsible not only for whether the code works, but whether the system behaves correctly in production.Build APIs and platform services
• Design clean interfaces that allow other teams and products to build on top of your systems.
• Create reusable platform capabilities rather than repeatedly solving the same problem inside individual applications.Work with complex data flows
• Build systems that move and transform data across multiple services and workflows.
• Reason about transaction boundaries, consistency models, caching, indexing, schema evolution and data lifecycle.Engineer for reliability
• Design for failures before they happen.
• Build appropriate observability, metrics, logging and tracing so systems are understandable when something goes wrong.
• Participate in debugging production incidents and improve systems based on what we learn.Make systems scalable
• Identify bottlenecks before they become production problems.
• Improve application, database and infrastructure performance as workloads grow.
• Know when horizontal scaling solves the problem and when the architecture itself needs to change.Raise engineering standards
• Contribute to architecture reviews, code reviews and engineering discussions.
• Help improve how the team approaches system design, testing, reliability and maintainability.
• Mentor engineers when appropriate and help the team make better technical decisions.

What We're Looking For

• 7+ years of professional software engineering experience, primarily working on backend or distributed systems.
• Strong fundamentals in data structures, algorithms, operating systems, networking and databases.
• Strong experience designing and operating production backend systems.
• Strong system-design ability and clear reasoning about architectural trade-offs.
• Experience designing APIs, service boundaries and data models.
• Experience with relational databases, including indexing, transactions, locking and query performance.
• Experience with asynchronous processing using queues, event systems or background workers.
• Strong understanding of concurrency, retries, idempotency and common distributed-system failure modes.
• Experience debugging production systems using logs, metrics and traces.
• Understanding of caching and the consistency trade-offs it introduces.
• Experience building systems that have scaled meaningfully in traffic, data volume or complexity.
• Strong coding ability in at least one backend language such as Python, Go, Java or similar.
• Experience with at least one major cloud platform such as AWS, GCP or Azure.
• Ability to independently take a technical problem from ambiguity to production.

Systems Design Expectations

Systems design is a significant part of the engineering bar for this role. We care less about memorised templates and more about whether you can identify the important constraints, make assumptions explicit, and reason through trade-offs.

You should be comfortable discussing questions such as:

• How would you design a service that needs to handle millions of requests reliably?
• When would you choose synchronous communication versus an event-driven architecture?
• How do you make a job safe to retry?
• How do you prevent duplicate processing in a distributed system?
• When should data live in one database versus separate services?
• How do you evolve an API without breaking existing consumers?
• How do you design for partial failure and slow dependencies?
• How would you build a workflow that needs to run reliably for several hours?
• When should you use caching, and how do you keep cached data correct?
• How do you identify whether a scaling problem comes from compute, database, network or architecture?

Nice to Have

• Go or Python in production.
• PostgreSQL or other relational databases at scale.
• Kafka, SQS, Pub/Sub or similar messaging systems.
• Kubernetes and containerized production environments.
• Infrastructure as code and strong production operations practices.
• Workflow orchestration systems.
• Microservices or service-oriented architectures.
• Distributed tracing and observability platforms.
• Multi-tenant B2B systems and enterprise security patterns.
• High-volume commerce or transaction systems.
• AI or agentic systems, including MCP or tool-based agent architectures.
• Search, indexing, retrieval infrastructure, or data-intensive analytics platforms.

How We Think About Backend Engineering

We care about engineers who understand that production systems are more than application code. A strong backend engineer should be able to ask:

• Where can this system fail?
• What happens when the database becomes slow?
• Can this request safely be retried?
• What if the same event arrives twice?
• What state should be persisted?
• Which operations require strong consistency?
• What should happen during a partial outage?
• How will we understand this system six months after it goes live?
• What assumptions stop being true when the workload grows 10x?
• Are we building something reusable or adding another one-off service?Writing clean code matters. Knowing what system should be built in the first place matters even more at this level.

Why Mstack

• Work on systems that connect software and the physical world
• The systems we build influence real scientific, commercial and operational workflows rather than existing only behind a screen.
• Solve problems across multiple domains
• You may work on AI infrastructure one quarter and commerce or operational systems the next. The engineering principles remain the same, but the problems are rarely repetitive.
• Build foundations, not just features
• The Platform team is responsible for capabilities that multiple products and teams can build upon. Good technical decisions have leverage across the company.
• Own meaningful architecture
• Many of the systems that Mstack will need at scale are being designed today. You will have the opportunity to shape those systems rather than simply operate infrastructure designed years ago.
• Work close to the problem
• Engineers work directly with product teams and domain experts. You will understand why a system is being built, not just receive a ticket describing what to implement.

What Success Looks Like

• Within your first few months, you should be able to independently own a meaningful backend system or platform capability from design to production.
• You should be able to understand an ambiguous problem, propose an architecture, identify its risks and trade-offs, and drive the implementation.
• Over time, we expect you to become one of the engineers people rely on for difficult systems-design decisions. You should raise the quality of the systems around you through better architecture, stronger reliability practices, thoughtful abstractions and high engineering standards.
• We value demonstrated engineering ability over a particular degree or career path.
• If you have built systems you are proud of, we would love to hear about what you designed, what scale it operated at, where it failed, and what you would do differently today.