Cómo Superar con Éxito las Entrevistas Técnicas de Android

Crecer dentro de una empresa de software implica entender que el cliente siempre tiene la razón (aunque no siempre sea así). Muchas decisiones están influenciadas por temas de negocio y lo que sea mejor para el crecimiento de la empresa. Pero, ¿qué me diferencia de los demás desarrolladores de Android que aspiran a entrar en la empresa de mis sueños? Rompe el paradigma; no seas solo técnico, destaca en la entrevista con pequeños detalles. ¿Cómo hacerlo? Te pongo un ejemplo:

Imagina que Dean quiere entrar a la empresa donde trabajas, y tú coordinas la entrevista. Al escuchar a Dean animadamente hablar de lo buena que es la empresa y del ambiente cool, sus nervios disminuyen (¡aunque siguen ahí!). No todos los entrevistadores son animados, y a veces los nervios pueden jugar malas pasadas, pero así es como se crece en el mundo tecnológico, ganando experiencia con cada paso que das.

Una vez inicia la entrevista técnica con la tecnología que sea uno no se espera las preguntas de universidad que los profesores de programación nos enseñaban a cada rato sobre, cuales son los 4 principios de la OOP?, Herencia, Polimorfismo, Encapsulamiento, cual me falta? estee…ah si, Abstracción (suele suceder incluso que se te olviden esos pequeños detalles), uno por defecto desde la universidad hasta la actualidad tiene arraigado esas enseñanzas pero sólo están orientados a la práctica pero no a la teoría (lo cual no es malo, pero es mejor en esos casos colocar ejemplos prácticos donde apliques ese conocimiento que tienes aún sino sabes el concepto que sacas de wikipedia para explicar alguno de los principios), vale mas una definición que saques al momento de alguna experiencia que tuviste y lo reflejes en uno de los principios de la OOP, ahi está un pequeño factor diferencial, ahora un caso real de una entrevista que hice:

Volvamos con Dean, cuando le hice la pregunta de que es Herencia, el me dio un ejemplo que usualmente seria con las figuras geométricas, que si el triangulo, circulo, cuadrado u otro ejemplo clásico como animal y persona, pero en este caso no fue así, fue de un videojuego en específico, fue sobre Elden Ring y yo que? wtf? (lo gracioso, es que estuve jugando una semana completa ese juego con mi hermano y me recordaba los jefes imposibles de ese juego), la verdad la entrevista fue muy divertida por nada mas ese pequeño ejemplo y ya con eso me di cuenta de que el resto de la entrevista iba a ser duradera.

Puede darse el caso de que hay entrevistadores que te pidan que seas breve y conciso con las respuestas que das pero cuando lo haces de esa forma la persona entrevistada con los nervios solo te responderá como ejemplo:

Que es una Activity?

Es donde muestro la UI de una Aplicación…y ya, hasta cierto punto tu le darias el ok a esa resuesta?, no verdad?, continuarias a la siguiente pregunta..

Pero cuando te extiendes luego de que te digan que seas breve y ahi denotas que tienes seguridad al hablar, tienes confianza de que lo que dices es lo correcto porque tienes la experiencia no sólo por lo que haces en tu dia a dia como desarrollador sino porque también lo pones en práctica a partir de proyectos pequeños que luego subes a github, entiendes como usar las herramientas que tienes a tu disposición y en como funcionan cada una de ellas.

Antes de querer entrar a una entrevista, hazte estas preguntas, quiero cambiar mi trabajo actual?, no me siento a gusto?, me siento atascado?, quiero crecer?.

Ahora si apuntas a un puesto mas grande con mejores beneficios y mejor salario, hazte la idea de que la entrevista será aún mas retadora y no es solo tener claro que es una Activity (para el caso de entrevistas en Android), eso es sólo un abre bocas de lo que te puede esperar y como mínimo preguntas de ese tipo como:

• Que es un Fragment?
• Dime todos los métodos del ciclo de vida de una actividad (no sólo los nombres da ejemplos de casos de uso)
• Que métodos del ciclo de vida del Fragment no forman parte del ciclo de vida de una Activity?
• Serializable vs Parcelable (quien es mas rápido y porque?)
• Como comunicas 2 módulos de una app sin agregar la dependencia en el gradle?
• Que es ANR?

Y así un sin fin de preguntas que pueden surgir a la hora de la entrevista, donde el entrevistador a partir de como vayas respondiendo querrá ir complicándotela mas porque la idea es que no logres responder todo(?), si respondes todo felicitaciones, te ganaste una galleta, si sientes que fallas una o dos que fueron realmente complicadas no tienes porque sentirte mal no quiere decir que fallaste toda la entrevista (aunque por dentro te carcoma y tu ego haya sido herido), todo desarrollador tiene su ego eso incluso aplica al entrevistador quien se siente con el poder de decidir si apruebas o no y de ahi la presión extra que tiene el entrevistado porque al fallar una es pensar que no eres bueno y no es así, ahora si fallas al explicar que es una Activity, Fragment, y los ciclos de vida y como funciona cada uno, mas adelante se te va a complicar mucho mas la entrevista.

No todo gira entorno a Android Jetpack de Google, Android es mucho mas que sólo MVVM + LiveData + Navigation + Paging + Room + Coroutines

Android es más que solo Jetpack; es entender Context, Activity, Fragment, backstack, patrones de diseño, Intents, Bundles, y mucho más. Y ahora, con las novedades de Compose y KMM, el campo sigue expandiéndose (pero esa será otra historia).

Una vez te sientas en el nivel que tienes claro como funciona cada componente, cada API y que es lo que hace, ve más allá, antes de entrar a la empresa en la que estoy fallé varias entrevistas, todo fue porque no iba más allá, “under the hood”, ya que sólo me limitaba a dar el concepto sacado de un libro de Programación básica en Android.

Entender como funciona como si se tuviese que crear desde 0, siempre te dirán el famoso dicho de “no reinventes la rueda” y es MUY cierto, lo que no tienes que hacer nada de 0 pero tienes que entender como funciona para que tengas un pensamiento mas allá del concepto que sacaste del libro o de la guía de Google, ya que te ayudará a pensar mas como un Arquitecto y no como un desarrollador más.

Después de muchas entrevistas, tanto fallidas como exitosas, he aprendido que es crucial entender no solo los conceptos básicos sino también profundizar más allá de ellos. Si una entrevista no va como esperas, no es el fin del mundo. Anota lo que aprendiste, pide retroalimentación, y usa eso para seguir creciendo en tu campo.

Sin más que agregar, ¡éxito en tus próximas entrevistas! Sé que lo lograrás, y cuando lo hagas, no dudes en dejar un comentario contando tu logro.

Hasta la próxima.