Procesos de selección: agobio, estrés y aprendizaje.

Aunque tenga solo un poco más de un año de experiencia, he estado en varios procesos de selección, tanto cuando estaba buscando mi primer trabajo, como las veces que he cambiado de trabajo. Quiero contarles cómo han sido las entrevistas y pruebas técnicas que me han hecho, espero te pueda ayudar en algo.

ES UN POST LARGO. Sorry.

Tipos de pruebas técnicas que he tenido y cómo las he resuelto (o intentado resolver):

Prueba de código o code test.

Te dan una especie de historias de usuario y unos requerimientos para que la desarrolles en X días. He tenido 3 de este tipo.

Primera:

Esta fue mi primera entrevista. El primer día tuve 3 entrevistas, primero con el Product Owner, luego con el equipo técnico (un back y un android) en el que sólo me preguntaron qué tal Adalab y qué había aprendido; y luego con la CEO. Dos semanas después me enviaron la prueba de código. Tenía que documentar todo lo que hacía, lo que no sabía, lo que investigaba, etc en el README. Me pidieron hacer un buscador de series. Pero no me daban API, así que pregunté y me dijo que tenía que “mockearla”. No tenía ni idea de qué significaba “mockear una API”. Así que investigué y la hice con Postman (era muy sencillo, pero el término asustaba). Todo lo que no sabía y que tuve que investigar para implementarlas, se lo dejé por escrito en el README. Unas 3–4 semanas después me escribió la CEO para hacerme una oferta. El feedback de la prueba fue que les gustó mucho el nivel de resolución y de intentar e investigar aunque no lo supiera. Este fue mi primer trabajo.

Conclusiones de esta prueba:

• No te quedes de brazos cruzados porque no sabes algo, averigua, investiga, lee… que muchas veces nos piden cosas que nos intimidan, pero luego lo aprendes y era una tontería y puedes decir “no sabía hacer esto, pero lo aprendí y aquí lo hice” . Quedas bien, resolutivo y además te llevas ese conocimiento.
• ¡Pregunta! quizás él daba por hecho que yo sabía que tenía que “mockear una API” y por eso no dijo nada al respecto. O quizás ellos dejan estos “vacíos” a posta para ver si tu preguntas =P

Segunda:

Esta no la logré hacer dentro del tiempo estipulado pero porque era UNA LOCURA para hacerla en 2 horas. Primero tuve una entrevista con el CTO, me preguntó sobre mí, mi trayectoria, tecnologías que he usado, etc. Luego me envió un enlace que en lo que lo abres, tienes 2 horas para terminarlo. Me dijo “no te asustes porque es algo muy sencillo y solo queremos ver la manera en la que programas, cualquier cosa me escribes y me preguntas”. Bueno, ni sencillo ni corto. La primera hora se me fue intentando organizar lo que había que hacer y creando el repo 😂. De solo leer la prueba, ya comencé a llorar riéndome y sudando porque era algo que no iba a lograr ni en dos días. Le escribí para saber si podía tomarme más tiempo y nunca me respondieron. Era una prueba fullstack, tenía que hacer parte de servidor con base de datos, más la parte del cliente, más unos esquemas ahí locos que en la vida había hecho…. en fin, que se terminó el tiempo y les dije “lo siento, esta prueba se escapa de mis capacidades, quizás en otro momento cuando tenga más experiencia”. La verdad es que me enfadó, porque no sentí que era una prueba muy grande para mí, yo creo que la hubiera podido hacer con más tiempo. Me pareció de coña el tiempo. De hecho, le envié los requerimientos a un amigo que es muy crack y me dijo que la única manera de terminar esa prueba en dos horas era mínimo con un boilerplate.

Tercera:

Esta fue una prueba que disfruté y aprendí muchísimo. Lo único malo es que fue un proceso muy largo y que al final no quedé ☹️. Fue una oferta que vi de casualidad y me gustó tanto cómo estaba redactada y diseñada que lo intenté.

