Senior Python Engineer

Backend devs who've worked alongside data science teams. They write production-grade code: typed (mypy), tested, observable. They aren't notebook-first. If you need someone for exploratory ML/notebook work, we'd staff a different profile — say so up front and we'll match accordingly.

Yes. Upgrades are a common first engagement. We start with a dependency audit (what's pinned, what's transitively breaking), automate the test suite if it isn't, and step through versions one at a time with CI proving each step. Big-bang upgrades are how teams get stuck — we don't do them.

Three options, picked per workload: (1) async with asyncio + uvicorn for I/O-bound APIs (most common); (2) multiprocessing for CPU-bound work; (3) offload hot paths to Rust via PyO3 if profiling shows pure-Python is the actual bottleneck. We measure first; the GIL is rarely the real problem.

We're tool-agnostic but opinionated about lockfiles. If you have nothing, we usually start with `uv` — it's the fastest and the lockfile format is stable. We won't migrate your existing tooling unless there's a concrete reason.

Standard stack: FastAPI for the service, structured logging on every prompt + response, Pydantic-typed I/O contracts, retries with backoff for upstream rate limits, prompt-version tagging in the database. We treat prompts like code: reviewed PRs, change history, regression tests against a fixed eval set.

Yes. We've shipped in all three. Our preference is to keep production code out of notebooks (Jupyter is great for exploration, weak for ops), but we'll work within whatever your data team has standardised on.