Software Engineer II (JVM)

Nexla, briefly

Nexla is the data layer for enterprise AI. We give AI apps and agents the connectivity, context, and governance to work across more than 1,000 enterprise systems in real time, and we process over a trillion records a month doing it. DoorDash, LinkedIn, Johnson & Johnson, Instacart, and LiveRamp run mission-critical data on us. Honorable Mention in the Gartner Magic Quadrant™ for Data Integration Tools, and top-rated by customers on Gartner Peer Insights four years running. Founded 2016, remote-first, headquartered in San Mateo.

Our values are short and we actually use them: Have Empathy. Be Curious. Be Intellectually Honest. Achieve Excellence. Remember to Relax.

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 it. Production Java every day. You take a problem, shape the design, build it, and own it through deploy and on-call. You debug it when it breaks. Small, focused team, which is why the ownership is real rather than nominal. This role sits closest to the integration layer, where the platform meets everything outside it, so the problem below is the one you would live in.

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.
• Design decisions inside your scope, and a real voice in the ones above it. Multi-tenancy, concurrency, and latency show up in almost everything here, and you would be expected to have views on the tradeoffs rather than only implementing someone else’s.
• 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.

Roughly 70% building and shipping, 15% design and technical discussion, 15% code review and the RFCs, runbooks, and docs that come with it.

The hard problemOur 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

• 5 to 8 years of software engineering, with some of it on backend platforms, services, or SDKs rather than only end-user applications.
• Strong Java. You understand JVM memory management, concurrency models, and non-blocking I/O, and you can work your way to the cause of a thread starvation issue from a heap dump.
• Hands-on experience with distributed systems in production: Kafka, Spark, Flink, or similar. You have run them, not only built against 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 raise the quality of what is around you through review and pairing, not just the quality of what you write yourself.

*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 wan…