Era una prueba en la que lo más importante era cómo te organizabas tu, al proyecto y la separación de responsabilidades (arquitectura, que me cuesta mucho ver y pues, fui ahí donde me caí jaja). Había que hacer un login que devolviera un token y tenía que implementarse con CI (Jenkins o Github Actions) y una de las US ponía que no tenían aún la parte de back, por lo que había que simularlo todo. Como no ponía expresamente que había que implementar la API (cosa que hubiera podido hacer, pero he aprendido que quizás si algo no te lo piden, no lo tienes que hacer y debes ceñirte a lo que te piden) pues simulé la llamada con promesas y un set time out. El tema de la CI me tenía asustada, pero averigué, leí e investigué y resulta que configurar las Github Actions no es nada del otro mundo y me emocionó muchísimo aprender a configurar que si no hay un mínimo de 80% de cobertura de los test ni el linter pasando, no te dejaba hacer push a master ¡Me encantó!

Al mes y medio más o menos (sí, demasiado) me dijeron que les gustó mi prueba y querían hacerme una entrevista. He aprendido que no hay que dar nada por hecho y que preguntar no está mal y que de hecho, del otro lado puede que no se tomen muy bien que no preguntes, porque pueden tomarlo como una falta de interés. Yo al principio pensaba distinto, pensaba que sonreír y decir que todo está bien y perfecto era lo ideal porque “no pones muchas pegas” y realmente, eso es un error. Además que estamos en nuestro derecho de preguntar. Luego más abajo les digo las preguntas que suelo hacer yo.

Entonces pregunté que de qué tipo era la entrevista, si era otra técnica o era más de RRHH y menos mal que pregunté, porque era técnica y sobre estos conceptos: patrones de diseño, testing, POO, Programación funcional, recursividad, patrones de arquitectura, principios SOLID. Y una entrevista así no te puede agarrar fuera de base, tienes que prepararte (a menos que te lo sepas todo, aunque bueno, si te lo sabes todo igual no estás leyendo esto).

Yo antes no tenía ni idea de ninguno de estos conceptos. Pero hice el curso de JS avanzado de Fictizia en donde los aprendimos. Así que cogí mis apuntes y volví a estudiarlos.

Aquí hago un poco de spoiler sobre “Entrevistas con preguntas técnicas”. Esta entrevista fue para ver un poco si conocía estos conceptos y si sabía cuáles había implementado en mi prueba; o que por qué tomé esta decisión de hacer esto así, cómo podría hacerlo de otra manera, etc. Yo siento que me fue genial y que me desenvolví muy bien. Lo que más me gustó fue que lo que no sabía, mi entrevistador muy majo y abierto me lo explicaba, así que aprendí muchísimo.
Yo sabía que aquí estaban buscando a alguien muy crack, no me esperaba entrar aunque siempre me quedaba un poco de esperanza 🙃. Efectivamente, no quedé, pero me dieron muy buen feedback.

Conclusiones de esta prueba:

• Aunque me puso muy triste no quedar, aprendí mucho y estaba muy contenta con mi desempeño. Esto es muy importante y me di cuenta luego hablándolo con un amigo. A pesar del rechazo, no sentí ni que había perdido mi tiempo, ni me sentía fracasada. De hecho, se de gente que hace pruebas técnicas aunque no tengan pensando cambiarse; tengo entendido que lo hacen para aprender, para ver qué cosas han cambiado, qué se está pidiendo y sobretodo para el feedback. Yo creo que hay dos tipos de feedback, el que te dan al terminar la prueba cuando te rechazan o aceptan y el que se recibe durante la entrevista, que depende de la actitud del entrevistador, qué tan abierto es, las ganas que tiene de estar ahí, si te explica las cosas que no sabes, si es receptivo, majo… todo cuenta.
• Voy a sonar un poco Mr Wonderful, perdón, pero trata de quedarte con lo que has aprendido, sea para bien o para mal. Ya te rechazaron, no puedes hacer nada. Seguro que lo has hecho genial pero, quieras o no, no eres el único en el proceso.

