Show Cal how
you build and deliver.

At Lyft, I led Android delivery of Driver AI from the specification through public launch. The driver-facing experience combined chat, voice input, and plan cards, with controls that accounted for whether the driver was moving.

I wrote the Android specification, worked with the shared-contract owner on additive chat and tile models, and implemented the client interactions. The difficult part was making the experience work across systems and teams. I aligned client, backend, and data engineering on what data we were gathering, and coordinated our changes with support and the driver team.

When duplicated messages and backend ownership gaps became launch blockers, I helped resolve them across the Android and backend boundary. My responsibility was Android delivery and integration; the other owners retained responsibility for their systems.

The product launched publicly, and the chat patterns were later reused. I'm proud of carrying the work through the complete driver experience, including implementation, data alignment, and the teams supporting the launch. I can walk you through the shared-model decision or one integration blocker.

Another project was navigation voice choices and the shared speech framework behind them. Drivers wanted voice options, while speech capabilities were duplicated across Driver AI, navigation, and RiderAI.

I consolidated speech-to-text and text-to-speech services and led Android work across voice profiles, settings, APIs, and navigation runtime integration. I also worked through provider throttling and cache warming. The complexity was delivering a driver feature while creating a capability other products could reuse.

I delivered later voice work in smaller reviewable stages after feedback on a large pull request. The framework was reused across three products, and the reported early rollout had more than 600 drivers switching voices in roughly ten days.

What I like about this project is that the shared engineering work enabled a concrete choice for drivers. I can go deeper on the product boundary, provider constraints, or rollout.

At Verdict MMA, I implemented the native Android deposit and withdrawal experience across backend APIs and a hosted payment provider.

The client had to represent loading, errors, success, and pending states, and handle back and close actions. I worked with amount-in-cents contracts across the boundary. One important distinction was that a redirect from the payment provider did not establish final settlement, so the UI needed to reflect the actual payment state.

My contribution was connecting those backend and provider behaviors to the native user flow. It is a good example of the kind of client development I enjoy: the user sees a simple interaction, while the implementation has to represent asynchronous behavior accurately.

I can walk through the transition from submission to a pending result, or explain the boundary between returning to the app and confirming settlement.

On Driver AI, a principal engineer and I disagreed about the initial voice implementation. They favored speech-to-text on the client: send the transcript to the backend, pass it to the LLM, and return text to the client. I wanted a real-time streaming API for a better experience. The tradeoff was the experience I was advocating for against the resources and time available.

I made the case for streaming, then aligned with the principal engineer’s direction for the initial release. We committed to the client-side transcription flow and delivered it. I followed up with streaming afterward.

We saw a 40% increase in usage after that follow-up. What I value about the example is that I could advocate for the experience, commit to a shared decision, and still carry the improvement forward.

That is how I want to work with senior engineers: make the tradeoff clear, keep the team aligned on delivery, and follow through on the improvement.

One pressure example was an Android Auto release at Lyft that started failing when drivers connected to a head unit. My responsibility was to narrow the failure and help the team recover safely.

I reproduced it on physical head-unit hardware, compared phones and operating-system versions, and shared the logs. I isolated the regression to Android 16. That gave the team a basis for restoring the feature to unaffected cohorts while we investigated the targeted fix.

I helped validate the fix, including a manifest-test issue in CI and checks on the release candidate. We had a targeted fix within roughly three days.

Under pressure, I want to make the next decision clearer: what is affected, what can recover safely, and what still needs investigation. I stay engaged with the other owners and make the evidence useful to the team.

I try to give people enough context to own their work. At Lyft, I helped onboard two engineers who shipped production code in their first sprint.

I gave them a specification template and a worked example, coached on-call triage and handoffs, and supported implementation through review. As they built context, I gave them room to make decisions. One later drove a server-driven UI flow with minimal oversight. The work they shipped was theirs; my contribution was the context and support.

I use the same approach on larger projects. With Driver AI, I aligned client, backend, and data engineering on what we were gathering and coordinated changes with support and the driver team. I can drive my implementation independently while keeping the people around the project involved and clear about their responsibilities.

A clear example is Android Auto ride acceptance at Lyft. A driver requested the capability on LinkedIn, and David Risher replied. I implemented the Android Auto ride-acceptance work.

What made this memorable was the direct connection between a driver’s request and a feature I worked on. The need was concrete, and the discussion gave it visibility beyond an internal engineering conversation.

