Cómo conseguí un trabajo de desarrollador de pila completa sin un título técnico o experiencia laboral

Hace seis meses, obtuve mi primer trabajo de desarrollador como desarrollador web de pila completa para una startup. No tenía experiencia laboral relevante, ningún título técnico y ni siquiera un año de experiencia activa en codificación. Y, sin embargo, logré conseguir la oferta de mis sueños, y hoy puedo, por primera vez en mi vida, decir que amo mi trabajo. Así es como lo hice: la versión larga.

Parte 1: Abrazar la crisis del cuarto de vida

Hace unos tres años, estaba en medio de una terrible crisis de un cuarto de vida. Me gradué de la escuela de negocios, conseguí un trabajo atractivo en banca de inversión y luego renuncié a ese mismo trabajo solo unos meses después de darme cuenta de que odiaba todo al respecto.

Completamente perdido y bastante cliché, viajé solo durante unos meses para "encontrarme a mí mismo". Y aunque pensé que sí, no lo hice. De todos modos, no es suficiente. Pero en realidad me ayudó a descubrir algunas cosas.

Lo primero fue que simplemente no podía seguir con una carrera en finanzas. Simplemente no podía ver ningún escenario futuro en el que eso me hiciera feliz.

La segunda cosa fue que viajar como mochilero y surfear, aunque era genial y todo eso, no me ayudaría a encontrar esa “vocación” que estaba buscando. Lo único razonable que se podía hacer parecía ser el método clásico de prueba y error.

Entonces, cuando regresé a casa, decidí probar algunas cosas que pensé que podrían hacerme feliz y, al mismo tiempo, proporcionarme una vida digna. Y fue prueba y error.

Primero, pensé que le daría una oportunidad seria a la escritura. Entonces comencé a escribir y editar a tiempo parcial para una revista de negocios en línea. Estuvo muy bien por un tiempo. Trabajar tres días a la semana en una oficina editorial de ritmo rápido, escribiendo sobre cualquier tema relacionado con negocios, finanzas, tecnología o sustentabilidad.

Al mismo tiempo, había escuchado tanto sobre la vida como autónomo mientras viajaba que pensé en probarlo. Así que monté mi propia empresa y pronto me topé con algunos proyectos de analistas comerciales. Ser mi propio jefe fue, por supuesto, muy emocionante al principio, y poder trabajar literalmente desde cualquier lugar fue completamente nuevo para mí.

Seguí así durante unos ocho meses, trabajando como redactor / editor y como analista de negocios independiente. Pero finalmente comencé a perder interés en el trabajo en la revista.

Como sabrá cualquier persona cuerda que se ocupe de contenido digital, las culturas clickbait se obtienen a expensas de la creatividad y la calidad. En otras palabras, cuando el incentivo principal de su contenido son los clics, todos los superlativos necesarios para cazar esos clics pronto desgastarán las ambiciones creativas que estaban allí en primer lugar. Además, no podía evitar la sensación de que, como escritor / editor, siempre estaba demasiado lejos de la acción sobre la que estaba informando.

Así que renuncio. Lo cual estaba bien de acuerdo con mi trato de prueba y error conmigo mismo. Pero todavía se sentía horrible, ya que en realidad había invertido ocho meses en escribir todo. Pero como alguien inteligente puede haber dicho o no: cuando una puerta se cierra, se abre otra.

Y todavía tenía una cosa más en mi lista de prueba y error para marcar.

Parte 2: El almuerzo que cambió mi vida

La vida es extraña y, a veces, esconde las inspiraciones más grandes y transformadoras en los lugares que menos esperas. Ciertamente fue así para mí cuando experimenté mi primer "tirón" hacia la codificación.

Aunque dejar el trabajo en la revista se sintió como un fracaso, la experiencia resultó no haber sido completamente en vano después de todo. Después de escribir tanto sobre nuevas empresas tecnológicas y las emocionantes vidas de los emprendedores, también estaba decidido a darle una oportunidad a ese estilo de vida.

Y después de aproximadamente un mes de investigación y búsqueda de empleo, logré conseguir un trabajo en una de las entonces, supuestamente, más prometedoras empresas de tecnología financiera en los países nórdicos. En solo unos años, había crecido hasta convertirse en una de las plataformas de financiación colectiva de acciones más grandes de Europa.

Realmente no había solicitado ningún puesto de trabajo específico. Pero como realmente creía en la misión de la empresa y me impresionó su éxito, preferiría ponerme en contacto con su director financiero para decirle exactamente eso. Nos reunimos un par de veces y, de repente, yo estaba trabajando allí en un rol de desarrollo empresarial bastante confuso.

Aunque esperaba ponerme manos a la obra en proyectos estratégicos y analíticos, terminé haciendo lo que suelen hacer los desarrolladores de negocios confusos: vender. Esa fue también la razón por la que este trabajo tampoco funcionó al final.

Pero hay más.

Al igual que la última experiencia laboral de la revista, este trabajo también demostraría no haber sido todo en vano. De hecho, sin él, probablemente no sería desarrollador hoy. Porque ahí es donde conocí a Sandra.

Ella era una desarrolladora de front-end en el equipo de producto, sentada justo en el otro extremo de la pequeña oficina de coworking en la que estábamos hacinados en ese momento.

Técnicamente éramos colegas, pero como sabrá cualquiera que haya trabajado en una empresa de tecnología disfuncional, la distancia entre el equipo de ventas y el equipo de producto a menudo puede parecer como galaxias separadas.

Tampoco ayudó que la gerencia hubiera decidido subcontratar a todo el equipo de desarrollo a un equipo remoto en Ucrania. Lo que significa que Sandra y todos los demás desarrolladores serían despedidos y más o menos solo cumplirían su aviso de dos meses.

A pesar de esta distancia, un día Sandra y yo terminamos almorzando juntas. Básicamente, sería mi primera conversación real con un desarrollador profesional, y creo que fue una mezcla de curiosidad genuina y mi acelerada crisis existencial lo que rápidamente convirtió más o menos el almuerzo en una entrevista.

Y nuestro almuerzo terminó siendo una experiencia que me cambió la vida. Más específicamente, tres revelaciones lo hicieron así.

  1. Me sorprendió saber que ella no tenía una educación "real" en desarrollo web, lo que para mí en ese momento equivaldría nada menos que a un título académico. Todo lo que sabía, lo había aprendido de las plataformas MOOC (Massive Open Online Courses), como freeCodeCamp y Codecademy.
  2. Me dijo que tenía experiencia en finanzas, como yo. De hecho, había trabajado como controladora comercial durante varios años hasta hace poco, cuando se unió a la misma startup que yo, solo unos meses antes como pasante de front-end.
  3. Cuando me mostró la página del portafolio que había creado con solo seis meses de experiencia en codificación, no lo podía creer. Fue increíble.

Ese almuerzo me abrió un mundo de posibilidades. La historia de Sandra me dio hambre de más.

Así que durante semanas investigué los diferentes tipos de caminos que las personas habían tomado para convertirse en desarrolladores. Terminé en todo tipo de foros y artículos, muchos de los cuales encontré aquí mismo en Medium.

Por ejemplo, la encuesta anual de desarrolladores de Stackoverflow (100.000 entrevistados) indicó que solo la mitad de todos los desarrolladores profesionales tenían una licenciatura, y de esta mitad, una tercera parte se especializó en algo completamente ajeno a la informática y la ingeniería de software.

Cuanto más leía, más me di cuenta de lo estrecha que había sido mi definición de educación. Si no necesita un grado de la informática para entrar en algo tan complejo como la ingeniería de software, lo que hizo que necesita un grado académico para? Aunque quizás no pude verlo entonces, ahora veo claramente lo roto que está el sistema académico.

Fue diseñado para la era industrial de los trabajadores , donde te especializarías en un oficio y luego usarías esas mismas habilidades por el resto de tu vida. Ciertamente no fue diseñado para la sociedad del conocimiento actual, donde toda la información de la historia del mundo nunca está a más de unos pocos clics de distancia, y donde las cosas cambian tan rápido que la educación debe ser un proceso de por vida, y no el aprendizaje. -una experiencia única de uso para siempre.

Pero ese es un tema lo suficientemente grande para un artículo en sí mismo. Lo importante de ese almuerzo con Sandra fue que encendió algo en mí y me motivó a liberarme del ciclo destructivo que encontré en mi actual carrera empresarial a medias.

Aunque siempre había envidiado a los programadores que me rodeaban, incluso en la medida en que había tomado un curso de verano de Python 101 unos años antes, nunca lo había considerado una carrera viable para mí. Al menos no sin haber vuelto a la universidad durante 3 a 5 años.

Entonces, si estás leyendo esto Sandra, ¡gracias! Si con este artículo puedo inspirar a una sola persona de la forma en que tú me inspiraste, consideraría el esfuerzo de escribirlo recompensado mil veces.

Parte 3: El texto que me costó $ 6,000

Durante los siguientes meses, pasé cientos de horas en plataformas en línea como Codecademy y freeCodeCamp. Incluso compré una suscripción a la plataforma de pago Code School.

No estoy seguro de saber realmente cuál era mi objetivo. Lo que me hizo comenzar fue la desesperación de las decepciones recurrentes de mi carrera. Pero lo que me mantuvo en movimiento fue lo ridículamente divertidos y gratificantes que encontré los ejercicios de codificación.

Ni siquiera podría decirles en qué momento la codificación pasó de ser un proyecto secundario casual a la seriedad absoluta: "Voy a ser un desarrollador profesional". Pero probablemente estaba en algún lugar por aquí. Estaba a punto de recibir mi certificado de front-end de freeCodeCamp, cuando ocurrió mi próximo evento que cambió mi vida.

Después de dejar mi trabajo como desarrollador de negocios, decidí escapar del limbo helado que es el invierno sueco para viajar por Centroamérica. Calculé que si iba a pasar cientos de horas solo, aprendiendo a programar por mí mismo, también podría hacerlo en un lugar cálido, barato y no deprimente.

Estaba codificando en mi computadora portátil en un albergue en El Salvador, cuando recibí un mensaje de texto de mi amiga Marie.

"¡Conseguí el trabajo!" decía.

Marie también estaba aprendiendo a codificar. Recordé cómo ella, unos meses antes, me había estado contando sobre esta escuela de códigos a la que asistía. Un "campo de entrenamiento de codificación".

En ese momento básicamente me burlé de ella por eso. ¿Vas a pagar $ 5,000 por un curso de 12 semanas? ¿Y no está recibiendo un solo crédito universitario por ello? ¿Y abandonó su MBA de primer nivel para hacer esto? Suena bien.

Y sin embargo ahí estaba ella. Cuatro meses después, Marie fue empleada oficialmente por una de las agencias digitales de Accenture como desarrolladora de back-end junior. Estaba muy feliz por ella, pero por supuesto también extremadamente celosa.

Dejé lo que estaba haciendo e hice algunos cálculos. Si pudiera mantener mi ritmo actual, codificando unas 6 horas al día en promedio, unos 5 días a la semana, haría 30 horas a la semana. Entonces, para terminar el programa completo de 1.200 horas de freeCodeCamp, me tomaría al menos 8 meses más. Y eso es si pudiera mantener el ritmo. Lo cual definitivamente no podía, ya que mi dinero se estaba acabando y tendría que regresar a Suecia y conseguir un nuevo trabajo pronto.

