Saltar al contenido
Aethel

Entrevista con IA para desarrolladores iOS y Android

Actualizado en noviembre de 2026

Las entrevistas de desarrollo móvil preguntan por cosas que en la web casi no existen: lanzamientos que no se pueden revertir en un minuto, teléfonos que usted no controla, redes que se cortan y fallos que solo ve en los reportes. Una entrevista con IA va a buscar cómo encontró un fallo, cómo lanzó un cambio riesgoso, cómo sincronizó datos sin conexión y cómo hizo que la app se sintiera rápida en un teléfono de gama baja. Aquí están las preguntas, dos ejemplos resueltos y los hábitos que debilitan las respuestas.

Practicar preguntas de desarrollo móvil gratis

Esta guía y la práctica para su rol están en español. La inscripción y la página de resultados de Aethel están en inglés, y la entrevista la puede hacer en español: lo elige justo antes de empezar.

Qué preguntan las entrevistas con IA a desarrolladores iOS y Android

  1. Un fallo que no podía reproducir

    “Cuénteme de un fallo de la app que al principio no podía reproducir. ¿Cómo encontró la causa?”

    Lo que se escucha: Reportes de fallos y sus rastros, el patrón de equipo o de sistema operativo, y cómo confirmó el arreglo.

  2. Lanzamientos graduales

    “¿Cómo lanzó un cambio riesgoso en una app móvil?”

    Lo que se escucha: Un lanzamiento por porcentajes, banderas remotas, un interruptor para apagarlo y qué métricas miró.

  3. Sin conexión y sincronización

    “Describa cómo manejaba su app la falta de conexión y la sincronización posterior.”

    Lo que se escucha: Reglas para los conflictos, qué veía el usuario y un error real que el diseño causó o evitó.

  4. Velocidad en teléfonos reales

    “¿Qué hacía lenta su app en teléfonos de gama baja, y qué cambió?”

    Lo que se escucha: Tiempo de arranque, cuadros perdidos o memoria, medidos en un modelo concreto.

  5. Cambios de la plataforma

    “¿Cómo manejó una versión nueva del sistema operativo o una política de la tienda que rompió algo?”

    Lo que se escucha: Con cuánta anticipación probó, qué se rompió y a cuántos usuarios llegó.

  6. Versiones viejas de la app

    “¿Cómo cambió una API mientras todavía se usaban versiones viejas de la app?”

    Lo que se escucha: Seguimiento de versiones, actualizaciones forzadas o sugeridas, y cuánto vivieron las versiones viejas.

  7. Nativo o multiplataforma

    “Cuénteme de una decisión entre código nativo y un framework multiplataforma.”

    Lo que se escucha: El equipo, las funcionalidades, el costo y qué volvería a elegir.

Ejemplo resuelto: una app que se cerraba en teléfonos con poca memoria

Cada ejemplo muestra una respuesta débil y una fuerte a la misma pregunta. Las líneas “Con las reglas de Aethel” aplican las reglas de calificación publicadas de Aethel, un ejemplo concreto de cómo una entrevista con IA puede evaluar una respuesta.

Ejemplo inventadoEscrito por Aethel para mostrar la diferencia. No es una persona real y la IA no lo calificó.

Pregunta: “Cuénteme de un fallo de la app que al principio no podía reproducir. ¿Cómo encontró la causa?”

Respuesta débil

“Había un error que no podíamos reproducir, así que revisé los logs de fallos, encontré el problema y lo arreglé. Era un tema de memoria. Después del arreglo dejó de pasar y la app quedó más estable.”

Por qué es débil: Se salta justo lo que hacía difícil el caso. No hay app, ni cantidad de usuarios afectados, ni patrón de equipos, y "un tema de memoria" es un síntoma, no una causa. "Más estable" no es un resultado.

Con las reglas de Aethel: Situación 1, razonamiento 1, resultado 1: 3 de 8 puntos, y sin un caso específico el área llega como máximo a 60 en la escala de Aethel.

