Este año 2017 tengo como objetivo conseguir un nuevo trabajo como desarrollador PHP y esto es lo que estoy aprendiendo.
(Al final del artículo hay una actualización)
El proceso comenzó hace ya bastante tiempo. No tanto la búsqueda activa de trabajo, como el hecho de prepararme para hacerlo.
Primeros pasos
Estar en una empresa no tecnológica en la que realizas trabajo de desarrollo como equipo de una sola persona, pero que no es lo único que haces, tiene ventajas y bastantes inconvenientes.
Al trabajar solo, tienes la ventaja de tocar todos los palos del proceso, como preparar y gestionar servidores, dominios, el desarrollo en sí, el diseño, los diversos lenguajes y tecnologías relacionados con la web, etc. La parte buena de todo esto es que todos los aspectos del desarrollo y despliegue de una aplicación web te suenan y eso puede ser un plus a la hora de integrarse en un equipo y comprender las demandas y necesidades de los demás.
Los inconvenientes son bastantes y van a depender mucho de que estés dispuesto a esforzarte en luchar contra la inacción. Me explico. Si en tu empresa te dejan “a tu aire” y no les preocupan conceptos como escalabilidad, mantenibilidad o están constantemente diciéndote que tal vez no deberías estar trabajando en eso, vas a tener poco estímulo para mejorar tu código y, por tanto, tus capacidades como programador. La filosofía de “si funciona, no lo toques” te puede llevar a limitar tu actividad al simple mantenimiento para que las cosas no se rompan y punto.
Y eso es fatal. Yo estuve cerca de ello y paralicé el desarrollo de mi aplicación durante bastante tiempo, y con eso mi evolución profesional.
El descubrimiento
Yo llegué al desarrollo PHP un poco por circunstancias, aunque siempre estuve tocando los temas tecnológicos y programaba desde los 16 años. En un momento dado surgió la necesidad de hacer una aplicación relativamente seria (un sistema de gestión de incidencias para la ISO 9000).
La aplicación funcionó bastante bien para ser un proyecto de bastante mala calidad, pero con el tiempo me pidieron otras aplicaciones y para entonces decidí partir de un framework (que fue CakePHP) y empezar a construir con algo más de visión y de sentido.
Claro que yo tampoco me tomaba el tema de la programación como un aspecto principal de mi trabajo, que estaba más enfocado al tema de la tecnología educativa.
Pero con el tiempo, mi situación en el trabajo empezó a deteriorarse y, poco a poco, mi situación personal también. Eso desembocó en una crisis profunda y varios cambios significativos en mi vida. No fue el trabajo uno de ellos, pero las circunstancias me llevaron, como efecto colateral, a tomar un nuevo interés en la programación. Descubrí todo lo que tenía que ver con principios SOLID, patrones de diseño de software, refactoring, arquitectura limpia, DDD y otros muchos los elementos que constituyen el saber y saber hacer de un desarrollador profesional.
Todo eso cambió mi forma de ver y plantear el trabajo y empecé a experimentar con los conceptos y cambiar mis herramientas. Decidí que si quería tener un futuro como programador tenía que empezar a trabajar como tal.
Cambios
Los cambios conceptuales me llevaron a pensar en cómo reescribir mis aplicaciones actuales y cómo afrontar nuevos proyectos, y aproveché un pequeño encargo para experimentar con todas las nuevas ideas.
Pero también hice otros cambios en mis herramientas de trabajo. Adopté Symfony como pila de componentes para escribir aplicaciones desacopladas de un framework. Obviamente, a estas alturas ya tendría que estar usando Composer para manejar todo esto.
Aunque ya hacía TDD, no acababa de sentirme a gusto con PHPUnit en esa tarea, por lo que decidí probar con PHPSpec y behat, de modo que ahora ambas utilidades forman parte de mi ciclo de desarrollo. Utilizar PHPSpec ha sido una de las cosas que más ha contribuido a mejorar la calidad de mi código en menos tiempo. PHPSpec no solo te ayuda a diseñar tus clases, sino que te enseña a programar mejor.
Por otro lado, ya llevaba un tiempo trabajando con SASS para la escritura de CSS, y finalmente, después de algunos experimentos, aprendí a usar Gulp para la gestión de assets Javascript, CSS y demás.
Llevaba unos años trabajando con TextMate como editor, pero lo jubilé, primero a favor de Atom y desde hace un par de semanas he ido a por el mejor IDE: PHPStorm. No solo es un editor fantástico, sino que también te permite integrar todas estas herramientas en un solo lugar.
Y, además, pasé de usar SVN como gestor de versiones para usar Git y tengo repositorios en GitHub. Y esto me lleva a…
La sorpresa
Buscar ofertas de trabajo atractivo en el entorno cercano no estaba dando muchos resultados. En Galicia la oferta resulta escasa y pobre, lo poco que veía iba enfocado a puestos precarios, mal pagados y con pocas expectativas. La verdad es que tampoco me estaba empleando muy a fondo porque no me sentía preparado.
Hasta que un día apareció un mensaje de correo que decía algo más o menos así:
Hola, hemos visto tu repositorio en GitHub y creemos que te podrías encajar en un puesto en nuestra compañía. Si te interesa escríbenos…
Tuve que leerlo varias veces e investigar un poco. La empresa era una Start-up de Viena llamada Tourradar y la propuesta era del todo seria (y realmente atractiva). Me pidieron hacer una prueba técnica con varios cuestionarios y varios ejercicios de programación. El siguiente paso fue una entrevista a través de Skype, que resultó muy agradable y larga (una hora de conversación).
Finalmente, rechazaron mi candidatura muy amablemente. Pero el daño ya estaba hecho: ahora sabía que podía optar a trabajos de desarrollador PHP de buen nivel a pesar de mi perfil un tanto extraño.
En realidad, la sorpresa no acabó ahí. Algunos días después llegó otro correo de otra empresa de Viena: Kununu, que forma parte Xing, en el que me preguntaban si estaría interesado en un puesto de Front-end developer. Lo más alucinante fue que el contacto se lo habían pasado desde la empresa anterior, Tourradar. Por desgracia, mi experiencia como Front-end developer es pobre y tras un par de correos quedamos en que no encajaría en sus necesidades. Una pena, porque las condiciones eran fantásticas y Viena es una ciudad realmente atractiva para irse a vivir. Y tengo que decir que las personas con las que hablé tuvieron un trato exquisito conmigo.
Aunque estas excelentes oportunidades no cuajaron (hubiera sido un milagro, para qué nos vamos a engañar) sí que tuvieron el efecto de despertarme del letargo. En primer lugar, porque eran señales de que podía estar suficientemente capacitado para buscar trabajo en el campo del desarrollo con ciertas garantías. En segundo lugar, porque me forzaron a ampliar mi campo de búsqueda. Salir de la zona de comodidad (en este caso geográfica) y buscar oportunidades con mejores condiciones y más probabilidad de éxito.
Algunas observaciones
Tengo 48 años y un perfil un tanto extraño como desarrollador PHP, aunque no tan inhabitual como para que los reclutadores técnicos te rechacen. Para algunas ofertas de trabajo esto es un hándicap, tanto la edad como el perfil. Normalmente esto ocurre si la solicitud de empleo la gestiona primero la gente de recursos humanos, a la que le han encargado ciertas características y si no chequean todas las casillas no lo pasan y no siempre están preparados para entender qué puedes aportar y qué no, aunque no tengas mucha experiencia en algún aspecto.
Por lo demás, la edad está dejando de ser un impedimento. Una persona más madura y reflexiva está siendo un factor a favor en las empresas que quieren ir en serio y al largo plazo.
El perfil profesional no es tan problemático tampoco como podría parecer. Partiendo de que tengas un buen nivel (hablo de buenas prácticas, patrones, arquitectura, etc.) el cómo hayas llegado a ello es indiferente. Si tienes oportunidad de mostrar tu trabajo es mucho mejor y para eso no hay nada como una prueba técnica en la que tengas que resolver un problema realista que refleje tu estilo y tus habilidades como programador.
El factor que está siendo más limitante, en mi caso, es el hecho de trabajar en una empresa con pocas necesidades. Tener experiencia con APIs y servicios en la nube, como AWS es un factor importante. Si no has tenido esas necesidades, es posible que sean temas que no hayas tocado. Lo mejor es buscar cualquier excusa para explorarlos y conocerlos.
El proceso de búsqueda
Por un lado, decidí volver a abrir una cuenta en LinkedIn orientada al objetivo de buscar trabajo como desarrollador. En lugar de intentar “ir a por todo” lo centré en ese aspecto y busqué ofertas de empleo en ese ámbito. También sabía qué podía ofrecer y qué no.
Por otro lado, envié algunas solicitudes directas.
En LinkedIn las respuestas han sido relativamente pocas, pero me han proporcionado 3 entrevistas, de momento, de unas 36 solicitudes, con alguna respuesta más. De ellas, al menos una mantiene posibilidades abiertas.
En cuanto a las solicitudes directas, hice dos. Una a una empresa de Viena y otra de Barcelona y de ambas obtuve respuesta. De la primera, en forma de entrevista. No salió. Pero fue también una buena experiencia.
En la segunda, la cosa fue bastante mejor. Un intercambio de correos y una prueba técnica. Y la prueba técnica no solo fue bien (mejor de lo que esperaba), sino que fueron tan amables de explicarme punto por punto la evaluación de lo que había hecho y lo que les había parecido.
Tuvimos una entrevista que fue muy bien y ahí sigo en el proceso :-).
Actualización (10/5/2017)
Desde que escribí la primera versión de este artículo han pasado un montón de cosas.
Lo primero que tengo que contar es que ese proceso prometedor del que hablaba al final no pudo concretarse, pero no te pongas triste todavía.
Por supuesto, he seguido enviando solicitudes, alrededor de 60 en lo que va de año, de ellas más de 50 solo a través de LinkedIn. Algunas dieron lugar a entrevista.
Como conclusiones más interesantes te puedo contar:
Cuando tienes un perfil extraño (quiero decir que no tienes un título relacionado con Informática o no vienes de empresas de desarrollo o tecnológicas) y las ofertas proceden de consultoras de RRHH, o de los departamentos de RRHH de las empresas, es muy difícil que lleguen siquiera a enviarte un email de rechazo. Las ofertas que vienen por consultoras suelen ser casi imposibles para los perfiles raros.
Aun así, es posible que la persona responsable contacte contigo y hasta que te haga una primera entrevista, al menos para averiguar algunos detalles sobre ti. El problema es que muchas veces estas mismas personas tienen que hacer un filtro para localizar los perfiles más prometedores y, ciertamente, si el tuyo se sale de ciertos parámetros es posible que te rechacen. Como me dijo una persona que me entrevistó: “la verdad es que a nosotros nos puedes engañar con las cosas técnicas, así que vamos a hablar de otros asuntos” (y en mi caso, eso sirvió para pasar el filtro :-)).
Si la selección la está llevando a cabo un CTO o una responsable técnica con frecuencia llegarás a una primera entrevista con tal de que tu CV sea decente. Lo bueno de una entrevista con alguien del lado técnico (que probablemente te supervisará en caso de llegar a contratarte) es que si estás realmente capacitado y sabes de lo que hablas, esta persona lo puede percibir y valorar. En una entrevista para una start-up me llegaron a decir que no me aceptaban porque realmente buscaban un ingeniero, pero que estaba preparado para hablar de tú a tú de cuestiones de desarrollo. Un poco agridulce, pero ¡qué le vamos a hacer!.
Un rechazo a este nivel siempre es un poco más útil porque normalmente te ayuda a identificar dónde están tus limitaciones y cómo podrías trabajar para solucionarlas: qué estudiar, qué tecnologías utilizar, etc. En este sentido, he tenido entrevistas de las que he sacado información para tomar decisiones para mi trabajo y para mi autoformación.
Las pruebas técnicas son de lo mejor que te puede pasar, aunque a veces sean chungas de superar. En mi caso, las cuatro pruebas técnicas que hice me dieron paso a la siguiente etapa del proceso de selección.
Las pruebas técnicas pueden incluir ejercicios de código o preguntas técnicas. En dos de las que hice hubo preguntas técnicas. Obviamente puedes buscar respuestas en Internet para responderlas, pero no puedes limitarte a un copia-pega ciego. Hay que ser una persona honesta y realista.
- Si un tema te supera realmente porque no sabes ni por dónde empezar, mejor reconócelo y no contestes. No te creas que se selecciona a quien lo contesta todo, sino al que demuestra que entiende de lo que está hablando.
- Si no tienes experiencia en un asunto, pero entiendes de qué va y puedes explicarlo en tus propias palabras, con un poco de ayuda de algún lugar de referencia, hazlo, pero indica que no has trabajado con ello (tal vez nunca has tenido necesidad, pero que puedas hablar de ello indica por una parte interés, y por otra, que posiblemente con un poco de trabajo te pongas al día).
- Y si el tema lo dominas y tienes experiencia, recurre a tus propios ejemplos y explicaciones.
Como me dijeron en mi última entrevista: “La única respuesta incorrecta es que me digas que no lo sabes y no te interesa saberlo”.
Los ejercicios de código varían entre los problemas de algoritmos “geek style” a la realización de microproyectos para resolver un problema.
De los primeros, he tenido problemas relativamente sencillos, orientados a descubrir si tienes ciertos recursos en el lenguaje y tu forma de pensar a la hora de resolverlos indica que entiendes el problema y eres capaz de articular una solución eficaz.
En otro caso, los problemas fueron realmente bastante fastidiados y encima con limitación de tiempo. Si saqué un 5 fue raspado. Al día siguiente me bajé un libro de algoritmos y estructuras de datos para refrescar.
Aquí cuenta tanto que tengas una cierta formación en algoritmos estructuras de datos, para no reinventar ruedas, así como identificar los elementos del problema y representarlo adecuadamente. Obviamente, puedes destacar si haces usos inteligentes de los recursos del lenguaje, aquí el ser capaz de utilizar one liners o una función o estructura que encaje en el problema, pero que es poco conocida es un plus.
Lo que me gusta es cuando hay que hacer miniproyectos de programación orientada a objetos. Te plantean un problema real y te piden que prepares una solución.
En los dos casos que tuve que hacer algo de esto, preparé un proyecto organizado con una arquitectura tipo hexagonal, y fui modelando clases con PHPSpec (o PHPUnit, si haces TDD tienes mucho ganado tanto para realizar un trabajo digno como para que tengas posibilidades de ser contratado).
Aquí es donde puedes brillar y dónde el reclutador puede sacar la información más útil. Es dónde se ve si sabes segregar responsabilidades, si tu código es capaz de expresar tu intención, si manejas conceptos de arquitectura, etc. Es el punto clave que te puede dar acceso a un nuevo trabajo.
Pero bueno, ¿te contrataron o no?
Todavía no, pero no pierdo la esperanza.
Como comenté antes, la oferta con más posibilidades finalmente no pudo ser (por falta de medios, que no por acuerdo entre ambas partes).
Sin embargo, otras opciones seguían vivas.
En una de ellas el proceso comenzó con una prueba técnica de algoritmos con tiempo limitado (la del 5 raspado, si es que llegué al cinco).
Lo que no sabía era que había una segunda prueba, en la que tenía que realizar un pequeño proyecto. Así que me cogió del todo por sorpresa que me llegasen las instrucciones para realizarla. Tenía dos días y me lo tomé con calma, lo hice despacio y con buena letra.
Unos días después, apareció un mensaje en mi correo que se puede resumir así: “has superado las pruebas técnicas y vamos a tener una entrevista de RRHH contigo”.
La entrevista fue bien y muy agradable. Esa fue la persona que me dijo que no íbamos a hablar de cuestiones técnicas. Hablamos un poquito de mi perfil, de mis posibilidades y me explicó las condiciones. Solo voy a decir que son fantabulosas.
La respuesta fue que en unos días sabría algo.
La verdad es que había asumido que no iba a seguir en el proceso (la experiencia de otras solicitudes fue esa), así que cuando tras un par de días o así me llegó un mensaje concertando una entrevista con los responsables técnicos me llevé una nueva sorpresa y un poco de susto: iba a hablar con miembros de un equipo de desarrollo de altísimo nivel en una empresa muy importante en su sector.
La nueva entrevista resultó muy bien. Para empezar, me sorprendió del todo el tipo de preguntas, más centradas en qué principios de desarrollo manejo que en las tecnologías específicas que haya tocado. Y eso para mí fue una ventaja, porque si bien reconozco que puedo ser poco competitivo a la hora de tener experiencia con ciertas tecnologías específicas, en cambio me considero muy competente en esos aspectos un poco más “filosóficos”, pero que en esta entrevista se valoraban.
Tuve la oportunidad de explicarme, poner mis propios ejemplos, etc. También reconocí mis limitaciones (no quiero engañar a nadie, empezando por mí mismo), aunque realmente no parecían tener mucha importancia para la persona que me entrevistó.
¿El resultado? Pues de momento es una incógnita, aunque he tenido una ayuda inesperada que puede hacer subir mis puntos en este proceso.
Quizás no llegue a conseguir este puesto en concreto, pero el camino, con sus altibajos, está siendo una buena experiencia en muchos sentidos. Obviamente hay momentos de desánimo, los rechazos no gustan a nadie, y de cierto miedo pensar que igual no estoy a la altura para tal o cual entrevista (algo que se va reduciendo con el tiempo).
También los hay muy buenos. La mayoría de las entrevistas que he tenido han sido muy gratificantes por las personas con las que traté y porque me han ayudado a mejorar mi preparación, me han dado pistas para trabajar y aprender.
Así que, la cosa sigue en el aire. De cualquier forma, espero que esta historia te pueda servir.