I like customer-facing work where I can connect the engineering decisions to something a person wants to do. This example gives me a direct way to explain that connection and then walk through my implementation.

Outside work, I’m interested in health optimization. I’ve tried different diets and supplements, and I care about finding what is sustainable and works for me. Sleep is a consistent priority.

There was a funny coincidence with this opportunity. I recently moved, and my bed is beside a window, so that side of the room gets colder. My partner has also mentioned that I snore. Eight Sleep was already on my mind when Gary reached out.

The product is personally relevant to me, and the engineering interests me too: turning preferences and automation into an app-and-device experience people can rely on every night. I want to keep growing as a hands-on engineer while working in health tech, where I already have a personal interest in the problem.

My strength is carrying ambiguous client work through delivery while keeping the people around it aligned.

With Driver AI, I owned the Android specification, implementation, and integration through public launch. I worked with the shared-contract owner and aligned client, backend, and data engineering on what we were gathering. I also coordinated changes with support and the driver team.

I’m comfortable taking responsibility for my part of the work, getting into implementation details, and staying engaged across dependencies. I also make the ownership boundaries clear so other teams can do their parts. That combination of hands-on delivery and collaboration is what I would bring to this role.

I sometimes commit to more work than I can realistically deliver at once. I want to help and keep things moving, and I’ve been too slow to make the capacity tradeoff explicit.

On a voice project, the scope grew, backend gaps appeared, and I had overlapping on-call work. I kept absorbing it without raising the impact on the estimate early enough. My estimate slipped, and that was my responsibility.

I raised it with my manager and reset the plan. Since then, I’ve been more explicit about capacity, raised scope changes earlier, and split subsequent work into smaller reviewable pieces. I want the team to be able to rely on my commitments, so making the tradeoff clear is part of ownership.

At Lyft, I led Android delivery of Driver AI from the specification through public launch. The driver-facing experience combined chat, voice input, and plan cards, with controls that accounted for whether the driver was moving.

I wrote the Android specification, worked with the shared-contract owner on additive chat and tile models, and implemented the client interactions. The difficult part was making the experience work across systems and teams. I aligned client, backend, and data engineering on what data we were gathering, and coordinated our changes with support and the driver team.

When duplicated messages and backend ownership gaps became launch blockers, I helped resolve them across the Android and backend boundary. My responsibility was Android delivery and integration; the other owners retained responsibility for their systems.

The product launched publicly, and the chat patterns were later reused. I'm proud of carrying the work through the complete driver experience, including implementation, data alignment, and the teams supporting the launch. I can walk you through the shared-model decision or one integration blocker.

A second example is navigation voice choices and the speech framework behind them. Drivers wanted voice options, while speech-to-text and text-to-speech capabilities were duplicated across Driver AI, navigation, and RiderAI.

I consolidated the shared services and led Android delivery across voice profiles, settings, APIs, and runtime integration. For the driver, the feature was a choice they could make in navigation. Underneath it, we needed a reusable capability that worked across multiple product integrations.

I worked through provider throttling and cache warming, and delivered later voice work in reviewable stages. Feedback on a large pull request changed how I structured that work: voice-to-voice used six pull requests and alternative voices used four.

The framework was reused across three products. The source reports more than 600 early voice switchers in roughly ten days of a staged release. That is the user uptake I can substantiate. This is a project I enjoy because the shared engineering foundation directly enabled something drivers had asked for.

At Lyft, I built a workflow that takes a product request through research and planning into draft pull requests for iOS and Android. What interested me was turning a promising prototype into something engineers could operate and review.

I added a Redis-stream work queue, authenticated webhook ingress, a GitHub App, and human review gates. I worked through restart and cluster failures and aligned the integration with the team that would own the infrastructure. That meant addressing recovery, permissions, and ownership alongside generated code.

I packaged the workflow for broader use. It was used in a sprint, and another organization expressed interest in adopting it. I also became involved in helping the team adopt AI practices, which was recognized in my interview feedback.

The part I value is helping others get useful work out of the capability. I want the workflow to fit how the team plans, reviews, and ships. I can go deeper on the work queue, recovery behavior, or the human-review boundary.

At Verdict MMA, I co-founded the product and worked across native Android, web, and backend systems. It gave me experience carrying user-facing work across a small startup’s technical boundaries.

