Mejor prueba React Native para contratación: lo que realmente funciona
Por qué las pruebas estándar de JavaScript fallan en React Native
Muchas empresas contratan ingenieros de React Native usando evaluaciones de JavaScript o pruebas genéricas para desarrolladores frontend. Esto es un error. React Native comparte sintaxis con React, pero las limitaciones, trampas y patrones de diseño son completamente diferentes.
Un candidato que aprueba una prueba de codificación frontend podría fallar en React Native. No porque sea incompetente, sino porque React Native obliga a diferentes compensaciones.
Qué hace diferente la contratación en React Native
El problema del puente
En React Native, hay que pensar en el límite entre JavaScript y el código nativo. Los desarrolladores web nunca lo hacen. Un ingeniero de React Native necesita entender:
- Cómo llamar módulos nativos desde JavaScript
- Qué ocurre cuando bloqueas el hilo principal (la app se congela instantáneamente)
- Cómo funciona el layout de forma diferente (sin CSS, modelo de caja distinto)
- Depuración a través de dos runtimes (Chrome DevTools para JS, Xcode/Android Studio para nativo)
Esta brecha entre JavaScript y el código nativo es donde surgen las malas contrataciones.
El rendimiento es más difícil
Los desarrolladores web pueden ser lentos y salirse con la suya. React Native se ejecuta en teléfonos con la mitad de la memoria de un portátil. El rendimiento importa:
- Renderizar 1000 elementos con FlatList es lento sin optimización
- El almacenamiento en caché de imágenes es crítico
- El tamaño del bundle afecta al tiempo de inicio
- La serialización del puente es cara (demasiadas llamadas nativas = latencia)
Un desarrollador web brillante que nunca ha pensado en rendimiento escribirá React Native lento.
Las pruebas son diferentes
Web: jsdom, Jest, React Testing Library. React Native: las pruebas específicas de plataforma son más complicadas. Muchos ingenieros de React Native apenas hacen pruebas. Una evaluación que no mide aptitud para testing pierde señal importante.
La estructura ideal de una evaluación React Native
Fase 1: Screening (30 minutos en vivo)
Dale una app a medio construir con un bug específico. Ejemplo:
"Esta app muestra un listado paginado de usuarios desde una API. Cuando desplazas hacia abajo, carga la siguiente página. Pero la lista se entrecorta (pierde fotogramas) al cargar. Encuentra el cuello de botella y explica cómo solucionarlo."
Lo que esto evalúa
- ¿Pueden razonar sobre rendimiento en React Native?
- ¿Conocen FlatList, keyExtractor y optimización?
- ¿Entienden el puente y por qué importa el código nativo?
- ¿Pueden diagnosticar sin ejecutar el código?
Un desarrollador web podría sugerir memoización. Un ingeniero de React Native sabe que la optimización de FlatList es la respuesta real.
Fase 2: Take-home (90 minutos)
"Construye una app simple de notas. Los usuarios pueden crear, editar y eliminar notas. Las notas persisten en el almacenamiento del dispositivo. Requisitos:
- Usa AsyncStorage para persistencia
- Muestra un estado de carga mientras se cargan las notas
- Maneja el caso donde el almacenamiento está lleno
- Navegación entre las pantallas de lista y detalle"
Lo que esto evalúa
- ¿Pueden construir una característica completa?
- ¿Piensan en persistencia?
- ¿Manejan casos límite (almacenamiento lleno, datos corruptos)?
- ¿Pueden usar React Navigation de manera efectiva?
- ¿Está el código organizado y es testeable?
Rúbrica de calificación:
- ¿Funciona? (50%)
- ¿Se cumplen los requisitos? (30%)
- ¿Es mantenible? (20%)
No esperes perfección. Espera código que funcione y sea reflexivo.
Fase 3: Walk-through (30 minutos)
Pregunta:
- "Cuéntame cómo se guarda la nota. ¿Cuál es el flujo desde la entrada del usuario al almacenamiento?"
- "¿Qué pasa si el usuario cierra la app mientras se está guardando una nota?"
- "¿Cómo harías pruebas de esto? ¿Qué testearías?"
- "Si tuviéramos que sincronizar notas con la nube, ¿qué cambiarías?"
Esto revela:
- ¿Entienden su propio código o lo copiaron?
- ¿Han pensado en modos de fallo?
- ¿Pueden razonar sobre compensaciones arquitectónicas?
El problema del puente en profundidad
Este es el filtro de contratación más importante. Haz esta pregunta en el walk-through:
"Necesitas guardar un archivo grande en el dispositivo. Escribes un módulo nativo (Objective-C o Kotlin) que lo hace de manera eficiente. Tu código JavaScript llama a este módulo. Cuéntame cómo lo estructurarías. ¿Qué pasa si el archivo es demasiado grande? ¿Cómo manejas el progreso?"
La respuesta revela si entienden:
- Estructura de módulos nativos
- Límites de serialización del puente
- Patrones asincrónos a través de dos runtimes
- Manejo de errores en código entre lenguajes
Un desarrollador web no piensa en esto. Un ingeniero de React Native sí.
Disciplina de testing
Los ingenieros de React Native que no pueden hacer pruebas son un riesgo de contratación. Escriben código que es difícil de refactorizar. Añade esto a la evaluación:
"¿Cómo escribirías una prueba para la lógica de guardar notas? ¿Qué harías para testear? ¿Qué es difícil de probar?"
Buena respuesta: Las pruebas verificarían que AsyncStorage se llama, que los errores se manejan, que la UI se actualiza. Parte difícil: probar el comportamiento real del almacenamiento del dispositivo.
Respuesta débil: "¿Pruebas con Jest? Solo simulo todo y compruebo que se llamen las funciones."
Señales de alerta en evaluaciones React Native
Demasiado código nativo
Si la evaluación requiere escribir Kotlin o Swift, estás probando experiencia en plataformas, no ingeniería de React Native. Los ingenieros de React Native deberían poder usar módulos nativos, no necesariamente escribirlos.
Demasiadas características de tipo web
"Construye un sistema completo de autenticación con OAuth" no prueba habilidades de React Native. Prueba si han usado OAuth antes.
Casos límite faltantes
Una evaluación que ignora soporte offline, persistencia de datos o manejo de permisos está incompleta.
Sin restricciones de rendimiento
"Haz una app" sin consideración de rendimiento es demasiado fácil.
Comparando las soluciones de los candidatos
Dos soluciones podrían funcionar ambas. ¿Cómo las distingues?
Candidato A:
- Usa FlatList con keyExtractor
- AsyncStorage envuelto en una capa de servicio
- Maneja errores (almacenamiento lleno, permiso denegado)
- Sin pruebas escritas
- El código está organizado pero es defensivo
Candidato B:
- Usa FlatList correctamente
- AsyncStorage con un wrapper que maneja serialización JSON
- Maneja errores y casos límite
- Incluye pruebas (Jest + mock AsyncStorage)
- El código es limpio, pequeño y testeable
El Candidato B es mejor. No porque la app funcione (ambas funcionan), sino porque ha pensado en mantenibilidad y pruebas.
Evaluando React Native con experiencia en React web
Si el candidato tiene un sólido trasfondo en React pero sin experiencia en React Native, ajusta las expectativas:
- La sintaxis y el pensamiento en componentes se transfieren inmediatamente
- Los patrones de gestión de estado (Redux, Zustand) se transfieren
- Los patrones de pruebas (Jest, mocking) se transfieren en su mayoría
Pero tendrán dificultades con:
- Navegación (React Router es diferente de React Navigation)
- Optimización de rendimiento
- Integración de módulos nativos
- Pensar en términos de limitaciones de memoria del dispositivo
La evaluación debería seguir probando toda la pila, pero puedes ser más flexible con la curva de aprendizaje y enfocarte en habilidades de razonamiento central que se transferirán.
Implementando la evaluación
Si estás evaluando desarrolladores móviles a escala, considera que React Native tiene herramientas y compensaciones diferentes a iOS o Android nativo. No mezcles las evaluaciones. Los ingenieros de React Native necesitan su propio pipeline.
Las tres fases (screening en vivo, take-home, walk-through) toman aproximadamente 2,5 horas de tiempo del candidato y 1,5 horas de tiempo del entrevistador. Esto es apropiado para un rol de nivel medio.
Para ingenieros React Native senior, añade una discusión de arquitectura de 30 minutos: "Estás construyendo una app que obtiene datos de una API, los almacena en caché localmente y se sincroniza cuando está offline. ¿Cómo lo estructurarías? ¿Qué librerías usarías?"
Errores comunes a evitar
- No pruebes frameworks web (React DOM, Next.js, etc.)
- No requieras conocimiento de una librería específica de gestión de estado
- No hagas la evaluación sobre CSS o estilos
- No asumas que han usado todas las plataformas (Android, iOS, Web)
Enfócate en:
- Fundamentos de React
- Fundamentos de JavaScript
- Patrones específicos de React Native (FlatList, AsyncStorage, Navigation, Bridge)
- Limitaciones del dispositivo y pensamiento de rendimiento
Usa este marco para interpretar resultados de pruebas de manera justa y consistentemente a través de candidatos.