Leyendo un post de Gerardo Fernández en LinkedIn he acabado haciendo mi propio post a modo de respuesta en mi largamente olvidado blog. Mi capacidad de síntesis está en entredicho, jejeje.

Yo veo el conocimiento como un árbol de innumerables niveles con innumerables nodos en el que sólo puedes saltar al siguiente nivel mediante una clave.

No es posible profundizar en todos. Se puede saber un poquito de todo o ser especialista en algo, y cuanto más profundizas, más consciente eres de lo poco que has recorrido.

Para conseguir la clave de un nodo y pasar al siguiente nivel se necesita experiencia, práctica, curiosidad, conocimientos, voluntad, tiempo...

La prueba técnica

Respecto a las entrevistas técnicas, mi opinión, como desarrollador de software y enfocada al mundo del desarrollo de software...

Personalmente, prefiero las pruebas técnicas offline donde el candidato tiene tiempo para analizar, diseñar, investigar y entregar un trabajo a su máximo nivel.

Soy positivo y veo las pruebas técnicas de acceso a una empresa como katas, como pruebas o retos que van a ofrecerme claves para profundizar en este árbol de conocimientos, sea cual sea el resultado final, enfrentarse a un reto y descubrir vulnerabilidades en la code review sólo me aporta cosas positivas.

Yo no tengo miedo a las correcciones, me hacen mejor... Yo tengo miedo al que cree que no las necesita

El entregable

La revisión comienza nada más el candidato entrega... el entregable :)

El código fuente

El código fuente de un software es la impronta que describe no sólo la forma de pensar del desarrollador, sino el interés mostrado, los recursos que tiene, el dominio del lenguaje o de los conceptos relativos a los requisitos de la prueba.

En una prueba de algoritmia se puede ver si se dominan estructuras de datos, algoritmos standard, complejidad espacial y temporal, si se ofrecen distintas soluciones...

En una prueba tradicional de diseño orientado a objetos se demuestra el dominio de los principios SOLID (qué bien le vino al tío Bob que el apellido de Barbara empezara por L), clean code, patrones de diseño, mantenibilidad, extensibilidad, si su modelo es anémico (ya lo dijo Martin), si es un exceptions lover, si prefiere notificaciones... Hablan sus entidades con extraños (guiño a una diosa griega)?

En una prueba cliente - servicio se puede ver si domina los frameworks utilizados, si ofrece una UX compliance, si domina la asincronía, la reactividad, los eventos... mono, flux, promesas, observables... loops tradicionales u operadores funcionales?

Le va la herencia? Está bien hecha? Prefiere la composición? Inyecta dependencias? cuántas? dónde? en el constructor verdad? Abstracciones o concrecciones? Cómo va esa inmutabilidad, bien?

Clean architecture? Hexagonal? Flux? Redux? DDD? CQRS?... era necesario? Está justificado? Por qué? Sobreingeniería?

Ofrece health endpoints? Swagger? Comprende REST o se atreve con GraphQL? Usa una DB relacional, noSQL, Por qué? ORM, no? Dockeriza el entregable?

Caml, kebab, snake... que case utilizas? por qué? npm, yarn, maven, gradle... cuál? por qué? Este framework? el otro? por qué?

Emplea un buen naming? Cómo es la paquetización? Qué tal va la cohesión, y el acoplamiento? Usa comentarios en el código (espero que no! ups...)?

y un sinfín de diferentes tipos de pruebas, requisitos, paradigmas y entornos diferentes...

Los tests

Va más allá del happy path? Gestiona posibles errores y se anticipa a ellos en su lógica de negocio? Ha empleado una aproximación TDD? Cómo son los tests, cubren todos los use cases? Hay informe de cobertura?

Son necesarios tests e2e? te refresca la sombra del ciprés?

Muchas veces pasa que invertimos un gran esfuerzo en tener un código de calidad, y luego hacemos unos tests de 58 lineas por use case.

Los tests son, sin lugar a dudas, código fuente, y por lo tanto se les debe exigir lo mismo que al código que implementa la lógica de negocio

A mi, un tal Blé, de nombre Carlos, me cambió totalmente la visión del testing en sólo 2 días... me dió la clave para saltar al siguiente nivel. Eternamente agradecido... ;)

La documentación

La gran olvidada. Pero no sólo en las pruebas, en el día a día de todos. Mira que nos encanta encontrar un paquete de software, librería o framework bien documentado, con ejemplos, explicaciones, instrucciones de configuracion y uso, que hace que nos sea más fácil configurarlo, utilizarlo y entender para qué sirve.

Por qué entonces no devolvemos ese agradecimiento?

Actitud

No todo es ciencia... la actitud del candidato y de los correctores / entrevistadores es muy importante. Si vas a entrar a formar parte de un equipo, es vital ver como se desenvuelven las personas en una code review... aceptan las críticas? Se muestran colaboratibos? Abiertos al debate y al cambio de opinión? Talibanismo? Inventan o asumen cuando no saben algo?

Candidato, ten presente, si el entrevistador te hace una pregunta es porque obviamente conoce la respuesta, inventando no vas a engañar a nadie, es más, quedas peor. Más vale una retirada a tiempo y ser humilde... pues mira, no lo se, no domino el concepto, lo he oido pero no he profundizado... me lo puedes explicar?

Pero tranquilo, de los errores se aprende... ;)

Cuántas cosas!

