#4 Tienes que mirar, por ejemplo, 100 ofertas y de esas 100 ofertas estudiarte lo que más coincide en ellas. Si, por ejemplo, Docker coincide en la mayoría, pues empieza por ahí.
Por ejemplo, yo me di cuenta que cada vez, si no todas, en las ofertas que leía se pedía TDD (Desarrollo dirigido por Test). Pues me puse en su día a estudiar a verme eso. También pues otras tecnologías.
También pienso una cosa. No me gustan las empresas que se centran mucho y dan mucha importancia a que sepas X tecnologías ahí como sin fuera el ABC. Voy a explicar esto... Hay empresas que te exigen, por ejemplo, saber X framerwork como si fuera el padre nuestro. Lo veo loable porque ellos manejarán ahí su negocio con ese framework y les será importantísimo. Sin embargo, yo intentaría no buscar trabajo en esas empresas, a no ser que fuera imprescindible o porque esté en paro.
Las mejores empresas que me he encontrado, las de calidad y no las chapuzas, son las que se centran y piden aplicar buenos principios de desarrollo ya sea en programación orientadas a objetos, funcional, etc. Realizar un código bueno, sin chapuzas, teniendo una capacidad analítica y haciendo las cosas lo mejor posible, hacer los tests, aplicar principios SOLID o arquitecturas oportunas, etc. Es decir, centrarse en ser bueno analizando y desarrollando código. Por ejemplo, una pregunta clave para mi en una entrevista que haría es "¿Qué opinas del uso de la herencia?". Si el tío me responde "La herencia es lo mejor, la uso siempre"... pues yo no cogería a ese a persona. Si me dice algo "Bueno, hay casos que puede ser útil, aunque casos muy concretos. Podemos hacer uso de la composición en vez la herencia", pues ya para mi gana +1. Decir que soy un poco anti-herencia, aunque eso es otro debate.
Pues eso, las ofertas de trabajo que mejor he visto te piden 3-4 cosas y no una pila de tecnologías del a leche. Yo hace tiempo que no hago uso de la librería de Bases de datos de ROOM de Android ahora mismo... si mañana me pidieran hacer algo con ella pues tendría que vérmela y echar un rato para recordar como funciona. Igual que hace tiempo que no me encargo de hacer peticiones api y ahora tendría que volver a verme Retrofit. Simplemente sé que está ahí esa herramienta y que cuando me haga falta la usaré. Eso es lo importante. Saber qué existen y entender de qué van.
Lo que sí veo importante es más saber programar bien. Saber que si a un método le tienes que pasar 5 parámetros es que estás haciendo algo que puede ser un poco chapuza o que si haces algo que luego cuesta mucho hacer un test o mockear mil cosas para conseguir hacer un test pues estás haciendo algo deberías hacer diferente.
Mi consejo es que seas un buen desarrollador, que estudies arquitecturas, principios, paradigmas de programación, aprendas el lenguaje que estés usando (conozco gente que sigue haciendo en Kotlin el clásico bucle FOR para buscar en una lista los números pares y quedarse con ellos), aprender buenas prácticas, etc.
Que sí, que para buscar un trabajo de Android debes conocer el framework de Android, está claro, y si vas a hacer backend pues lo que toque en su momento. Pero no croe que haya que obsesionarse con sabérselo todo como si fuera el padre nuestro, respecto a tecnologías... que la diferencia está en hacerse preguntas tipo:
¿Cómo separo la capa de la peristencia de la lógica de la app? ¿Merece a pena separarlas? ¿Tengo que hacer un patrón adapter si voy a usar una librería de terceros para encapsularla en una interfaz y no meterla a lo loco en la aplicación? ¿Debería crear mapeadores entre los datos que recojo de una petición y luego el modelo de datos de mi aplicación para no usar las miasma clases para las 2 cosas y tenerlos separados? ¿Igualmente debería hacer lo mismo para la clases que simplemente va a usar la vista?
Esto es una opinión abierta que hago aprovechando el tema. No quiero decir que una empresa no pueda estar buscando el tío más experto en X tecnologías y no sea buen sitio para trabajar, pero si quiero decir que no nos tenemos que obsesionar tanto con la lista de mil tecnologías que a veces nos piden. A mi en una entrevista de trabajo me preguntaron "¿Te consideras rápido o lento para programar?". Yo le dije "mira, yo tengo capacidad analítica y me gusta pensar las cosas... si me vas a pedir que escriba código a 100 por hora... no soy quien buscas. Si quieres gente que piense las cosas y no agache la cabeza y empiece a picar código sin mas, entonces ese soy yo".
Para terminar, ya corto el rollo, a mi me gustó mucho cuando descubrí este canal:
https://codely.tv
En youtube están aquí: https://www.youtube.com/CodelyTV
Creo que tienen buenos cursos orientados a lo que te comento. Cursos que no se centran en saber poner una librería si no en hacerte buen programador. Échale un ojo a sus vídeos, sigue su canal y luego a los cursos. Creo que valen aunque seas backend, frontend, móvil o uses el lenguaje X o Y. Bueno, en general, algunos son más específicos. Te recomiendo ir viendo sus vídeos gratuitos de youtube y verás lo que te quiero transmitir en mi post.
En fin, para terminar pondré el ejemplo que siempre digo. Tú conoces GIT y lo importante no es ser el típico que se sabe los comandos de memoria. Lo important es saber lo que ofrece. Qué tienes el Merge y el Rebase. Que tienes luego el stash y el pop y cómo usar eso, etc. Luego usas un programa tipo Gitkraken y no vas a tener que estar con comandos y es mucho más cómodo. Si un día necesitas hacerlo sin interfaz visual pues irás a buscar cómo hacer el stash por comando y punto... El tema es saber lo qué tienes y para qué sirve. Pues eso igual con lo demás.
Céntrate en desarrollo TDD, arquitectura, buenas prácticas... etc. Las buenas empresas es lo que quieren, al fin y al cabo. Las tecnologías las irás aprendiendo por inercia, aunque ya sepas la base de ellas.
Importante: Igual que en una entrevista de trabajo a ti te preguntan (hablo de cuando ya tienes un trabajo y quieres cambiar, no de si estás en paro que entonces entiendo que te interesa tener trabajo cuanto antes) cosas sobre ti y conocimientos, o lo que sea. Es bueno que tú también preguntes a ellos sobre qué metodologías usan, por el equipo y compañeros que estarán contigo, cómo se llevan a cabo los proyectos, que se está usando en la empresa (no sé de backend y eso pero por ejemplo en Android yo siempre pregunto si están usando MVP, MVVM, otro... si siguen usando Java o Kotlin o si están migrando...), cómo se organiza el trabajo diario (reuniones, análisis de las tareas a hacer, quién y cómo se establece el tiempo para hacer X tarea, etc. Si ves que todo esto les suena un poco a chino pues entonces plantéate si de verdad quieres trabajar ahí. Es decir, busca también trabajos que te permitan a ti crecer como desarrollador y no solo sea aporrear el teclado y que luego la empresa no tenga una filosofía de querer hacer que tú sigas formándote y mejorando y que solo le interesa que saques proyectos como churros aunque sea eso ahí como quien pone un andamio con palos y cañas que se cae en cuanto viene el primer soplo de viento.