Respuesta fuerte

“Trabajaba en la app Android de un servicio de domicilios en Colombia, con unos 900.000 usuarios al mes, muchos con teléfonos de gama baja. Después de rediseñar el menú de los restaurantes, los usuarios sin fallos bajaron de 99,5 a 98,1 por ciento, y en los teléfonos del equipo no pasaba nada. Los reportes mostraban que casi todos los cierres eran por falta de memoria, en equipos con 2 gigabytes de RAM y siempre en menús con más de 60 platos. El rediseño cargaba cada foto a resolución completa, unas 30 veces más píxeles de los que se mostraban. Conseguí dos teléfonos usados del modelo más afectado para reproducirlo, cambié la carga de imágenes para pedirle al servidor el tamaño exacto de cada miniatura y liberé las que salían de la pantalla. Consideré quitar las fotos de los menús largos, que se arreglaba en un día, pero los restaurantes las pedían y los pedidos con foto se concretaban más. En la versión siguiente, los usuarios sin fallos volvieron a 99,6 por ciento y el menú pasó a cargar en 1,2 segundos en lugar de 3,1 en ese modelo.”

Por qué es fuerte: Convierte "no lo podía reproducir" en un patrón: un tipo de equipo, una cantidad de memoria y un tipo de menú. La causa es el mecanismo real, la reproducción es deliberada y el arreglo rápido se descarta por lo que les costaba a los restaurantes. El resultado se mide dos veces: estabilidad y velocidad en el equipo afectado.

Con las reglas de Aethel: Situación 2, razonamiento 2, resultado 2: 6 de 8 puntos, que en la escala fija de Aethel son 87. Un puntaje real puede ser distinto.

Lo que viene después: Repregunta probable: ¿cómo evitó que otro cambio volviera a cargar imágenes gigantes? Una prueba automática en un equipo de gama baja, o un límite de tamaño en el servidor, responde la pregunta.

Ejemplo resuelto: precios por peso con versiones viejas de la app en uso

Ejemplo inventadoEscrito por Aethel para mostrar la diferencia. No es una persona real y la IA no lo calificó.

Pregunta: “¿Cómo cambió una API mientras todavía se usaban versiones viejas de la app?”

Respuesta débil

“Cuando cambiamos la API, pusimos versiones en las rutas para no romper nada. Les pedimos a los usuarios que actualizaran la app y después de un tiempo apagamos la versión vieja. Salió todo bien.”

Por qué es débil: Describe una práctica general, no un cambio concreto. No dice qué cambió en la API, cuántos usuarios seguían en versiones viejas, cómo se les pidió actualizar ni cómo decidió cuándo apagar lo viejo. "Salió todo bien" no se puede revisar.

Con las reglas de Aethel: Situación 0, razonamiento 1, resultado 0: 1 de 8 puntos, y sin un caso específico el área llega como máximo a 60 en la escala de Aethel.

Respuesta fuerte

“En la app de un supermercado en Perú, con unos 350.000 clientes al mes, teníamos que cambiar el cálculo del carrito para aceptar precios por peso, como frutas y carnes, y la API vieja solo entendía unidades. El 22 por ciento de los pedidos venía de versiones de la app con más de seis meses, sobre todo en teléfonos que no se actualizan solos. Dejé la ruta vieja funcionando con una traducción: a la app vieja, los productos por peso se le mostraban como paquetes de 500 gramos, que era como ya se vendían en las tiendas. Cada respuesta registraba la versión de la app, y con eso armé un tablero semanal. Evalué forzar la actualización desde el primer día, que simplificaba el código, pero para un cliente con poco espacio en el teléfono una actualización obligatoria podía ser una compra perdida. A los dos meses mostramos un aviso suave para actualizar, y cuando las versiones viejas bajaron al 3 por ciento de los pedidos, forzamos la actualización. En todo ese tiempo la API no rechazó ningún pedido, y la venta de productos por peso creció un 30 por ciento.”

