.jpg?1679514745){kind=logo}
Want to know if this job is worth applying to?
United States
Remote only
Role Summary
Fusion Worldwide is a global open market distributor of electronic components. When a supply chain breaks because of an allocation, a shortage, or a part going end-of-life, we're who the world's largest manufacturers call.
That business runs on knowing things: which companies are real and active, which parts substitute for which, who is likely to need what. Our traders make those calls in hours, using what the platform shows them.
We run a production data and intelligence platform. RMS is our system of record, a custom internal ERP we build and maintain. Every order, quote, and transaction lives there. Our platform sits on top. It reads from RMS, enriches and models that data, and writes operational results back.
Tech Stack
• Data: Microsoft SQL Server, Azure SQL
• Languages: Python, PySpark, SQL, TypeScript
• AI: Claude connected directly to our platform for agentic development
• Applications: Custom applications in React, APIs consumed by Web RMS
• Integration: RMS, HubSpot, vendor APIs
• Cloud: Microsoft Azure
• Work management: Atlassian (Jira, Confluence)
Platform & Data
• Work with the object model covering companies, parts, offers, and demand signals. That includes adding object types, properties, and relationships as the data needs them.
• Build and maintain ingestion from RMS, Azure SQL, HubSpot, and vendor APIs, along with the transforms, pipelines, and automations behind it.
• Build and maintain the quality gates, including data expectations that fail the build, freshness checks against declared SLAs, and tests that catch problems nobody would otherwise notice.
• Tune performance across query plans, index design, materialization strategy, and caching.
• Help with incident response when pipelines or write-backs break, which may include on-call.
System of Record Write-backs
• Work on the write-back path into RMS. Scores, enrichment, resolved entities, and operational flags get written back to the system of record.
• Handle idempotency, conflict handling, and reconciling the two sides when they disagree.
APIs, Applications & AI
How We Work
Our team built this platform with AI agents, and you'd keep working that way. We're rolling out a federated team model, and this role sits on the core data platform team. Claude connects directly to our platform and writes transforms, queries our data, runs audits, and reads the object model as it goes.
You'll have a budget for AI tooling and compute, and we won't make you fight for model access.
Agents write most of the code. You build and maintain the agents, including their instructions, the tools and data they can reach, and the checks that catch their mistakes. You review what they produce and fix it when it's wrong. A few things that have gone wrong here: a scoring pass quietly stopped running. An LLM we used to check output lost part of its prompt and started approving everything. A library upgrade changed a default setting and turned off a live feature, and no test caught it.
We want someone who has used agents heavily on production systems, had them fail, and changed how they work because of it.
Leave your ego at the door. Everyone on the team does hands-on work, including the tedious parts. We're not interested in self-promotion. If most of your AI experience is posting about it on LinkedIn, this role isn't a fit. We'll ask what you built, what broke, and what you'd do differently. People who do well here give credit freely and say so when they're wrong.
You'll inherit written standards, including runbooks that define "done" for a pipeline, notes on past mistakes, and approved project plans. We'd expect you to follow them and add to them.
What We Build Has to Be Explainable
A trader who disagrees with a number can see where it came from. Parameters and thresholds are stored as versioned data, and every output records which version it used. None are hard-coded in a transform. Anything an LLM generates comes with a plain-English reason and a link to the source field. Lineage is kept end to end, so you can trace a wrong number back to the row that caused it.
Taking a Feature End to End We have a product manager, and you'd work with them on direction and priorities. They don't have to sit in the middle of every decision. Once you pick up a problem, you'll do most of the scoping, building the POC, iterating, and deciding when it ships. You'll do some of the product work yourself. That includes talking to the trader who raised the problem, deciding what the first version leaves out, and choosing when a rough version is ready to show them. Everything you work on gets a Jira ticket. You'll work in a light Agile process, with story point estimates. The product manager or business analyst writes most tickets, and you'll write your own for improvements, fixes, and iterations, using AI to draft them.
Requirements
• Production data platform experience, on platforms such as Databricks, Snowflake, Spark, or dbt.
• 8+ years building software, weighted toward backend and data engineering.
• Expert SQL and deep experience with relational databases such as SQL Server, PostgreSQL, Oracle, or MySQL. We run SQL Server. You can read an execution plan, design indexes that hold up under load, and tell when a normalized model is the wrong choice.
• Experience writing back into a system of record. Transactional integrity, idempotency, and reconciliation.
• API design. You've designed APIs for applications you don't control, changed them without breaking those applications, and shaped them around what a UI needs.
• End-to-end delivery. You can point to features you drove from idea through POC, build, iteration, and release. We'll ask what you cut from scope, what you shipped rough, and what you killed.
• Caching and performance engineering. You've made slow things fast and can explain what you changed.
• Git, code review, and CI/CD. You work in Git, review other people's code, and ship through automated tests in a CI/CD pipeline.
• Data governance and security. Access controls, handling sensitive data, and meeting audit requirements.
• Production LLM systems you built and shipped, including what comes after shipping, such as evaluation, guardrails, cost, and latency.
• Day-to-day work with AI agents on production systems, with specifics on where they help and where they quietly fail.
• Building systems other people can audit. Lineage that holds up, parameters stored as versioned data, and outputs a non-engineer can challenge.
• Clear written communication. We write a lot of documents, and this role writes many of them.
Strongly preferred
• 3+ years hands-on experience with a production data platform, including object modeling, building and shipping pipelines, and shipping an application that people use
• Python and PySpark, including catching what an agent gets wrong, such as a transform that looks right but skews the join, a window function that silently drops rows, or a fix that passes tests and breaks the contract downstream
• Dimensional modeling and schema design judgment
• Entity resolution, master data, taxonomies, or knowledge graphs
• React
• Process mining
• Jira, including connecting to it with Claude or other AI tools
• ERP integration experience • Streaming and event-driven ingestion (Kafka, CDC)
• Electronics distribution, supply chain, or industrial B2B data
Explicitly not required
• A PhD
• Deep learning research or model training. We use frontier models; we don't train them
• Prior distribution-industry experience
• Front-end as a primary skill. The job is data and backend
Ramp
Application Question Instead of a cover letter, we'd rather have your answer to one question: Describe something you built on a data platform that you'd model differently if you started again today, and what changed your mind. Our interviews include a hands-on build session. You'll use Claude, and you'll explain every line you ship.