Hoy te voy a enseñar los 5 diferentes tipos de pruebas técnicas que te puedes encontrar
en los procesos de selección para programación o desarrollo.
Vamos a ver en qué consiste cada una, algunos consejos para superarlas,
cuáles son mis favoritas y tus favoritas,
y sobre todo, cuál me parece más difícil y más fácil.
Empezamos por la primera, la más odiada por la gran mayoría, el LifeCoding.
Consiste en una prueba en vivo, normalmente un pequeño reto,
porque tienes un tiempo bastante limitado, una hora, dos horas.
Te enfrentas a esta prueba con dos personas de la empresa,
una persona que está liderando y otra que hace de shadow.
¿Por qué dos personas? Porque así tienen dos puntos de vista
cuando tienen que dar feedback de cómo lo has hecho.
Siento decirte que este tipo de prueba cada vez se utiliza más en estos tiempos del remoto.
Y es que además de ser bastante rápida,
también se considera que es muy respetuosa con el tiempo de los candidatos.
Consejos, practica, practica y practica.
¿Cómo? Es muy fácil, píllate a un compañero o una compañera,
algún amigo que tengas por ahí y vais a hacer esta prueba
donde os vais a estar cambiando el rol.
Algunas veces entrevistado, otras veces entrevistador.
De esta forma os podéis dar feedback el uno al otro de cómo lo estáis haciendo,
practicar en vivo y mientras estáis solucionando, ir explicando la solución.
También es súper útil que practiquéis en algunos sitios como StackBlitz,
CodeSandbox o, muy importante, CodeSignal,
porque este tipo de plataformas son las típicas que se utilizan.
Si las llevas de la mano, así te va a costar mucho menos.
Tengo que decir que es de mis favoritas en cuanto al tiempo,
porque así la puedo hacer y me puedo olvidar muy rápidamente.
Pero es verdad que los nervios le pasa factura a cualquiera.
Y yo no soy menos.
Una de las que más triunfan entre las personas es la charla técnica sin código.
Simplemente se habla sobre tecnología, programación, background técnico...
Y esto lo que sirve es para nivelarte, para saber por dónde van un poco los tiros
y entender exactamente si eres el perfil que están buscando.
A veces esta prueba no es suficiente y se utiliza otras pruebas que vemos en este vídeo
justamente pues para filtrar del todo.
Pero es una de las primeras que se utiliza justamente para saber
si tienen que continuar el proceso contigo.
El problema de esta prueba es que es bastante subjetiva.
Pero aún así se puede preparar.
Mi consejo es que te mires artículos como esos de
las 50 preguntas de JavaScript más preguntadas.
Lo que debes saber sobre el backend.
Hay un montón de artículos que recogen este tipo de preguntas.
A partir de ahí, una vez que estás en la entrevista,
que te preguntan algo que no sabes, no pasa nada.
Lo reconoces y tienes que ser una persona humilde y modesta.
Pero nunca digas que no tienes ni idea.
Puedes reconocer que no sabes algo y aún así intentar articular una posible respuesta,
una hipótesis de respuesta con conocimientos que sí que puedes tener.
Esto te puede ayudar porque así van a ver que, aunque no lo sepas,
sí que eres capaz mentalmente de unir algunos hilos.
Si te estás viendo este vídeo, seguramente es porque estás buscando trabajo
o te interesan las entrevistas.
Y hoy en día lo mejor es que busques un trabajo en remoto.
Así que no te puedes perder ARC.dev.
En ARC vas a poder aprovechar al máximo tu tiempo.
Vas a tener que pasar una vez un proceso
y en 14 días vas a tener un montón de empresas que van a estar aplicando por ti
y no al revés.
Lo mejor es que además tienes coaching totalmente gratuito
para que consigas las mejores oportunidades.
Y todo esto con un proceso que solo dura una hora y media.
Y totalmente gratis.
¿Y sabes lo que dicen que no debería ser gratis?
El tercer formato de prueba técnica.
Y es llevarte un ejercicio a casa y tener X días para completarlo.
Este también es uno de los ejercicios favoritos para la gente.
Aunque tiene un problema bastante grave.
Y es que muchas veces no sabes cuántas horas realmente le tienes que dedicar.
¿Qué hace esto?
Pues que si te dan dos semanas igual le dedicas 20 horas a la prueba.
Y todo para que luego te digan que no.
Por eso te digo que igual no deberían ser gratis y deberían pagarte algo.
No sería la primera vez que en algún ejercicio de estos
al final ese código ha llegado a producción.
Si es así, deja un comentario y cuéntame a ver si te sabes alguna historia.
En este caso, el mejor consejo que te puedo dar
es que te ciñas exactamente a lo que te piden.
Ni mucho más, pero sobre todo no menos.
Esto quiere decir que si te dicen que te tienes que trabajar el ritmi,
que tienes que hacer test, lo tienes que hacer.
Tienes que asegurarte que vas a cumplir esos requisitos.
Y está muy bien ir a por la nota,
pero a veces hay que tener cuidado de no sobrepasarse.
Si al final hacemos demasiada ingeniería,
puede ser incluso contraproducente para nosotros.
Otra recomendación que te doy es que hay un montón de repositorios
en GitHub donde recogen este tipo de pruebas.
Así que le puedes echar un vistazo y puedes ir practicando
antes incluso de aplicar algún proceso de selección.
Una cosa que sí que te desaconsejo
es que hagas que otra persona haga la prueba por ti para entregarla.
Normalmente, y es muy típico,
vas a tener que defender el código que has producido.
Así que si no tienes ni idea, te van a pillar
y seguramente te van a borrar para cualquier proceso futuro.
El cuarto formato es bastante novedoso y cada vez se va viendo más.
Y esto es trabajar con el equipo.
¿Qué quiere decir esto?
Pues que quizás tienes uno o dos días donde vas a trabajar en la empresa
en la que estás aplicando para trabajar con un equipo real en proyectos reales.
Esto es muy interesante porque así conoces a las personas
con las que vas a estar trabajando y ellos y ellas te conocen a ti.
Pero tiene un problema muy grave y es que normalmente tienes que dedicarle mucho tiempo.
No todo el mundo se puede dedicar a perder dos días de su vida
para ir a la empresa a conocer a la gente.
O se tiene que tomar vacaciones o tiene que pedir algún permiso.
Esto complica bastante las cosas.
Igualmente, si es el caso y vas a hacer una prueba de este tipo,
mi consejo sería que te asegures de demostrar que eres una persona
que sabe trabajar en el equipo.
Y que demuestres curiosidad no solo en conocer al producto,
sino también en conocer a las personas con las que vas a trabajar.
Lo mejor que tiene este tipo de pruebas
es que normalmente no son muy estresantes.
Simplemente es cuestión de estar ahí ocho horas.
Yo particularmente no soy muy fan de este tipo de entrevistas,
aunque sí que me gusta conocer al equipo con el que voy a trabajar.
Pero creo que muchas veces es suficiente una comida
y no tener que estar dos jornadas laborales, ir a reuniones, etc.
Me parece una pérdida de tiempo.
E imagínate que te caen todos mal.
¿Qué haces ahí dos días?
Y el último formato de entrevista es una entrevista
que gira en torno al código.
Pero ojo con esto.
A veces puede ser código de los entrevistadores
que te lo ofrecen para que lo comentes.
Y también puede ser que te digan que te traigas tu propio código
para mostrarlo y para hablar de él.
La verdad es que es una entrevista que a mí particularmente me gusta mucho.
Tiene lo mejor de que no le dedicas mucho tiempo.
Puede ser código que ya conoces,
que ya has pensado, que ya has practicado.
Y del que estás, sobre todo, muy orgulloso.
Creo que puede ser una charla bastante distendida.
Y todo esto sin perder un ápice de la calidad que quieres demostrar.
El problema y la realidad es que no es muy frecuente.
Lo cual, si a mí me preguntas, me parece una tontería.
Pero sinceramente, creo que es la entrevista del futuro.
Creo que es una entrevista que tiene muchas cosas buenas,
como por ejemplo también, pues, respetar el tiempo de la gente.
Este tipo de entrevista puede ser bastante interesante,
especialmente para perfiles seniors.
Es gente que no tiene tiempo de hacer pruebas técnicas.
Y estoy seguro que deben tener un montón de código por ahí
del que se sientan orgullosos o orgullosas.
Así que puede ser un buen reclamo
para que sí se animen a aplicar a tu empresa.
Mi consejo para este tipo de entrevista,
lo que sí que te diría es que si vas a mostrar un código,
te asegures que está bien.
Y que es realmente el mejor código que tienes.
Linter, test, buenas prácticas, buen diseño, todo.
Y ahora que te sabes todos los formatos de entrevista,
¿por qué no me dejas en los comentarios cuál es tu favorito,
cuál es el que más odias
y cuál es el que te gustaría que te hicieran
en tu próximo proceso de selección?
Gracias por verme y espero que hayas aprendido algo nuevo.
¡Chao!