The Role Decoded
The Senior Data Scientist, Business Analytics posting translated line by line — what each responsibility actually means day-to-day, who you'll answer to, and what the title "Senior Data Scientist" is quietly hiding.
The posting, decoded
The title says "Data Scientist." Read the responsibilities and you'll notice something: there is not one word about models, forecasting, or ML. This is a job description for a founding analytics engineer with business acumen that HR dressed in a more senior-sounding title. That gap between the title and the work is the single most useful thing to understand before you walk in — it tells you what to talk about (infrastructure, trust, decisions) and what not to lead with (a clever churn model).
Here is the actual posting, phrase by phrase, translated into what it means when you're doing the work, and how you signal that you get it during the loop.
| JD phrase | What it actually means day-to-day | How you signal it in the loop |
|---|---|---|
| "Establish end-to-end data infrastructure — decide where sourcing, storage, and querying happen" | There is no warehouse yet. Data lives in Stripe, Postgres, PostHog, an API gateway, and on-chain. You are making the foundational architecture calls: warehouse choice, ingestion, modeling layer, BI. This is greenfield, and you own it. | Have an opinionated-but-humble v1 stack ready (see Ch 03). Name real tools, justify Postgres-or-DuckDB before Snowflake, and lead with consolidation, not sophistication. |
| "Consolidate data access across financial, product, and growth metrics to kill duplicate systems" | Finance has one number for "users," marketing has another, product has a third, and leadership doesn't trust any of them. Your first real deliverable is a single source of truth — conformed definitions, one place to look. | Talk about a semantic/metrics layer and standardized definitions. Say the phrase "one number, defined once." This is a governance and trust problem before it's a technical one. |
| "Support experiment-tracking infrastructure for product teams" | PostHog is already chosen. You make experimentation trustworthy: clean event schemas, guardrail metrics, someone who can tell product whether a result is real — without user-level surveillance. | Show you can run rigorous A/B without per-user identity graphs (Ch 05). Mention feature flags, guardrails, and how you'd handle a privacy-safe randomization unit. |
| "Proactively surface & answer strategic business questions, transparent about analytical uncertainty" | Nobody hands you a ticket. You find the question leadership should be asking, answer it, and attach a confidence level instead of false precision. Being honest about what you don't know is graded, not penalized. | Give recommendations with a confidence band and a "what would change my mind" line (Ch 08). Model it in the interview itself when you cite the company's own numbers. |
| "Build dashboards, self-serve tools, reporting pipelines" | The end state is that a PM or the CEO can answer their own question without pinging you. You're building leverage, not becoming the human query endpoint. | Talk about democratizing SQL/warehouse access and self-serve BI (Metabase). Frame it as avoiding the "single point of failure" trap that kills first data hires. |
| "Collaborate across product, eng, finance, marketing, leadership" | You have no team. Your influence is entirely cross-functional and depends on relationships. At ~50 people, you'll talk to nearly everyone. This is an evangelism job as much as a build job. | Have a stakeholder-mapping answer and a data-culture-change story. Emphasize outcomes over tech — organize the work around business questions, not pipelines. |
| "Advocate against unnecessary data collection to protect privacy commitments" | You are sometimes paid to say "no, we shouldn't track that." You're a check on the org's instinct to instrument everything. See the dedicated section below — this is the culture-defining line. | Demonstrate genuine alignment, not lip service. Be ready to talk a hypothetical PM out of collecting something (Ch 02). |
| "Build metrics robust to the company's rapid product iteration" | The product changes weekly; models get added, tiers get reshuffled, moderation policy shifts. A metric hard-wired to today's schema breaks by next sprint. You design definitions that survive change. | Talk about metric versioning, stable grain, and not over-fitting a dashboard to a UI that will be gone in a month. "Comfort iterating fast rather than perfecting" is stated in the requirements — echo it. |
Every responsibility resolves to the same job: build the trusted foundation, make it self-serve, and defend the privacy line while doing it. Requirements confirm it — SQL fluency + production-quality code, data-warehousing + a modern analytics stack, explaining uncertainty to execs, and privacy alignment. "Product-minded and engineering-capable" is the phrase; there is deliberately no "PhD," no "deep learning," no "ML in production." If your prep is about models, you're prepping for a different job.
The first-data-hire archetype
The person who succeeds here is a hybrid: analyst + analytics engineer + business operator. Not a research scientist, not a pure ML DS. The center of gravity is getting data into a tidy warehouse and turning it into decisions — ingestion → conformed models → dbt → dashboards — long before anything resembling a machine-learning model is appropriate. Foundations first, always.
Foundations before ML
There is a natural ordering to a first data hire's work, and skipping ahead is the classic failure mode:
- Ingestion — get Stripe, Postgres, PostHog, gateway logs, and on-chain data flowing into one place.
- A tidy warehouse — a place where the data is trustworthy and joins actually work.
- dbt models — conformed financial / product / growth marts with definitions everyone agrees on.
- Dashboards & self-serve — the surface where decisions get made.
- Only then, and only if it earns its place, anything predictive.
Be honest, in the room, that a first data hire produces no meaningful strategic insight for roughly three months — because the first three months are spent fixing logging, wiring ingestion, and building the warehouse. A candidate who promises a game-changing model in week two is telling the hiring manager they don't understand the job. A candidate who says "months one through three are unglamorous plumbing, and here's the 30-60-90 that gets us there" sounds like someone who has done this before. (The full 30-60-90 lives in Ch 03 and Ch 10.)
Evangelizing a data culture
At a ~50-person, fast-moving, remote company, the technical build is maybe half the job. The other half is culture change: getting people to organize decisions around evidence, democratizing warehouse and SQL access instead of hoarding it, and establishing shared metric definitions people actually trust. Culture change needs both top-down air cover (your VP mandating that decisions cite the numbers) and bottom-up pull (PMs and marketers who want the dashboard because it makes them faster). You'll be working both ends.
The way first data hires fail is not usually technical. It's building beautiful dashboards nobody uses, in an org that isn't ready to make decisions with data — you become decoration. The defense is to anchor every deliverable to a live decision someone actually has to make, and to earn trust with a few high-value, correct answers before you try to boil the ocean. If the interviewer probes "how do you avoid becoming a report-generating service," this is the answer they're listening for.
Say it plainly: this is not an ML role. If you're a strong modeler, that's a nice-to-have, not the thing being bought. The thing being bought is someone who can stand up a data function from zero, keep it honest, and change how a company makes decisions — inside a privacy constraint most data people have never worked under.
Who you report to, and what that means
You report to the VP of Business Operations. Find out who currently holds that role and confirm the name on LinkedIn before you walk in — treat any name you turn up on aggregator sites as unverified; getting a name wrong in the room is a cheap, avoidable mistake, and getting it right is a cheap point.
You are not reporting into Engineering, and not into Product. You're reporting into Business Operations. That is a deliberate choice and it tells you what this role is for. If the company wanted a modeling toy or an ML research function, this would sit under Eng or a Chief Scientist. Sitting under Biz Ops means the mandate is business-decision impact: consolidating financial and growth metrics, sizing decisions, telling leadership the truth about the business. You are an instrument of operating the company, not a lab.
What a VP of Business Operations almost certainly cares about, and therefore what you should be ready to speak to:
- One trustworthy set of numbers. Their nightmare is three departments quoting three different revenue figures in a board meeting. Consolidation and a single source of truth is job one for them, which is why it's job one for you.
- Financial + growth in one view. MRR, churn, free→paid conversion, CAC/LTV, and — uniquely here — the token/staking economics that also fund inference capacity. They want the whole picture reconciled, not siloed.
- Runway, margin, and unit economics. The company is profitable but capital-intensive (it's pivoting toward owned GPUs). Biz Ops lives on gross margin and the COGS-of-inference story (Ch 04). Speak that language.
- Decisions on a deadline, honestly caveated. They'd rather have a directional answer today with a stated confidence level than a perfect answer next quarter. "Transparent about analytical uncertainty" is in the posting because it's what this manager values.
- Low drama, high trust. The company's culture copy prizes "high trust, high autonomy, direct communication... zero tolerance for politics." A Biz Ops leader wants someone who just makes the numbers real and doesn't build a fiefdom.
The clause that defines the culture
Buried in the responsibilities is a line that has no business being in a data science job description at any normal company:
"Advocate against unnecessary data collection to protect the company's privacy commitments."
At every other data-driven company, you are rewarded for collecting more. More events, more properties, richer user profiles, longer retention — more surface to mine. Here you are explicitly paid, in part, to collect less. Your job includes being the person in the room who says "we don't need to track that, and tracking it would violate the thing customers are paying us for." That is a genuine, load-bearing inversion of the normal data-person incentive, and it is not a throwaway line.
Why it's real, not marketing
The company's entire value proposition is that it doesn't know what you type. Chats live in your browser (IndexedDB); prompts aren't logged server-side; inference runs on zero-retention GPUs. Privacy isn't a feature bolted onto the product — it is the product, and it's what a paying user is actually buying. So a data hire who quietly instruments everything "just in case" isn't being thorough; they're destroying the asset. The advocacy clause exists because the founder needs someone in the data seat who will defend the line from the inside, against the org's own natural instinct to measure more. See Ch 02 for how you still run a rigorous data function under that constraint — the reframe is that privacy-safe measurement is the job, not an obstacle to it.
How a crypto-libertarian founder screens for this
The company was founded by a well-known crypto-libertarian founder with a genuine ideological commitment to privacy and permissionless access, not a marketer who focus-grouped "privacy" as a growth angle. That matters for your interview because it changes what's being tested. Competence is table stakes. What founders like this screen hard for is genuine alignment — do you actually believe surveillance-by-default is wrong, or are you a talented data person who'll say the right words and then, under pressure, reach for the user-level tracking you've always used?
Don't perform ideology — it reads as fake and these people have finely-tuned detectors for it. Instead, demonstrate alignment through craft: show that you can name the privacy-preserving techniques (aggregation, k-anonymity, differential privacy, consented linkage) and would genuinely reach for them first. The tell of a real believer is someone who gets visibly energized by the constraint — who treats "no prompt logging" as an interesting design problem they'd enjoy, not a handicap to complain about. If you can talk a hypothetical PM out of collecting a tempting piece of user data, on the merits, you've shown the thing that can't be faked.
Compensation & leveling
The company doesn't publish a band, and there's no public salary data, so what follows is estimated from the role's seniority (7+ years, first serious data hire), the company's stage (recently raised at a nine-figure valuation, profitable), and current crypto-comp benchmarks. Treat the ranges as directional and calibrate against what they actually tell you.
| Component | Estimate | Notes |
|---|---|---|
| Base salary | ~$160K–$185K | Senior IC, US-remote. Reasonable for a 7+ yr first data hire at a profitable, recently-funded startup. |
| Equity | ~0.1%–0.5% | This is the post-raise band, at a nine-figure valuation. It is not the 1–1.5% seed-stage band — the company already raised at a large valuation, so early-employee percentages are gone. Don't anchor on pre-funding numbers. |
| Staking-token grant ($TOKEN) | Likely, separate line | Because the platform's staking token ($TOKEN) is live and traded, expect a separate token grant, RTU-style (restricted token units), likely on a ~4-year vest, 1-year cliff, with a lockup. This is genuinely additive to equity — but it's also volatile (the token has swung through enormous drawdowns and recoveries). |
It's tempting to assume a crypto company means an outsized cash package. The data says otherwise: crypto cash comp actually contracted in 2024–25. Dragonfly's compensation report found average crypto salaries fell ~18% year-over-year to around $144K, and token grants were down roughly 75%. So the base here is likely competitive-with-tech, not a premium, and the token grant is real but should be valued at a discount for volatility and lockup — not at last week's spot price. If comp comes up, price the token exposure conservatively and negotiate the base and equity as the reliable components.
What the loop tests
Now that you know what the role actually is, here's how the rest of the guide maps to what a first-data-hire loop at the company will probe. Each item points to the chapter that fully arms you.
| What they're testing | Where it's covered |
|---|---|
| Do you understand the company and believe the thesis? Founding, product surface, and the privacy architecture that defines everything. | Prerequisite: your own research on the specific company — its product, business model, and market. Background you build before the loop, not covered in this guide. |
| Do you understand where the money comes from? Subscriptions, API, and the staking/compute-credit token economy. Know staking cold. | |
| Can you evaluate the business honestly? Competitors, the moat question, bull vs bear. | |
| The core design question: "How do you build analytics here without logging prompts?" Almost certainly asked. | 02 · Analytics Without Surveillance |
| Can you stand up the infrastructure? Warehouse, ingestion, dbt, BI, and a defensible 30-60-90. | 03 · Building the Data Stack |
| Do you think like an operator? Freemium conversion, NRR, token metrics, inference-as-COGS margins. | 04 · Metrics That Matter |
| Can you run experiments without user identity? Privacy-safe A/B for a fast-iterating product. | 05 · Experimentation |
| Do you know the public token data? On-chain analytics and the consented-linkage rule most candidates miss. | 06 · On-Chain Analytics |
| Can you write production-quality SQL fast? Timed screen on subscription- and usage-shaped tables. | 07 · SQL & Technical Screen |
| Can you communicate uncertainty to execs? Recommendations with confidence, and defending the privacy clause. | 08 · Communicating Uncertainty |
You now know what the job actually is behind the title, who you're building for, and why the privacy clause is the cultural keystone. Next, learn how to run a rigorous data function inside that privacy constraint — start with 02 · Analytics Without Surveillance.