Career Analysis

STAR Interview Report — Data Science

Joel Johnston 2026-06-17 Post-stroke design

STAR Interview Report — Data Science

Joel Johnston | Data Science / AI Architecture

General Purpose — Adaptable to Any DS Role

Candidate Summary


Name	Joel Johnston
Title	AI Systems Architect
Experience	20+ years — US Bank (10yr), Wells Fargo (10yr), WCTC Adjunct (7yr)
DS Stack	Python (10yr), SQL Server (20yr), C#/.NET (25yr), Linux (30yr)
Statistical	Z-score anomaly detection, behavioral baselines, deviation analysis, time-series correlation
Pipeline	ETL architecture, batch reconciliation, multi-source integration, dimensional modeling
AI/ML	Distributed inference routing, neural network fundamentals (ANN OCR built from scratch), multi-model orchestration
GitHub	github.com/xsubi — 23 repos, ~500 commits, 3,248 tests
Education	B.S., Computer Science
Current Focus	Distributed AI systems, anomaly detection, autonomous mesh intelligence

Situational Responses

Q1. Describe a project where you built a data pipeline to integrate data from multiple heterogeneous sources.

Situation: US Bank trust division managed syndicated banking data flowing from three federal source systems plus internal trust fund transfer data. Each source had different schemas, formats, and delivery schedules. Over 100 government regulatory reports depended on this data monthly, and regulatory requirements meant every row had to land or be accounted for.

Task: Design and build the complete ETL pipeline: ingest from heterogeneous sources, cross-reference across systems to resolve bank relationships in commercial loans, reconcile data monthly, and produce validated datasets for downstream reporting.

Action: Built a full data integration pipeline in C# with SQL Server. Created bridge tables to materialize cross-system relationships, implementing multi-hop joins across 3-4 sources to resolve individual fields. Developed batch flow control for pipeline orchestration. Built reconciliation logic to handle monthly source-data inconsistencies — rows that didn't land were flagged, not silently dropped. Collaborated with the senior SQL Server DBA on dimensional model design for trust financial reporting, challenging and refining schema decisions.

Result: Delivered a permanent operational pipeline that reliably ingested, reconciled, and served data for 100+ regulatory reports on schedule. The reconciliation logic caught data quality issues at ingestion rather than at report time. The senior DBA began consulting me on database architecture decisions — a signal that the data modeling quality exceeded the typical developer-DBA dynamic. Pipeline remained in production throughout my tenure.

Data Science Relevance: Multi-source integration, schema resolution, data quality enforcement, dimensional modeling, pipeline orchestration — the unglamorous 80% of data science that determines whether the analysis is trustworthy.

Q2. Tell me about a time you used statistical methods to detect anomalies or patterns in data.

Situation: Robonet (current project) — a distributed autonomous mesh system where nodes operate independently across a network. In any distributed system, nodes can behave anomalously due to compromise, misconfiguration, resource exhaustion, or software faults. Traditional threshold-based alerting produces excessive false positives and misses subtle behavioral drift.

Task: Design and build a distributed anomaly detection system (Sentinel) capable of identifying behavioral deviations across mesh nodes without centralized authority.

Action: Built a three-layer anomaly detection system:

Layer 1 — Local behavioral baseline: Each node maintains a rolling statistical profile of its own behavior (message rates, response times, resource usage). Deviations are measured using z-score analysis against the node's own baseline, not global thresholds.
Layer 2 — Cross-node correlation: When a node detects a local anomaly, it publishes an AnomalySignal to the mesh. The SentinelQueen correlates signals across nodes to distinguish isolated events from systemic patterns.
Layer 3 — Consensus eviction: If correlated anomalies exceed a confidence threshold, Sentinel initiates a consensus vote to quarantine or evict the affected node. No single node can unilaterally act.

Implemented configurable sensitivity (z-score thresholds), sliding time windows for baseline computation, and trust dynamics that adjust node reputation based on historical accuracy.