Prueba de algoritmia de pizarra en blanco:

La he tenido solo en un proceso, pero fueron dos pruebas. Fue un proceso que también me encantó porque aprendí mucho, aunque también me agotó. Tuve que estudiar mucho y las pruebas en sí fueron muy estresantes.

Primero tuve una entrevista con RRHH, aquí fueron muy claros en contarme que son muchos pasos y que las pruebas técnicas eran de algoritmia de pizarra en blanco. Yo no había hecho nunca una y la palabra algoritma me asustaba. Bueno, me sigue asustando. En Adalab tuvimos una sesión con Javier Abadía sobre pruebas de pizarra en blanco, pero claro, al nivel de cuando estamos saliendo de Adalab. Las de este proceso tenían un nivel un poco más avanzado 🤯. Investigué sobre estas pruebas y conseguí MUY poco material. Pedí ayuda a un amigo y me dijo que son las típicas pruebas que hacen en Google, así que me pasó unos vídeos (están al final del artículo) que me ayudaron muchísimo a entender qué es lo que realmente se quiere en estas pruebas: quieren saber cómo piensas, cómo resolverías el problema, cómo vas para atrás si te das cuenta que lo que estás haciendo no es la mejor vía, cómo te generan nuevas ideas, etc.

Trucos para estas pruebas:

• SIEMPRE piensa en voz alta, ellos lo que quieren es escucharte.
• Di todo lo que se te pase por la cabeza. Bueno, no seas como yo y trata de evitar el “uff, estoy sudando”, que literal lo dije y salí de esas pruebas con la camisa mojada del estrés (también era Agosto a las 5pm).
• Lee el problema en voz alta las veces que necesites, conviértelo en tus palabras.
• PREGUNTA. Por ejemplo, a mi me pidieron ordenar un array de números: “entonces lo que tengo que hacer es ordenar este array de menor a mayor? y puedo crear otro array vacío? puedo tener una variable donde ir guardando?” Ellos quieren que los involucres e intervenir, que sea una especie de “pair programming”, que digas “ah pero si yo hago esto, pasa esto, ¿¿verdad??” y ellos te van a responder. No están ahí para juzgarte ni pensando en qué perdido estás.
• En esta sesión que comenté más arriba que tuvimos con Javier Abadía sobre pruebas técnicas, nunca se me va a olvidar lo que nos dijo: El entrevistador no es tu enemigo, él quiere que seas seleccionado, porque sino, no te hubieran llamado ni estuviera perdiendo una hora de su tiempo delante de ti, él te quiere ayudar.

En esta primera prueba, a pesar de que salí con la camisa mojada del estrés, me gustó mucho. Me sentí muy apoyada y lo mejor es que lo logré resolver (con dos bucles, pero lo logré 😅). Luego me hicieron preguntas sobre mi trayectoria, sobre mi cambio, sobre herramientas y tecnologías con las que he trabajado, sobre metodologías ágiles, etc. Fueron muy majos. Creo que el éxito de estas pruebas depende del entrevistador. Tiene que ser alguien que facilite el proceso, que te ayude e intervenga. Si te toca alguien que no está en su mejor día o que te hace sentir que no quiere estar ahí, todo puede salir muy mal y puedes salir muy frustrado.

A la semana y media me dijeron que les había gustado y que pasaba a la siguiente entrevista. Pregunté nuevamente de qué era y me dijeron que era OTRA prueba de algoritmia de pizarra en blanco 😵

Pensé que sería un nivel más difícil, así que seguí estudiando. Me enteré que en Joppy hay un nuevo apartado “challenges” en el que hay varios lenguajes y niveles para ir practicando justamente este tipo de pruebas. Son horriblemente difíciles para mí pero me ayudaron MUCHO. Así que fui más preparada aún.

