How to Write an SOQ for a Research Data Analyst Position

Research Data Analyst (RDA) is a classification used across a wide range of California state agencies — from health surveillance at CDPH to budget analysis at the Department of Finance to workforce research at CalHR. The work, tools, and domain vary substantially by department, but RDA SOQs typically reward three things:

1. Technical methodology — what research designs, statistical methods, and software you have actually used, and at what depth
2. Analysis-to-decision pipeline — whether your work informed something: a policy recommendation, a program change, a budget decision, a published report
3. Communication of findings — your ability to translate complex analytical results into language that non-technical stakeholders can act on

Note: each department designs its own SOQ scoring rubric, so the relative weight given to each area will vary by posting. Read the duty statement to gauge where the division puts the most emphasis.

RDA SOQ reviewers are often research analysts themselves. They will notice the difference between someone who says "I used statistical analysis" and someone who says "I used propensity score matching in R to control for selection bias in a quasi-experimental evaluation of a Medi-Cal outreach program." Precision signals expertise; vagueness signals surface-level familiarity.

The RDA series (class series 5729) also includes Research Data Specialist I, II, and III — the senior tiers this classification progresses into. If you are exploring senior research roles in California state government, search CalCareers for those titles as well.

Before writing, read the posting's duty statement carefully. An RDA role in the DOJ Research Center will weight statistical rigor differently than one in a program evaluation unit. Tailor your technical depth to what the specific division does.

There is no statewide CalHR-mandated SOQ format — CalHR's HR Manual delegates format requirements to individual departments (Policy 3004). That said, the following conventions are common across RDA postings and are a reasonable default when the job posting doesn't specify otherwise:

• 12-point Arial font
• Single-spaced within responses
• 1-inch margins on all sides
• Responses numbered to correspond to each prompt
• Your name and the position title in a header

Page limits vary by posting. Two pages is the most common ceiling, but some postings allow 3 or even 4 — and a small number of departments (DOJ, OAG) supply their own SOQ template file. Some postings require double-spacing. Always defer to the "Special Requirements" section of the specific CalCareers posting. The conventions above are a starting point, not a substitute for reading the instructions.

Technical background prompt:

This is where you establish credibility as an analyst. Structure your response to cover:

• Statistical methods: descriptive statistics, regression (linear, logistic, Poisson), time series, survival analysis, propensity score methods, difference-in-differences, Bayesian methods — name what you have actually used and in what context
• Software and tools: R, Python (pandas, scikit-learn, statsmodels), SAS, SPSS, Stata, SQL, Tableau, Power BI, Excel — name the specific tools and what you used them for
• Data types and sources: survey data, administrative records, claims data, census data, longitudinal cohorts, linked datasets — the type of data you have worked with signals the complexity of your analytical experience
• Research design: observational studies, randomized trials, quasi-experimental designs, program evaluations, secondary data analysis — describe the designs you have executed, not just used

Avoid the keyword-list trap. Instead of a paragraph of tool names, integrate them into narrative: "I conduct primary data analyses in R using tidyverse and ggplot2 for data wrangling and visualization, and I run regression models using lme4 for mixed-effects structures. I query source data from SQL Server databases, joining administrative records across multiple tables before extracting to R. For visual reporting, I build Tableau dashboards connected to live database views..."

Research project prompt:

Use the STAR method, but with analyst-level depth:

1. Situation — what was the policy question or program problem that motivated the research; what was the data environment (administrative records, survey, linked data)
2. Task — your specific analytical responsibility: were you the primary analyst, a team member, the project lead?
3. Action — the analytical approach: how did you frame the research question, handle data quality issues, select your method, validate your model, interpret results? Be specific about methodological choices and why you made them
4. Result — what did you find, and what happened as a result of your findings? Did a program change? Did leadership adopt a recommendation? Was a report published or presented to the legislature?

Weak: "I analyzed program data to evaluate outcomes and presented findings to leadership." Strong: "I conducted a retrospective cohort analysis of 18,000 Medi-Cal enrollees using linked enrollment and claims data to evaluate the effect of a care coordination pilot on 30-day hospital readmission rates. Using a difference-in-differences design with propensity score matching, I found a 12% reduction in readmissions among pilot participants. My findings were incorporated into a DHCS report to the legislature and used to justify a two-year program extension."

Communication / presentation prompt:

Research findings are only valuable if decision-makers understand them. Describe a specific situation where you translated complex analytical output for a non-technical audience:

• Who was the audience (executive leadership, program staff, legislators, community members)?
• What was the key finding and what made it complex to communicate?
• What format did you use (slide deck, written brief, dashboard, one-pager, oral presentation)?
• How did you simplify without distorting?
• What was the outcome — did your communication enable a decision, answer a question, or change something?

Using "I analyzed data" as your entire technical description — this is the most common RDA SOQ failure. Every analyst analyzes data. What separated your analysis: the method, the data structure, the sample size, the research design, the findings? Be specific.

Not naming tools — if you don't name the software and methods you used, reviewers cannot assess your technical depth. "Statistical software" and "data visualization tools" are invisible to a scorer.

Listing methods without project context — naming 15 statistical methods you know scores lower than describing 3 methods you applied in real projects with real results.

Skipping the "so what" — describing an analysis without saying what decision it informed or what happened as a result leaves the reviewer unable to assess impact. Every project example should end with a consequence: a recommendation adopted, a report published, a program modified, a policy changed.

Using passive voice throughout — "Analyses were conducted," "results were presented." Write "I analyzed," "I presented," "I developed."

Not tailoring to the specific division — an RDA position in health surveillance expects different technical depth than one in workforce policy or criminal justice research. Read the duty statement and match your most relevant examples to the domain.