Por qué es fuerte: Nombra el cambio y por qué rompía a las versiones viejas, mide cuántos usuarios estaban en riesgo y diseña una traducción que los mantiene funcionando. Pesa la actualización forzada contra lo que les costaba a los clientes, decide con un tablero en lugar de una fecha arbitraria y el resultado incluye el cierre del camino viejo.

Con las reglas de Aethel: Situación 2, razonamiento 2, resultado 2: 6 de 8 puntos, que en la escala fija de Aethel son 87. Un puntaje real puede ser distinto.

Lo que viene después: Repregunta probable: ¿cómo comprobaba que la ruta vieja seguía funcionando mientras cambiaba la nueva? Nombre las pruebas de contrato o las versiones viejas que mantenía instaladas para probar.

Errores comunes en las respuestas de desarrollo móvil

  • Tratar un lanzamiento móvil como un despliegue web. Una app no se revierte en un minuto. Diga cómo las banderas remotas, los lanzamientos por porcentajes o la configuración desde el servidor ocuparon ese lugar.
  • Una tasa de fallos sin contexto. Diga usuarios o sesiones sin fallos, en qué plataforma y en qué versiones, antes y después.
  • Olvidar las versiones viejas. Algunos usuarios nunca actualizan. Diga cómo su cambio de API los mantuvo funcionando, o cómo los llevó a actualizar.
  • Probar solo en su propio teléfono. Si buena parte de sus usuarios tiene equipos de gama baja, dígalo y nombre en cuáles probó, o qué datos usó para elegirlos.
  • Dejar la falta de conexión para el final. Si su app puede perder la señal, describa qué veía el usuario y cómo se resolvían los cambios en conflicto.
  • Debatir frameworks sin una decisión. Nativo contra multiplataforma solo interesa con el tamaño de su equipo, sus funcionalidades y lo que volvería a elegir.

Números que conviene tener a mano

Un entrevistador ubica un caso por sus números. Búsquelos para cada uno de sus casos antes de la entrevista; redondeados sirven:

  • Usuarios o sesiones sin fallos, por plataforma, antes y después de un arreglo
  • Tiempo de arranque en frío en un equipo de gama baja que pueda nombrar
  • El porcentaje de usuarios en las versiones más viejas de la app y del sistema operativo que todavía soportaba
  • El tamaño de descarga de la app, y cuánto lo cambió un lanzamiento
  • Los pasos de un lanzamiento gradual y cuánto duró cada uno
  • Usuarios activos al mes, y el porcentaje en cada plataforma

Practique gratis

Elija un nivel, escriba una respuesta a cada pregunta y lea la revisión rápida después de cada una. Es gratis, no necesita cuenta, no se guarda nada y no es un puntaje.

Preguntas de desarrolladores móviles

¿Una entrevista con IA me va a preguntar de iOS y de Android?

Normalmente sigue sus respuestas. Diga al principio en qué plataformas ha publicado y elija casos de la que mejor conoce. Si trabajó en las dos, un caso en que se comportaron distinto es muy buen material.

¿Conviene nombrar Swift, Kotlin, Flutter o React Native?

Cuando la elección importa para la historia, como un error que solo existía de un lado del puente o una funcionalidad que el framework no permitía. Si no, la decisión y el resultado importan más que el lenguaje.

Publico apps por mi cuenta. ¿Eso cuenta?

Sí. Los números de las tiendas son reales: descargas, calificaciones, tasa de fallos, reseñas que le cambiaron los planes. Diga qué decidió y cómo lo midió, igual que en una empresa.

¿Cómo cuento un rechazo de la tienda de aplicaciones?

Como un incidente: qué señaló la revisión, qué cambió usted, cuánto tiempo le costó y qué hace ahora para evitarlo. Un rechazo del que aprendió es un buen caso.

Más guías

In English: AI interview prep for mobile developers