Thanks, Sarah. I started it about four months ago — mostly evenings and weekends. I wanted something where I was making all the architecture decisions myself, not just following a tutorial. I wrote ADRs for the bigger choices, like why I picked SQLAlchemy async over a lighter ORM, and the auth flow design. It's been the most useful learning project I've done.

The most transferable skill is probably systems thinking. Odoo is a genuinely complex platform — 30+ interconnected modules, a multi-layer ORM, event hooks that cascade in ways that aren't always obvious. Debugging it teaches you to think in data flows, not just functions. That transfers directly to any backend system.

What I'll need to unlearn — or at least recalibrate — is framework dependency. In Odoo, everything is built on top of the framework's conventions. You rarely design from scratch. Moving to FastAPI means I own more of those decisions, and I've been deliberately practicing that with the Expense Tracker.

We had a webhook integration with a payment gateway that started silently failing — transactions were coming in, getting acknowledged, but never being recorded on our side. A client noticed a discrepancy in their reports hours later.

My first move was to check the logs and confirm the pattern — it was hitting the endpoint but failing silently in a try/except that was swallowing the error. The fix itself was quick. But the real problem was architectural: we had no dead-letter queue, no alerting on failed webhook processing, and the acknowledgment was happening before the write succeeded.

After the fix, I added structured logging, moved the acknowledgment to after a successful DB commit, and added a Celery-based retry queue for failed events. And I wrote a postmortem — not to blame anyone, but to document the design gap so we wouldn't repeat it.

Before doing anything, I'd want to understand where the coupling is actually causing pain — is it slowing down deployments, making testing hard, causing bugs? Coupling isn't always a problem worth solving; it depends on the cost.

If it's worth addressing, I'd start by mapping the dependency graph — which modules import from which, and where the shared state lives. Usually there's a small number of "god objects" causing most of the pain. The first step isn't splitting modules — it's introducing clear interfaces within the monolith. Enforced contracts between domains, even as internal packages.

From there you can move toward extracting services if needed, but I'd be conservative about microservices. Most of the teams I've seen move too fast to microservices end up with distributed monolith problems instead. I'd rather have a well-structured modular monolith than a poorly-defined microservices mesh.

BRT gives me a decent overlap with both coasts — I'm typically online by 8am, which is 7am New York and noon London. So the first few hours of my day are the most collaborative: standups, code reviews, any sync conversations. After that, I work more async — deep work, PRs, writing.

In terms of what I try to do well remotely: I write more than I talk. If I make a decision, I document it. If I'm blocked, I say so early and clearly in async rather than going silent and waiting for a sync meeting. I've found that over-communication async is almost always better than under-communication.

The thing that genuinely changed how I think recently was going deep on SQLAlchemy 2.0's async session model. It's not just "the same thing but async" — the session lifecycle, how you manage transactions across request boundaries, the difference between lazy and eager loading in an async context — it forced me to understand the ORM at a deeper level than I had before.

I've also been paying more attention to how teams document architectural decisions. I'd heard of ADRs before but never actually used them seriously. Writing them for my own project — even alone — made me more intentional about decisions I would've made by instinct before. That's something I'd bring into any team I join.

"What would make you say this hire was clearly successful after 3 months?"

"What's the balance between feature development and technical debt on the current roadmap? Does engineering have a voice in that prioritization?"

"How do senior engineers grow here — is there a technical track beyond management, or is that the main path?"

Just that I'm genuinely excited about this role — not just as a next step, but because the problems you described around the monolith and the team structure match exactly what I'm trying to grow into. I want to be at a place where engineering decisions matter and where I can contribute beyond just shipping features. I think that's here.

Thank you both for the time — this was a really honest conversation and I appreciated it.