Staff Software Engineer

Location: Bengaluru, Karnataka, India
Department: Engineering

Nexla, briefly

Nexla is the data connectivity layer for enterprise AI. Over 1,000 bidirectional connectors give agents real-time access to data and actions over MCP. Nexla's Agentic Data Integration handles high-volume streaming ETL, CDC, and Document ETL. At the core of the platform is Helix, a context engine that continuously learns from metadata, schemas, telemetry, and documentation to give agents accurate context and keep pipelines reliable. Nexla processes over a trillion records a month for enterprises including DoorDash, LiveRamp, LinkedIn, and J&J. Honorable Mention in the Gartner Magic Quadrant™ for Data Integration Tools, and top-rated by customers on Gartner Peer Insights four years running.

Role
You would work on the backend systems that move data through Nexla: JVM services, the streaming runtime on Kafka, and the distributed processing underneath. Production Java every day. Nobody hands you a finished design. You own systems end to end, from design through deploy to on-call, and you debug them when they break. The role sits between our platform and integration layers, so you would work across both rather than inside one. Small, focused team, which is why the ownership is real rather than nominal.

What you'll own

• Core framework features, designed and shipped by you. Schema evolution, pagination, rate limiting, circuit breaking, and the automated retries and self-recovery that keep pipelines running without a human watching. The SDKs and interfaces other teams build on sit here too: you write them, document them, and use them yourself.
• The streaming and processing path in production. Kafka, Spark, and Flink workloads, checkpointing, backpressure, and failure recovery. You operate what you build.
• Technical direction. Architecture for multi-tenancy, high concurrency, and low latency, plus the technology calls underneath it: where the JVM is the right answer, where an alternative runtime is better, and how to cut infrastructure cost without giving up reliability.
• The hard debugging. Trace failures across Kafka clusters, distributed runtimes, and flaky third-party APIs, fix them, then build the guardrails so they do not come back.

Staff scope: you work directly with Product and the CTO to turn customer needs and market shifts, from GenAI data ingestion to real-time CDC and agentic workflows, into technical plans. On a team this size your standards become the team’s standards.
Roughly 60% building and shipping, 25% architecture and technical direction, 15% code review, design sessions, and the RFCs, runbooks, and docs that come with them.

The hard problem
Our platform integrates with more than a thousand external systems, each with its own schema quirks, auth scheme, rate limits, and retry semantics. The framework problem is the N+1 one: making the thousandth integration as cheap to add as the tenth. That means absorbing the differences into the abstraction rather than special-casing them, while the data underneath keeps moving at production volume.

Must-Haves

• 10 to 14 years of software engineering, with significant time building platforms, frameworks, or SDKs rather than end-user applications.
• Expert-level Java. You understand JVM memory management, concurrency models, and non-blocking I/O well enough to diagnose a thread starvation issue from a heap dump.
• Deep experience with distributed systems in production: Kafka, Spark, Flink, or similar. You have operated these systems, not just used them.
• Comfort with the modern data stack and the protocols around it: Snowflake, Databricks, gRPC, GraphQL, webhooks, and CDC.
• You have owned production systems and know what good operational discipline looks like.
• You use AI tools in your actual work and can say specifically where they help and where they mislead you.

Bonus points

• Contributions to open-source data projects such as Airbyte, Flink, Debezium, or Arrow.
• Time at an iPaaS or ELT company: MuleSoft, Fivetran, Informatica, Airbyte, or similar.
• Deep Kubernetes and cloud-native experience, including Strimzi for Kafka.
• Security architecture: OAuth 2.0, mTLS, and encrypted credential management at scale.

You'll thrive here if

• You want ownership and will take it. You write code every day and you carry what you ship, through deploy and on-call.
• You are comfortable defining scope on the fly and shipping before the full picture is clear.
• You would rather build the guardrail than fix the same failure twice.
• You are fine with your standards becoming the team’s standards. On a team this size, they will.

One thing to be clear about: our product definition is still moving as AI reshapes data integration, and the platform has to move with it. If you want a stable, well-defined surface to work on, this is not it.

How we hire
Four conversations, about two weeks end to end.

• Coding. Working through real code rather than a puzzle. 60 mins.
• Low-level design. How you structure a system at the class and interface level, and the tradeoffs you would defend. 60 mins.
• High-level design. Distributed systems design on a problem close to what we run in production. 60 mins.
• Product deep dive and fit. Our product in depth, and whether the scope of this role is what you actually want. 60 mins.

On AI in the coding round. Use it the way you would on the job, ours or anyone else’s. We build AI tooling and we expect you to use AI tooling, so watching you work without it would tell us nothing useful. What we dig into is your judgment: what you delegated, what you verified, and what you threw away.
You will hear from us either way.

The practical stuff
Bengaluru, hybrid, two days a week in office. Compensation includes base salary and equity, set by depth and experience rather than by title. You will need to overlap with morning Pacific hours for syncs, design reviews, and collaboration with our US-based leadership and engineering teams. On-call is part of the role.

Worth a look before you apply

• What we are building now. MCP Studio and Express, our two newest bets.
• Who uses us, and why. nexla.com/customers
• The product in engineer terms. docs.nexla.com
• Our CEO on why we take "Remember to Relax" seriously. Read the founder story
• Everything else. nexla.com  ·  Blog  ·  All open roles

Why Nexla? Why now?

A few large companies - DoorDash, SentinelOne, Johnson & Johnson, LinkedIn, Amex, Integrity Marketing, among them use Nexla for data integration. Connectors, runtime, transformations, scheduling, the parts of the stack where data has to move between systems reliably.

The reason this is an interesting moment to join is what the agent shift is doing to the category. Data integration used to mean "land this data in that warehouse so a human can look at it." That product is mature. What it's becoming is closer to "an agent asks a business question, and the platform figures out which data and what code and which APIs add up to a real answer." That's a much bigger problem, and most of the architecture for it hasn't been built yet by anyone.

A concrete example. A revenue team wants to ask "which enterprise customers are showing renewal risk" and get a real answer through whatever agent or app they work in. Today there is no clean way to answer that question, it requires CRM, usage, support, and billing data joined in org-specific ways, and the calling agent can't just invoke a tool that returns the right answer unless someone first establishes whether the underlying data is even capable of producing one.

That is the system we are building. A probe agent investigates the data plane whether the right fields are populated, whether freshness is adequate, whether the joins exist, whether credentials cover the required scope and returns a grounded feasibility answer. Where there are gaps, Express.dev composes the pipelines to close them. The capability is then exposed as an MCP server: "renewal risk" as a curated product, with the business logic correct and the query semantics described well enough that the calling agent uses it as intended. The MCP Gateway governs which agents can call which capabilities, with the policies, audit, and observability an enterprise control plane requires.

The bet is that ten years of connector work, an enterprise customer base, and a runtime that already moves real volume are the right foundation to define this layer from.