Hire Data Scientists remotely from our vetted global talent

A data scientist turns data into business decisions. The role sits between analytics engineers, who model and structure the data warehouse, and ML engineers, who productionize models in user-facing systems. A data scientist's output is rarely a dashboard and rarely a service. It is an answer: which experiment won, which customer segment is churning, which feature drove the lift, which forecast the planning team should trust. At Terminal, data science hires are the engineers product teams reach for when the question is harder than the SQL.

Analytics and insight generation: The foundation the rest of the role builds on.

• SQL at depth, including window functions, lateral joins, recursive CTEs, and the discipline to read query plans when the warehouse cost matters

• Dashboarding and exploration in Hex, Mode, Lightdash, Looker, or Streamlit, picked by the team's actual workflow

• Exploratory data analysis in pandas, polars, or duckdb depending on the data scale and the engineer's preference

• Writing the memo, not just running the query: framing the question, surfacing the answer, and naming what the team should do next

Experimentation: The discipline that separates a data scientist from an analyst.

• A/B testing with proper power analysis, minimum detectable effect, and pre-registered hypotheses

• Multi-armed bandits and sequential testing where the cost of the worst arm is high

• Novelty effects, network effects, and the long tail of biases that break naive readouts

• Variance reduction with CUPED, stratification, or covariate adjustment when the metric is noisy

Causal inference: What the engineer reaches for when an experiment is impossible.

• Difference-in-differences for rollouts that were not randomized

• Regression discontinuity for policy changes with a sharp eligibility cutoff

• Propensity score matching for observational comparisons across user segments

• Synthetic control for one-off interventions where there is no clean comparison group

Predictive modeling: Tabular ML is still where most data science value lives.

• XGBoost, LightGBM, and CatBoost for structured-data classification and regression

• scikit-learn for the rest of the supervised and unsupervised toolkit

• Time series with Prophet, statsmodels, sktime, or Nixtla's libraries depending on the data shape

• Deep learning with PyTorch, transformers, and Hugging Face when the problem actually needs it

Common stacks worth knowing: Real-world data scientists usually go deep in one or two combinations.

• Python with pandas or polars, scikit-learn, XGBoost, and statsmodels for the modal product analytics workflow

• SQL plus dbt models in a warehouse (Snowflake, BigQuery, Databricks, Redshift) for analytics-engineering-adjacent work

• PyTorch with Hugging Face for fine-tuning, embedding models, and LLM-augmented analysis

• MLflow, Weights & Biases, Vertex AI, SageMaker, or Databricks Model Serving when models leave the notebook

• Hex, Mode, or Lightdash notebooks for analyses the team needs to share, comment on, and revisit a quarter later

The case for a data scientist is almost always a question-quality argument. When the company needs someone to translate business questions into measurable hypotheses, run the experiments, and tell the team what is actually true, hiring a data scientist who lives in that work full-time is the highest-leverage move on the roadmap. The case against shows up when the company needs infrastructure or modeling instead.

Experimentation is the operating system: Anywhere the company makes decisions by testing them.

• Product teams running dozens of concurrent experiments where naive readouts produce false positives

• Growth teams where the lift on every channel needs an honest counterfactual

• Pricing, packaging, and onboarding tests where the cost of getting the math wrong is months of misallocated effort

• Platforms with enough traffic to power small effects, where the lift is real but easy to miss

Causal questions outnumber predictive ones: When the team needs to know why, not just what is going to happen.

• Marketing attribution where last-touch is wrong and multi-touch is incomplete

• Retention work where confounders drown out the actual treatment effect

• Policy changes, pricing changes, and rollouts that cannot be randomized

• Product decisions where correlation is plentiful and causation is what the executive wants

Predictive models that pay for themselves: When the model output drives a decision the business cares about.

• Churn, lifetime value, propensity, and lead scoring models that route resources where they matter

• Demand forecasting for inventory, capacity, or headcount planning

• Fraud, abuse, and anomaly detection where a small false-negative rate is worth a lot

• Recommender systems and ranking models where ML engineers ship the system but data scientists own the metric

AI Fluency multiplier: Agentic AI workflows have changed how data scientists explore, model, and communicate, and the gains compound on analysis work.

