Scorecard de entrevista para Desarrollador Mobile
Un scorecard estructurado para entrevistar a un Desarrollador Mobile: seis competencias con pesos, qué es realmente un 1 y qué es un 5, y preguntas que sacan evidencia en vez de opiniones. Imprimilo o copialo a tu ATS.
El scorecard para Desarrollador Mobile
| Competencia | Peso | Puntaje 1 — cómo se ve | Puntaje 5 — cómo se ve |
|---|---|---|---|
| Ciclo de vida de la plataforma y manejo de estado Si la persona maneja lo que el sistema operativo le hace a la app — pasar a segundo plano, morir, restaurarse — y no solo el camino feliz. | 20% | Describe pantallas y navegación pero nunca enfrentó una app cerrada en segundo plano que perdía lo que el usuario había escrito. | Explica dónde persiste el estado, qué sobrevive a la muerte del proceso y un bug que solo se reproducía cuando el sistema liberaba memoria. |
| Responsabilidad sobre el release y la revisión de la store Si la persona publicó en una store de punta a punta — versionado, firma, rollout gradual, rechazo — o le pasó los builds a otro equipo. | 18% | Dice que otro equipo publica la app y no puede describir qué pasa entre una rama mergeada y un usuario instalando la actualización. | Describe su checklist de release, una entrega rechazada y por qué, y cómo frenó un rollout después de una señal fea de crashes. |
| Comportamiento offline y sincronización de datos Cómo se comporta la app con conexión mala o nula, lo que define cuánto del producto funciona fuera de una red de oficina. | 18% | Trata la falla de red como un cartel de error y no consideró qué pasa con una acción que el usuario hizo estando sin conexión. | Describe qué se encola, qué se reintenta, cómo se resuelven los conflictos al reconectar y una pérdida de datos que ese patrón evitó. |
| Performance en dispositivos reales Si el tiempo de arranque, la memoria y la batería se miden en hardware que la gente realmente usa, y no en un simulador o un teléfono de gama alta. | 16% | Dice que la app se siente rápida en su propio equipo y nunca perfiló tiempo de arranque ni memoria en un dispositivo de gama baja. | Nombra la métrica que siguió, la gama de dispositivo donde probó, el cambio que hizo y la mejora medida después de aplicarlo. |
| Triage de crashes con telemetría de producción Si la persona usa reportes de crashes y errores para encontrar causas reales, dado que los bugs de mobile rara vez se reproducen en su máquina. | 16% | Espera reportes de usuarios o un caso reproducible, y describe los crashes como problemas en ciertos dispositivos, sin más detalle. | Lee un stack trace contra la apertura por dispositivo y versión de sistema, enuncia la hipótesis que sostuvo y muestra la tasa de crashes antes y después. |
| UI adaptable y accesibilidad Si la interfaz aguanta distintos tamaños de pantalla, escalado de fuente del sistema y tecnología asistiva, y no solo el dispositivo del diseño. | 12% | Construye contra un solo tamaño de pantalla y trata la rotura de layout en otros dispositivos como un problema de diseño para reportar a otros. | Describe pruebas con fuentes del sistema ampliadas y lector de pantalla, y nombra un layout que rehízo porque se rompía en esas condiciones. |
Los pesos suman 100. Acordalos antes de la primera entrevista, no después: ajustar pesos cuando ya hay puntajes es la forma en que un panel justifica a su favorito.
Preguntas que sacan evidencia
Cada una pide algo que ya pasó, con suficiente detalle como para verificarlo. Las hipotéticas premian el ensayo, no la trayectoria.
- Contame un bug que solo aparecía en dispositivos reales en producción. Qué mostraban los datos de crashes y cómo confirmaste la causa.
- Contame tu último release, desde el código mergeado hasta el usuario instalando. Qué tiene tu checklist y cuándo fue la última vez que frenaste un rollout.
- Describí cómo se comporta tu app cuando se corta la conexión en medio de una acción. Qué encolaste o reintentaste y qué conflicto generó al reconectar.
- Qué número de performance mejoraste — arranque, memoria, batería. En qué dispositivo lo mediste y cuánto era antes y cuánto después.
- Mencioná una pantalla que tuviste que rehacer tras probarla con fuentes grandes del sistema o un lector de pantalla. Qué se rompió y qué cambiaste.
Señales de alarma
- Publicó apps durante años pero nunca vio una entrega rechazada o demorada por la store.
- Describe los crashes como problemas de ciertos dispositivos sin haber leído nunca un stack trace de producción.
- Prueba solo en el teléfono más nuevo que tiene y considera el hardware más viejo fuera de alcance.
- Nombra frameworks con soltura pero no puede explicar qué pasa cuando el sistema mata la app.
Cómo usar este scorecard
- Acordá los pesos con el panel antes de que alguien entreviste, y dejalos por escrito.
- Cada entrevistador puntúa todas las competencias por separado, con una nota que cite lo que el candidato dijo textualmente.
- Comparen los puntajes antes de discutirlos. Discutir primero ancla al panel en quien habla más fuerte.
Armar un scorecard a medida → · Cadena booleana para buscar Desarrollador Mobile →
Preguntas frecuentes
¿Qué debe incluir un scorecard de entrevista para un desarrollador mobile?
Competencias ponderadas propias de mobile y no de ingeniería en general: ciclo de vida de la plataforma y manejo de estado, responsabilidad sobre el release y la revisión de la store, comportamiento offline y sincronización, performance en dispositivos reales, triage de crashes con telemetría y UI adaptable con accesibilidad. El ciclo de vida y el release deben pesar más, porque es donde mobile más se diferencia del trabajo web y donde una mala contratación se ve públicamente en las reseñas.
¿Cómo evaluar habilidades mobile sin una prueba de código en vivo?
Preguntá por evidencia de producción que no se pueda inventar: cuál era su tasa de crashes y cómo la movió, qué le enseñó un rechazo de la store, qué pasa con una acción que el usuario hizo sin conexión. Todo eso requiere haber publicado y haber observado una app en manos de usuarios, algo que ningún tutorial produce.
¿Conviene contratar un desarrollador nativo o cross-platform?
Definilo desde tu roadmap antes de empezar a entrevistar, no durante. Si la app necesita integración profunda con la plataforma, priorizá profundidad nativa; si dos plataformas deben avanzar a la velocidad de un solo equipo, la experiencia cross-platform pesa más. En cualquier caso puntuá las mismas competencias — ciclo de vida, release, offline, performance — porque esas preguntas de criterio no cambian con el framework, y mantené la evidencia citada junto a cada calificación.
Cuando lo que está en juego es una contratación real, usá evidencia
Estas herramientas son heurísticas rápidas. Verdict lee el CV contra tu descripción de puesto y puntúa seis dimensiones con citas textuales como evidencia — un documento de contratación que podés defender.