One example is the native deposit and withdrawal experience. I implemented the Android flow across backend APIs and a hosted payment provider, with amount-in-cents contracts and explicit loading, error, success, pending, back, and close states. A redirect from the provider had to remain distinct from final settlement, so the native experience needed to communicate the actual state.

A separate backend challenge was concentrated scoring and notification work during live fights. I moved push delivery into a Redis-backed Bull queue, used bounded processing and bulk enqueueing, and made database-connection cleanup explicit when jobs failed.

Those examples show different kinds of complexity: asynchronous state in a client-facing financial flow, and controlled background work under bursty demand. I’m comfortable carrying work across those boundaries and getting into implementation details while keeping the user experience in view.

A concrete bias-for-action example is a P000 duplicate-message issue at Lyft. It affected the message experience, and I worked on the fix rather than letting it remain someone else’s problem.

The result I can describe is the duplicate-message correction. For the technical discussion, I would walk through the actual trigger, why the duplicate was created, the change I made, and how we verified the fix.

What matters to me in production work is taking a user-visible problem seriously and carrying my part of the response through to a working correction. It is also important to make the failure and next steps understandable to the people working on it.

A customer-facing example is Android Auto ride acceptance at Lyft. A driver posted on LinkedIn requesting the capability, and David Risher replied. I implemented the Android Auto ride-acceptance work.

What I liked about this example was the direct connection between a driver’s request and the feature I worked on. It made the user need concrete and gave the work visibility beyond an internal engineering discussion.

For the deeper technical discussion, I would explain how the acceptance action reached the existing ride flow, the state the head-unit experience had to represent, and how I verified the behavior. This is a useful example of connecting a real customer need to Android delivery.

On Driver AI, a principal engineer and I disagreed about the initial voice implementation. They favored speech-to-text on the client: send the transcript to the backend, pass it to the LLM, and return text to the client. I wanted a real-time streaming API for a better experience. The tradeoff was the experience I was advocating for against the resources and time available.

I made the case for streaming, then aligned with the principal engineer’s direction for the initial release. We committed to the client-side transcription flow and delivered it. I followed up with streaming afterward.

We saw a 40% increase in usage after that follow-up. What I value about the example is that I could advocate for the experience, commit to a shared decision, and still carry the improvement forward.

That is how I want to work with senior engineers: make the tradeoff clear, keep the team aligned on delivery, and follow through on the improvement.

I’m comfortable taking ownership independently, and I also want the people around me to become more effective. A concrete example is helping onboard two engineers at Lyft who shipped production code in their first sprint.

I gave them a specification template and a worked example, coached on-call triage and handoffs, and supported implementation through review. As they built context, I gave them room to own the decisions. One later drove a server-driven UI flow with minimal oversight.

Their shipped work was theirs. My contribution was the context and support that helped them become independent. I bring the same approach to larger projects: I can drive my part of the work, make the interfaces and responsibilities clear, and bring the other owners into the decisions.

That matters to me because a successful project should leave the team better able to deliver the next one.

Outside work, I’m interested in health optimization. I’ve tried different diets and supplements, and I’ve learned to care about what is sustainable and works for me. Sleep is a consistent priority.

There’s a funny coincidence behind Eight Sleep. I recently moved, and my bed is by a window, so that side of the room gets colder. My partner has also mentioned that I snore. Eight Sleep was already on my mind when Gary reached out.

That makes the product personally relevant. I’m interested in how the app turns temperature preferences and automation into a reliable nightly experience. I’d like to put my engineering work into a product area I already care about.

A big motivation for me is becoming the best engineer I can be. I enjoy work that stretches my judgment and gives me responsibility for a real product outcome. That’s what draws me to a team building something meaningful in health tech.

I’ve worked across a startup and large-scale mobile products, with launch dependencies and production issues that required me to stay engaged through the difficult parts. I also learned from a voice project where scope growth and on-call work affected my estimate. I owned the slip and changed how I communicate capacity and split work for review.

I want to bring that combination of urgency, high standards, and clear communication here: take ownership, help the team move, and keep improving how we deliver.

In a few years, I want to be a technical lead who stays hands-on and owns larger projects from idea through launch.

I want to build that depth in health tech, understanding how the app, device, and user experience fit together. At Eight Sleep, I'd like to become someone the team trusts with its hardest Android problems, while helping other engineers grow.