Practice Pitches

Hi, I'm an Android engineer with several years building production apps in Kotlin. My focus is modern Android — Jetpack Compose, coroutines and Flow, and a clean MVVM architecture backed by Hilt and Room.

Most recently I led a Compose migration and an offline-first rebuild: I owned the architecture, the performance work, and the release pipeline.

I'm drawn to this role because it's senior, Kotlin-first, and the kind of mature product where architecture and performance actually matter.

Sure. I'm a senior Android engineer. I've spent the last several years shipping Kotlin apps to Google Play, and I specialize in modern Android: Jetpack Compose for UI, coroutines and Flow for async and state, and MVVM with a clean data layer.

On my last team I was the technical lead for a screen-heavy consumer app. I drove the migration from the View system to Compose, rebuilt the data layer to be offline-first with Room as the single source of truth and Retrofit syncing in the background, and wired the whole graph with Hilt.

A big part of my work was performance: I tracked down recomposition and jank issues with Perfetto and Macrobenchmark, added Baseline Profiles, and cut cold start measurably. I also owned releases — CI with instrumented tests, staged rollouts, and watching the crash-free rate.

I'm looking for a senior, Kotlin-first role on a mature product where I can go deep on architecture and performance — which is exactly what this looks like.

I'll give you the short arc. I started in Android back in the Java and XML days — Activities, Fragments, RxJava — building features and learning the platform the hard way: lifecycle bugs, configuration changes, and memory leaks.

When Kotlin became first-class I moved over fully, and that changed how I write code: null-safety, sealed classes for state, and coroutines instead of callback chains. I rebuilt async flows around structured concurrency and Flow, which made cancellation and testing genuinely simple for the first time.

The last few years were my deepest chapter. I led a Compose adoption on a large app — not a rewrite, an incremental migration screen by screen — and re-architected the data layer to be offline-first: Room as the source of truth, a repository owning sync, and the UI just observing state. I introduced Hilt, modularized the codebase by feature for faster builds, and set up Baseline Profiles and Macrobenchmark to defend startup and scroll performance.

What ties it together is that I care about the boring fundamentals — lifecycle, threading, and state — because that's what makes an app feel fast and not crash. A senior, Kotlin-first role on a mature product is exactly the next step I want.

Two reasons. First, the craft: Android forces you to respect constraints — the lifecycle, limited memory, a single main thread, real network variability. Getting an app to feel instant on a mid-range phone with a flaky connection is a genuinely hard, satisfying problem.

Second, Kotlin and Jetpack made the platform a joy. Coroutines turned async into something you can read top to bottom; Compose made UI declarative and state-driven; and the type system catches a whole class of bugs before they ship. I like that modern Android rewards engineers who think about state and threading clearly.

This is the one to tailor — so here's the shape. Open with something specific about their product or engineering culture (a feature you admire, their scale, their Compose adoption, an engineering blog post). Then connect it to you: “That's exactly the kind of problem I want to work on, and it lines up with my depth in X.”

Close on the team and the level: “A senior, Kotlin-first role on a product this mature is where I do my best work — I want to own architecture and performance, mentor through reviews, and ship things that hold up.”

The shape: pick one project and tell it as a problem, a design, and a result. My go-to is the offline-first rebuild.

Problem: the app showed spinners constantly and lost user work on a dropped connection, because each screen fetched directly from the network and held its own copy of the data.

Design: I made the local Room database the single source of truth. The UI observes Flow from the DAO, so it always renders local data instantly. A repository owns synchronization — it writes optimistic updates locally, enqueues mutations, and reconciles with the server via WorkManager when connectivity returns, with a last-write-wins policy per record type. Everything is wired through Hilt and runs in viewModelScope so it cancels cleanly.

Result: the app worked fully offline, the spinner-on-every-screen problem disappeared because of stale-while-revalidate reads, and our crash-free rate went up because we stopped doing fragile network work on the main thread. I added Turbine tests around the sync logic so it couldn't regress.

Situation: our main feed stuttered while scrolling on mid-range devices, and users noticed.

Task: I owned making it smooth without a rewrite.

Action: I profiled instead of guessing — a Macrobenchmark scroll test plus Perfetto traces and the Layout Inspector's recomposition counts. Two culprits: a list item took an unstable List parameter, so every item recomposed on any change; and we decoded a full-size image on the main thread. I made the model an immutable type, added stable keys, moved image loading off the main thread with a proper loader, and generated a Baseline Profile for the feed.

Result: jank dropped to near-zero in the benchmark, cold-start-to-first-scroll improved, and I left a Macrobenchmark test in CI so it can't regress. The team adopted “profile first, then fix the proven hotspot” as a habit.

Situation: we were shipping a significant feature and our release process was ad-hoc and risky.

Task: I took ownership of the release path end to end.

Action: I set up CI to run unit and instrumented tests on every PR, automated signing and the Play Console upload, and moved us to a staged rollout — 5% to 20% to 100% — gated on the crash-free rate. I put the risky part of the feature behind a feature flag with a kill switch, and wrote a short runbook for rollback.

Result: at 5% we caught a crash on a specific OEM, halted, root-caused it, shipped the fix with a regression test, and re-rolled cleanly. The feature reached 100% with a healthy crash-free rate, and the staged-rollout process became our default.

Situation: I joined a team mid-flight on a large, unfamiliar modular codebase using patterns I hadn't used before.

Task: get productive quickly without breaking things.

Action: I read the data flow before the files — the DI graph, the navigation graph, and the repositories — to build a mental model. Then I shipped the smallest safe change with a test to learn the feedback loop, and I followed the existing conventions instead of importing my own. I asked a few targeted questions early rather than guessing.

Result: I had a meaningful PR merged in my first week and was owning a feature within a month. The phrase I live by is “the smallest safe change that unblocks the next feature.”

Always have three or four sharp questions ready — it signals you're evaluating them too. Good ones for an Android role:

• How far along is your Compose adoption, and what's still on the View system?
• How is the codebase modularized, and what's the build time like day to day?
• What does your release process look like — staged rollouts, and what crash-free bar do you hold?
• How do you balance feature work against performance and tech-debt paydown?

Close warmly: “This has been great — the work lines up exactly with what I want to go deep on, and I'd be excited to join.”