Pitches de Práctica

Hola, soy ingeniero Android con varios años creando apps de producción en Kotlin. Mi enfoque es Android moderno — Jetpack Compose, coroutines y Flow, y una arquitectura MVVM limpia respaldada por Hilt y Room.

Más recientemente lideré una migración a Compose y una reconstrucción offline-first: fui dueño de la arquitectura, el trabajo de rendimiento, y la pipeline de releases.

Me atrae este rol porque es senior, Kotlin-first, y el tipo de producto maduro donde la arquitectura y el rendimiento realmente importan.

Claro. Soy ingeniero senior de Android. He pasado los últimos años distribuyendo apps Kotlin en Google Play, y me especializo en Android moderno: Jetpack Compose para UI, coroutines y Flow para asíncrono y estado, y MVVM con una capa de datos limpia.

En mi último equipo fui el líder técnico para una app de consumo pesada en pantallas. Lideré la migración del sistema de vistas a Compose, reconstruí la capa de datos para ser offline-first con Room como la fuente única de verdad y Retrofit sincronizando en segundo plano, y conecté todo el grafo con Hilt.

Gran parte de mi trabajo fue rendimiento: rastreé problemas de recomposición y jank con Perfetto y Macrobenchmark, añadí Baseline Profiles, y reduje el arranque en frío mediblemente. También fui dueño de releases — CI con tests instrumentados, lanzamientos escalonados, y monitoreo de la tasa de crash-free.

Busco un rol senior, Kotlin-first en un producto maduro donde pueda profundizar en arquitectura y rendimiento — que es exactamente lo que esto parece.

Te daré el arco corto. Empecé en Android en la época de Java y XML — Activities, Fragments, RxJava — construyendo features y aprendiendo la plataforma a la fuerza: bugs de ciclo de vida, cambios de configuración, y memory leaks.

Cuando Kotlin se convirtió en primera clase migré completamente, y eso cambió cómo escribo código: seguridad de nulos, clases sealed para estado, y coroutines en lugar de cadenas de callbacks. Reconstruí flujos asíncronos alrededor de concurrencia estructurada y Flow, lo que hizo la cancelación y testing genuinamente simple por primera vez.

Los últimos años fueron mi capítulo más profundo. Lideré una adopción de Compose en una app grande — no un rewrite, una migración incremental pantalla por pantalla — y re-arquitecté la capa de datos para ser offline-first: Room como fuente de verdad, un repository poseyendo la sincronización, y la UI solo observando estado. Introduje Hilt, modularicé la codebase por feature para compilaciones más rápidas, y configuré Baseline Profiles y Macrobenchmark para proteger el rendimiento de arranque y scroll.

Lo que une esto es que me importan los fundamentos aburridos — ciclo de vida, hilos, y estado — porque eso es lo que hace que una app se sienta rápida y no crashee. Un rol senior, Kotlin-first en un producto maduro es exactamente el siguiente paso que quiero.

Dos razones. Primero, el oficio: Android te obliga a respetar restricciones — el ciclo de vida, memoria limitada, un solo hilo principal, variabilidad real de red. Hacer que una app se sienta instantánea en un teléfono de gama media con una conexión inestable es un problema genuinamente difícil y satisfactorio.

Segundo, Kotlin y Jetpack hicieron la plataforma un placer. Las coroutines convirtieron el asíncrono en algo que puedes leer de arriba a abajo; Compose hizo la UI declarativa e impulsada por estado; y el sistema de tipos atrapa una clase entera de bugs antes de que se distribuyan. Me gusta que Android moderno recompensa a ingenieros que piensan sobre estado e hilos con claridad.

Este es para personalizar — así que aquí está la estructura. Abre con algo específico sobre su producto o cultura de ingeniería (una feature que admiras, su escala, su adopción de Compose, un post de blog de ingeniería). Luego conéctalo contigo: "Ese es exactamente el tipo de problema en el que quiero trabajar, y se alinea con mi profundidad en X."

Cierra con el equipo y el nivel: "Un rol senior, Kotlin-first en un producto tan maduro es donde hago mi mejor trabajo — quiero ser dueño de arquitectura y rendimiento, mentorear a través de revisiones, y distribuir cosas que se sostengan."

La estructura: elige un proyecto y cuéntalo como un problema, un diseño, y un resultado. Mi favorito es la reconstrucción offline-first.