• An AI Enabled data scientist running Cursor or Claude Code with human-in-the-loop review can scaffold a SQL query, the polars transform that consumes it, the model that fits it, and the memo that explains it in a single session

• An AI Native data scientist orchestrates agents for agentic data exploration, LLM-augmented EDA across unfamiliar tables, and RAG-driven internal tools that put analysis in product managers' hands directly

• Prototyping LLM-driven product features (RAG over internal corpora, embedding-based search, agentic workflows) sits inside the data scientist's lane in 2026, alongside traditional modeling

• Terminal classifies every engineer in AI Assisted, AI Enabled, or AI Native tiers and surfaces those signals at hire time

When not to hire a data scientist: Other roles win in adjacent problems.

• Pre-product-market-fit startups where founder instinct beats statistical rigor and the data volume cannot power any test

• Companies that need warehouse modeling and dbt ownership: hire an analytics engineer instead

• Companies that need to ship models behind APIs at scale: hire an ML engineer instead

• Teams that only need a dashboard built once a quarter: hire an analyst, not a senior data scientist

• Organizations without the upstream data infrastructure to support analysis: fix the warehouse before hiring someone to query it

A senior data scientist's job description is broader than the job posting suggests, but the day-to-day is concrete. Here is what they actually own.

Question framing and stakeholder partnership: The default unit of work.

• Translate an executive or product question into a measurable hypothesis, with the metric, the population, and the time window defined before any SQL gets written

• Push back on questions that cannot be answered with the available data, and propose the version that can

• Own the change from kickoff (the question) through landing (the memo, the recommendation, the follow-up)

• Pair with product, engineering, and finance on the framing before the analysis starts, not after

Experiment design and analysis: The work the rest of the role is judged on.

• Power analysis, sample-size calculation, and pre-registered metrics before the experiment ships

• Randomization unit chosen deliberately (user, session, account, geography) to match the treatment

• Readouts that account for novelty effects, peeking, multiple comparisons, and the rest of the bias zoo

• Post-experiment memos that name the lift, the confidence interval, and the decision the team should make

Causal inference when randomization is impossible: The senior bar is knowing when correlation is enough and when causality matters.

• Choose the right quasi-experimental design for the data: difference-in-differences, regression discontinuity, propensity matching, synthetic control

• Identify and stress-test the assumptions each method imposes, and document where they hold or break

• Communicate uncertainty honestly to stakeholders who want a single number

• Refuse causal claims the data does not support, even when the executive is impatient

Predictive modeling, end to end: From data pull to model output the business uses.

• Feature engineering, target leakage avoidance, and the unglamorous discipline of clean training data

• Model selection that prefers the simplest model that meets the bar, not the most fashionable

• Calibration, threshold selection, and the trade-offs between precision and recall for the actual decision

• Hand-off to ML engineering for productionization, with the documentation and tests that survive the hand-off

Analytics and dashboarding: The work that scales the data scientist's answers across the company.

• SQL that other analysts and PMs can read, modify, and trust

• Dashboards in Hex, Mode, Lightdash, or Looker that answer one question well, not twenty questions poorly

• Metric definitions that match the semantic layer (dbt, LookML, Cube) so the same number does not have three values

• Self-service tools that get PMs and operators answers without a data scientist in the loop

LLM-augmented analysis and tooling: Senior data scientists treat agents as part of the workflow.

• Use Claude Code, Cursor, or notebook-native agents to draft SQL, scaffold polars transforms, and explore unfamiliar tables

• Build RAG over internal documentation, query logs, and analysis memos so the rest of the team can ask questions in plain English

• Prototype agentic data products: triage agents, alerting agents, narrative-generation agents for executive reporting

• Validate model output rigorously. Agents accelerate the work, but the data scientist still owns the answer

Cross-team communication and influence: A lot of the work happens outside the notebook.

• Write memos that engineers, PMs, and executives can act on without a follow-up meeting

• Present findings to leadership with the right level of statistical rigor for the audience

• Partner with analytics engineers on the upstream models the analysis depends on, and push back when a metric definition does not match the question

• Partner with ML engineering on the hand-off from notebook to production, including the tests and documentation the model needs to survive without the original author