Como veis, una prueba técnica, incluyendo su code review contiene una increible y valiosísima información sobre el perfil de un candidato... es útil? A mi sí me lo parece :)

Y todo esto se puede extraer de una prueba de tamaño discreto, no hace falta un sistema titánico porque el perfil buscado es ¨senior¨. Y lo pongo entre comillas porque hoy en día, a mi juicio, determinar qué / quién se considera senior da para un buen rato. Pero eso es para otra ocasión.

Es cuestión de cuántas claves tengas en tu recorrido por el árbol del conocimiento... desde arriba no se aprecia cuántos y cuántos niveles con cuántos y cuántos nodos hay.

Y tantas otras cosas de las que ni siquiera estaré al tanto.

Como candidato

Opto por hacerlas si el esfuerzo merece la pena, si la oferta es interesante en alguno o varios de los aspectos que valoro (sin esfuerzo no hay recompensa). Y no es lo mismo poder elegir que tener necesidad.

En épocas de búsqueda activa pueden pedirte una prueba técnica que conlleve tiempo personal en cada oferta a la que aspires... Hay que ponerse metas alcanzables, gestionar el tiempo disponible, comprometerse con plazos que se puedan cumplir y conocer tus propios límites.

En los comentarios del post de Gerardo se ofrecían posibles alternativas. Una que me llama la atención es esta: La empresa, tras revisar el curriculum y hablar con el candidato, decide confiar en el y lo incorpora en periodo de prueba.

Yo veo varios inconvenientes.

Para el candidato, en mi caso, si no tengo trabajo genial, pero si tengo uno y quiero cambiar? me arriesgo a que en unas semanas me digan en el nuevo que yo no era lo que ellos esperaban y pierdo el que tenía y el nuevo? O yo me doy cuenta de que la empresa no es lo que esperaba y me voy?

Esto puede pasar también haciendo una prueba técnica, pero los riesgos se habrán minimizado.

Para la empresa. Puede una empresa permitirse esta dinámica? esta itinerancia? Incorporar a alguien a la plantilla supone trabajo de recursos humanos, onboarding, tarjetas de acceso, de comida, alta en seguridad social, seguro médico, firma de contrato... también implica trabajo de la gente de sistemas, configurar el equipo, las cuentas, puesto de trabajo... trabajo del equipo, formación y tutela, etc... Es decir, no es gratis incorporar alguien a una empresa.

Por otro lado, yo también fui junior y se que cuesta entrar al principio... pero tranquilo, en 3 años ya serás senior (OMG!) aunque aviso... también cuesta después (soy un crack dando ánimos)

Con esto, lo que intento decir, es que sí. La prueba para entrar sin saber si te van a coger o no es un esfuerzo a priori sin recompensa... o no?

Si no me cogen me llevo lo aprendido en el proceso, y evito entrar en una empresa donde mi perfil no se ajusta, me acabaré llendo o me acabarán echando, win win

Somos unos privilegiados en el mundo IT, al menos, en mi experiencia y mi círculo de contactos... que nos hagan una prueba para darnos rol SUPER_ADMIN en la cueva del tesoro no me parece tan descabellado.

En su mayoría, las pruebas que he hecho como candidato, pero también como entrevistador me aportan, ya sea por la prueba en sí que me lleva a investigar nuevos aspectos / tecnologías / requisitos o por los comentarios de los entrevistadores / candidatos que me aportan una nueva visión.

Como entrevistador

Consciente del esfuerzo que supone una prueba técnica, yo también dedico esfuerzo a entender y analizar la prueba entregada, y después, en la code review, proponer / guiar al candidato hacia la mejor de las soluciones que nos permitan nuestros conocimientos combinados, sabiendo que juego con ventaja porque conozco bien la prueba y he corregido muchas de diferentes candidatos con distintas visiones.

Mi valoración de un candidato no lo define, simplemente determina su nivel de compatibilidad con los requisitos para el puesto... y no deja de ser una valoración basada en criterios más o menos subjetivos, según quién

Aplico lo mismo si yo soy el candidato, me ahorra inseguridades cuando la respuesta es no. Y esto es totalmente compatible con aceptar la crítica, reconocer mis errores y ponerles solución: hotfix y PR!

Conclusión

Una prueba técnica define muchos, aunque no todos, de los aspectos involucrados en el desarrollo de software, documentación, diseño, testing, metodología, code review... y da lugar a debates interesantes en los que tanto el candidato como el corrector muestran otros aspectos importantes.

En la prueba hay que lucirse, asumo como candidato o como entrevistador que se da por hecho que la prueba técnica es un anticipo de las cualidades del candidato como desarrollador, de ahí que prefiera una prueba offline donde no haya variables de presión o miedo escénico.

Es más, la oferta económica al candidato probablemente se base en la calidad de la prueba técnica, entre otras cosas, ya que no es la única variable a tener en cuenta.

Una vez más, aunque lo hemos oido muchas veces...

Una entrevista es bidireccional, tanto la empresa como el candidato descubren aspectos que les permiten tomar una decisión

Ésta es mi experiencia, habrá otras similares, diferentes, habrá empresas que den más feedback, otras que no, habrá entrevistadores geniales o malvados... cada experiencia y cada situación definen una realidad única, si no, habría un único paradigma de programación, un único lenguaje, un único framework, etc... :)

Y recuerda, no olvides darle a subscribe si te ha gustado el... uy! que esto no es youtube :)