BackEnd Engineer: Experiments; Remote

About us

Constructor is the next‑generation platform for search and discovery in ecommerce, built to explicitly optimize for metrics like revenue, conversion rate, and profit. Our search engine is entirely invented in‑house utilizing transformers and generative LLMs, and we use its core and personalization capabilities to power everything from search itself to recommendations to shopping agents. Engineering is by far our largest department, and we've built our proprietary engine to be the best on the market, having never lost an A/B test to a competitive technology.

We're passionate about maintaining this and work on the bleeding edge of AI to do so. Out of necessity, our engine is built for extreme scale and powers over 1 billion queries every day across 150 languages and roughly 100 countries. It is used by some of the biggest ecommerce companies in the world like Sephora, Under Armour, and Petco.

We're a passionate team who love solving problems and want to make our customers' and coworkers' lives better. We value empathy, openness, curiosity, continuous improvement, and are excited by metrics that matter. We believe that empowering everyone in a company to do what they do best can lead to great things. Constructor is a U.S. based company that has been in the market since 2019.

It was founded by Eli Finkelshteyn and Dan McCormick who still lead the company today.

The Experiments team at Constructor builds an experimentation platform: traffic allocation, exposure logging, metric computation, statistical analysis, and a UI for launching experiments and interpreting results. It’s used both internally and by customers running experiments on production traffic.

We’re scaling customer experimentation usage and investing in making experiments faster, more reliable, and easier to interpret. Unlike boxed experimentation tools, our platform has to support a wide range of customer integrations, traffic patterns, and industry constraints — which makes the engineering problems unusually real‑world and high‑leverage.

Team: 3 Software Engineers, 1 Data Analyst, an Engineering Manager, and a Product Manager.

This is primarily a backend role (Python services + data‑heavy systems). You’ll occasionally work in the Dash UI and contribute to Spark jobs, but those are not the main focus. We care about correctness, observability, and product usability more than complex infrastructure.

Tech:
Python, FastAPI, Postgre

SQL, Plotly Dash, PySpark/Databricks, AWS, Cloud Watch, Sentry

(Spark work is ~5–10% — we don’t expect you to be a data engineer or own the data platform.)

• Build and maintain backend services for experiment assignment, logging, and report generation
• Improve scalability, performance, and reliability of experiment reporting pipelines
• Add product‑facing features to the UI to help users launch experiments and interpret results
• Take technical ownership of projects: shape solutions, break down work, and drive execution with the team
• Participate in a weekly on‑call rotation (investigating occasional issues and answering internal questions)

You’ll collaborate closely with Search/Recommendations engineers, ML/DS partners, and customer‑facing teams when needed. This role does not require frequent direct customer calls.

• Strong experience building and owning production backend services in Python
• Experience with monitoring, alerting, and debugging user‑facing systems
• Strong SQL skills and confidence working with data‑heavy systems (metrics, logging, analytics)
• Ability to ship maintainable software (tests, code review, incremental delivery)

• You take ownership: you can turn ambiguous problems into an executable technical plan
• You care about building systems people trust and rely on

• Experience with experimentation systems, metrics platforms, or A/B testing workflows
• Experience with PySpark and/or Databricks
• We don’t expect you to already be an expert in experimentation methodology — but we do expect strong backend fundamentals and the ability to ramp up effectively in a data‑heavy domain

• We’re a distributed team. Preferred time zones are UTC+1 to…