Questions I hope you ask
The classic interview prompts, answered in advance, each with a link to the proof. Ask me these in person and you will get the same answers with more detail, because they all really happened.
"Tell me about a time your plan didn't survive contact with reality."
I designed a time-to-decision survival analysis of Toronto's planning queue, and the very first look at the data showed it records no decision dates at all. Rather than force the method, I rebuilt the study around what the data honestly supports, a current-status design, and stated the identification cost wherever it applies. The whole pivot is on the study page, because knowing when a method cannot be used is the same skill as knowing the method.
"Tell me about a bug that scared you."
An invisible trailing space in a status label silently dropped 3,799 records and flipped a key result upside down, with no crash and no warning. A 98% figure that was too tidy to be true gave it away. The before-and-after is charted on the study page, and the habit it taught me became rule two of my pre-flight checklist.
"How do you check your own work?"
Three layers: a data-quality checklist before modeling, honesty machinery inside the models (a placebo test in the shelter study, a published functional-form sensitivity in the opioid study), and a standing rule to check hardest whatever confirms my expectations. The bugs I caught are documented on the pages where they happened.
"When would you not use a regression?"
When counting answers the question. My building-standards study reports its headline findings as shares and medians because a flat gradient and an 84% figure need no model, and adding one would only add false precision. My methods map shows the routes in both directions.
"How do you explain uncertainty to a non-technical audience?"
By drawing it and naming it plainly: every estimate chart on this site carries whiskers described as "the range the true number very likely falls in," and a marginal result gets called exactly that, as in the opioid study's decline that "does not quite clear conventional significance" (p = .063, said out loud). Every study page also carries a "technical terms, translated" box.
"Tell me about working with stakeholders and messy real-world constraints."
Two years as a research analyst at a community mental-health nonprofit in Gansu, handling sensitive client information under strict confidentiality, plus teaching-assistant work explaining methods to large classes, and freelance project coordination across three companies (experience). The plain-language half of every study page is that skill, practised in public.
"What would your first month here look like?"
The same arc as every study on this site: find the data your team already has, run my pre-flight checks on it, reproduce one number your team already relies on to make sure I understand your pipeline, and deliver one small finding in plain language by week four. The six studies are that promise, demonstrated six times.
"What don't you know yet?"
Plenty, and my evidence page is built on that honesty: tools I have not used do not appear on it. SQL joined the inventory in 2026 the same way Python did, self-taught and then applied: the building-standards study now carries a SQL rebuild that reproduces its published numbers from a relational database. R sits next on my learning list. I would rather show you a true inventory than a padded one.
Every answer above compresses a longer story that lives on this site. If an interview question of yours is missing, the odds are good the claims-and-evidence page or a study's "honest fine print" section answers it.