> Markdown version of [/jobs/ext/4572190-analytics-engineer-data-platform](https://www.wearedevelopers.com/jobs/ext/4572190-analytics-engineer-data-platform). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Analytics Engineer, Data Platform

- **Company:** The Upside
- **Location:** Washington, DC, United States
- **Experience:** Experienced
- **Contract:** Permanent contract
- **Skills:** Query Performance, Airflow, Data Analysis, BigTable, Code Review, Continuous Integration, Data Governance, Data Infrastructure, Software Debugging, Software Design Documents, Python (Programming Language), SQL Databases, Snowflake, Machine Learning Operations
- **Published:** November 4, 2026
- **Apply:** https://www.careerbuilder.com/job-details/analytics-engineer-data-platform-washington-dc--2486d892-06e1-452f-b707-7e4b7fb5b421

## About the Role

Retail, Sustainability, Data Modeling, Concrete, Marketing, Testing, Debugging Skills, Coaching, Code Reviews, Data Analysis, * You've spent around 3-5 years in data or analytics engineering, or you've done comparable work under a different title

 * You're fluent in SQL, comfortable with window functions and complex joins, and you think about query performance without being asked
 * You've owned dbt models in a version-controlled repo; conventions, tests, CI, and the occasional cleanup of someone else's tangle
 * You know Python well enough to work in orchestration, transformations, and tests
 * You have an opinion on modeling tradeoffs (dimensional vs. one big table) and can explain which you'd pick and why
 * You can explain a technical decision to a marketer and an engineer in the same meeting, and adjust how you say it for each
 * You've worked in Snowflake, or a comparable warehouse you could translate from

## Description

* Own a scoped domain of dbt models: design, build, test, ship, and monitor them, with a clear point of view on how they should be structured
 * Turn ambiguous asks from Marketing and Product into scoped work, and talk openly about tradeoffs when the ask and the timeline don't fit together
 * Write the design doc for the features you own and break the work into pieces teammates can pick up
 * Add monitoring and alerting to your models so your team catches problems before stakeholders do
 * Take your turn on our support rotation, debug what breaks, and prevent the repeat
 * Leave behind runbooks, schema docs, and diagrams that make your work easy for the next person to own
 * Coach engineers earlier in their careers on the team, in code review and day to day, * Marketing, growth, or lifecycle data: events, attribution, experimentation, or tools like Braze, Iterable, or Segment
 * Dagster, Airflow, or another modern orchestrator
 * CI/CD for data, data governance, or cost-conscious warehouse design
 * Supporting ML workflows, like building features or watching model inputs
 * Making warehouse data usable by AI tooling; semantic layers, data contracts, or documentation that agents and humans can both read