Why this chapter exists
Full-stack DS roles ask for a stack of skills that few candidates have all of: rigorous ML, production code quality, domain depth, and end-to-end ownership. Most candidates are strong on two or three and learning the fourth. The temptation to overclaim is high — and interviewers catch it within 60 seconds.
The right move is honest precision: name what you've done, name what you haven't, name how you'd close the gap. Strong candidates don't sound humble; they sound calibrated.
Four common backgrounds
1. The ML researcher transitioning to applied / production DS
- You have: deep modeling, evaluation discipline, paper-level rigor.
- You're weakest on: production code quality, real-time inference, monitoring, the operational glue.
- Recruiters worry: "Will this person ship, or notebook forever?"
2. The ML engineer leveling into staff DS
- You have: production deployment, infra fluency, code quality, testing.
- You're weakest on: framing modeling problems from a business question, domain depth, deciding which models to build.
- Recruiters worry: "Can this person own the modeling decisions, not just implement them?"
3. The data analyst / scientist moving into production-flavored work
- You have: SQL, business framing, stakeholder communication, light ML.
- You're weakest on: production code quality, model deployment, the engineering bar.
- Recruiters worry: "Can this person write code an engineer would accept?"
4. The applied-AI generalist (prompts, agents, SaaS AI)
- You have: LLMs, prompts, customer-facing iteration, multimodal data.
- You're weakest on: classical ML for tabular data, statistical inference, the "boring" parts.
- Recruiters worry: "Outside the LLM hype, can this person reason about features and metrics?"
How to leverage each background
If you're coming from ML research
Your unfair advantage is rigor. Don't undersell it. Frame production-DS work as "applying my modeling rigor to a domain where the answer ships and gets used."
Story prompt
"In my research work, the work was done when the experiment ran. I want a role where the work isn't done until the model is live, monitored, and improving outcomes — because that's the loop where I think I'd grow fastest."
If you're coming from ML engineering
You have the production half. The question is whether you can drive the modeling. Pre-empt it: describe a modeling decision you owned, not just shipped.
Story prompt
"I've shipped a lot of models other people designed. The shift I want is to be the one framing the modeling question — choosing what to label, what features to build, what the eval criterion is. That's the staff bar I'm reaching for."
If you're coming from analytics
You have the framing. The question is whether you can write production code. Don't dodge it; commit to closing the gap.
Story prompt
"I've spent years writing analytical Python. The next step is writing engineering Python — types, tests, modules. I'd want this role to push me there, and I'd plan the first three months around upleveling on production patterns."
If you're coming from applied-AI generalist work
Your edge is iteration speed and prompt fluency — particularly relevant for Archetype. For SentiLink, you'll need to demonstrate classical ML depth.
Story prompt
"I've been shipping LLM-flavored products fast. The thing I want to invest in is classical ML — gradient boosting on tabular data, calibration, threshold tuning at imbalanced rates. The roles that combine both — applied LLM and tabular ML — are where I see myself most useful."
The honesty floor
When asked about a skill you don't have, the strong shape is three-part:
- Name the gap precisely. "I've trained gradient boosting models in research notebooks. I have not shipped one to real-time inference under a 100ms latency budget."
- Show the adjacent thing you do have. "But I have shipped a Python service under similar latency constraints (for a different problem) and I know what the patterns are — feature precomputation, model serialization, monitoring."
- State the closing plan. "If this role required real-time inference from day one, I'd want to spend the first two weeks pair-coding with whoever owns the existing inference path before I shipped any change."
Don't bluff on production code
Of all the gaps to bluff about, production code is the worst — it shows up in the live-coding round immediately. If your code looks like a notebook, the interviewer notices. The honest play: "my recent work has been research code. I'd want feedback on the patterns I'm not yet fluent in."
Building the through-line story
- One sentence on what you do now and your unfair advantage in the work.
- One specific project: ambiguity overcome, decision shaped, model shipped (or insight that changed direction).
- The bridge to this role — anchored to one specific line in the JD.
- One concrete thing you want to learn here that the role offers.
For SentiLink specifically, that "one specific project" should lean toward domain depth — a feature that came from understanding a system better than the off-the-shelf framing. For Archetype, it should lean toward speed — turning ambiguous customer input into a testable result fast.
Scripts for hard moments
"You don't have fraud / sensor / video / domain experience"
Concede directly. Then pivot: "I haven't worked in fraud, you're right. What I have is [adjacent domain] where the core problem was [similar shape] — and the methods carried over. I'd plan my first month around shadowing risk ops and reading old SARs to build the domain instinct." The senior signal is concrete plan, not bluster.
"You've never trained at our scale"
"True. My production models have been at [N] rows; you're at [larger]. The differences I'd expect are [memory, distributed training, sample weighting]. My plan would be to verify in the first month whether the patterns I'm bringing translate, and where they break."
"Show us code from a recent project"
Always have ~50 lines you can talk through unprompted — a feature module, a small utility, a test file. Pick something that demonstrates: type hints, small functions, error handling, a unit test or two. Notebooks aren't a flex; modules are.
"What's a time you owned a model end-to-end?"
Have one ready. Frame: the business question, the framing decision (target definition, unit of prediction), the data acquisition, the features (lead with the domain-insight feature), the model, the evaluation (calibration, lift at top X%, business utility), production (where did it live, how was it monitored), and post-launch (what surprised you, what you'd do differently).