Pruebas de selección

| | Este post surge a raiz de artículo escrito por @Ari_Reinventada en Medium(https://medium.com/@AriJDB/procesos-de-selecci%C3%B3n-agobio-estr%C3%A9s-y-aprendizaje-2c761bf36207)donde comenta su paso por diferentes procesos de selección. Como "contrapartida" en este post voy a hablarde mi experiencia estando al "otro lado" |

Aquellos maravillosos años

Durante todos estos años de aplastar teclas he tenido que pasar por muchasy variadas formas de entrevistas para optar a algún puesto de trabajo.

Desde aquellas pruebas psicotécnicas de los 90 donde tenías que completarsecuencias de fichas de domino (me apuesto el cuello que todavía se hacen en algún sitio) hasta la de tener que instalarun software que medía tustecleos, si consultabas páginas de Internet y cosas así para resolver unproblema algorítmico en 2 horas (que obviamente no pasé)

De muchas de ellas, tras el rechazo a mi candidatura, pude ver en qué había fallado (aunque eso no implique queaprendiera de ello y lo corrigiera) pero una en especial sí me llegó al alma.

Mala experiencia

Tras ponerse en contacto conmigo alguien de RRHH de una empresa tecnológica y pasar los preliminares me enviaron ladichosa prueba de código. No era complicada, efectivamente, algo así como un servicio RESTal que se le actualizaban precios por un lado y los mostraba por otro, y me puse manos a la obra.

| | Hay mucha "literatura" al respecto de hacer pruebas de código. Gente que no quiere dedicar su tiempo libreen ella, o que piden que se le remunere, etc. Para mí son posturas totalmente válidas pero en mi caso no me importapues las veo como retos a resolver,si bien es verdad que nunca me han planteado una prueba que parezca que es para resolverles un marrón. |

Creé el servicio (en Gradle, Groovy y Micronaut por supuesto) lo más sencillo posible y para completarlo le añadí loque me pareció lo mínimo que se debía crear para un proyecto:

• unos test mínimos

• docker-compose para levantar la base de datos y el servicio

• repositorio en Gitlab

• pipeline en Gitlab para construir el proyecto

• documentación (obvio) con Asciidoctor incluida en el build del proyecto

• README explicando cómo construir el proyecto y donde encontrar la documentación

Vamos, una oportunidad donde poder demostrar que tocas varios palos y poder discutir sobre ello.

A las 2 horas de haberles enviado la url al repo recibí la negativa ("muchas gracias pero no has usado el patrónsampitopato") y realmente estuve cagándome en sus muelas durante unos cuantos días.

Me parecía increíble que alguien les enviara una propuesta tan completa, como a mi me parecía, al día siguientede proponerla y la despacharan con ese argumento. Pero lo más alucinante es que ni tan siquiera ofrecieran la oportunidad de discutir mi propuesta. Según me había comentado la persona que se puso en contactoconmigo tenían la intención de contratar a 200 técnicos en un año!!!

Lo repito: no es que me sintiera ofendido porque no aceptaran mi propuesta. Es que pienso en el coste en el que estaban incurriendo para captar talento y lo desperdiciaban simplemente porque no usabas un patrón !!

| | La parte buena de esta experiencia fue que me piqué con el patrón sanpitopato y a partir de ahí me líe a haceruna serie de bots para Telegram …​ donde seguí sin aplicar el patrón sanpitopato. |

Tymit

Tiempo después, y gracias a contactos que te avisan de oportunidades que surgen, me "enfrenté" a la de Tymit la cual megustó bastante y sobre la que, una vez que formé parte del equipo, hemos ido trabajando para mejorarla, al menos ennuestro entender.

Básicamente el proceso completo, que a priori puede parecer largo, se divide en una serie de entrevistas:

• una charla corta con RRHH para conocerte y explicarte la vacante y el proceso

• una charla corta, 1/2 hora aprox, con dos miembros del equipo con los que no necesariamente vas a trabajar codo con codo.Sirve principalmente para resolver dudas de cómo es la compañía, explicarte el producto y forma de trabajar por encima,y que te pueda servir para ver si estarías cómodo trabajando en la empresa (y para qué mentir, sirve para ver si encajaríasen la misma)

• una charla técnica de 1h aprox con otros dos técnicos diferentes (si se puede). Se trata de que el candidato conozcatanta gente como sea posible del equipo así como a la inversa.Es en esta charla donde me voy a centrar pues obviamente es la principal

• una charla "corta" para conocer al CTO. Como buen CTO si le das pie puede estar horas hablando contigo.

Prueba técnica (backend)

En mi opinión, en Tymit no vas a encontrar a grandes gurús tecnológicos capaces de hacer el algoritmo cuántico del momento,(obviamente si así fuera yo no habría pasado la prueba) por lo que la prueba no consiste en resolver ningún algoritmo,aplicar un patrón, y por supuesto nada de trabajar sobre una hoja en blanco (Me da el flato de la risa de pensar enla pobre @Ari_Reinventada haciendo HTML en una hoja).

La prueba la hemos dividido en una serie de preguntas "incrementales":

• elegir entre dos trozos de código Java (no más de 10 líneas cada uno) y comentarnos qué hace, que problemas le ves, etc.

• dado un problema mundano con unas especificaciones supersimples, cómo plantearías los tests. Ni spock, ni junit, nicucumber, …​ lo que tú harías, si bajas a pseudocódigo bien, si no tendrás que explicarte de viva voz.

• un día a día con Git

• algo de docker super fácil

• elegir una pregunta entre dos sobre un API Rest y charlamos sobre ello.

• idem de microservicios

• una pregunta bastante rebuscada sobre arquitectura.

Y sí, solamente tenemos este documento para cualquier nivel al que se opte por dos razones:

• no necesitas saber de todo, si de algo no sabes no se busca que te lo inventes sino que lo digas sin tapujos. Lo buenoes que muchas veces la gente te sorprende y alguien que opta a un nivel medio se ha peleado con algún tema más raro yasí tiene la oportunidad de hablar de ello.

• somos tan vagos que para qué vamos a hacer dos versiones.

Lo que se busca en este prueba no es tanto que demuestres tus conocimientos resolviendo el problema del siglo sino quediscutamos y puedas expresar tus puntos de vista, forma de hacer las cosas, en definitva conocernos.

Se procura en cada apartado no sólo escuchar al candidato sino poder aportarle algo. Por ejemplo puede que no hayastenido que tocar nada de Docker y tengas interés en saber qué se buscaba en esa pregunta.

Al final de la entrevista (que alguna vez se ha alargado mucho más de la hora) se procura reservar unos minutos pararesolver las dudas que se puedan tener principalmente sobre la forma de trabajar, organizarnos, etc e inmediatamente letrasladamos nuestras impresiones a RRHH para que se pongan en contacto con la persona que opta cuanto antes y letraslade si continúa o no.

Hemos evaluado en este punto si deberíamos enviarle nuestro feedback pero al menos a díade hoy creemos que la entrevista es tan abierta y se comentan todos los puntos que creemos que es suficiente.

Conclusiones

El principal problema que le veo a esta "metodología" es que no "escala".

Quiero decir con ello que es un proceso que requiere su tiempo así como esfuerzo por parte del equipotécnico que tiene que aparcar sus tareas durante un buen rato (lo bueno es que la hemos hecho ya algunas veces,rotandonos entre nosotros, y ya tenemos claro lo que buscamos y cómo plantearla)

Por parte de la persona que opta también es un esfuerzo obviamente pero a cambio obtiene el conocer, de forma gradual,a mucha parte del equipo con el que vas a trabajar. Creo que en estos tiempos de teletrabajo es una buena manera porqueya no se puede hacer una reunión física con el equipo (reunión que por otra parte no servía de mucho porque todo elmundo intenta ser políticamente correcto y poco más)

Por el contrario la principal ventaja es que se han propiciado al menos 2-3 entrevistas para conocernos y una de ellas contemas tan diversos que se ha favorecido tanto el poder detectar si la persona se adaptaría al equipo como que la personapiense si podrá trabajar con el equipo. O esa es la idea