Problema: la app mostraba spinners constantemente y perdía el trabajo del usuario en una conexión caída, porque cada pantalla obtenía directamente de la red y mantenía su propia copia de los datos.

Diseño: Hice la base de datos local de Room la fuente única de verdad. La UI observa Flow del DAO, así que siempre renderiza datos locales instantáneamente. Un repository posee la sincronización — escribe actualizaciones optimistas localmente, encola mutaciones, y reconcilia con el servidor vía WorkManager cuando la conectividad regresa, con una política de última escritura gana por tipo de registro. Todo está conectado a través de Hilt y se ejecuta en viewModelScope para que se cancele limpiamente.

Resultado: la app funcionó completamente offline, el problema de spinner-en-cada-pantalla desapareció por las lecturas stale-while-revalidate, y nuestra tasa de crash-free subió porque dejamos de hacer trabajo de red frágil en el hilo principal. Añadí tests de Turbine alrededor de la lógica de sincronización para que no pudiera haber regresión.

Situación: nuestro feed principal tartamudeaba al hacer scroll en dispositivos de gama media, y los usuarios lo notaban.

Tarea: Fui dueño de hacerlo fluido sin un rewrite.

Acción: Perfilar en lugar de adivinar — un test de scroll de Macrobenchmark más trazas de Perfetto y los contadores de recomposición del Layout Inspector. Dos culpables: un elemento de lista tomaba un parámetro List inestable, así que cada elemento se recomponía en cualquier cambio; y decodificábamos una imagen de tamaño completo en el hilo principal. Hice el modelo un tipo inmutable, añadí keys estables, moví la carga de imágenes fuera del hilo principal con un cargador adecuado, y generé un Baseline Profile para el feed.

Resultado: el jank bajó a casi cero en el benchmark, el arranque-en-frío-a-primer-scroll mejoró, y dejé un test de Macrobenchmark en CI para que no pueda haber regresión. El equipo adoptó "perfilar primero, luego arreglar el punto crítico demostrado" como hábito.

Situación: estábamos distribuyendo una feature significativa y nuestro proceso de release era ad-hoc y riesgoso.

Tarea: Tomé ownership de la ruta del release de principio a fin.

Acción: Configuré CI para ejecutar tests unitarios e instrumentados en cada PR, automatice la firma y la subida a Play Console, y nos movimos a un lanzamiento escalonado — 5% a 20% a 100% — con control de la tasa de crash-free. Puse la parte riesgosa de la feature detrás de un feature flag con kill switch, y escribí un runbook corto para rollback.

Resultado: al 5% atrapamos un crash en un OEM específico, detuvimos, encontramos la causa raíz, distribuimos la corrección con un test de regresión, y relanzamos limpiamente. La feature alcanzó el 100% con una tasa de crash-free saludable, y el proceso de lanzamiento escalonado se convirtió en nuestro predeterminado.

Situación: Me uní a un equipo a mitad de camino en una codebase grande, desconocida y modularizada usando patrones que no había usado antes.

Tarea: Ser productivo rápidamente sin romper nada.

Acción: Leí el flujo de datos antes de los archivos — el grafo DI, el grafo de navegación, y los repositorios — para construir un modelo mental. Luego distribuí el cambio seguro más pequeño con un test para aprender el bucle de retroalimentación, y seguí las convenciones existentes en lugar de importar las mías. Hice algunas preguntas específicas temprano en lugar de adivinar.

Resultado: Tuve un PR significativo fusionado en mi primera semana y era dueño de una feature dentro de un mes. La frase que vivo es "el cambio seguro más pequeño que desbloquea la siguiente feature."

Siempre ten tres o cuatro preguntas agudas listas — eso señala que tú también los estás evaluando. Buenas para un rol Android:

• Qué tan avanzada está su adopción de Compose, y qué aún está en el sistema de vistas?
• Cómo está modularizada la codebase, y cómo es el tiempo de compilación día a día?
• Cómo es su proceso de release — lanzamientos escalonados, y qué tasa de crash-free manejan?
• Cómo balancean trabajo de features contra rendimiento y pago de deuda técnica?

Cierra con calidez: "Esto ha sido genial — el trabajo se alinea exactamente con lo que quiero profundizar, y me emocionaría unirme."