En esta segunda prueba, era otras personas ( No tan majas y fáciles como las otras…), misma dinámica, otro problema y además en inglés, que por más buen nivel que tengas, es un estrés que se añade. Esta vez tenía que, de un array de números, devolver el índice de los dos números que sumados daban un target. Al principio me cagué, pero luego a medida que iba haciendo la cantaleta en voz alta, fui descubriendo posibilidades y fui tirando y lo resolví bastante rápido (con dos bucles de nuevo😂) y… pues me pidieron optimizarlo y hacerlo con un solo bucle. Ahí ya me pillaron y me hicieron sudar de nuevo 😬, me costó bastante pero al final lo saqué.

Al día siguiente me llegó un correo de RRHH dándome un feedback muy positivo sobre mi comunicación y resolución de problemas, pero que les dieron órdenes de parar las contrataciones y que me hablarían en un futuro. Creo que hubiese preferido un “no quedaste”, que un “sí pero no”😒

Conclusiones de estas pruebas:

• Si logras resolver algo muy rápido y muy eficiente, genial, pero ellos siempre van a pinchar hasta llegar al hueso. Esto también lo aprendí de Javier Abadía. Si te sabes algo, ellos no se van a quedar con eso, siempre van a ir apretando un poco más hasta llegar justo al punto en el que no sepas, pero no por mal, sino por saber hasta dónde es tu nivel. Si por ejemplo lees este post y te aprendes estos ejercicios de algoritmia de memoria, no pienses que tienes las pruebas comidas… porque van a ir un pasito más hasta donde te cueste de verdad y lograr ver tu nivel.

Entrevistas con preguntas técnicas.

Primera:

Esta ya se las comenté anteriormente donde hice spoiler.

Segunda:

Esta fue buscando mi primer trabajo. En un día me entrevistaron RRHH, técnico y PM. La parte técnica eran preguntas básicas de JS y que muchas no supe responder porque no tenía ni idea de lo que hablaba, pero aun así, él me las explicaba y me daba ejemplos así que salí con nuevos conocimientos de ahí también.

Ejemplos de preguntas:

• ¿Es JavaScript mono hilo o multi hilo? Le dije que no tenía ni idea, ni siquiera había escuchado ese término, pero que me aventuraba a decir que era multi hilo porque la asincronía me sonaba a eso 🤣 me explicó por qué era mono hilo.
• Diferencia entre == y === (esta es típica)
• Diferencias entre let y const. Yo en este momento no tenía ni idea del hoisting, ni sabía que se llamaba así. También me lo explicó y me puso ejemplos.
• ¿Qué es una promesa?
• ¿Qué es un closure? Primera vez que escuchaba eso 😂
• Tipos de funciones
• ¿Qué es una función pura?
• Event Loop. Nunca lo había escuchado y me parece que es uno de los conceptos básicos para saber cómo funciona JavaScript que todos debemos saber. Me lo explicó, no lo entendí y al final lo entendí leyendolo 7 veces y viendo GIFs sobre cómo pasa de la queue al stack 🤣
• Buenas prácticas
• Especificidad en CSS.
• No me acuerdo más.

Entrevistas de lápiz y papel

Bueno, yo no entiendo estas pruebas, ¿por qué en un folio? ¿por qué escribir a mano? Me gustaría saberlo de verdad.

Primera.

Tenía que escribir la lógica para multar a coches que pasaran por Madrid Central en ciertos horarios y con ciertas pegatinas. Esta la hice también buscando mi primer trabajo y yo lo que hice fue hacer un churro enorme y horrible de condicionales que no tenía ni pies de cabeza. Evidentemente, no me cogieron. Ah! antes de esta prueba me hicieron una en la que tenía que estimar el tiempo para armar 3 Lego’s… y armarlos, por supuesto.

Segunda.

