Loopio · SDE 2

Moved onto a new team after the hackathon, working the ML side of what's now core Loopio infrastructure: a centralized knowledge base meant to be consumed by every other component in the codebase, built on a graph database (Neo4j).

It's early and still WIP. I ran an end-to-end POC to validate the approach against the actual requirements - multi-tenancy, latency under load, text-to-knowledge-graph ingestion, vector search, and semantic search over the graph - rather than taking the design on faith.

In mid-Feb 2026, moved onto a sister product during a churn-heavy patch - customers were leaving over bugs and missing features and the team needed reinforcing. The ingestion path takes an uploaded RFP (docx, pdf, excel) and converts it to a normalized document - a common JSON shape the frontend can render uniformly regardless of source format.

I shipped Excel parsing support into the service and worked on the PDF rendering pipeline (heavy use of Aspose). The codebase is C#/.NET, which was new to me - Claude Code did a lot of heavy lifting and I'd be honest about that in an interview. I'm comfortable in the codebase, I know the algorithms, but I'm not going to claim C# fluency.

Wound down at the end of July, then spent the first three weeks of August captaining a cross-repo PR-impact system (Neo4j knowledge graph + a hosted agent) at an internal hackathon - the graph work there fed directly into what came next.

Library Review Audit Trail. Regulated-sector enterprise customers needed full visibility into every review cycle on a library entry - not just the current one - including the comments logged when an assignee passed a review along. It was a Q4 commitment.

I worked on the data foundation and the report surfaces - Review Cycle Export Report and Library Review Workload Report - letting users search across library entries and download the complete review history as CSV from the Library Reporting page. Took the prior feedback about seeking early review seriously this round: shared design + approach with stakeholders before writing the implementation, which paid back in a much cleaner foundation.

Two adjacent projects under the same umbrella.

Reporting microservice. Pulled Loopio's project reporting out of the monolith into a standalone service. On the data side: stood up the data warehouse layer - fact tables, views, dimensions - and built the microservice's APIs against it. Also cleared a backlog of critical bugs in the existing reporting surfaces on the way in.

Insights. Loopio's Strategic Insights product surfaces win-themes, library health, and readiness scores from 10+ years of RFP response data. I worked on the unsexy plumbing that makes it shippable: granular permissions auth/authz with the monolith, repo-wide unit test coverage, Sentry-based monitoring, and the bug bash before alpha. Then a stretch of technical spikes on context reduction and per-model token thresholds - the findings ended up feeding into how other teams pick models against cost and latency budgets.

Shortly after I joined, Alight divested Strada - a real, time-boxed customer split that needed every Alight customer's library content cleanly moved off the shared instance. Professional Services scoped the manual path at ~6 months. I owned the alternative.

I designed and built an automated migration tool that compressed that timeline by months and secured the customer renewal. Architectural decisions ran through the team lead; code review went through the senior engineers on the platform. The framework I left behind is what Loopio now reaches for when other migrations come up (e.g. LFS → Loopio Core).

I had zero prior experience with PHP, CodeIgniter, or domain-driven design when this started. I treated that as the job rather than a blocker - read the codebase end-to-end before writing anything substantive, then iterated tight loops with the people who owned the schemas I was reading from.