Business Intelligence Analyst Talent Network

$70–120/hrrate as listed

Mercor is building a standing pool of business intelligence practitioners to write, review, and grade tasks that test how well frontier models handle SQL, dashboarding, and data modeling work. You apply once, pass an AI screening interview, and get matched to contract projects as labs request BI expertise — typically 15–30 hours per week at an observed $70–120/hr.

Summary, eligibility guidance and screening preparation are prepared by Sidequest from the platform's posting. Check the source listing before applying.

What the work actually looks like

Projects vary, but BI work on AI evaluation platforms usually falls into a few shapes. You might write realistic analytics prompts — a messy schema, an ambiguous stakeholder request, a metric definition that conflicts across two source tables — and then author the reference answer yourself. You might grade model output: checking whether a generated SQL query actually returns what the question asked, whether a proposed star schema handles the stated grain, whether a dashboard recommendation reflects how a real business user would consume it. Other assignments lean toward rubric writing and adjudication, where you resolve disagreements between two earlier graders and explain your reasoning in writing.

The hard part is rarely the SQL. It's articulating why an answer is wrong in a way that transfers — distinguishing a query that's syntactically valid but silently wrong from one that's merely inelegant, or noticing that a model confidently invented a join key. Labs pay for that judgment, and written explanations are usually weighted as heavily as the pass/fail call.

What the platform screens for

Mercor's intake is resume verification plus an AI-conducted interview. The interview probes specifics: which warehouse you worked in, how large the tables were, what a particular metric definition actually meant at your company, how you handled a modeling decision you later regretted. Vague answers get follow-ups until they aren't vague. Expect to name tools, describe schemas, and defend a technical choice under pressure. Passing the interview makes you eligible; it does not create an assignment.

Logistics

Fully remote, largely asynchronous, with occasional project-specific calibration sessions
Typical commitment 15–30 hrs/week when matched; matching is rolling and there can be gaps between projects
Pay band observed at $70–120/hr — actual rates are set per project by the client lab, not guaranteed by the listing
Contract work, self-scheduled within project deadlines

What they look for

Professional SQL and data querying experience against production warehouses
Data modeling and warehousing (dimensional modeling, grain, slowly changing dimensions)
Dashboard and visualization work in Tableau, Power BI, or Looker
Clear written explanation of analytical reasoning and error diagnosis
Independent remote work with minimal supervision
Prior stakeholder-facing analytics experience translating vague requests into specs

Before you apply

Would you pass this screen?

Drawn from what this listing actually requires. Answered in your browser — nothing is sent to us, and we do not store your answers.

Do you have at least 2 years of professional experience writing SQL queries for data analysis or reporting?
SQL experience · required
Are you proficient in at least one of Tableau or Power BI for data visualization and dashboard creation?
BI tool proficiency · required
Are you authorized to work remotely in your current work location and able to commit 15–30 hours per week?
Remote work authorization · required
Have you worked with data warehouses, dimensional models, or ETL processes in a professional capacity?
Data modeling exposure · preferred

0 of 4 answered

Included with this listing

Interview prep — 10 questions

Matched to what this platform's screening actually measures. Answer each out loud in 60–90 seconds: claim → concrete example → implication.

What it tests: This tests whether you've actually designed schemas, normalized data, and made trade-offs between query performance and maintainability—not just queried existing structures.
A strong answer: Your answer should describe a specific schema design or dimensional model you created, explain why you chose that structure (star schema, normalization level, partitioning strategy), and name a real constraint you had to solve (time-series data, many-to-many relationships, update frequency).
Where people lose it: Candidates often describe writing queries against someone else's warehouse rather than designing the warehouse itself. Saying 'I modeled data' without explaining the actual schema decisions signals you've mostly consumed data, not architected it.