Aquí me mandaron a hacer el HTML de un input y un botón (Creo recordar). Y yo fui a lo básico: hice un input y un botón… pensaba que me iban a ir pidiendo cosas progresivamente en base a esto, pero no, efectivamente querían que hiciera un input y un botón EN UNA HOJA DE FOLIO, y pues… no puse ni el <form> ni la <label> ni na’. Todo mal. Me sentí muy idiota en esta prueba. Nunca supe si quedé o no porque el día siguiente acepté mi primer trabajo y les dije que no seguiría en el proceso.

Bonus caca💩

Ha sido la peor entrevista que he tenido, me hicieron sentir horrible. Estaba buscando mi primer trabajo. La entrevista era con uno de los CEO. Me dijo que era imposible conseguir trabajo solo con este “cursito”, que en todo caso él podía hacerme el favor de, si paso la prueba, contratarme como becaria y que me recomendaba, en todo caso, estudiar para ser fullstack para que me vaya mejor. Me dio su portátil así improvisadamente con el VSCode abierto y un archivo .json y me pidió que pintara esos datos. Yo solo sabía hacer peticiones a una API, esto nunca lo había hecho… y ya me sentía horrible que me bloqueé y no supe cómo hacerlo. Quizás si no me hubiera tratado tan mal, hubiese puesto empeño en buscar y hacerlo (porque tuve tiempo de sobra), pero ya no tenía ganas. Me dijo que tenía 20 minutos y me dejó ahí sola. Volvió como a la hora y le dije que no pude hacerlo y que no estaba interesada en continuar el proceso porque no me interesaba un contrato de prácticas.

Entrevistas no técnicas con RRHH😴

He tenido cien y me aburren un poco. Es repetir siempre lo mismo. Me siento como cuando en Tinder iba conociendo a gente por el chat y te hacían las mismas preguntas aburridas que al principio respondes muy animada jiji jaja pero ya luego te aburres de presentarte tanto y repetir lo mismo una y otra vez…

Te recomiendo tener preparada una charlita sobre ti, tu trayectoria, etc. Si vienes de otra área y te reinventaste, te van a preguntar por qué hiciste el cambio, que si te ofrecen trabajo en lo que eras antes, lo aceptas o te quedas en programación (esto me lo preguntan SIEMPRE).

Ten preparadas las típicas preguntas de RRHH: por qué deberíamos contratarte, descríbete en 3 palabras, por qué te quieres cambiar de trabajo, etc.

También te recomiendo que lo tengas preparado en inglés porque lo más seguro es que esta sea la parte que te pregunten en inglés (si has aplicado a un trabajo que requiera de este idioma, claro)

Preguntas que yo hago.

Como les dije antes, estamos en nuestro derecho de preguntar y por más encantada que estés, no está bien irte sin hacer ninguna pregunta. De hecho, hay veces que antes de tu preguntar te dicen todo muy completo. Incluso en ese caso, lo que yo hago es decir “bueno, la verdad es que todas las preguntas que tenía preparadas sobre tal y tal ya me las has respondido” y repito lo que entendí para ver si no se me escapó nada.

Normalmente pregunto sobre la conciliación, el teletrabajo, flexibilidad horaria, presupuesto para formación, el tiempo del período de prueba, cada cuánto y en base a qué hay revisiones salariales (si es en base a objetivos cumplidos, pregunto cuándo y cómo se establecen dichos objetivos). Actualmente, sin falta, pregunto cómo les ha afectado el confinamiento y si han tenido que tomar medidas durante esos meses y cuáles, básicamente para saber cómo me van a tratar o qué pueden llegar a hacer en caso de que haya otro confinamiento u otra situación loca.

También les pregunto cuál es el siguiente paso y en cuánto tiempo más o menos me darían respuesta. Esto lo hago porque en muchos sitios, luego de la primera entrevista con RRHH hacen ghosting y no te escriben nunca más, entonces así tienes un tiempo en el que puedes volver a escribir para que por favor te digan algo, así sea que no vas a continuar en el proceso pero con un feedback. PIDE FEEDBACK SIEMPRE.