Result: 62 tests covering the full detection pipeline. Zero false positive rate in testing. The system distinguishes between "node is slow today" (local variance, no action) and "node is exhibiting a pattern consistent with compromise" (correlated signals, consensus response). Validated across simulated anomaly injection scenarios.

Data Science Relevance: Statistical process control, z-score analysis, time-series behavioral modeling, signal correlation, consensus-based decision making — applied to operational data in real-time rather than batch analysis.

Q3. How have you handled data quality issues in a production environment?

Situation: US Bank regulatory pipeline — three federal source systems delivered data monthly with different schemas, formats, and varying levels of quality. Some sources delivered malformed records. Some delivered partial datasets. Some fields required cross-referencing 3-4 systems to resolve a single value. Regulatory deadlines were non-negotiable, and errors carried legal consequences.

Task: Ensure 100% data accountability — every row either lands correctly or is explicitly flagged for review. No silent data loss.

Action: Built reconciliation logic directly into the pipeline:

Row-count validation at each stage (source → staging → production)
Cross-system join validation — if a multi-hop join failed to resolve, the record was quarantined with the specific failure point identified
Schema normalization at ingestion — source-specific adapters translated heterogeneous formats into a canonical internal schema
Monthly reconciliation reports showing exactly which records succeeded, which failed, and why
Bridge tables that materialized cross-system relationships, making the join logic auditable rather than buried in query chains

Result: Data quality issues were caught at ingestion, not at report time. When source systems delivered inconsistent data (which happened regularly), the pipeline identified the specific inconsistency and flagged it for resolution. Zero silent data loss across the entire tenure. Regulatory reports were delivered on schedule with full data lineage.

Data Science Relevance: Data quality is the foundation. Models built on dirty data produce confident wrong answers. This experience established the discipline: validate at ingestion, trace lineage, account for every row, and make failures visible — not silent.

Q4. Describe a situation where you had to present complex analytical findings to non-technical stakeholders.

Situation: US Bank — 100 government regulatory reports were due by end of month. The existing production pace was approximately one report per week. At that rate, delivery was mathematically impossible. These were regulatory-grade financial reports where errors carried legal consequences.

Task: Communicate the structural problem to management — not just "we're behind," but why the current approach could never succeed and what the alternative was — then deliver the solution.

Action: Rather than arguing about timelines or resources, I spent three hours analyzing the problem structurally. The bottleneck was output formatting, not data processing. I built a templating framework using the Strategy design pattern with C# reflection — each report became a configuration entry in the same engine rather than hand-coded output. Presented the approach to management as: "The data pipeline works. The bottleneck is report generation. I can eliminate that bottleneck by making reports configuration-driven instead of code-driven. Here's the framework."

Result: All 100 reports delivered in one week — approximately 100x throughput improvement. The framework was reusable for future reports. Management understood the solution because I framed it in terms of the business constraint (deadline and legal risk), not the technical implementation (Strategy pattern, reflection, templating). The technical details were available for engineers; stakeholders got the impact narrative.

Data Science Relevance: Data science value is zero if findings don't reach decision-makers. Translating analytical work into business-relevant narratives — framing around impact, risk, and constraints rather than methodology — is the difference between a data scientist and someone who runs notebooks.

Behavioral Responses

Q5. Tell me about a time you had to learn a new technology or domain quickly to solve a problem.

Situation: At Wells Fargo, an Apache performance problem had gone unresolved for 2-3 years. I had zero prior Apache experience. My manager dispatched me based on a general reputation for cross-domain problem solving — "do you know Apache?" "No." "Figure it out."

Task: Diagnose and resolve a multi-year performance bottleneck with no domain background, no documentation handoff, and no ramp-up time.

Action: Spent three days decomposing the system from first principles. Didn't start with Apache documentation — started with the observable behavior (symptoms), then traced backward through the system architecture to identify where the performance degradation originated. Built a mental model of how the system should behave, compared it to how it did behave, and narrowed the search space to the component causing the deviation.