Me castigé por no haber tomado el mismo camino que Marie desde el principio, y gasté mi dinero en un bootcamp en lugar de viajar como mochilero durante 4 meses. Bueno, lo hecho, hecho está, pensé. Aún tendría que aceptar el hecho de que un bootcamp era la mejor opción para alcanzar un nivel de empleo lo suficientemente rápido.

Volvamos a la vieja investigación de Google.

En cierto modo, me sentí como si estuviera de regreso donde comencé después de ese almuerzo con Sandra. Solo que esta vez, miré todo el fenómeno del campo de entrenamiento con un par de ojos nuevos. Al conocer la historia de Marie, sabía que no todas eran estafas demasiado buenas para ser verdad, sino formas realmente plausibles de entrar en la industria.

Más tarde, la encuesta anual para desarrolladores de Stackoverflow volvió a tranquilizarme con las estadísticas de que el 88,1% de los ex alumnos del bootcamp de codificación habían sido contratados dentro de un año después de terminar el bootcamp.

Gracias a Switchup y Coursereport, no pasó mucho tiempo hasta que descubrí Le Wagon, la historia de éxito de una startup de bootcamp de codificación francesa con más de 15 ubicaciones en todo el mundo y las 5 mejores calificaciones en ambas clasificaciones (en el momento de escribir este artículo, en realidad # 1 en ambos, ¡con 27 ubicaciones!).

Después de compararlo con alternativas como Hack Reactor, Ironhack, General Assembly y NYCDA, algunas razones principales me hicieron preferirlo a los demás:

  • El precio relativamente bajo (en ese entonces $ 6,000).
  • El enfoque en el espíritu empresarial y el desarrollo de productos.
  • La presencia global y la comunidad.

Sin embargo, todavía tenía algunas dudas sobre el programa.

  1. La elección del lenguaje backend Ruby y el framework MVC Rails. Aunque parecía que esto era bastante común entre otros bootcamps reconocidos, casi todos los artículos que leí sobre el tema sugirieron que Javascript estaba realmente de moda y lo que buscaban los empleadores. El bootcamp de mi amiga Marie, por ejemplo, enseñó una pila de backend basada en Node.js y Express.js. Ambas tecnologías basadas en Javascript. Algunos argumentos comunes parecían ser que Ruby era un gran lenguaje para aprender, pero que Node y Express eran habilidades que los empleadores valoraban mucho más. ¿Ruby era realmente el caballo en el que apostar?
  2. La duración del curso de 9 semanas parecía un poco corta. La mayoría de los programas de la competencia parecían tener al menos 12 semanas, lo que ya parecía demasiado corto para convertirse en un desarrollador web empleable.
  3. Le Wagon no ofreció ayuda real para la búsqueda de empleo después de completar el campamento de entrenamiento. Muchos competidores ofrecían garantías de empleo o funciones de servicios profesionales aparentemente sólidas.

Abordaré cada una de estas tres dudas una por una con mis conclusiones posteriores al bootcamp al final de la siguiente sección.

Sin embargo, a pesar de mis preocupaciones, pensé que era mi mejor opción, por eso decidí postularme a su escuela en Barcelona. Unos días después, el director de la escuela local, Gus, se acercó a mí para una entrevista por Skype.

Conectado a un Wi-Fi de mierda en un café en el perezoso surftown de El Tunco, tuvimos una breve charla. Pero fue mucho más informal de lo que esperaba. Sentí que estábamos conectados, lo que me hizo querer ser admitido aún más. Y luego, ni siquiera 24 horas después, recibí el correo electrónico que estaba esperando. Gus me dijo que estaría encantado de tenerme en el próximo lote y que lo único que tenía que hacer a continuación era pagar el depósito de $ 1,200 para reservar mi lugar.

Eso era básicamente todo el dinero que me quedaba en ese momento, y se suponía que iba a pagar mis últimas semanas en El Salvador, incluido el eventual viaje a casa. Pero si me las arreglaba para mantener un presupuesto más ajustado y reservar un vuelo a casa antes de lo esperado, sabía que podría hacerlo.

Entonces, después de un breve momento de vacilación, y recordando las preocupaciones que todavía tenía por Le Wagon, actué por intuición y le transferí el depósito a Gus. Después, recuerdo sentirme un poco incómodo. ¿Realmente me había comprometido a pagar casi $ 6,000 por un curso de codificación de 9 semanas? Como sueco, que nunca ha pagado un solo centavo por la educación, la situación se sentía bastante extraña.

Sin embargo, no pasó mucho tiempo hasta que ese extraño sentimiento se convirtió en emoción. Al menos ahora sabía que no tendría que volver a trabajar en finanzas, ventas o medios en línea en un futuro cercano. El mismo día, comencé a hacer arreglos para el tiempo hasta el bootcamp.

En los tres meses que quedan, de alguna manera tendría que ganar los $ 4,800 restantes de la tarifa. Más alquiler y gastos de manutención. Bueno, mierda.

Me comuniqué con una de las empresas para las que había consultado anteriormente y, afortunadamente, tenían el proyecto perfecto de analista de negocios en camino. Dado que inicialmente no aceptarían nada menos que un contrato de 4 meses, tuve que convencerlos de que podía hacer el trabajo en dos. De alguna manera funcionó.

¡Uf! Solo una semana antes, había sido un viajero fugitivo sin pensar en volver a casa. Ahora, iba a comenzar mi nuevo concierto de dos meses en Estocolmo en menos de dos semanas y luego mudarme a Barcelona. De hecho, hay cosas emocionantes por delante.

Parte 4: Bootcamp en Barcelona

Avance rápido tres meses ... Es el 1 de mayo de 2017, y estoy en un salón de clases asistiendo a mi primera conferencia de Le Wagon.

A mi alrededor hay unas 25 personas de todos los rincones del mundo. Kilian de Alemania, Daniel de Venezuela, Francesca de Francia, Arbi de Italia, Courtney de los EE. UU., Etc. Algunos sin ninguna experiencia en codificación, algunos con un poco y otros a medio camino de obtener sus títulos en informática.

Estamos escuchando a Gus, el director de la escuela local, ya Ruben, un maestro de Ruby, explicando la estructura del programa que tenemos por delante.

Como todos llegaríamos a saber, el programa era muy sistemático. Durante las próximas 9 semanas, dedicaríamos más o menos la misma cantidad de tiempo a 6 módulos diferentes, cada uno de los cuales trataría un tema propio, y terminaríamos con dos semanas dedicadas a la planificación y desarrollo de nuestra propia aplicación web.

Durante toda la primera semana, recuerdo haberme sentido bastante confiado con el contenido del curso. Después de todos esos cientos de horas en freeCodeCamp, el nivel de dificultad de los desafíos diarios de codificación parecía un poco bajo.

Aunque Ruby todavía era bastante nuevo para mí, los conceptos básicos parecían ser más o menos los mismos que con Javascript y Python. Escuchar conferencias y hacer ejercicios para aprender sobre variables, matrices, hashes, funciones básicas e iteraciones se sintió bastante repetitivo. Así que me volví engreído y me pregunté si realmente sacaría algo de este campo de entrenamiento. Sin embargo, ni siquiera una semana después, todo eso cambiaría. Pasé de sentirme como el mejor de la clase a luchar por mantener el ritmo.

Antes de darme cuenta, estábamos pasando de lo básico a la programación orientada a objetos, las arquitecturas MVC y las bases de datos, y hubo muchos días en los que sentí que ni siquiera había entendido los conceptos del día anterior y que ya se esperaba para pasar al tema siguiente.

Así que tuve que poner la siguiente marcha. Diez horas al día en el aula no sería suficiente para mí. Hice una rutina para dedicar algunas horas extra cada noche y pasar la mayor parte de los fines de semana repitiendo las cosas más difíciles de la semana pasada. Apestaba un poco no poder disfrutar de Barcelona tanto como las primeras semanas, pero el hecho de haber invertido todos mis ahorros en el bootcamp fue una gran motivación.

Otra fuente de frustración fue la naturaleza dispersa de las cosas que estábamos aprendiendo. Se sintió como si nos hubieran dado cien piezas de rompecabezas, pero sin instrucciones sobre cómo juntarlas todas. Saber escribir Ruby, HTML, CSS, Javascript y SQL básicos fue realmente enriquecedor, pero ¿cómo me ayudaría ese conocimiento a crear una aplicación real?

Y luego vino mi gran momento AHA.

Era la semana 6 y finalmente habíamos llegado al módulo Ruby on Rails. Antes de darme cuenta, estaba mirando la ventana de mi navegador Chrome y leyendo las palabras “¡Yay! ¡Estás sobre rieles! ”. Esa fue mi primera aplicación web, dijo la maestra.

¿Qué? Todo lo que hice fue ejecutar algunos comandos simples en mi terminal y navegar en // localhost: 3000 / en mi navegador. ¿Qué estaba mirando?

No fue hasta que abrí el directorio de la aplicación en el editor de texto que ese gran y dulce entendimiento encajó. Rails lo mostró todo de una manera hermosa y sencilla.

Una carpeta para HTML, una para CSS y Javascript, una para los controladores y otra para los modelos. Un archivo para las rutas. Y un archivo para ese esquema dulce, dulce, mapeando toda la base de datos como si no fuera más complejo que una lista de compras.

Después de finalmente tener una idea general de cómo todas esas piezas encajarían prácticamente juntas en un marco MVC como Rails, pasar todas mis noches y fines de semana codificando ya no fue una gran lucha. Muy al contrario, a menudo me costaba levantarme de la computadora portátil para ir a la cama por la noche.

Estaba en una buena racha, obteniendo nuevos conocimientos cada día. Y le dio este efecto embriagador que todavía es un poco difícil de expresar con palabras.

  • ¿Entonces puedo mezclar HTML y Ruby en mis archivos erb?
  • ¿Puedo acceder a las variables de instancia desde el controlador en el archivo html.erb asociado?
  • ¿Puedo importar código que otras personas escribieron usando esta cosa llamada Gems?
  • ¿Puedo escribir tanto JavaScript vainilla como quiera en el directorio assets / javascript?
  • ¿Puedo usar la consola Rails en la terminal para básicamente hacer lo que quiera con toda la base de datos?

Fue solo un flujo interminable de momentos Aha increíblemente satisfactorios. Como si acabaras de darte cuenta de que la fuerza era realmente fuerte contigo, y que te acercaste un paso más para convertirte en un Jedi completo con cada nuevo conocimiento. Incluso ahora, nueve meses después, siento que todavía estoy en el mismo nivel y empiezo a pensar que en realidad podría ser algo permanente. Qué hermoso sería eso.

De todos modos, el tren del campo de entrenamiento no se estaba desacelerando, y pronto llegamos a las últimas dos semanas, cuando se suponía que debíamos crear nuestra propia aplicación. Las dos semanas terminarían con un gran día de demostración, donde cada grupo presentaría y demostraría sus aplicaciones frente a las cámaras y una gran audiencia.

Presión.

Para nuestra sorpresa, la planificación resultó ser, con mucho, la parte que más tiempo consumía. Aunque nos preparamos mucho en las últimas semanas (presentando ideas de aplicaciones, formando grupos, diseñando funciones en Sketch), no fue hasta después de unos días de codificación que nos dimos cuenta de que habíamos sido demasiado ambiciosos.

La idea inicial de la aplicación fue una especie de "Happn para las conexiones profesionales". Más específicamente, permitir a los usuarios crear páginas para eventos de redes a las que otros usuarios podrían asistir y registrarse. "Pero eso es Meetup", podrías estar pensando. Pero nuestra idea tenía un giro: solo podía registrarse en un evento si estaba físicamente en el lugar del evento. De ahí el "Happn para las conexiones profesionales".

Una vez que se registró en un evento, un usuario podría ver los perfiles profesionales de otros usuarios registrados, utilizando los datos recopilados a través de la API de LinkedIn, y conectarse y chatear con los que coincidían con sus intereses, sin perderse así conexiones potencialmente excelentes. .

Este fue nuestro MVP inicial (producto mínimo viable) y decidimos llamarlo Unify. Súper cursi y aspirante a Silicon Valley, lo sé. Pero en nuestra defensa, teníamos mejores cosas que hacer con nuestro tiempo que pensar en mejores nombres.

Como una lluvia de ideas sobre las características reales. Pero luego hicimos una lluvia de ideas demasiado, y se agregaron y eliminaron funciones hasta que terminamos con una aplicación completamente diferente que,

  1. nunca estará lista para la demostración en los diez días restantes, y
  2. no fue tan disruptivo como pensamos que fue nuestra primera idea.

Así que tuvimos que reducir las funciones al MVP y, de hecho, terminamos con casi exactamente el mismo producto que el gerente de Le Wagon, Gus, había recomendado que usáramos desde el principio.

Una gran pérdida de tiempo, fue lo que pensamos entonces. Pero el proceso al menos me enseñó algunas cosas realmente importantes sobre el desarrollo de productos:

  • Cuando se hace bien, debería tratarse mucho más de la planificación que de la codificación real.
  • Tener que limpiar los errores del código antiguo requiere mucho más tiempo que planificar a fondo y hacer las cosas desde el principio.
  • El MVP siempre es más pequeño de lo que piensas desde el principio.

Unos diez días después, después de más de 100 horas de codificación, diseño, discusión, pruebas, migraciones de bases de datos y reversiones de bases de datos, de alguna manera llegamos milagrosamente al Demo Day y realmente nos sentimos bastante bien con nuestra aplicación. Claro, estaba lejos de ser perfecto, pero todas las características principales realmente funcionaban como queríamos.

Sin embargo, solo unas horas antes de la demostración, casi tendríamos un infarto.

La API de geolocalización de Google no respondía como debería a nuestras solicitudes, por lo que no pudimos registrarnos en el evento que usaríamos para la demostración. Probamos de todo. Cambio de ordenadores y usuarios. Eliminar y crear nuevos eventos. Cambio de la dirección postal del evento. Nada funcionó.

Los tres intentamos mantener la calma y no entrar en pánico. Probablemente fue solo un error que el responsable de la función de geolocalización sabría resolver fácilmente.

Pero llegaba tarde, así que intentamos llamarlo.

Sin respuesta.

Intentamos llamar de nuevo.

Sin respuesta, de nuevo.

Y luego entramos en pánico.

No fue hasta el último minuto, gracias a uno de nuestros increíbles asistentes de enseñanza, Antoine, logramos encontrar el error. Resulta que accidentalmente habíamos configurado el rango de distancia demasiado bajo, razón por la cual la aplicación no pudo confirmar que estábamos en la ubicación del evento. Simplemente aumentamos el radio en unos pocos kilómetros, nos comprometimos e impulsamos el cambio a nuestro servidor de producción.

Y voilà, la aplicación funcionó perfectamente. Y también lo hizo la demostración.

En general , mi experiencia con Le Wagon fue increíble. Probablemente nunca había aprendido tanto en tan poco tiempo. En retrospectiva, es realmente difícil de creer que la mayoría de nosotros pudimos desarrollar aplicaciones web con todas las funciones con básicamente solo 9 semanas de experiencia en desarrollo.

Pero no se engañe, el bootcamp no hará el trabajo por usted. Para sacarle provecho, tendrá que entregarle todo su compromiso. Yo mismo vi a muchas personas quedarse atrás o incluso abandonar porque

  • no tenía las expectativas correctas del nivel de dificultad,
  • no estábamos lo suficientemente preparados, o
  • estaban demasiado ocupados con otras cosas para mantener el ritmo.

En una nota final, creo que un error que cometen muchos novatos es considerar un título en informática como un sustituto del autoaprendizaje o un bootcamp, como un medio para convertirse en desarrollador web y / o móvil. Según mis experiencias, esto no es exacto.

Incluso si está buscando un título en ciencias de la computación, aún deberá llenar un montón de brechas de conocimiento práctico para ser productivo. Prácticamente vi esto de primera mano en mis compañeros de bootcamp con 2-3 años de estudios de informática a sus espaldas. Nuevamente, eso se debe a que el modelo académico está roto y desactualizado y, por lo tanto, no puede mantenerse al día con el ritmo extremo con el que está cambiando el desarrollo de software del mundo real.

Desde mi punto de vista, si el objetivo es convertirse en desarrollador, en algún momento será necesario el autoaprendizaje o un bootcamp. Por lo tanto, un título en informática debe percibirse como un complemento y no como un sustituto .

Y la razón por la que un (buen) bootcamp puede convertirlo en un desarrollador más rápido que el autoaprendizaje es la combinación de lo siguiente:

  • un plan de estudios completo pero conciso,
  • una plataforma en línea perfecta con tutoriales y ejercicios, y lo más importante;
  • el apoyo de guardia de un humano cuando chocas contra una pared.

Para concluir esta sección, me gustaría abordar las tres preocupaciones que tenía antes de comprometerme con el bootcamp con los conocimientos que he obtenido desde entonces.

1. Aprendiendo Ruby on Rails en lugar de una pila basada en JavaScript

Si actualmente se encuentra en la posición en la que estaba antes de unirme a mi bootcamp de Rails, abrumado por todo el bombo de JavaScript que inunda Internet, puede preguntarse si Ruby es un lenguaje anticuado y si Rails es un marco anticuado. Si este es el caso, mi respuesta corta sería no.

La respuesta larga, sin embargo, sería esta.

La empresa en la que trabajo ahora tiene una aplicación web de alto tráfico creada con Rails en el backend y el marco de frontend Ember.js en el frente. Habiendo trabajado a tiempo completo con esta aplicación durante unos seis meses, ahora he requerido tanto código en Javascript como en Ruby, lo que me ha dado una idea de las diferencias y similitudes entre las tecnologías.

Y claro, cuando se trata del renderizado HTML / CSS del lado del cliente (o las "vistas"), la experiencia del usuario de Rails ni siquiera es comparable a los grandes frameworks de JavaScript. Eso debo darle a los enemigos de Rails.

Por ejemplo, tome una sección de comentarios básica de un artículo o publicación de blog. Como usuario, esperaría que los comentarios que envíe aparezcan instantáneamente en su pantalla.

En un marco de JavaScript moderno, esto es simplemente una cuestión de enviar los nuevos datos (el comentario) al almacén de datos del lado del cliente y asegurarse de que la lista de comentarios actualice su estado para mostrar el nuevo comentario. De esta manera, no tiene que esperar a que el nuevo registro se envíe al backend, se almacene en la base de datos y luego el cliente lo solicite nuevamente. En cambio, el nuevo comentario aparece instantáneamente en su pantalla.

Sin JavaScript en la parte superior de su código HTML de Rails, el usuario tendría que actualizar la página para ver cualquier comentario nuevo sobre el artículo. Lo que es horrible UX. Para evitar esto, puede tomar algunos caminos diferentes.

Antes de la era de los frameworks JS, la solución principal sería esparcir un poco de lógica AJAX bastante desestructurada sobre el HTML, que a menudo sería muy difícil de mantener a largo plazo a medida que su aplicación se hace más grande. Otra opción disponible para Rails recientemente es la solución websocket pubsub (publicación-suscripción) que utiliza algo como Action Cable. Por ejemplo, esto es lo que usamos para el chat en la aplicación que construimos en el bootcamp. El problema es que sin un marco de JavaScript envolvente, la lógica de websocket puede volverse innecesariamente compleja y también difícil de mantener.

Afortunadamente, sin embargo, hoy tenemos la opción mucho mejor para usar marcos de JavaScript para este tipo de problemas. Y dado que, en mi opinión, el lado del cliente es el punto más débil de Rails, este es también mi principal argumento de por qué Rails no debe descartarse como una opción para, por ejemplo, Laravel o la pila MERN. Simplemente coloque un marco JavaScript nítido en la parte superior, como React o Ember, y estará listo para comenzar.

Personalmente, me encanta nuestra integración entre Rails y Ember y cómo se complementan entre sí. Su naturaleza obstinada, sólidos antecedentes, liderazgo visionario y enormes comunidades de contribuyentes los hacen estables, confiables y adecuados para desarrolladores junior como nosotros.

Si todavía, a pesar de mis mejores esfuerzos, duda sobre apostar por Ruby como su primer lenguaje de backend, me gustaría recordarle que no sabía prácticamente nada sobre JavaScript hace seis meses (a excepción de algunos JS básicos vanilla, React, y sintaxis de jQuery), y hoy trabajo con estos dos lenguajes y marcos, y hago la transición entre ellos sin problemas a diario. Y ama cada minuto (en sentido figurado).

Entonces, no importa en qué apueste como su primer idioma, no se preocupe, ¿siempre puede aprender el segundo en el trabajo?

2. ¿No son 9 semanas demasiado cortas para aprender algo?

Con respecto a mi preocupación de que la duración del bootcamp (apenas 9 semanas) podría ser demasiado corta para aprender algo valioso, Le wagon también me ayudó a acabar con ese mito. En retrospectiva, está claro que preferiría 9 semanas a las 12 que ofrecen la mayoría de los otros bootcamps.

La razón es que el bootcamp en sí no lo lleva a un nivel de preparación para el empleo. Al menos no para mi. Más bien me brindó una sólida introducción a todas las herramientas necesarias que necesitaría para alcanzar un nivel productivo y cómo ponerlas todas juntas. Entonces, incluso si me hubieran dado tres semanas más, solo habría significado una docena de presentaciones de herramientas más. Herramientas que luego tendría que aprender a usar en profundidad. Y esa lista ya era más que suficiente.

No fue hasta después del bootcamp, después de semanas de crear mi propia cartera de aplicaciones, que comprendí cómo funcionaban realmente las herramientas. Entonces, si ha decidido que desea hacer el bootcamp, pero está comparando opciones en función de una diferencia de unas pocas semanas, mi consejo sería eliminar esa variable de la ecuación. Porque si eres como yo, aún tendrás que volver a aprender cada herramienta por tu cuenta.

Mirando hacia atrás, en realidad es bastante notable lo preciso que fue el conjunto de herramientas de Le Wagon. En mi trabajo actual utilizo la mayoría de estas herramientas a diario. Algunos ejemplos serían Postgres, Git, GitHub, Sidekiq, Pundit, Heroku y Cloudinary. Las únicas dos cosas en las que desearía que mis maestros hubieran dedicado más tiempo serían cómo usar un marco de JavaScript como React y cómo escribir pruebas con tecnologías como Rspec. Porque aprender esos dos por mi cuenta más tarde resultó ser crucial para conseguir mi primer trabajo de desarrollador.

3. ¿Me habrían ayudado una garantía de empleo y / o servicios profesionales?

Como mencioné anteriormente, muchos bootcamps tienen una política de "ser contratado o recuperar su dinero". Y muchos más tienen un organismo de servicios profesionales para ayudarlo a ponerse en contacto con empleadores potenciales y asesorarlo para solicitudes y entrevistas.

Y aunque esto probablemente suene como un buen trato para muchos, en realidad no creo que hubiera hecho una diferencia para mí. Pero, de nuevo, también tuve tiempo para dedicar unas 500 horas a codificar durante los dos meses posteriores al bootcamp, el privilegio de tener un título universitario de élite en mi currículum y mucha experiencia en la aplicación y entrevistas de trabajo. Si estas cosas no se aplican a usted, tal vez este sea un factor a considerar al elegir entre los bootcamps. No lo sé.

Parte 5: Creación de una cartera

El último de julio de este verano pasado, el campo de entrenamiento terminó. Pero recién estaba comenzando.

Desarrollar la aplicación Unify en el campo de entrenamiento y llevarla a la línea de meta me había dado un gran impulso, y estaba decidido a aprovechar al máximo ese impulso mientras estaba allí.

Todavía me quedaba algo de dinero en el banco y me quedaban unas semanas en el subarrendamiento del apartamento en Barcelona. Básicamente, todos los que conocía en la ciudad se iban. Así que no tenía ninguna razón para no seguir comiendo, durmiendo y soñando código. Solo a medias, establecí algunas rutinas y hábitos nuevos para mí:

  • Codificaba todos los días hasta que alcanzaba mi objetivo, que por supuesto era conseguir ese primer trabajo de desarrollador. Es decir, de lunes a domingo, día y noche.
  • Enviaría cada fragmento de código que escribí a Github , el lugar número uno para que los empleadores potenciales inspeccionen sus habilidades de código y su nivel de ambición. Incluso si no sintiera que había producido algo que valiera la pena comprometer, lo haría solo para construir sobre esa dulce historia verde de compromisos para que todo el mundo lo vea.
  • Y me sumergiría completamente en la mayor cantidad de contenido de software que pudiera . Eso significaba escuchar podcasts como Software Engineering Daily y SE Radio cada vez que hacía un recado, salía a correr o cocinaba. Significaba ver charlas de código, tutoriales y conferencias de canales de Youtube como Coding Tech, Traversy Media y CS50. Significaba leer publicaciones de Medium como Hacker Noon, freeCodeCamp y Codeburst y revistas como Techcrunch y The Next Web. Y significó instalar Dash en mi computadora portátil, para poder buscar siempre fácilmente la documentación adecuada sobre cualquier problema de sintaxis con el que estuviera luchando en un momento dado (para mí, en su mayoría, documentos web de MDN, api.rubyonrails.org y RubyDocs) .

En otras palabras, mi motivación para convertirme en desarrollador era más fuerte que nunca, y sabía que al no tener ningún mérito académico o profesional para presumir, probablemente nunca me llamarían para una entrevista de trabajo a menos que tuviera un portafolio increíble. Así que eso es lo que me propongo hacer a continuación.

El día después del Demo Day, apenas sobrio por la noche que siguió, comencé a construir mi primera aplicación Rails (¡así de fuerte fue el impulso!). A pesar de lo arrogante que era, pensé que la primera aplicación tardaría unas semanas en completarse, ahora que ya la había revisado una vez con la aplicación Unify. Nuevamente me equivoqué.

Me llevaría casi dos meses terminarlo. Hubo tantos procesos en las últimas dos semanas del bootcamp que habían pasado tan rápido, sin que yo los entendiera completamente. Me quedé atascado durante varios días en todo tipo de cosas, desde vergonzosamente simples hasta algo avanzadas. Solo configurar un selector de fecha y hora requirió varios días dedicados a Stackoverflow. Sin mencionar la función de chat, usando websockets con Action Cable, que me llevó aproximadamente dos semanas hacerlo bien.

Pero el tiempo invertido valió la pena. La aplicación resultó bastante buena: en realidad, era algo que podía hacer una demostración para la gente y sentirme orgulloso. Y aunque hubo muchos momentos de desesperación, aprendí un montón. Y de hecho, experimentar todo ese ajetreo me dio mucho consuelo en el sentido de que el bootcamp probablemente había sido una buena elección.

Si fue tan difícil codificar estas cosas ahora cuando estaba familiarizado con todo, ¿qué tan difícil no hubiera sido si no hubiera tenido los asistentes de enseñanza, la plataforma y el plan de estudios cuando lo hice todo la primera vez?

Así que en algún momento a finales de agosto terminé la aplicación. Estaba de vuelta en casa en Estocolmo, viviendo en el apartamento de mi padre, arruinado y sintiéndome bastante patético. Hice todo lo posible para usar esa autocompasión para seguir aumentando mis esfuerzos de codificación. Y estaba funcionando bastante bien.

Muy pronto llegó el momento de codificar el sitio web de la cartera real. Y por una vez, decidí mantenerlo simple. Así que armé una página web estática muy minimalista donde podía recopilar las cosas que había hecho.Después de terminarlo, mi plan había sido comenzar a solicitar puestos de trabajo. Pero había algo que me molestó. ¿Recuerdas que dije que había dudado un poco sobre Ruby on Rails antes de unirme a Le Wagon? Bueno, aunque en realidad había llegado a amar el minimalismo de Ruby y la simplicidad de usar Rails, todavía sentía que había tomado un atajo en alguna parte.

En la sección "Habilidades" de la página de mi cartera, se pueden encontrar Ruby, Rails, SQL, Postgres, HTML / CSS, jQuery, Bootstrap, Sketch, Git y Heroku. Y JavaScript.

Fue el último que me molestó. Se sintió como una mentira.

Si comenzara a solicitar trabajo ahora, probablemente podría conseguir algo decente como desarrollador de Rails. Pero, ¿y si todos los que odian tuvieran razón, y Rails en realidad estuviera desactualizado y muriendo? ¿Y qué pasa si encuentro el trabajo de mis sueños y me doy cuenta de que utilizan tecnologías JS avanzadas? No tendría ninguna posibilidad con mis 200 horas en freeCodeCamp y 2 - 3 días de jQuery + 1 día de React.js en el bootcamp.

La parte arrogante de mi cerebro me habló de nuevo: "Aquí tienes una idea: ¿qué pasaría si yo también aprendiera la pila MEAN?" MEAN como en MongoDB, Express.js, Angular.js y Node.js, que es algo así como el equivalente en JavaScript de lo que Rails es para Ruby. De acuerdo con los resultados de búsqueda en LinkedIn y Glassdoor, eso significaría que más o menos duplicaría la cantidad de trabajos de desarrollador para los que estaba calificado.

Recordé que Gus, el director del campo de entrenamiento, me había dicho que tardaría un mes en aprenderlo. ¿Qué tan difícil podría ser? Probablemente podría hacerlo en dos semanas, fue mi pensamiento.

Y así es como terminé en lo que me gustaría llamar el pantano del tutorial .

Una vez más, recurrí a mi viejo amigo Google para investigar estrategias de aprendizaje. Pero después de unas horas, todavía parecía que no podía encontrar un buen curso en línea para mis necesidades de MEAN stack 101. Todos parecían estar enfocados en una parte a la vez, lo que definitivamente es el camino correcto a seguir si desea comprender un marco en profundidad. Pero como quería aprender todo lo que pudiera en dos semanas, lo suficiente para poder agregar un nuevo proyecto a mi portafolio, no tuve tiempo para eso.

Fue entonces cuando descubrí una dimensión completamente nueva de la educación para el desarrollo: los tutoriales de YouTube. Había tantos ahí fuera. Por cada tecnología o pila que pude pensar, encontré al menos cinco tutoriales decentes.

Finalmente encontré mi camino hacia el canal Traversy Media, y la serie de tutoriales MEAN Stack Front To Back. Diez videos de 20 minutos cada uno, que le muestran cómo crear una aplicación web RESTful básica con registro de usuario y autenticación de inicio de sesión. Perfecto.

Comencé de inmediato y codifiqué cada video en mi computadora portátil. Y bastante loco, después de solo unos días terminé. De hecho, había codificado una aplicación web en pleno funcionamiento utilizando tecnologías completamente extranjeras. Node para el backend, Mongo para administrar la base de datos, Angular para el frontend y Express para unirlo todo.

¿Realmente podría ser así de fácil? ¿Sabía esto ahora? Aunque estaba feliz de que hubiera sido mucho más fácil de lo que pensaba, un escalofrío de demasiado bueno para ser verdad recorrió mi espalda.

Bueno, ya que me adelanté a lo programado, pensé, ¿por qué no desarrollar la aplicación un poco más? Mi idea era convertirlo en un clon medio, simplemente habilitando las acciones CRUD básicas de la publicación del blog (crear, leer, actualizar, eliminar), como lo habíamos hecho en un proyecto en el bootcamp con Rails.

Sin embargo, no llegué muy lejos. Pensé que solo necesitaría agregar un par de nuevas rutas, modelos, controladores y vistas, y eso sería todo. El problema era que todavía estaba pensando en el "modo Rails", donde "la convención sobre la configuración" hace que funciones como esta sean realmente fáciles y rápidas de construir.

Como había leído y escuchado muchas veces, la pila MEAN sigue el mantra opuesto: "configuración sobre convención", lo que significa que obtienes un marco significativamente más flexible al renunciar a algunas de las automatizaciones "mágicas". Como obtener una acción de controlador de cierto nombre conectada a una vista con ese mismo nombre, nada más sacarlo de la caja. Lo cual es una pieza de magia realmente dulce para obtener cuando eres un principiante.

Entonces, darse cuenta por primera vez de lo difícil que era codificar siguiendo la "configuración sobre la convención" fue una gran bofetada. Porque demostró que mi corazonada de que todo el proceso del tutorial había sido demasiado bueno para ser verdad era correcta. Pero no fue hasta que comencé a codificar fuera del guión, sin las reconfortantes instrucciones de Brad Traversy, que me di cuenta.

Así que ahí estaba yo, hasta las rodillas en el gran charco de lodo que era la pila MEAN para mí en ese momento. La aplicación no estaba lista para ser agregada a mi página de portafolio. Literalmente no tenía características. Solo la posibilidad de que los usuarios se registren, inicien sesión y no hagan nada más que mirar algunos diseños estáticos de Bootstrap.

Otra opción era seguir apresurando la forma de prueba y error. A diferencia del bootcamp, me quité las ruedas de entrenamiento MUY pronto y probablemente tendría que pasar semanas en Stackoverflow para poder terminar la aplicación de la manera que la había planeado. No tuve semanas. Se suponía que debía empezar a solicitar trabajo ayer.

Irónicamente, resultó que la única forma de salir del pantano de tutoriales en el que me había metido era seguir vadeándolo, siguiendo más tutoriales. Afortunadamente, encontré uno bastante bueno en el mismo canal de Youtube y decidí usarlo como mi salvavidas.

Y así es como la aplicación web que se suponía que era un clon de Medium al final se convirtió en una aplicación de descubrimiento de música, utilizando la API de búsqueda de Spotify.

A pesar de todo el ajetreo, dos semanas después de la decisión de intentar aprender la pila MEAN, de hecho implementé una aplicación web decente. Cuál había sido mi objetivo. Claro, era un poco como hacer trampa, pero pensé que mientras pudiera hacer una demostración y explicar todas las partes en una entrevista de trabajo, a nadie le importaría si había seguido un tutorial o no.

Auge. De repente, tenía tres aplicaciones en mi cartera y podía agregar un montón de nuevas tecnologías a mi repertorio de habilidades. Finalmente, llegó el momento de entrar en la siguiente fase de mi viaje como desarrollador: la búsqueda de empleo. Y no fue un día demasiado pronto.

Parte 6. Solicitud de empleo

En total, me tomaría alrededor de 4 semanas, 30 solicitudes, 10 entrevistas y 3 ofertas para encontrar ese ajuste perfecto. E irónicamente, en realidad sería la primera empresa a la que postulé y me uniría. Por supuesto, podría llamarlo una coincidencia, pero creo que es más un efecto de un proceso de selección exhaustivo antes incluso de comenzar a enviar solicitudes.

Debo admitir que creo que una buena cantidad de suerte jugó en mi rápido éxito en la búsqueda de empleo. Pero por si sirve de algo, describiré el proceso que seguí, ya que creo que me enseñó algunas cosas sobre los trabajos y las empresas en los que enfocarme para ese primer trabajo de desarrollo.

Lo primero que hice fue crear una hoja de cálculo para una lista corta de trabajos interesantes (originalmente soy un economista aburrido, ¿recuerdas?). Luego, pasé varios días buscando en las bolsas de trabajo de LinkedIn, Glassdoor y Stackoverflow trabajos basados ​​en palabras clave como web, desarrollo, software, frontend, backend, Ruby, Rails, Javascript, Angular, Node y Postgres.

Como era de esperar, las búsquedas arrojaron cientos de puestos de trabajo solo en el área de Estocolmo. Las empresas detrás de ellos iban desde nuevas empresas hasta agencias digitales, empresas de medios, proveedores de servicios en la nube, desarrolladores de juegos y todo lo demás.

Durante los últimos meses, me las arreglé para reunir un conjunto bastante limitado de criterios de lo que quería de mi próximo empleador.

Si pudiera elegir cualquier trabajo que quisiera, mis prioridades se parecían más o menos a las siguientes:

  1. Codificaría en toda la pila, lo que significa que podría hacer tantas cosas de base de datos y arquitectura como cosas de UX / UI, y principalmente en JavaScript. Todo el revuelo en torno a React probablemente tuvo mucho que ver con este último. Como te dije antes, por todo lo que sabía en este momento, Rails básicamente estaba muriendo, y JavaScript era el futuro.
  2. Mi curva de aprendizaje sería extremadamente empinada, hasta el punto que tendría que codificar día y noche para mantenerme al día. Todo para volverme lo mejor posible en el menor tiempo posible.
  3. Mis compañeros de trabajo serían inteligentes, ambiciosos, divertidos e informales, y preferiblemente todos al mismo tiempo.
  4. La empresa sería una startup de alto crecimiento con una misión significativa y un producto relacionado con blockchain, IA y / o sostenibilidad, o una agencia digital de primer nivel con tales proyectos.
  5. Me pagarían bastante.

Eso fue todo. Se podría pensar que hay demandas bastante altas para un novato. Pero tenga en cuenta que un salario alto no formaba parte de los criterios (ni lo es hoy, con 6 meses de experiencia profesional). Quizás estoy diciendo lo obvio, pero si estás migrando a un rol de desarrollo puro desde algo completamente diferente, creo que es importante saber que no importa lo que te pagaban antes.

Por ejemplo, sabía que mi valor de mercado en la industria financiera era de aproximadamente $ 5,000 por mes. Pero al darme cuenta de que el desarrollo de software es un oficio fundamentalmente diferente, fijé mi objetivo alrededor de $ 3,700, pero me conformaría con tan solo $ 3,000 (que es significativamente más bajo que el salario promedio sueco de alrededor de $ 4,000).

Con todos los criterios anteriores en mente, comenzaría a revisar los anuncios de trabajo uno por uno, agregando los que me gustaban a mi lista corta y abandonando los que no. Después de un tiempo, noté algunos patrones:

En primer lugar, la mayoría de las empresas en papel requerían muchas más habilidades y experiencia tecnológicas de las que yo podía ofrecer. Esto no fue ninguna sorpresa. Tanto por mi propia investigación como por el campo de entrenamiento, supe que la posición de “desarrollador junior” estaba muriendo.

Que muchas empresas consideraron demasiado caro dedicar el valioso tiempo de los desarrolladores senior a la tutoría de novatos. Por eso prefirieron contratar desarrolladores senior, que tienen una demanda muy alta pero una oferta extremadamente baja.

La gran paradoja aquí es, por supuesto, que si nadie se encarga de fomentar y enseñar a los desarrolladores junior, ¿cómo podemos solucionar la escasez de desarrolladores senior en el mercado? Sin embargo, al darme cuenta de que esta es la forma en que funciona la industria hoy en día, también me di cuenta de que tendría que postularme para puestos para los que no estaba calificado.

En segundo lugar, vi que cuanto más grande y atractiva era la empresa, más probable era que incluyera requisitos de algún título relacionado con la informática y experiencia en desarrollo profesional. Calculé que seguro, una cartera decente y una carta de presentación probablemente podrían conseguirle una entrevista con una empresa que requiera un "ninja de Rails" o una "superestrella de React" en lugar de un novato como yo.

Pero si el anuncio de trabajo requiere explícitamente más de 3 años de experiencia profesional en JavaScript y una maestría en un campo relacionado con la informática, mis posibilidades de obtener una entrevista probablemente sean muy escasas.

En tercer lugar, que casi todos los anuncios de trabajo mencionaban React. A pesar de todo el bombo publicitario en línea, todavía me asombraba su enorme demanda.

Tan sorprendido que de hecho decidí pasar unas horas al día construyendo una pequeña aplicación web React, usando React.js en la parte frontal y Rails en la parte posterior, para poder agregar eso a mi portafolio y reanudar también.

Para esto, en realidad utilicé principalmente las notas de la única conferencia de React en el campo de entrenamiento de Le Wagon, pero si estaría interesado en aprenderlo, no tendrá dificultades para encontrar guías gratuitas, no menos las de freeCodeCamp.

Excepto por el hecho de que pude incluir React en mi currículum, el mayor beneficio de esta experiencia fue sentirme cómodo con la construcción de una aplicación web usando componentes (en lugar de controladores y vistas, como es el método Rails), y trabajar con accesorios y estado. .

Lo más probable es que tarde o temprano tenga que hacerse amigo de algún tipo de marco JavaScript, y luego estos conceptos serán útiles de cualquier manera, ya sea React, Angular, Vue, Ember o cualquier otro de los miles de marcos JavaScript que existen.

Con nuevos conocimientos como los anteriores, pude desarrollar y refinar los criterios que ya tenía para determinar si un determinado trabajo debería agregarse a mi lista corta o no. Muy pronto tuve una lista de unos 50 puestos de trabajo y llegó el momento de comenzar a enviar solicitudes. Viniendo de una experiencia en la que había solicitado y entrevistado en cientos de empresas, esto parecía la parte más fácil hasta ahora.

Esto podría tener algo que ver con que yo sea el tipo de persona que escribe una carta de presentación genérica que les envío a todos. Sé lo que estás pensando: todos los mentores / maestros / reclutadores con los que has hablado te han desaconsejado esto. Pero vamos. Es una solicitud de empleo. No es el discurso de la boda de tu mejor amigo.

Lo más probable es que el reclutador no gaste más de un minuto en eso de todos modos. Por lo tanto, realmente no importará si menciona el premio que ganó la empresa, o que quedó impresionado por el crecimiento interanual del año pasado, o su opinión totalmente especulativa sobre por qué su cultura es mucho mejor que la de la competencia X.

Lo que importa es que puedas expresar en texto el caso por qué vale la pena que dediquen una hora a conocerte, de una manera convincente, basada en datos y gramaticalmente impecable. Si quieres echarle un vistazo al mío, escríbeme y te lo envío! Recibí comentarios bastante halagadores al respecto, solo digo ...

Lo siguiente que hice fue actualizar mi CV y ​​perfil de LinkedIn. Y aquí no puedo enfatizar lo suficiente la importancia de las palabras clave. Asegúrese de que los nombres de todas las tecnologías que conoce (o quiere fingir que sabe) estén incluidos en ambos. De esta manera, es más probable que aparezca en los resultados de búsqueda (lo mismo aquí, solo pregúntame y te enviaré mi CV).

Después de enviar todas las solicitudes, pasó una semana sin que yo tuviera noticias de ninguna de las empresas. En realidad, resultó ser un período de descanso muy necesario para mí. Me tomé un tiempo para volver a conectarme con los amigos y la familia que había descuidado durante los últimos meses, atrapado por mi nueva obsesión.

Luego comencé a recibir respuestas.

Parte 7: Hacer entrevistas

La primera respuesta vino de una startup realmente joven. Básicamente, estaba formado por dos personas, un ex director ejecutivo bancario y un director de tecnología de desarrollo senior. El correo electrónico era del CTO y me estaba invitando a mi primera entrevista de desarrollador.

Consciente de que las respuestas positivas siempre vendrán antes que los rechazos, traté de mantener la cabeza fría y no emocionarme demasiado.

Pero aún así, el solo hecho de que este tipo, un desarrollador senior con más de 10 años de experiencia, haya revisado mi perfil de LinkedIn, carta de presentación, CV y, lo más importante, mi cartera y el código detrás de él en mi perfil de Github, y todavía pensó Podría escribir un buen código para ellos, me hizo sentir muy orgulloso de mí mismo.

Aunque no pensé que la compañía realmente cumpliera con todos mis criterios (principalmente debido al pequeño equipo y las malas perspectivas salariales), respondí de inmediato y acepté la invitación.

A pesar de todos mis esfuerzos hasta este punto, no había pasado mucho tiempo preparándome para la entrevista técnica . Pero por lo que había oído y leído, se suponía que era un arte en sí mismo y, en muchos casos, algo para lo que la gente pasaba meses preparándose.

A menudo, los alumnos de bootcamp y los programadores autodidactas con más experiencia práctica no pasarán la entrevista técnica debido a su falta de conocimiento en la teoría fundamental de la informática. Al igual que los graduados de CS a menudo fracasarán debido a su falta de experiencia en la creación de aplicaciones con tecnologías modernas.

Pero como me estaba quedando sin tiempo y sin dinero, pensé que esto también era algo que tendría que aprender haciéndolo. Simplemente no podía posponer más la fase de entrevistas. Al igual que me había quemado muchas veces al aprender a hacer el tipo de entrevista financiera, sabía que esas quemaduras eran cruciales para que finalmente averiguara cómo ganar la entrevista. ¿Por qué la entrevista técnica sería diferente?

Así que acepté la invitación y unos días después entré al vestíbulo de su oficina. Me estaban esperando en la recepción.

El lugar era un tugurio. Si alguna vez hubiera visto The Office, se sintió como si acabara de entrar en la oficina de Dunder Mifflin Paper Company. Me dijeron que solía ser una oficina para una gran empresa de auditoría, reconvertida en un espacio de coworking provisional y barato durante el tiempo que quedaba hasta su renovación planificada. Entramos en una sala de conferencias y nos sentamos junto a una gran mesa de madera.

Comenzaron contándome mucho sobre ellos mismos y la empresa. Acababan de lanzar una versión beta de una nueva aplicación Medium-ish para destacados escritores de estilo de vida y habían recaudado un poco de dinero de amigos y familiares en su ronda inicial. Pero aún estaban antes del lanzamiento y, definitivamente, antes de los ingresos.

Después de aproximadamente una hora de lo que se sintió mucho más como un argumento de venta que una entrevista, el CEO se fue y me dijeron que el CTO y yo continuaríamos para la parte técnica de la entrevista. Mi corazón se salto un latido. De todo lo que había leído sobre entrevistas técnicas, esperaba recibir todo tipo de acertijos, desafíos de codificación y preguntas sobre estructuras de datos complejas.

Pero no vino ninguno. En cambio, el CTO comenzó a hacerme todas estas preguntas abiertas.

Como qué tecnologías y frameworks me gustaron. Si pudiera elegir cualquier tecnología nueva para aprender a continuación, cuál sería. Lo que pensé sobre la nueva sintaxis introducida por ES6 (la actualización de Javascript de 2015, que presenta muchas cosas nuevas y geniales como funciones de flecha, promesas y constantes).

Tuvimos una agradable conversación que duró probablemente otra media hora. Pero luego vino la gran reacción, cuando el CTO decidió poner todas las cartas sobre la mesa.

Debido a su difícil situación financiera, me dijo, solo podían ofrecerme un puesto de pasantía de 6 meses con un pago simbólico por ahora (es decir, prácticamente sin pago). Sin embargo, si la pasantía iba bien, estaban muy abiertos a ofrecer equidad y un salario decente.

"Si la empresa todavía existe para entonces", casi agregué.

Aunque me sentí halagado de que me hubieran hecho una oferta en el acto, supe al instante que no era ni la empresa ni el producto que estaba buscando. Sin embargo, no los rechacé de inmediato. Una oferta sigue siendo una oferta, pensé, y siempre puede ser útil cuando se negocia con otras empresas más adelante.

A pesar de la decepción tanto por el trabajo como por el hecho de que la entrevista técnica no me había enseñado nada nuevo, todavía recibí una oferta, lo que me dio un gran impulso de confianza para las próximas entrevistas.

La segunda respuesta que obtuve fue de una startup un poco más grande llamada Teamtailor. Eran una empresa con sede en Estocolmo con la misión de digitalizar la industria de la contratación y la marca del empleador, actualmente dirigida por consultores de contratación y gerentes de recursos humanos sin conocimientos técnicos.

No es una mala idea. Aunque los anuncios de empleo que comenzaran con palabras como "contratación" y "RRHH" en nueve días de cada diez me hubieran asustado, había algo en esta empresa que me intrigaba.

A partir de mi investigación bastante exhaustiva, descubrí que habían existido durante aproximadamente 4 años, tenían unos 30 empleados, presencia en 4 o 5 países, 600 clientes (empresas), una tasa de crecimiento de ingresos de más del 100% y sin perder de vista algún margen en la parte superior. No está mal.

Para colmo, su cuenta de Instagram reveló su oficina: una antigua fábrica de cerveza de ladrillo rojo al estilo de Brooklyn en el medio de Södermalm, la mejor zona que Estocolmo tiene para ofrecer.

MM Mmm.

Todo apuntaba al hecho de que estaban en ese punto óptimo del ciclo de vida de la empresa. Lo suficientemente joven como para poder hacerte sentir como si estuvieras en un viaje juntos, con una cultura informal y mucho espacio para la iniciativa y el crecimiento. Pero todavía tiene la edad suficiente para haber establecido algunas estructuras, en las que puede ser agradable apoyarse cuando está aprendiendo algo nuevo.

De todas formas. Una vez más, fue el CTO quien me escribió. Después de algunos mensajes de ida y vuelta, nos decidimos por una primera entrevista en su oficina unos días después. Me dijeron que tanto él como otro cofundador se reunirían conmigo.

Incluso antes de reunirme con cualquiera de ellos, tuve un muy buen presentimiento sobre todo el asunto. Lo que estuvo mal. Al menos en mi cabeza. Porque ahora entraría en la entrevista probablemente deseándolos más de lo que ellos me querían a mí, pensé. Después de subir las escaleras de la antigua fábrica de cerveza, finalmente llegué a la puerta de su oficina y entré directamente en una escena bastante especial.

Primero, un gran cartel rosa justo en mi cara, con letras blancas en negrita gritándome: "Teamtailor es una de las 100 empresas emergentes más populares de Europa: la revista Wired". A mi izquierda, lo que parecía una sala de estar, donde un grupo de veinteañeros jugaban a FIFA en una pantalla enorme. Frente a mí, una sala más grande, donde la mesa más cercana a mí estaba llena de desarrolladores, casualmente pirateando en grandes pantallas nítidas. Y a mi alrededor, suaves ritmos hip hop pulsando desde los altavoces Sonos.

Justo en ese momento, desapareció cualquier mal prejuicio que hubiera tenido contra ellos por ser una empresa de recursos humanos. Este lugar fue asombroso. Maldita sea.

Se pueden decir muchas cosas malas sobre la típica oficina de aspirantes a Silicon Valley. Pero en mi opinión, incluso la peor oficina de este tipo seguirá siendo mil veces mejor que la típica contraparte corporativa. Así que para mí fue el paraíso. Lo cual fue realmente malo para mi intento de frialdad para la entrevista.

Un tipo alto y delgado con una gorra de béisbol me sonrió y se levantó de su silla para saludarme. Fue el CTO. Entramos en una sala de conferencias con paredes de cristal y césped artificial verde que cubría el suelo. El otro cofundador se unió a nosotros e iniciamos la entrevista.

A diferencia de mi última entrevista, empezaron contándome sobre el proceso en el que me encontraba. El propósito de esta primera reunión era principalmente conocerme mejor. Si procediera, el segundo paso sería una entrevista técnica. Me sentí tan aliviado al escuchar eso. El síndrome del impostor era real.

La primera pregunta fue más o menos la clásica "¿Por qué quieres ser desarrollador?" Me dijeron que más que nada, fue mi carta de presentación y mi CV lo que les llamó la atención. Encontrar desarrolladores con mentalidad empresarial era poco común, y encontrar desarrolladores con títulos comerciales y experiencia tanto en desarrollo empresarial como en finanzas aún más raro. Entonces, ¿por qué había decidido desviarme de mi camino para seguir este camino totalmente diferente?

Por experiencia en entrevistas, he aprendido que la honestidad es casi siempre la mejor manera de actuar en estos casos. Así que básicamente les dije lo que les dije al principio de este artículo, que odio vender, amo la tecnología y quería hacer la transición al lado creativo de las cosas.

A partir de este momento, la conversación cobró vida propia. En un momento, les dije que si hubiera sabido las cosas que sé ahora, probablemente habría elegido estudiar ciencias de la computación en lugar de negocios. Para mi sorpresa, el CTO se sorprendió por este comentario. Él se rió y me preguntó por qué.

Yo dudé. Me di cuenta de que era una de esas cosas que había dicho porque pensé que era lo que querían escuchar. Me soltó y me dijo que también era un desarrollador autodidacta. La única asignatura que había estudiado en la universidad eran estudios cinematográficos. Eso me sorprendió un poco. Pero había más.

De hecho, ninguno de los 10 desarrolladores de la empresa tenía un título en informática real. Algunos de ellos habían tomado uno o dos años de algún programa de desarrollo web privado, pero la mayoría eran autodidactas.

Escuchar eso de este tipo me hizo muy feliz. Acababa de confirmar lo que mi ex colega Sandra me había dicho un año antes: que no necesitas un título para convertirte en un gran desarrollador. Buen material.

La conversación siguió tan fluida que no fue hasta los últimos minutos cuando me preguntaron por mi carpeta. Solo uno de ellos lo había mirado realmente, y literalmente dijo que solo había "echado un vistazo". Todos atrapados por lo bien que iba la entrevista, les dije que estaría feliz de probar una de mis aplicaciones.

Inmediatamente, sus rostros se iluminaron y se enderezaron en sus sillas, asintiendo con la cabeza. Estaba a punto de darme cuenta de que acababa de cometer un GRAN error.

La única aplicación que fue lo suficientemente buena para mostrársela a estos chicos fue la que hice durante el mes inmediatamente posterior al bootcamp. Y no lo había tocado durante al menos un mes. Conecté mi MacBook a la pantalla grande frente a nosotros e ingresé la URL en el navegador.

La primera vergüenza fue que, literalmente, tomó 20 segundos cargar la página de inicio. Con la garganta seca, traté de explicar que estaba usando la versión gratuita de Heroku, lo que significaba que cada vez que el servidor asociado con el dominio no recibía ninguna solicitud durante más de una hora, entraba en este "modo de suspensión". de la cual tardó mucho en despertar. Lo último que quería era que pensaran que mi aplicación era lenta.

Cuando realmente se cargó, me tomé un tiempo para explicar la idea detrás del producto. Básicamente, era un servicio para crear líneas virtuales, que permitía a organizaciones como aerolíneas, bancos y hospitales configurar colas en línea en lugar de en sus ubicaciones físicas.

Luego vino la segunda vergüenza. Cuando intenté iniciar sesión en mi cuenta usando la autenticación de Facebook, falló. Como me di cuenta demasiado tarde, la razón fue que no había actualizado la URL en la configuración de la API de Facebook después de obtener un nuevo certificado SSL. Entonces, Facebook esperaba solicitudes de un // dominio, mientras que la mía provenía de un // dominio. Error de principiante.

Finalmente logré iniciar sesión manualmente y demostré algunas de las características principales sin ningún problema. Pero luego vino la mayor vergüenza de todas. Parece que no pude hacer funcionar la joya de la corona de mi aplicación: el chat. Cuando hice clic en el enlace del chat, llegué a la página del chat, pero no pude ver a ninguno de mis usuarios falsos con quien conversar.

Entonces básicamente me di por vencido. Lo cual realmente no debería haberlo hecho. Porque solo unas horas después, me di cuenta de que el chat funcionaba perfectamente. Mi cuenta de usuario simplemente no se había registrado en ninguna línea para participar, por lo que tampoco pude ver a ningún usuario con quien chatear.

Nos despedimos y me dijeron que se pondrían en contacto. Salí de la entrevista sintiéndome enojado y decepcionado. ¿Por qué no me había preparado mejor para la demostración? Todo había ido tan bien hasta la última parte.

Sin embargo, no pasaría ni una hora hasta que David me escribiera de nuevo. Me dijo que había pasado al siguiente paso del proceso. No podía creerlo y no podría haber estado más feliz. Pero, por supuesto, también un poco asustado de aceptar mi primera entrevista técnica real.

Sin embargo, al final, esta segunda entrevista tampoco resultaría en nada como todas las historias de terror que había leído en línea. Ya en el correo electrónico de invitación, el CTO me dijo que me reuniría con dos de sus desarrolladores senior y que simplemente querían que mostrara una de mis aplicaciones más a fondo, junto con el código detrás de ella.

El objetivo principal sería comprender qué tan bien conocía su marco de backend (Rails) y qué tan rápido podría aprender su marco de frontend Ember.js (del que ni siquiera había oído hablar en este momento).

Supe al instante que la aplicación de demostración tendría que ser la que había creado usando Rails y React.js. Fue perfecto por dos razones:

  1. fue construido en Rails integrado con un marco de JavaScript (al igual que su pila), y
  2. Aprendí todas las cosas de React que usé en menos de dos semanas, lo que les daría una buena idea de lo rápido que podría aprender Ember.

Este caso es un ejemplo perfecto de por qué puede valer la pena no poner todos los huevos en una canasta cuando está construyendo su cartera, sino probar algunas pilas diferentes.

Muy pronto llegó el gran día y yo estaba de vuelta en su oficina en otra de sus salas de conferencias con piso de césped falso. Comencé mostrando el flujo de la interfaz de usuario de la aplicación.

Navegué por la aplicación web y pronto el título provisional "AppHunt" se iluminó en la pantalla con grandes letras moradas en negrita. Era algo así como Product Hunt, pero más como un mercado estrictamente para aplicaciones. Por lo tanto, cualquier usuario podría navegar por la página de inicio en busca de aplicaciones para la venta y la compra. Y si crearan una cuenta e iniciaran sesión, también podrían buscar y filtrar los elementos de la aplicación, calificarlos y escribir cosas en los campos de comentarios. Eso fue básicamente todo.

Pero afortunadamente para mí, fue suficiente. A los dos desarrolladores senior aparentemente les gustó tanto lo que les mostré que le dieron el visto bueno al CTO. Luego me contaron algunas cosas que les gustaron específicamente:

  • Que las funciones en tiempo real, como los cambios en los comentarios, los resultados de búsqueda y las calificaciones que aparecen instantáneamente, demostraron que sabía cómo usar el estado y los accesorios, lo cual es crucial en cualquier marco de JavaScript.
  • Que usé JBuilder para serializar las solicitudes JSON entre frontend y backend.
  • Que utilicé Elasticsearch para la función de búsqueda.
  • Que les gustó el diseño y que yo mismo hice mis bocetos en Sketch antes de comenzar a codificar.
  • Que el código CSS no tenía un estilo ni estaba anidado de manera muy contextual. En cambio, encontraron que gran parte de ella se podía reutilizar en toda la aplicación, lo cual era bueno. Sin embargo, una cosa que los habría dejado aún más impresionados, me dijeron, habría sido si también hubiera seguido la llamada convención de nomenclatura BEM CSS.

No fue hasta unas semanas después de la segunda entrevista que el CTO se acercó a mí nuevamente con una oferta. Después de algunas discusiones de ida y vuelta, establecimos un período de prueba de 6 meses, con un salario mensual de $ 3,300 que se elevaría a mi objetivo de $ 3,700 cuando alcanzara un nivel productivo.

Acepté de inmediato y comencé mi nuevo trabajo la semana siguiente. ✌️

Paralelamente a todo el proceso de Teamtailor, también entrevisté a otras 4 empresas. El más notable fue el fenómeno fintech sueco iZettle, que es una especie de paraguas de varios productos financieros diferentes, pero donde su terminal de tarjeta inalámbrica es probablemente el más conocido.

A medida que esta exitosa startup se acercaba a una valoración de unicornio, me enteré de que sus demandas de experiencia y nivel de habilidad eran significativamente más altas que las de las startups más pequeñas para las que había entrevistado hasta este momento. Lo vi tanto en el proceso de selección mucho más completo que tuvieron (¡5 entrevistas!) Como en el nivel de dificultad de las preguntas de la entrevista.

La razón principal por la que un novato como yo consiguió una entrevista allí en primer lugar, diría que se debe en gran parte a la recomendación de un amigo y al nombre de la escuela de negocios de la que me gradué. Así que en cierto modo hice trampa para entrar, diría yo. Pero obviamente no estaba preparado para ellos.

Al igual que con las otras empresas, la primera entrevista fue pura tontería y habilidades blandas. Pero aún más "RRHH" esta vez. ¿Por qué quieres trabajar como desarrollador? ¿Qué tecnologías te gusta usar? ¿Cuáles son sus fortalezas / debilidades? Y así. Cosas fáciles.

La segunda entrevista, sin embargo, resultaría una experiencia bastante traumática. Todo comenzó conmigo sentado en una sala de conferencias con dos de sus desarrolladores web. Repetimos toda la conversación de "conocernos" y me sentí bastante cómodo y seguro. Y luego recibí el golpe más grande de mi vida.

De la nada, el chico del otro lado de la mesa me entregó un enorme papel A3 blanco y un bolígrafo. Me dijo que querían que dibujara un bosquejo de los flujos de datos y los procesos involucrados en el siguiente escenario:

“El propietario de una pequeña empresa tiene una cuenta con iZettle y usa su terminal de tarjeta. Después de que uno de sus propios clientes haya realizado una compra utilizando el terminal, quiere iniciar sesión en la aplicación web o la aplicación móvil para ver la transacción "

Esto realmente me tomó por sorpresa, pero asentí vacilante y acepté el desafío. Luego, el tipo dijo algo como: "Iremos a tomar un café, y luego en 5 minutos más o menos regresaremos y te dejaremos explicar tus pensamientos".

¡5 minutos! ¿Eso fue una broma? Realmente no podría decirlo. Cuando se fueron, consideré seriamente si se trataba de una especie de pregunta capciosa, en la que se suponía que debía darme cuenta de que esta tarea era demasiado grande para realizarla decentemente en tan poco tiempo. Pero el tiempo ya se estaba acabando y era un riesgo demasiado grande. Así que decidí intentarlo.

En retrospectiva, me doy cuenta de que era una pregunta de diseño del sistema, lo que significa que querían que básicamente solo mapeara una vista general de cómo la aplicación web y la aplicación móvil realizaban solicitudes a alguna API que las conectaba al servidor (s) y la base de datos (si desea mejorar sus habilidades de diseño de sistemas, realmente recomiendo este canal de Youtube).

Pero no hice nada de eso. En mi estado de pánico, salté varios pasos y comencé a intentar dibujar el modelo de base de datos de la cuenta de usuario, con una tabla, columnas y claves externas (asumí que usaban una base de datos relacional). Cuando terminé con eso, me quedaban unos 30 segundos para mapear los otros componentes de la arquitectura. Estaba tan estresado que me puse filosófico y comencé a cuestionar cuáles eran los roles reales de la API y el servidor. No es buena señal.

Pasaron 5 minutos, y los dos desarrolladores volvieron a un boceto apenas digno de un niño de 5 años. Básicamente, solo dibujé tres círculos. Uno a la izquierda, que representa la base de datos, y dos a la derecha, que representan los clientes de aplicaciones web y móviles.

Por supuesto, fallé miserablemente en la entrevista. Esa fue también la razón por la que no pasé a una tercera. Sin embargo, me decepcionaron fácilmente, diciéndome que les agradaba y que debería presentar mi solicitud nuevamente cuando tuviera uno o dos años más de experiencia.

Toda la experiencia me desanimó, ya que no creía haber tenido la oportunidad de mostrarles mis habilidades prácticas. Aunque puedo ver que hay algún tipo de valor en poder ilustrar la arquitectura del sistema en una hoja de papel, realmente creo que hay mil veces más valor en poder mostrar sus habilidades con un ejercicio práctico, como una codificación. desafío o demostración de la aplicación. Pero bueno, hay una lección que aprender en cada fracaso, ¿verdad?

En total , durante mis 4 semanas de búsqueda de empleo terminé asistiendo a 11 entrevistas para 6 empresas, de las cuales 3 me hicieron ofertas. Entonces, a pesar de haberme quemado varias veces, fue realmente una experiencia increíble. Si me pidieran que nombrara la recompensa más grande (excepto por obtener la oferta de mis sueños), sería que me sintiera cómodo hablando con los desarrolladores sobre software . Si padeces el síndrome del impostor como yo (búscalo, es una cosa), simplemente no hay mejor manera de tratarlo.

Otra conclusión clave es que de mis 11 entrevistas, solo una resultó requerir conocimientos teóricos reales de informática. Sin preguntas sobre estructuras de datos complejas, sin acertijos tortuosos. Solo una pregunta sobre la arquitectura del sistema. El resto se centró al 100% en habilidades prácticas o blandas. Entonces, a menos que esté solicitando un trabajo de ingeniería de software llamativo en Google o Facebook, definitivamente recomendaría concentrarse en las cosas prácticas y aprender las teóricas más tarde.

Por último, me gustaría enfatizar el hecho de que no conocía a nadie involucrado en la empresa por la que terminé siendo contratado. Sé que hay mucho contenido que afirma que una red personal sólida es el factor más importante para conseguir el primer trabajo de desarrollo. Y aunque eso podría ser cierto estadísticamente, la aplicación en frío sin un referente definitivamente no es una pérdida de tiempo.

Parte 8: Qué hago hoy

En el momento de escribir este artículo, he estado trabajando en Teamtailor durante seis meses. Y el tiempo realmente ha pasado más rápido de lo que podría haber imaginado. Apenas he notado el invierno largo, oscuro y helado que suele ser una lucha para soportar aquí en Estocolmo.

Soy parte de un equipo de 12 personas, donde todos, excepto un diseñador, son desarrolladores completos de Rails y JavaScript. Algunos tienen más de 10 años de experiencia, algunos solo unos pocos años, pero solo dos tienen títulos académicos en tecnología. El resto de nosotros somos más o menos autodidactas.

Paso mis días pirateando nuestra plataforma Rails / Ember, todos los días tratando de dejar la aplicación un poco mejor de lo que la encontré esa misma mañana. El producto en sí es una aplicación web de contratación que permite a las empresas crear y gestionar sus propios sitios profesionales, sin esfuerzo y sin necesidad de tener conocimientos de codificación.

A su vez, la aplicación detrás de este sitio de carreras tiene dos dimensiones principales:

  1. Permite a los usuarios manejar la marca del empleador destinada a atraer talento, con medios como publicaciones de trabajo, contenido de redes sociales, un blog, imágenes, videos y gifs.
  2. Ofrece un conjunto masivo de herramientas para manejar el tráfico y los solicitantes, como rastrear a los candidatos, chatear, enviarles correos electrónicos y mensajes de texto, evaluarlos con pruebas, configurar activadores automáticos para ejecutar alguna acción cuando un candidato se mueve de una etapa a otra, y promocionar anuncios de empleo en las principales bolsas de empleo, por nombrar algunos.

Cómo trabajamos

En nuestro equipo de productos, hacemos todo lo posible para seguir los principios ágiles de Scrum, Kanban y la programación de pares. En la práctica, para nosotros esto significa que llevamos a cabo nuestro trabajo en ciclos, donde dividimos la implementación de nuevas funciones en proyectos que se ejecutan durante 6 semanas a la vez. A su vez, cada proyecto tiene desarrolladores emparejados dos y dos, y se hace responsable de enviar las nuevas funciones dentro de esas 6 semanas. Los pares despliegan su trabajo de forma continua, basándose en un tablero Trello predefinido de tareas más pequeñas dentro de cada función planificada.

Por supuesto, no solo construimos cosas nuevas. También mantenemos la aplicación. Y en el núcleo de este mantenimiento tenemos lo que creo que es una rutina bastante inusual: el deber de "técnico de guardia". Esto significa una posición rotativa semanal en la que cada desarrollador pasa una semana entera ayudando a nuestros usuarios y personal de soporte en Intercom.

Si cree que esto suena como una tarea frustrante y molesta, lo fue. Hasta que decidimos que cada técnico de guardia detendría todos sus otros proyectos mientras estaba en servicio de soporte. Entonces, de repente, cuando ya no sentía que cada minuto que pasaba en Intercom era un minuto robado de mis proyectos y plazos, comencé a disfrutarlo.

Piénselo: cuando se toma el tiempo para escuchar, se da cuenta de que básicamente tiene un ejército de probadores voluntarios de control de calidad a su disposición, siempre listos para brindar retroalimentación instantánea sobre la experiencia de usuario real del producto y los puntos débiles del usuario. Teniendo esto en cuenta, basta con decir que he aprendido tanto de mis semanas de servicio técnico como de cualquier otro proyecto o error en el que he estado trabajando.

Por último, entre cada ciclo de 6 semanas, nos tomamos dos semanas para hacer un esfuerzo común para eliminar todos los errores alineados en nuestro tablero de errores de Trello. También usamos estas dos semanas para desarrollar presentaciones de nuevas funciones que a nosotros mismos nos gustaría ver en la aplicación. Luego, cada desarrollador tiene la oportunidad de presentar estas ideas en una reunión de presentación compartida que tenemos cada 8 semanas, lo que realmente fortalece a alguien que no solo busca resolver problemas de código difíciles, sino también problemas comerciales a través de nuevas adiciones interesantes al producto existente. .

Lo que he hecho hasta ahora

Aunque la aplicación incluye tantas funciones y tecnologías que al principio me eran completamente ajenas, ya estaba en medio de la acción en mi segunda semana. El proceso de incorporación, es decir, que un desarrollador senior me enseñe las cuerdas, duró solo cinco días. Después de esa primera semana, en teoría, se suponía que yo sería más o menos autónomo.

Esto significaba que se esperaba que entendiera la arquitectura de la plataforma, el kit de herramientas de desarrollo, el flujo de trabajo del equipo, nuestra guía de estilo, cómo brindar soporte técnico a usuarios y colegas, y otras rutinas internas para desarrollar, probar, depurar, revisar e implementar código. . En otras palabras, MUCHAS cosas nuevas para alguien que acaba de salir de un campo de entrenamiento.

Si está entrando en pánico en este momento porque cree que realmente aprendí todo eso en una semana, relájese. Definitivamente no lo hice. No fue hasta después de unos meses que comencé a sentirme cómodo con la mayoría de esas cosas. Y con el tiempo, los demás se darían cuenta y me confiarían cada vez más responsabilidades. Desde entonces, he llegado a ser parte de algunos de los proyectos más emocionantes y desafiantes en los que he trabajado.

El primero serio fue actualizar el método que usamos para buscar información sobre los usuarios que se registraron en nuestra aplicación con solo un correo electrónico. Ya nos habíamos integrado con una API de terceros para esto, a la que hicimos solicitudes para obtener datos como nombres completos y URL para perfiles de redes sociales e imágenes de avatar.

Sin embargo, dado que descubrimos que los datos obtenidos a menudo eran incorrectos, el equipo de producto decidió cambiar a otro proveedor. Dado que me expondría a varias áreas cruciales y flujos de datos de la aplicación, fue el siguiente paso perfecto para mí.

Para implementarlo, tendría que navegar desde obtener el correo electrónico de la entrada del usuario en la parte frontal de la capa del cliente, hasta comprender cómo viajarían los datos desde la interfaz Ember, a través de adaptadores y serializadores al backend de Rails y finalmente se almacenan en la base de datos.

Mi segunda característica fue desarrollar lo que llamamos el "botón de llamada a la acción", lo que significa que permitiríamos a nuestros usuarios agregar botones personalizados a sus sitios de carreras en nuestra herramienta de edición.

Por ejemplo, queríamos permitirles redirigir a la página de una determinada oferta de trabajo, un determinado departamento o alguna URL completamente externa. En realidad, esto resultó ser mucho más fácil de lo que esperaba. La mayor parte de la arquitectura de backend ya estaba en su lugar, así que todo lo que tenía que hacer era básicamente crear algunos componentes nuevos de Ember y agregarlos a las otras opciones en el editor del sitio de carreras.

La tercera característica en la que trabajé fue permitir que nuestros usuarios se integraran con proveedores de evaluación externos, lo que significa que podrían enviar candidatos a una plataforma de prueba como Hackerrank. Cuando terminaron una prueba, los resultados se enviarían automáticamente a través de una integración entre nuestras API y las del proveedor. Este fue uno grande, por lo que actué principalmente como asistente del desarrollador senior (también conocido como el gran maestro Ember de nuestro equipo) responsable del proyecto. Aún así, me enseñó mucho sobre cómo configurar correctamente una integración de API y automatizar flujos de trabajo con activadores.

Mi cuarto proyecto fue el más grande hasta la fecha, y para bien y para mal terminé haciéndolo más o menos por mi cuenta. La aplicación completa se había construido originalmente en Rails, y la mayoría de las vistas se habían reescrito con JavaScript y Ember una por una. Solo una de nuestras secciones principales de la aplicación todavía tenía solo vistas de Rails. Era la sección denominada "Empleados", que era básicamente el destino principal para crear, editar y eliminar cuentas de usuario. Así que era muy importante que mi traducción a Ember fuera perfecta.

Lo que me estresó como loco. Como había estado en el equipo durante unos tres meses en este punto, pensé que era hora de dejar de actuar como un interno molesto y comenzar a trabajar de manera más independiente. Lo que significa que traté de molestar a los demás con la menor cantidad de preguntas posible. Lo bueno de esto es que tengo mucha confianza en mi capacidad para resolver problemas de software del mundo real por mi cuenta. Lo malo, sin embargo, fue que me hizo muy lento y que me tomó unas buenas 6 semanas enviar la reescritura completa de más de 2,000 nuevas líneas de código.

Al final, esta incluso resultó ser la razón principal por la que no obtuve el aumento que el CTO y yo habíamos acordado, ya que no había cumplido con mi parte del trato: no había alcanzado un nivel productivo. en línea con el resto del equipo .

Aunque esto apestaba en ese momento, ahora me doy cuenta de que su punto de vista era completamente justo y me enseñó una lección importante. En el mundo del desarrollo de software ágil, el lobo solitario no es una opción. El trabajo en equipo es una parte importante para encontrar un flujo de trabajo productivo.

El quinto proyecto es el último hasta la fecha y, de hecho, lo acabamos de enviar. Fue nuestra nueva característica para manejar la nueva legislación europea de privacidad de datos (GDPR) emergente. Para nosotros, eso se tradujo en herramientas de construcción que facilitaron que los candidatos de nuestros clientes borren sus datos personales de nuestra base de datos, y también para que nuestros clientes les pidan permiso para almacenar y seguir almacenando sus datos.

Suena bastante sencillo, ¿verdad? Bueno, no lo fue. En absoluto.

Creo que la razón principal fue que no podíamos concentrarnos en un solo destino de la aplicación. En cambio, la función nos obligó a agregar cosas por todas partes. Notificaciones en un lugar, banderas de advertencia en otro, filtros de búsqueda y acciones masivas en un tercero y docenas de nuevas acciones de envío de correo electrónico en todas partes.

Por primera vez desde que comencé, me emparejaron con el desarrollador senior y cofundador que me incorporó. Así que sentí que era muy importante para mí mostrarle cuánto había aprendido desde esa primera semana seis meses antes. Mi período de prueba estaba a punto de terminar, y pronto tendrían que tomar una decisión si yo era lo suficientemente bueno para seguir en el equipo. Y con este proyecto "simple", primero pensé que demostrar que sería pan comido.

Sin embargo, por extraño que parezca, creo que las complejidades hicieron que nuestras sesiones de programación en pareja fueran aún mejores. Había tantos escenarios de usuario para tener en cuenta al diseñar cada parte de la arquitectura, que nos vimos obligados a discutir y torcer y convertir cada nuevo bloque de código. Por primera vez, tendría que tener en cuenta no solo la dimensión UI / UX, sino también consideraciones legales extensas, que podrían causar muchos problemas a nuestros usuarios si no la implementamos correctamente.

Así que programamos mucho en parejas, y fue realmente genial. Cuando codifiqué, vino con una gran cantidad de comentarios positivos que, en su mayoría, hicieron que mi código fuera mucho más limpio. Pero a diferencia de esa primera semana de incorporación, en realidad también pude dar comentarios sobre su código, hacer sugerencias y hacer preguntas que realmente mejoraron su código.

Cuando estás en un estado de desarrollo intenso, como lo he estado yo durante el año pasado, creo que es difícil cuantificar cuánto han mejorado tus habilidades en un momento dado. Entonces, poder brindar comentarios constructivos a este tipo, con más de 15 años de codificación en su haber, realmente puso la escritura en la pared para mí.

Y, por cierto, también lo hizo la extensión de mi contrato de trabajo de prueba de 6 meses, del que me enteré recientemente. De ahora en adelante, soy un empleado regular a tiempo completo, ¿con el salario que pedí inicialmente hace seis meses? ?

Parte 9: Por qué convertirme en desarrollador es lo mejor que he hecho

Como probablemente ya se habrá dado cuenta, estoy enamorado de la codificación.

Me encanta que me siga forzando a superar mis límites intelectuales mediante la resolución cuantitativa de problemas.

Me encanta que me brinde una salida para las expresiones creativas al diseñar cualquier cosa, desde la interfaz de usuario hasta la arquitectura del sistema.

Me encanta que me brinde mil soluciones diferentes para cada problema del mundo real.

Me encanta que no solo tolera mi perfeccionista interior, sino que en realidad requiere que ese perfeccionista esté presente y castiga su ausencia.

Me encanta que me rodee de personas que valoran la autenticidad y la transparencia por encima de las conversaciones triviales y la cortesía.

Me encanta que, en mis días introvertidos, me permite ponerme los auriculares, remangarme y sumergirme en otra dimensión por un tiempo.

Me encanta que siempre me depare algo nuevo que aprender y que me requerirá ser un aprendiz de por vida, a diferencia de muchas otras profesiones estancadas.

Pero sobre todo, me encanta que la codificación me haya dado la sensación de que el futuro es verdaderamente ilimitado.

En unas semanas cumpliré 27 años y no tengo ni idea de lo que me depara el futuro. En tres años, por lo que sé, podría estar todavía en la misma posición que ahora, escribiendo código para la misma empresa. Podría ser un desarrollador líder. Podría ser propietario o gerente de un producto. O podría estar en un lugar completamente diferente.

Trabajando como autónomo de forma remota desde un paraíso soleado. Desarrollo de aplicaciones descentralizadas en una cadena de bloques disruptiva. Diseñar modelos de aprendizaje automático para combatir el calentamiento global. Escribiendo algoritmos de naves espaciales para expediciones a Marte. O construyendo mi propio producto.

Todos los escenarios anteriores me habrían parecido completamente locos antes de comenzar a codificar.

En el mejor de los casos, mis trabajos anteriores en finanzas me dieron la leve satisfacción de haber elaborado una presentación de PowerPoint gruesa llena de curvas de KPI con pendiente ascendente. Y el mejor escenario futuro posible que se me ocurrió entonces fue conseguir un puesto de director financiero o director ejecutivo en alguna empresa que cotiza en bolsa después de dedicar una década de mi vida a semanas laborales de 100 horas en algún banco de inversión, firma de capital privado o consultoría de gestión. Pasé mis días con personas a las que les importaba más el dinero y el prestigio que tratar de hacer algo significativo con sus vidas. Y eso me asustó.

Hoy, no hay ningún escenario futuro probable que me asuste en absoluto. Y solo eso me da la certeza de que mi viaje torcido durante los últimos tres años ha tenido un propósito.

Aunque es un poco triste que invirtiera tanto tiempo y energía en una carrera que resultó ser un callejón sin salida, sé que fui realmente afortunado de darme cuenta de eso a los 23 años, y de tener el lujo de poder hacer detenerme, mirar a mi alrededor y perseguir algo que me apasiona más.

Tan bueno o malo, supongo que fue la suma de todas mis experiencias lo que me llevó a donde estoy hoy. Un lugar donde de alguna manera me las arreglé para encontrar algo que pocas personas hacen, un trabajo que amo . Y por eso estoy más agradecido de lo que las palabras pueden expresar.

¡Felicidades! Ya que lo hizo hasta el final de este artículo MUY largo, debe estar tan loco como yo. Originalmente tenía dos intenciones con este texto: procesar mis fracasos y éxitos de los últimos tres años e inspirar a otros en caminos similares al mío. Considero el primero completado. Entonces, si tiene alguna pregunta o comentario, ¡contáctenos! Ya sea en los comentarios a continuación o en [email protected]