• Mentor junior data scientists and analysts through code review, design review, and analysis review

The skill bar separating a senior data scientist from a generalist is depth in a few areas, not breadth across all of them. Terminal screens for both. Only the top 7% pass our screening, and the skills below are the ones that come up in technical interviews.

Statistical foundations at depth: The non-negotiable core.

• Frequentist inference: hypothesis tests, confidence intervals, power, p-values understood correctly

• Bayesian reasoning: priors, posteriors, and when a Bayesian model produces a better answer than a frequentist one

• Regression at depth: linear, logistic, mixed-effects, regularized, and the assumptions each imposes

• The senior tell is knowing when a regression is the wrong tool and saying so

Experimentation expertise: Production experience designing experiments, not just analyzing them.

• A/B test design including randomization unit, stratification, and minimum detectable effect

• Multi-armed bandits, sequential testing, and group sequential designs when the team cannot afford a long fixed-horizon test

• Novelty effects, network effects, primacy effects, and the corrections that handle each

• Variance reduction with CUPED, stratification, or covariate adjustment when the metric is noisy

Causal inference judgment: The skill that distinguishes seniors from juniors.

• Difference-in-differences, regression discontinuity, propensity score matching, and synthetic control applied to real product questions

• Instrumental variables and front-door criteria when the assumptions are defensible

• Sensitivity analysis that quantifies how much an unobserved confounder would have to move to overturn the conclusion

• Juniors run regressions. Seniors design experiments and reach for causal methods only when randomization is impossible

SQL and the Python data stack: Real fluency, not bullet-point familiarity.

• SQL with window functions, CTEs, lateral joins, and the discipline to optimize the slow query

• pandas and polars at depth, with the judgment to pick the right one for the data size and the team

• numpy, scipy, statsmodels, and the rest of the scientific Python toolkit

• pyarrow and duckdb for fast local analysis on warehouse-scale data without standing up a cluster

Predictive modeling toolkit: Depth in the modal tabular ML stack.

• XGBoost, LightGBM, and CatBoost tuned with discipline, not default parameters

• scikit-learn for pipelines, cross-validation, hyperparameter search, and the rest of the supervised toolkit

• Time series with Prophet, statsmodels, sktime, or Nixtla depending on the data shape

• PyTorch, Hugging Face, and transformer fine-tuning for problems where deep learning earns its complexity

MLOps awareness: Senior data scientists hand off models that ML engineers can ship.

• Experiment tracking with MLflow or Weights & Biases as part of the workflow, not an afterthought

• Familiarity with model serving platforms (Vertex AI, SageMaker, Databricks Model Serving) even when ML engineering owns the deploy

• Feature stores, training/serving skew, and the operational risks that bite models in production

• Monitoring for drift, performance decay, and the silent failures that hurt the business months after launch

Communication and memo-writing: The output the role is judged on.

• Memos that name the question, the answer, and the recommendation in the first paragraph

• Visualizations that show the data honestly, not the data flattered

• Comfort presenting to executives, engineering, and product with the right level of detail for the audience

• Calibration: stating confidence honestly when the data is thin or the assumptions are shaky

AI Fluency: The capability shift that is reshaping data science output.

• Daily use of Claude Code, Cursor, GitHub Copilot, or comparable AI coding assistants for SQL drafting, notebook scaffolding, and exploratory data analysis

• Comfort with agentic data exploration, LLM-augmented EDA, and RAG-driven internal tools that put analysis in stakeholders' hands directly

• Working knowledge of embedding models, fine-tuning, and prototyping LLM-driven product features alongside traditional modeling

• AI Enabled or AI Native tier per Terminal's standard. The data scientist either uses AI tools to compound their output significantly, or builds agentic workflows directly

Soft skills that matter: The non-technical bar is real.

• Clear written communication. Most data science work lands as a memo, a doc, or an async update

• Pragmatism on scope. Knowing when a back-of-envelope answer is enough and when the question deserves a full study

• Mentorship instinct. Senior data scientists raise the analytical floor of the whole team

• Intellectual honesty under pressure. The instinct to say 'the data does not support that' when the executive wants a different answer

• Business literacy. Tying every analysis back to the metric that moves revenue, retention, or cost