Technical interview field guide

Sigma Assistant
Upgrade Plan

Turn a strong real-world AI product story into crisp, defensible technical reasoning—one decision, mechanism, measurement, and consequence at a time.

ArchitectureAI qualityEvalsSafetyScaleTrade-offs
Your north star

Four beats in every answer

1

Decision

What consequential technical choice did the team face?

2

Alternatives

What credible paths did you consider?

3

Evidence

Which measurements and constraints shaped the choice?

4

Consequence

What improved, what worsened, and what would you revisit?

Lead with the answer

The 90-second opening

“I’ll use Sigma Assistant, which converts a Stripe merchant’s natural-language analytics question into SQL. The request passes through authorization and domain checks; we retrieve the user’s permitted schema and, when relevant, a verified example; we assemble the prompt with bounded history; the model generates SQL; and we validate and execute it in a constrained, read-only workflow.

The most consequential trade-off was quality versus latency in grounding and validation. More retrieval and reasoning improved semantic correctness, but increased response time and cost. We set an interaction budget, tested alternatives against representative evals, and kept the steps whose quality lift justified their latency. I’ll walk through the architecture, then the evidence behind that decision.”

Use the structure—not invented precision. Replace every model, metric, threshold, and result with facts you personally remember and can defend.

System view

End-to-end architecture

User questionNatural language
API + orchestrationTemporal workflows
Policy checksAuth, domain, language
GroundingSchema + verified example
Prompt assemblyInstructions + history
ModelGenerate SQL
ValidateParse, policy, semantics
Execute safelyRead-only + limits
RespondSQL + assumptions + preview

For every box, prepare five answers: why it exists, what fails, how access is enforced, how it is measured, and what happens at 100× scale.

Gap 1

Executable SQL ≠ correct answer

1 · SyntaxDoes it parse and run in the required dialect?
2 · AuthorizationDoes it touch only permitted tables, columns, rows, and operations?
3 · SemanticsAre joins, filters, aggregations, and time windows correct?
4 · Business truthDoes it apply approved definitions of MRR, churn, and active customer?
Interview line: “Execution success is necessary but insufficient. A query can run perfectly and still answer the wrong business question.”
Gap 2

Make hallucination measurable

Failure taxonomy

Invented schema • wrong join • unsupported metric • wrong filter or aggregation • plausible but semantically wrong SQL • unauthorized access attempt.

Evaluation design

Representative categories • defined difficulty tiers • result-set comparison • rubric-based semantic grading • severity-weighted errors.

Operating loop

Regression gates • per-category pass rates • production feedback converted into eval cases • monitoring by impact, not anecdotes.

Be ready to define “accuracy”: the evaluation unit, grader, dataset composition, category distribution, and which failures are unacceptable regardless of the aggregate score.

Gap 3

Layer safety—don’t outsource it to a disclaimer

Prevent

Authorization-scoped context, privacy filtering, read-only operations, prompt-injection defenses.

Detect

Parsing, policy rules, execution checks, semantic graders, anomaly detection, confidence signals.

Contain

Sandboxing, timeouts, resource ceilings, per-tenant isolation, staged exposure, rate limits.

Recover

Clarify ambiguity, bounded repair retries, or abstain rather than manufacture certainty.

Explain

Surface tables, joins, filters, assumptions, metric definitions, and result drill-down.

Remember

A summary from the same model improves usability; it is not independent verification.

Gap 4

Explain RAG as a product decision

“Some questions depend on company-specific definitions and known-good query patterns. Schema alone cannot reliably communicate those conventions, so we retrieve a verified example only when it is genuinely relevant.”

Know the mechanism

Corpus ownership, embeddings, nearest-neighbor search, metadata filters, threshold, fallback.

Know the risk

An irrelevant example can anchor generation toward the wrong tables, joins, or definitions.

Know the evidence

Quality lift and latency cost by query category—not “RAG helped” as an unsupported claim.

Gap 5

Make the trade-off visual and explicit

More grounding

Richer retrieval, more context, stronger reasoning and validation.

Upside: semantic quality
Cost: latency, tokens, complexity

VS

Fast interaction

Lean context, limited retrieval, streaming, bounded retries.

Upside: responsiveness
Cost: weaker grounding or premature output

Answer template: “We considered A, B, and C. A optimized quality but added ___. B met our interaction target with ___. C reduced engineering effort but created ___. Based on our latency budget, eval results, and risk tolerance, we chose ___. I would revisit it if ___ changed.”
Gap 6

Prepare for 100× scale

Model limitsConcurrency + tokens
Workflow queuesBackpressure
SearchVector capacity
WarehouseQuery concurrency
RetriesLoad amplification
EconomicsTenant concentration

Name the likely bottleneck, the metric that proves it, and the first three mitigations. Consider provider limits, queue depth, warehouse saturation, long-running queries, connection pools, retry amplification, noisy neighbors, and token cost from large schemas.

Gap 7

Build where the product differentiates

Buy or reuse

Foundation model
Vector-search infrastructure
Workflow orchestration
Data warehouse
Internal privacy/model proxy

Build

Authorization-aware schema context
Verified retrieval corpus
Prompt and context assembly
Validation and repair workflow
Product-specific eval suite
Business definitions
Monitoring and feedback loop

The strategic point: differentiation lives in trusted context, evaluations, workflow, and user experience—not merely access to a foundation model.

Execution

Complete the fact sheet

Exact model and selection rationale
Models or approaches actually compared
Context window at the time
Typical and high-percentile prompt size
Retrieval corpus size and owner
Embedding model and search method
Candidate count, threshold, fallback
Exact definition of accuracy
Eval-set size and composition
Quality impact of each intervention
P50/P90 latency and stage breakdown
Retry rate and load amplification
Cost drivers or unit economics
Privacy, retention, and permissions
Launch guardrails and rollback rules
Post-launch quality and adoption

Write “unknown” when you do not remember. A strong line is: “I don’t remember the exact value, but the decision rule was…”

Practice loop

Five focused drills

90sec

Architecture

Deliver the request path without interruption. End by naming the trade-off.

2min

Correctness

Explain why executable SQL can be wrong using the four evaluation layers.

2min

Trade-off

Use one concrete decision and its measured quality, latency, cost, or privacy consequence.

3min

Failure recovery

Cover bad retrieval, ambiguous intent, and unauthorized access: detect, contain, recover.

2min

100× scale

Name the likely bottleneck, the proving metric, and the first three mitigations.

Final check

Before you stop speaking

✓ Answered the question in the first 30 seconds
✓ Named one consequential decision
✓ Explained credible alternatives
✓ Distinguished syntax, semantics, business truth, and safety
✓ Used only facts you can defend
✓ Named outcomes, limitations, and what you would revisit