Result: Resolved in three days. The approach — decompose from first principles, model expected behavior, compare to observed behavior, isolate the deviation — is domain-independent. It works on Apache, on data pipelines, on anomaly detection, on medical diagnostics. The technique is the same regardless of the technology.

Data Science Relevance: Data science roles require constant domain acquisition. New datasets mean new domains — healthcare, finance, logistics, manufacturing. The ability to rapidly build a mental model of an unfamiliar system, identify what "normal" looks like, and spot deviations is the core analytical skill. The specific technology is secondary.

Q6. How do you ensure reproducibility and rigor in your analytical work?

Situation: Building robonet — 20 packages, 209,000+ lines of code, sole architect with AI-augmented execution. Output averaged approximately 5,846 lines per day (~47x industry average for a senior engineer). No team for code review or peer validation. Quality assurance had to be structural, not social.

Task: Maintain production-grade rigor at sustained high throughput without peer review.

Action: Implemented specification-first development:

201 formal use cases serve as the source of truth — all code is derived from specifications
Built a gap scanner enforcing nine cross-reference integrity rules: every code file traces to a specification, every specification traces to code
3,248 tests across the product family run on every push — if tests fail, nothing merges
Architecture decisions documented as specifications before code, preventing structural drift
The quality bar: the entire codebase can be regenerated from specifications alone using AI. If the specs are complete enough to rebuild the product, the engineering discipline is sound.

Result: Gap scanner: 0 failures, 0 warnings, 0 gaps. Full traceability from specification to code to test. Zero external dependencies in core (stdlib only). The system is fully reproducible — given the specifications, any competent engineer (or AI) can reconstruct the implementation.

Data Science Relevance: Reproducibility in data science means: documented methodology, version-controlled transformations, traceable lineage from raw data to conclusion, and automated validation. The principle is identical — if someone else can't reproduce your result from your documentation, the analysis isn't rigorous. Notebooks without specifications are just scripts with commentary.

Q7. Describe how you handle competing priorities when multiple stakeholders need results simultaneously.

Situation: At Wells Fargo, three cross-team engagements were active simultaneously: a React SPA team blocked on frontend architecture, a Java/Spring Boot team with integration problems, and the multi-year Apache performance issue.

Task: Diagnose and unblock each team without taking ownership of their deliverables. Prioritize by impact, not by who asked loudest.

Action: Prioritized by business impact — the Apache issue (2-3 years unresolved, affecting production performance) received focused attention first. For the React and Spring Boot teams, I provided targeted guidance sessions rather than embedded support — assessed the problem, delivered recommendations, let them execute. Communication was direct: assess, report to my manager, execute. No status meetings, no Gantt charts, no stakeholder management theater.

Result: Apache resolved in three days. Both development teams unblocked. The pattern became routine — managers across the organization routed their blocked teams to me. Prioritization by impact rather than politics meant the highest-value problems got solved first.

Data Science Relevance: Data science teams face constant prioritization pressure — marketing wants a churn model, operations wants anomaly detection, finance wants forecasting, and everyone's deadline is "yesterday." Triaging by business impact, providing targeted analysis rather than embedded engagements, and delivering results without project management overhead is how a data scientist stays effective across multiple stakeholders.

Technical Responses

Q8. What is your approach to feature engineering and data transformation?

Core philosophy: Features should represent the domain, not the data format. The best features encode domain knowledge — they're hypotheses about what matters, expressed as transformations.

Examples from current work:

Sentinel anomaly detection:

Raw data: message timestamps, response latencies, error counts
Engineered features: rolling z-scores against per-node baselines, inter-arrival time distributions, error rate deltas (change in error rate, not absolute count)
Why: absolute values are meaningless across heterogeneous nodes. A response time of 200ms is normal for a Raspberry Pi, anomalous for a server. Z-scores normalize per-node, making cross-node comparison valid.

US Bank regulatory pipeline:

