La mejor prueba de React Native para contratar: lo que de verdad funciona

Por qué fallan los tests estándar de JavaScript para React Native

Muchas empresas contratan ingeniería React Native con evaluaciones de JavaScript o tests de frontend genéricos. Es un error. React Native comparte sintaxis con React, pero las restricciones, las trampas y los patrones de diseño son distintos.

Una candidatura que aprueba un test de coding frontend puede fracasar en React Native. No por mala, sino porque RN fuerza otros trade-offs.

Qué hace distinto contratar para RN

El problema del bridge

En React Native piensas en la frontera entre JavaScript y código nativo. La web nunca lo hace. Una RN engineer necesita entender:

• Cómo llamar módulos nativos desde JS
• Qué pasa al bloquear el hilo principal (la app se congela al instante)
• Cómo funciona el layout (sin CSS, otro modelo de caja)
• Depurar entre dos runtimes (Chrome DevTools para JS, Xcode/Android Studio para nativo)

Ese hueco entre JS y nativo es donde nacen las malas incorporaciones.

El rendimiento es más difícil

En la web puedes ser lento y vivir. RN corre en móviles con la mitad de RAM de una laptop. El rendimiento importa:

• Renderizar 1.000 ítems con flat list es lento sin optimizar
• El cacheo de imágenes es crítico
• El bundle size afecta al arranque
• La serialización del bridge es cara (demasiadas llamadas nativas = latencia)

Una web brillante que nunca ha pensado en rendimiento escribirá RN lenta.

El testing es distinto

Web: jsdom, Jest, RTL. RN: el testing específico de plataforma es más complicado. Muchas RN engineers apenas testean. Una evaluación que no mide actitud para testear pierde señal.

Estructura ideal de evaluación

Fase 1: cribado (30 minutos en vivo)

Dale una app a medio construir con un bug específico. Ejemplo:

«Esta app muestra un listado paginado de usuarias desde una API. Al hacer scroll abajo carga la siguiente página, pero la lista se entrecorta al cargar. Encuentra el cuello de botella y explica el arreglo».

Qué evalúa

• ¿Razona sobre rendimiento de RN?
• ¿Conoce FlatList, keyExtractor y optimizaciones?
• ¿Entiende el bridge?
• ¿Diagnostica sin ejecutar?

Una web puede sugerir memoización. Una RN engineer sabe que la respuesta real es optimizar FlatList.

Fase 2: take-home (90 minutos)

«Construye una app de notas. Crea, edita y elimina notas. Persistencia en el dispositivo. Requisitos:

• AsyncStorage para persistencia
• Estado de carga al cargar notas
• Manejar storage lleno
• Navegación entre lista y detalle»

Qué evalúa

• ¿Construye una feature completa?
• ¿Piensa en persistencia?
• ¿Casos límite (storage lleno, datos corruptos)?
• ¿React Navigation?
• ¿Código organizado y testeable?

Rúbrica:

• ¿Funciona? (50 %)
• ¿Cumple requisitos? (30 %)
• ¿Mantenible? (20 %)

No esperes perfección. Espera código pensado y funcionando.

Fase 3: walk-through (30 minutos)

Pregunta:

• «Cuéntame cómo se guarda la nota. Flujo desde input hasta storage».
• «¿Qué pasa si la usuaria cierra la app mientras se guarda?»
• «¿Cómo lo testearías? ¿Qué testearías?»
• «¿Qué cambiarías si tuviéramos que sincronizar a la nube?»

Esto revela:

• ¿Entiende su código o lo copió?
• ¿Pensó en modos de fallo?
• ¿Razona sobre arquitectura?

El bridge a fondo

El filtro más importante. En el walk-through:

«Necesitas guardar un fichero grande en el dispositivo. Escribes un módulo nativo (Objective-C o Kotlin) eficiente. Tu JS llama a ese módulo. Cuéntame cómo lo estructuras. ¿Qué pasa si el fichero es demasiado grande? ¿Cómo manejas el progreso?»

La respuesta revela si entiende:

• Estructura de módulos nativos
• Límites de serialización del bridge
• Patrones async entre dos runtimes
• Manejo de errores cross-language

Una web no piensa en eso. Una RN engineer sí.

Disciplina de testing

«¿Cómo escribirías un test para la lógica de guardado? ¿Qué testearías? ¿Qué es difícil de testear?»

Buena respuesta: verificaría que se llama AsyncStorage, que se manejan errores, que la UI se actualiza. Lo difícil: comportamiento real del storage del dispositivo.

Respuesta débil: «Tests con Jest. Mockeo todo y compruebo llamadas».

Banderas rojas

Demasiado código nativo

Si la evaluación pide Kotlin o Swift, mides experiencia de plataforma, no RN. Una RN engineer debe usar módulos nativos, no necesariamente escribirlos.

Demasiados rasgos web

«Construye un sistema completo de auth con OAuth» no testea RN. Testea si ya hizo OAuth.

Casos límite ausentes

Sin offline, persistencia o permisos, está incompleta.

Sin restricciones de rendimiento

«Haz una app» sin pensar en rendimiento es demasiado fácil.

Comparar soluciones

Dos pueden funcionar. ¿Cómo distingues?

Candidatura A:

• FlatList con keyExtractor
• AsyncStorage envuelto en service layer
• Maneja errores
• Sin tests
• Código defensivo y organizado

Candidatura B:

• FlatList correcto
• AsyncStorage con wrapper que maneja serialización JSON
• Maneja errores y bordes
• Tests (Jest + AsyncStorage mockeado)
• Código limpio, pequeño, testeable

B gana. No porque la app funcione (ambas), sino porque pensó en mantenibilidad.

Background React web

Si tiene buen React pero ninguna experiencia RN, ajusta:

• Sintaxis y component thinking se trasladan
• Patrones de estado (Redux, Zustand) también
• Patrones de testing en su mayoría

Pero penará con:

• Navegación (React Router ≠ React Navigation)
• Tuning de rendimiento
• Integración nativa
• Restricciones de memoria

Sé más comprensiva con la curva pero evalúa razonamiento que se trasladará.

Implementación

Si evalúas mobile a escala, RN tiene herramientas y trade-offs distintos a iOS o Android nativos. No mezcles. RN merece su pipeline.

Tres fases (cribado en vivo, take-home, walk-through) ~2,5 h candidatura y 1,5 h entrevistadora. Adecuado para mid-level.

Para sénior, añade 30 min de arquitectura: «Construyes una app que pide datos a una API, cachea local y sincroniza offline. ¿Cómo la estructuras? ¿Qué librerías?»

Errores comunes

• No testees frameworks web (React DOM, Next.js)
• No exijas conocer una librería específica de estado
• No hagas la evaluación sobre CSS o estilo
• No asumas que ha usado todas las plataformas (Android, iOS, Web)

Foco en:

• Fundamentos React
• Fundamentos JS
• Patrones específicos RN (FlatList, AsyncStorage, Navigation, Bridge)
• Restricciones de dispositivo y rendimiento

Usa este marco para interpretar resultados con justicia.