Y a nivel técnico pregunto sobre las tecnologías y herramientas que usaré, si tendré a alguien de apoyo que tenga más experiencia que yo (si estás recién saliendo de un bootcamp tienes que tener un mentor), cuál va a ser mi equipo, si usan metodologías ágiles, etc.

Hay sitios en donde no te hacen prueba técnica, solo con RRHH y ya te hacen una oferta. He tenido dos así, quizás por eso es que todos (menos uno) los ejemplos que les comparto no han tenido final feliz😂. Recién salido de un bootcamp es probable que no te hagan prueba técnica.

He tenido muchas primeras entrevistas con RRHH que no pasan a nada y otras que simplemente no te vuelven a responder. Por favor, no sean así…

Recomendaciones a la hora de buscar trabajo.

Recomendaciones que yo te puedo dar en base a mi experiencia.

• Tienes que estar claro que es un proceso agobiante, estresante y cansa mucho; sobre todo si estás dispuesto a prepararte y estudiar para ellas.
• Si estás trabajando y estás buscando, no eches CV a lo loco porque puede que de pronto estés con siete pruebas técnicas encima que tienes que hacer después de cumplir tu jornada laboral y es posible que mueras un poquito.
• Si estás sin trabajo y desesperado, ECHA A TODO. Bueno, con conciencia, porque si es un trabajo para un arquitecto y tu acabas de salir de un bootcamp, o si piden Python y tu eres de JavaScript, igual no.
• No te eches para atrás porque no cumplas el 100% de todos los requisitos. NADIE LOS CUMPLE y ellos no están esperando ese 100%. Yo siempre digo “que sean ellos los que te rechacen, no tu que no lo intentas”. Que les llegue tu CV y una buena carta de presentación (si la piden) es un paso y ya lo dejas en sus manos. Y si te llaman para la entrevista, es tu oportunidad de demostrar tus ganas de aprender y de echarle bolas. Yo cuando estaba buscando mi primer trabajo echaba a todas las ofertas de front que pedían hasta 2 años de experiencia aunque tenía 0. Más de 3, ya no. No me importaba si pedían Angular, PHP… me daba igual porque ya saben que sería mi primer trabajo y que yo lo que necesitaba era aprender. Es verdad que estaba desesperada y necesitaba un trabajo ASAP. Quizás si no estás tan desesperada, puedes pensártelo mejor, pero no caigas en el error de que si no cumples todo lo que piden, no echas. POR FAVOR.
• No te enamores *tanto* de las empresas, que luego el golpe de si no te cogen es peor.
• No pongas toda tu energía en solo un proceso, porque si no te cogen, la sensación es peor. Aunque por ahí me dijeron “no hay nada más motivador que un NO” ;)
• No mientas si no sabes algo, dilo y además pide que te lo expliquen. Si no sabes responder a una pregunta técnica, no comiences a tirar flechas, a mi siempre me sale un “uy, pff pues eso ni idea, ¿qué es?” y además, sales con conocimiento nuevo. Y si te medio suena pero no lo sabes por completo, dilo tal cual “pues no lo se muy bien pero me quiere sonar a que va por tal sitio, ¿es así?” y ahí te dirán y te explicarán. Pero con cabeza, no a lo loco como yo pensando que la asincronía me sonaba a multi hilo🤣
• Y lo típico: ¡se tu misma! no intentes aparentar algo que no eres.

Siento el pergamino, pero ojalá pueda te pueda ayudar.

Gracias especiales a Fran Quesada, quien me apoyó muchísimo en todo esto y es quien me compartió los vídeos y me dijo lo de los challenges de Joppy y se aguantaba mis pataletas y alegrías 😂🤗

*Aquí hay otro artículo (corto, jeje) sobre cómo y dónde he conseguido estas entrevistas.

Ánimo y suerte =)

Aquí los videos: