Über diese Customer Engineer Stelle bei Nexla
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, briefly
You would be the technical bridge between our customers and our engineering teams. When a customer’s pipeline breaks, or our Ops team spots something before the customer does, you take it: dig through logs and connectors, find the actual cause, and see it through to a fix. This is not ticket triage. You own the resolution, including the engineering conversations it takes to get there. Python, SQL, and REST APIs are the tools you reach for daily.
What you’ll own
- Technical resolution, end to end. Cases raised by customers and issues surfaced by our Ops and L1 team: first investigation, root cause, and the fix, including driving it with the engineering teams who own the code.
- The investigation itself. Logs, connectors, the Nexla environment, and whatever Python or shell you need to write to see what is actually happening. Written fast, often thrown away.
- What you learn, written down. Known and newly found solutions in the knowledge base so the next person does not start from zero, plus the Global Alerts and visibility updates that go to Sales and Customer Success when an issue reaches past one customer.
- The customer’s experience of all of it. Clear updates across email, tickets, Slack, and calls, and support through product releases.
The hard problem
Most of what lands on you will not be a bug in our code. It will be a third-party API that changed without telling anyone, a file that arrived malformed, an auth token that quietly expired, or a schema that moved. Across more than a thousand external systems, each with its own quirks, the hard part is working out which side of the boundary the problem sits on, and proving it, while the customer is waiting and reasonably assumes it is ours.
Must-haves
- 3 to 6 years in data engineering, technical support, or a closely related role.
- Strong Python. You write scripts quickly to debug something or set up an alert, and you are comfortable throwing them away afterwards.
- Solid SQL and hands-on with databases: Postgres, MySQL, Oracle, or SQL Server.
- REST APIs and the authentication around them: OAuth2, SSO, and token-based. You have debugged an auth failure that was not documented anywhere.
- Comfortable on both Linux and Windows, and with data formats including CSV, XML, JSON, and Parquet.
- You use AI tools in your actual work and can say specifically where they help and where they mislead you.
Bonus points
- Apache Airflow.
- You have worked a support or on-call rotation before and know what good looks like.
- Data integration, ETL, or iPaaS background.
You’ll thrive here if
- You can write a clear update to a frustrated customer and a clear one to a busy engineer, and you know those are different jobs.
- You like digging. Logs, traces, and the part where it finally makes sense.
- You do not handle a problem half-understood.
- You work well with people who are under pressure, without adding to it.
One thing to be clear about: this role runs on a shift rotation with weekend coverage shared across the team. We do not run late-night shifts, but your week will not always be Monday to Friday. If that does not fit your life, this is not the right role, and it is better to know now.
The practical stuff
Bengaluru preferred, and we are open to candidates working remotely elsewhere in India. The role runs on a rotational shift pattern with weekend coverage shared across the team. We do not run late-night shifts. Compensation includes base salary, bonus, and equity, set by depth and experience rather than by title.
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 you would be supporting. 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.
