Comparativa de pruebas para desarrolladores iOS vs Android: contratación específica de plataforma

La realidad del mercado de talento

Los mercados de ingenieros iOS y Android son estructuralmente diferentes. Los ingenieros iOS son más escasos, tienen salarios más altos y enfrentan menos competencia de desarrolladores junior. Android tiene un grupo de talentos más grande, más fragmentación de plataforma y diferentes trayectorias profesionales. Estas diferencias deben cambiar la manera en que evalúas cada una.

Si estás contratando para ambas plataformas y usas la misma evaluación, estás midiendo las cosas equivocadas.

iOS vs Android: El lado de la oferta

iOS

• Grupo de talento más pequeño: ~15% de desarrolladores móviles se enfocan en iOS vs. ~40% para Android
• Costo de especialización más alto: Deben aprender Swift, Xcode y el proceso de aprobación de Apple
• Continuidad profesional: Los ingenieros iOS tienden a permanecer más tiempo en el campo
• Prima salarial: Los ingenieros iOS ganan 10-15% más que sus pares de Android
• Implicación de evaluación: Estás filtrando por compromiso profundo con la plataforma, no solo fundamentos móviles

Android

• Grupo más grande y más amplio: El desarrollo de Android abarca Java, Kotlin, Flutter (multiplataforma) y React Native
• Barrera de entrada más baja: Las habilidades de Java se transfieren; la adopción de Kotlin aún está en progreso; muchos ingenieros junior comienzan en Android
• Fragmentación: Evaluar Android requiere entender variaciones de dispositivos, niveles de API y diferencias de vendedores
• Implicación de evaluación: Necesitas distinguir entre "sabe Android" y "sabe Android bien bajo restricciones"

Diferencias de evaluación: Qué cambia

Pruebas de memoria y ciclo de vida

iOS: El ciclo de vida de Apple es más limpio. viewDidLoad, viewWillAppear, deinit. El modelo es consistente. Una evaluación puede esperar que los candidatos conozcan estos por nombre.

Android: El ciclo de vida de Fragment y Activity es más complicado. Los cambios de orientación, cambios de configuración y restauración de estado son más difíciles de predecir. Una evaluación que prueba "¿puedes razonar a través de un problema de ciclo de vida?" es más valiosa que "nombra los métodos."

Prueba: "¿Qué sucede con tu estado cuando el usuario rota el dispositivo?" La respuesta de Android debe ser más profunda porque el problema es realmente más difícil.

Inyección de dependencias y arquitectura

iOS: iOS moderno usa inyección de dependencias pero es opcional. Muchas bases de código la saltan. La evaluación no debe asumir que se usa.

Android: La inyección de dependencias (Hilt, Dagger) es casi estándar. Las evaluaciones de Android pueden esperar que los candidatos usen patrones de DI y prueben la comprensión de arquitectura más profundamente.

Async y concurrencia

iOS: async-await llegó recientemente y de manera limpia. Combine es más antiguo y complejo. La evaluación puede probar el conocimiento de async-await como algo positivo pero no debería requerirlo para candidatos de nivel medio.

Android: Coroutines es estándar. Los callbacks son heredados. RxJava se está desvaneciendo. La evaluación debe esperar conocimiento de coroutines de cualquiera que sea de nivel medio o superior.

Cultura de pruebas

iOS: XCTest es el estándar. Las librerías de mocking existen pero la adopción varía. Las pruebas unitarias son buenas, pero las pruebas de integración son menos comunes.

Android: Espresso y Robolectric son estándar. Mockito es ubicuo. Los ingenieros de Android esperan escribir pruebas para diferentes capas (unitaria, integración, UI).

Una evaluación de iOS puede preguntar sobre pruebas unitarias. Una evaluación de Android puede esperar pruebas más sofisticadas.

Comparación práctica de evaluación

El mismo problema, diferentes rúbricas

Problema: "Obtén una lista de elementos de una API y muéstralos con paginación. Maneja errores de red con gracia."

Rúbrica de iOS:

• ¿El controlador de vista persiste correctamente el estado a través de cambios del ciclo de vida?
• ¿Es la capa de red comprobable?
• ¿El manejo de errores incluye retroalimentación visible para el usuario?

Rúbrica de Android:

• ¿Se usa ViewModel correctamente?
• ¿Se implementa el patrón de repositorio?
• ¿Se usan las coroutines correctamente (sin bloquear el hilo principal)?
• ¿Se configura la prueba usando Hilt?

El problema es el mismo. Las expectativas son diferentes porque las plataformas son diferentes.

Variaciones de problemas específicos de plataforma

Para iOS: Agrega una restricción sobre drenaje de batería. "Esta llamada a API ocurre cada 5 segundos. ¿Cómo evitas agotar la batería?" Los ingenieros de iOS deben saber sobre actualización de aplicación en segundo plano, servicios de ubicación y reactivaciones innecesarias.

Para Android: Agrega una restricción sobre fragmentación de dispositivos. "RecyclerView se ralentiza en dispositivos más antiguos (API 21). ¿Cómo lo optimizas?" Los ingenieros de Android deben saber sobre RecyclerView.setHasFixedSize(), getItemViewType() y almacenamiento en caché de imágenes.

Dificultad de contratación: ¿Cuál es realmente más difícil?

iOS es más difícil para contratar

• Grupo de candidatos más pequeño
• Barra de habilidades más alta (menos transiciones de junior a medio)
• Los candidatos esperan ofertas competitivas
• Ciclos de entrevista más largos (los candidatos reciben múltiples ofertas)

Estrategia de evaluación: Las evaluaciones de iOS deben enfocarse en profundidad, no amplitud. Prueba async-await, gestión de estado, seguridad de memoria. No desperdicies tiempo en lo básico.

Android es más difícil para contratar bien

• Un grupo de candidatos más grande crea ruido
• Más variabilidad en la calidad del candidato (buenos desarrolladores, desarrolladores mediocres y personas que solo saben Java)
• La fragmentación significa que un candidato podría ser experto en una versión de Android y débil en otra
• Los desarrolladores de Flutter y React Native agregan ambigüedad ("¿esta persona es realmente un ingeniero de Android?")

Estrategia de evaluación: Las evaluaciones de Android deben distinguir cuidadosamente entre nivel medio y senior. Usa preguntas de arquitectura para separar candidatos que solo han construido aplicaciones simples de candidatos que han manejado sistemas complejos.

Caso especial: React Native

Los ingenieros de React Native se sitúan entre ambas plataformas pero no dominan ninguna. Si estás contratando para React Native, no uses evaluaciones nativas de iOS o Android.

Prueba: "Necesitas llamar a una función nativa de Android desde JavaScript. ¿Cómo funciona el puente?" Un ingeniero fuerte de React Native conoce el límite. Uno débil no.

Relación de salario y evaluación

Los ingenieros de iOS cuestan más. ¿Significa eso que deberías evaluarlos más rigurosamente? Quizás no. Una evaluación más rigurosa significa:

• Ciclo de contratación más largo
• Mayor probabilidad de rechazo de oferta
• Es más probable que los candidatos acepten ofertas competidoras

Para iOS, la velocidad puede importar tanto como la profundidad. Un problema de programación en vivo de una hora podría revelar lo suficiente. Para Android, una evaluación más exhaustiva te ayuda a cribar un grupo más grande.

Construyendo tus propias evaluaciones

Si estás construyendo evaluaciones desde cero, recuerda:

• iOS: Asume que conocen Swift y UIKit/SwiftUI. Prueba ciclo de vida, concurrencia, gestión de estado.
• Android: Asume que conocen Kotlin y las librerías de Jetpack. Prueba arquitectura, disciplina de pruebas y manejo de restricciones.
• React Native: Asume que conocen React y JavaScript. Prueba conocimiento del puente de plataforma, patrones de navegación y pensamiento multiplataforma.

Los problemas deben ser diferentes. Las rúbricas de calificación deben ser diferentes. Y tu cronograma de contratación debe tener en cuenta la dinámica del mercado.

Cómo esto afecta el timing de la oferta

Los ingenieros de iOS se mueven rápido. Si los evalúas a fondo pero luego tardas una semana en decidir, aceptarán otra oferta. Si evalúas a los ingenieros de Android ligeramente, terminarás con desarrolladores de nivel medio en roles senior.

Calibra tu rigor de evaluación a tu velocidad de mercado y tamaño del grupo de candidatos. Esto es parte de evaluar desarrolladores móviles estratégicamente.