Raw data: three federal schemas + internal trust data, different key formats, different relationship encodings
Engineered features: bridge tables materializing cross-system relationships, multi-hop joins resolving bank relationships in commercial loans
Why: the meaningful entity (a bank's lending relationship) didn't exist in any single source. It had to be constructed from 3-4 cross-references. That construction is feature engineering — deriving a meaningful analytical unit from disparate raw inputs.

CapabilityRegistry routing:

Raw data: node capability strings, load metrics, model availability
Engineered features: AND-matched capability vectors, least-loaded scoring, resource-budget filtering
Why: the routing decision requires a composite feature (capabilities × availability × load) that doesn't exist in any single metric.

Tooling: SQL (20yr — feature engineering in SQL is underrated), Python (pandas, numpy), C# LINQ. The transformation language matters less than the domain reasoning behind the transformation.

Q9. How would you design an experiment or A/B test to validate a hypothesis?

Framework: I use a structure I'd describe as hypothesis → prediction → measurement → mechanism validation.

Example — robonet Sentinel calibration:

Hypothesis: Z-score threshold of 2.5 will distinguish genuine anomalies from normal variance in mesh node behavior
Prediction: At threshold 2.5, false positive rate < 5%, true positive rate > 90% on injected anomalies
Experiment: Injected known anomaly patterns (elevated message rates, latency spikes, error bursts) into simulated mesh traffic. Ran Sentinel detection across a range of thresholds (1.5, 2.0, 2.5, 3.0, 3.5).
Measurement: TPR/FPR at each threshold. Plotted the tradeoff. Selected 2.5 as the operating point.
Mechanism validation: Didn't stop at "2.5 works." Traced why — the underlying behavioral distributions are approximately normal for healthy nodes, meaning z-score is an appropriate test statistic. If the distribution were heavy-tailed, z-score would underperform and a different metric (MAD, IQR) would be needed.

Philosophy: A/B testing validates that something works. Mechanism validation explains why. Both are necessary. A model that works for unknown reasons will break for unknown reasons. I validate both the statistical result and the causal reasoning behind it.

Bayesian reasoning: I default to Bayesian logic — prior beliefs updated by evidence, with causal chain validation. Not just "is the p-value significant?" but "does the mechanism make sense?" A statistically significant result with no plausible mechanism is suspicious. A plausible mechanism with marginal significance deserves more data, not dismissal.

Q10. What tools and technologies do you use for data analysis, and how do you choose between them?

Current toolkit:

Category	Tools	Experience
Languages	Python (10yr), SQL (20yr), C# (25yr)	Production use across all three
Databases	SQL Server (20yr), PostgreSQL (5yr)	Schema design, dimensional modeling, query optimization
Statistical	Z-score, behavioral baselines, time-series correlation	Built from scratch in Sentinel
AI/ML	Neural networks (ANN OCR built from scratch ~2011), distributed inference routing, multi-model orchestration (Claude, GPT, Ollama, Groq)	Architecture-level, not library-level
Pipeline	Custom ETL (C#, Python), batch orchestration, reconciliation logic	US Bank production, robonet foundry
Infrastructure	Linux (30yr), Docker, Kubernetes, Ansible	Full stack deployment
Visualization	React dashboards, terminal-based displays	robonet-dashboard (React 19 + WebSocket)

Selection criteria:

SQL for anything relational, aggregated, or joins-heavy. SQL is the most underused tool in data science — it does feature engineering, aggregation, and filtering faster than pandas on any dataset that fits in a database.
Python for statistical computation, ML pipelines, and anything that benefits from numpy/scipy ecosystem.
C# when the pipeline needs to be production-grade, high-throughput, and long-running (US Bank regulatory pipeline ran for years).
Custom over library when the domain requires it. Sentinel's anomaly detection is custom because no off-the-shelf library handles distributed per-node behavioral baselines with mesh-consensus eviction. Standard tools for standard problems; custom solutions for novel architectures.

Philosophy: Tools serve the problem, not the resume. I'll use a SQL query over a Spark cluster if the data fits in PostgreSQL. I'll use a z-score over a neural network if the distribution is normal and the threshold is interpretable. Complexity should be proportional to the problem, not the toolbox.

Supplemental: Cross-Domain Pattern Recognition

The capability that makes data science more than statistics.

The 36-Domain Advantage

Data science produces insight when domain knowledge intersects analytical method. Most data scientists have depth in statistics and one application domain (finance, healthcare, marketing). My knowledge base spans 36+ confirmed hard domains including:

Category	Domains
Engineering	Software architecture, distributed systems, database architecture, networking, cryptographic protocol design, security engineering, hardware engineering
Science	Physics, biology, chemistry, neurology, pharmacology, anatomy, clinical diagnostics, dimensional cosmology
Design	Systems design, game design, UI/UX, curriculum design
Business	Banking/finance, regulatory compliance, insurance, project management
Applied	Aviation, automotive systems, music theory, theology, linguistics

Why this matters for data science: Every new dataset is a domain. Healthcare data requires understanding of clinical workflows, ICD codes, treatment protocols. Financial data requires understanding of regulatory frameworks, risk models, market mechanics. Manufacturing data requires understanding of process control, material science, failure modes.

I don't need ramp-up time to understand what a dataset represents. The domain knowledge is already loaded. The analytical question becomes: "What is this data trying to tell me?" rather than "What does this data mean?"

Real-Time Cross-Domain Analysis (Today)

In a single medical appointment today, I performed what amounts to a multi-source data integration and causal analysis:

Data sources: Family mortality records, personal symptom history (48 diagnoses), MRI imaging results, glucose monitoring data, medication metabolism observations, published biochemistry
Feature engineering: Mapped "sudden death" across generations to autonomic nervous system failure; mapped glucose threshold (123 mg/dL) to ALA synthase activation; mapped medication clearance changes to hepatic CYP450 enzyme availability
Pattern recognition: Identified porphyria as the unifying diagnosis across 48 prior diagnoses, family mortality patterns, and current stroke presentation
Causal chain: Genetic heme pathway defect → ALA accumulation → autonomic nerve damage → downstream organ dysfunction (cardiac, pancreatic, vascular) → misdiagnosed as separate conditions
Validation: Cross-referenced against published biochemistry, family behavioral data (grandfather's daily fruit intake → 86 years vs relatives without glucose management → sudden death), and medication response patterns

This is data science. The dataset was a family medical history spanning multiple generations. The model was causal chain analysis. The output was a diagnostic hypothesis that a Berkeley/Yale neurosurgeon endorsed.

AI Engineering Portfolio

Capability	Evidence
Statistical anomaly detection	Sentinel: z-score behavioral baselines, cross-node correlation, consensus escalation — 62 tests
Distributed data processing	Mesh inference routing: CapabilityRegistry AND-matching, least-loaded strategy, resource-budget filtering
Pipeline architecture	US Bank: 3-source ETL, reconciliation, 100+ regulatory reports. robonet-foundry: autonomous CI/CD
Multi-model AI orchestration	8+ LLM providers, tier-based routing, provider abstraction, capability-based model selection
Real-time data systems	WebSocket aggregation, event-driven architecture, pub/sub data flow
Data quality enforcement	Gap scanner: 9 cross-reference rules, spec-to-code traceability, zero-gap validation
Dimensional modeling	Trust financial reporting schemas, bridge tables, multi-hop join resolution

References

Name	Relationship	Notes
Jim Kloetske	WF Manager	Cold-called Joel into Wells Fargo. Overnighted offer. Talks to Joel daily. Says Joel would be a great manager. Providing reference.
Scott Schlatter	WF Principal Eng / Manager	Claimed Joel from interview: "I want Joel." Quote: "Your educated guesses are better than most people's knowledge." Potential reference.
EJ (DewWow)	20+ year colleague	First job together at Beta Systems. Flexible on title. Providing reference.

Prepared June 17, 2026