“Me llamaron de Recursos Humanos de una compañía y me dijeron que tenía que hacer la típica prueba de código. A mí me gustan, la verdad, porque me sirven para ver cómo respira la empresa, así que le dediqué un fin de semana: la trabajé, me planteé el reto, preparé la documentación… Pero menos de una hora después de haberla enviado me despacharon diciéndome que no era lo que buscaban, que no había usado cierto patrón que ellos querían. Muy bien, vale, pero… ¿De todo lo demás no había nada de lo que hablar? Aún estoy esperando que me contesten”.
Habla Jorge Aguilera, programador veterano. Aunque por el tono de su voz —a camino entre el fastidio, la incredulidad y una frustración bien digerida con humor— pueda parecer que la prueba de código la hizo el fin de semana pasado, la anécdota le ocurrió hace ya algún tiempo.
Ahora Jorge tiene empleo y en la empresa para la que trabaja, la startup Tymit, le toca con frecuencia estar del otro lado durante los procesos de selección: el de quienes ayudan a evaluar a los candidatos. No olvida sin embargo lo que le ocurrió hace años como aspirante. “Lo tengo clavado. Ahora me río, pero en su momento me fastidió, la verdad”, admite. Por esa razón, explica, cuando en su compañía buscan fichajes intentan que impere el feedback. “Que la gente vea que no son recursos, sino humanos”.
El de Jorge no es un caso aislado. Ni siquiera el más sangrante o polémico. Aunque —reconocen desde el sector— cada empresa es un mundo y la forma de plantear los métodos de selección varía de una compañía a otra, los procesos que afrontan los programadores cuando buscan trabajo están rodeados con frecuencia de, cómo mínimo, cuestiones abiertas a debate: ofertas que apenas incluyen información y durante las que el aspirante no llega a tener contacto directo con sus futuros empleadores, una enorme variedad de sistemas de evaluación —lo que hace prácticamente imposible estandarizarlos—, pruebas que exigen varios días de dedicación por parte del candidato sin ningún tipo de compromiso ni contraprestación… Incluso la sensación de que las compañías pueden llegar a sacar provecho en sus negocios de ese mismo material —que el desarrollador realiza para demostrar sus habilidades— sin el menor pago a su autor. Las casuísticas son numerosas.
Programadores y empresas explican sus puntos de vista.
Un fin de semana de trabajo... sin garantías
“Sí he tenido que hacer alguna prueba de ese tipo, de tirarme un fin de semana completo o un puente, tener que cancelar todos mis planes porque tenía que hacer una prueba de código”, reconoce Fran Quesada, desarrollador. Aunque evaluaciones de este tipo son frecuentes, apunta también que “poco a poco van perdiendo prestigio” en el sector. “Empieza a verse mal que tengas que dedicar tanto tiempo. Pero depende totalmente de la empresa. Yo personalmente no creo tanto en su validez. Al final los períodos de prueba están para lo que están”, comenta.
"Yo lo veo justificado si necesitas a alguien no tanto por el código que escribe sino por cómo organiza. Si necesitas asegurarte de que la persona que va a entrar en tu equipo es organizada o algo similar. Por suerte o por desgracia hay gente que copia. La realidad es que tú puedes enviar una prueba de código, que el entrevistado te la entregue y no la haya hecho él. Eso puede ocurrir. En ese sentido es un arma de doble filo —abunda Quesada—. Yo personalmente opino que muchas cosas que se ven en una prueba de código se pueden ver en una conversación normal con alguien".
A pesar de su experiencia, Fran explica que nunca ha terminado una selección con la sospecha de que su prueba pudiese servir luego a la empresa para sacarse trabajo de encima gratis. “Las que he hecho normalmente son cosas que están completamente fuera del producto para el que me entrevistaban. Una, por ejemplo, consistía en programar el radar de una nave de Star Wars —relata el desarrollador—. Compañeros míos sí han tenido que hacer cosas, sin embargo, que se veía que eran funcionalidades que tenían que meter en sus aplicaciones. A lo mejor te pedían un lector de códigos QR y luego veías que esa misma empresa no lo tenía todavía”.
¿Cómo mejorar los procesos? Desde su experiencia Quesada apuesta por dos claves. Desde el punto de vista del entrevistador anima a cuidar el feedback, mantener informados a los candidatos en la medida de lo posible. “Me he encontrado muchas veces con que tenía que reclamar feedback técnico”, relata. A los candidatos les sugiere otra cuestión igual de relevante: reflexionar sobre las motivaciones y plantear todas las preguntas que les surjan para aclarar sus dudas.
Ni cortas, ni fáciles y tremendamente diversas
“No son pruebas cortas, ni fáciles. Uno invierte esfuerzo y le pones muchas ganas porque quieres hacerlo bien y al final si no te escogen te quedas con la sensación de que has hecho trabajo para nada”, comenta Ariane Jurado, programadora, sobre las pruebas de código a las que los candidatos pueden dedicar varios días. A esa presión por ganar puntos ante la empresa se suma otro hándicap, recuerda: que habitualmente los candidatos están ya trabajando, lo que les obliga a sacar tiempo de debajo de las piedras, robar horas al sueño o al ocio y aprovechar ratos libres para completar los test que proponen las firmas.
A menudo están también las dudas, admite, sobre el uso que la empresa podría dar al material elaborado por los candidatos. “Hay pruebas técnicas que te piden mucha funcionalidad del producto al que aplicas y al final la gente siente que está sacando trabajo gratis. Hay mucho debate en la comunidad, con gente que dice que no deberíamos aceptar este tipo de pruebas porque al fin y al cabo supone un trabajo gratis y quien sostiene también que puedes demostrar tu capacidad técnica con un proyecto que ya hayas hecho, sin necesidad de hacer algo nuevo”, comenta.
Las pruebas prácticas tienen también sus defensores, que las equiparan casi a las audiciones que se exige a los intérpretes. "Si bien la entrevista es la parte central del proceso de selección, quedarse solo con eso es un enfoque extremadamente negligente. ¿Alguien contrataría a un actor sin realizar un casting?, ¿un deportista sin realizar pruebas físicas?", recoge este artículo de Infojobs en el que se apuntan las ventajas de valorar el código fuente de los candidatos, una manera eficaz y rápida —alega— de filtrar a los aspirantes. La forma en cómo se lleva a la práctica no tiene por qué ser siempre igual, sin embargo. Una de las opciones sería que el candidato aportase algún proyecto que ya ha escrito. Otra, que resuelva un problema planteado por la compañía.
“Creo que estas pruebas de siete o diez días son una locura y no son necesarias para ver si la persona tiene o no la capacidad de trabajar contigo”, abunda Ariane. Otra de las cuestiones sobre las que llama la atención es su diversidad. A lo largo de su carrera se ha encontrado code test, pruebas de algoritmia en pizarra en blanco, entrevistas con personal del área de RR. HH., otras con técnicos durante las que se preguntaba por cuestiones como patrones de diseño o de arquitectura, testing, POO, principios SOLID, programación funcional, recursividad… “Para mí fue un choque darme cuenta de que no siempre te vas a encontrar con lo mismo. Esa incertidumbre se suma a los nervios de no saber qué te van a plantear, cómo será la prueba”, lamenta.
“No entiendo por qué no hay unanimidad, por qué no puede ser siempre el mismo tipo de pruebas. En el trabajo en el que estoy ahora me hicieron simplemente una batería de preguntas básicas de JavaScrip de 40 minutos. El mismo día que tuve la reunión con RR. HH. y el manager. Más o menos una hora y cuarenta minutos y ya estaba”.
Jesús Martín, desarrollador de aplicaciones para IOS, tiene también experiencia afrontando procesos de selección y reconoce lo distintas que pueden llegar a ser las pruebas. “Dependiendo de la empresa te puedes encontrar una cosa u otra, de una simple entrevista con el responsable técnico de la compañía a otra mucho más elaborada en la que primero hablas con Recursos Humanos, luego te mandan una prueba para que la hagas en casa... Sobre todo lo que cambian son las fases del proceso de selección”, comparte.
"Yo puedo llegar a entenderlo por parte de la empresa para que tu no te prepararse la entrevista. No hay nada estandarizado. En el mundo del software es difícil hacerlo porque al final la tecnología cambia muy rápido y encontrar una prueba estándar es muy complicado". Al igual que otros muchos desarrolladores, Martín lamenta la falta de feedback e información por parte de algunas compañías durante el proceso de selección. También le ha tocado lidiar con pruebas de código que le requirieron varios días de dedicación. ¿Sintió en algún momento que estaba trabajando gratis? “Personalmente yo no, no me he encontrado en ese caso. Ni con la sospecha”, explica. La sensación que sí comparte es la de que los code test son “cada vez más comunes”.
Martín recuerda también cómo en algunas compañías tecnológicas se echa mano de las pruebas de algoritmia en pizarra, "la más complicada y bastante temida". "En EE. UU. es muy común. Te ponen frente a una pizarra, te cuentan un problema técnico y tú tienes que llegar a una solución o decir cómo lo resolverías. Tienes que dar con una solución mientras te examinan. Aunque, como todo, se puede preparar", señala. A modo de ejemplo recuerda Cracking the Coding Interview, libro que trata precisamente sobre cómo enfocarlas. Una de las compañías en las que se recurre a la programación en una pizarra en blanco —según recogía en 2016 de Business Insider— es Google.
La diversidad de las pruebas puede estar directamente ligada con la propia heterogeneidad de perfiles profesionales que se dedican a la programación. Ariane lamenta, por ejemplo, que aún hay profesionales que miran con recelo los bootcamps. "Hay mucha gente que todavía no cree en los cursos intensivos, que tiene esa 'titulitis' en la cabeza y piensa que si no eres ingeniero no sirves para programar. Están equivocados. Hay que creer en la gente y ver sus capacidades".
Del otro lado de la mesa: quienes seleccionan
Gracias a su dilatada experiencia Jorge Aguilera conoce bien los procesos desde ambos lados de la mesa. Desde la posición del candidato al que le llega por mail una prueba que debe completar en cierto tiempo —sin que haya el menor contacto humano con la compañía— a la del empresario o incluso técnico que apoya al departamento de RR. HH. durante la selección. En su empresa, Tymit, se emplea una "fórmula" de evaluación en la que se busca principalmente, asegura Jorge, “conocer la experiencia” y el modo de trabajar de quien se postula para el cargo.
La primera fase consiste en la búsqueda de currículos y perfiles desde el área de RR. HH., sobre la que recae la labor de “cribado inicial”. A los aspirantes se les explica en qué consiste la empresa, su enfoque o el puesto disponible. Le sigue una entrevista con personal de frontend y backend. “No son más de 15 o 20 minutos y no hablamos tanto de lo que hace la aplicación, como sí de la forma en que intentamos nosotros que lo haga. La idea es transmitir nuestros valores”, relata. Una vez completada, llegaría la entrevista técnica. “Ahí es donde tú tienes que darnos el feedback a nosotros”, bromea Jorge. Se habla de Java, fragmentos de código para que el candidato identifique su uso y problemas… “No necesito que me hagas pseudocódigo, solo que me lo discutas”.
"Diseñamos un documento sobre el que vamos a hablar de una serie de tecnologías. No hay prueba de código. No necesitas compartir pantalla, aunque en ocasiones es preferible que pudieras compartir porque a lo mejor te vas a sentir más cómodo escribiéndonos un pseudocódigo. Pero la función de esto es, por ejemplo: ponemos un cachito de código de Java y de lo que se trata es de que tú nos digas qué crees que hace el código, qué problemas le ves… Siempre en el plan de que te lo leas tranquilamente y me comentes qué problemas estás viendo. No necesito que me hagas un seudocódigo ni nada. Simplemente discútemelo", señala Aguilera.
“Luego la siguiente prueba, a la que damos mucha importancia, son los test. Tenemos un ejemplo muy tonto. A veces hemos hecho una máquina de café; otras un radiador, algo que no es del negocio. Y planteamos: supón que tienes que hacer los test de la máquina, ¿Qué propondrías? Se trata de que planteen test unitarios, de integración, cómo lo diseñarían…”, comenta. A lo largo del proceso sobre la mesa se deslizan cuestiones relacionadas con Java, GIT, Docker… El último paso es la entrevista con el CTO para conocer la filosofía de la compañía.
Iria Vázquez, del departamento de RR. HH. de Bahía Software, explica que en su compañía recurren a un recruiting activo. “Estamos en LinkedIn buscando diferentes perfiles. Dado que en el sector actualmente el número de perfiles que están empleados es casi del 90% somos nosotros quienes contactamos con aquellos que nos parecen interesantes e iniciamos el proceso”, añade. Sus ofertas están disponibles también en su web de Enjoy Bahía. La primera toma de contacto de los aspirantes se establece con el departamento de selección de personal y consiste en una evaluación general a la que le sigue después la de carácter más técnico, en la que se puede plantear una evaluación y entrevista con personal del equipo, como un responsable del proyecto. “En el primer contacto ya dejamos claro de antemano cuál va a ser el proceso, en qué va a consistir y también los plazos”, apostilla.
"Es cierto que hay determinadas situaciones en las que los plazos se dilatan porque puede estar alguien de vacaciones, surgir algún imprevisto que lo retrase un poco… Pero habitualmente solemos manejar unos plazos de unas dos o tres semanas para concluir el proceso de selección en todas sus fases. Y es algo que el candidato conoce ya en el primer contacto".
Durante el proceso —explica la técnica de RR. HH.— se recurre a pruebas de carácter técnico. Aunque pueden variar de una oferta a otra, poco tienen que ver sin embargo con las que requieren días de trabajo. “La más exigente está pensada para que se complete en tres horas, más o menos. Como cada candidato las hace en el momento que le viene bien, normalmente damos varios días de margen. Nos adaptamos a las circunstancias de cada uno de los candidatos. En función de sus preferencias o tiempo del que pueda disponer, nos amoldamos”, detalla.
¿Se usan los resultados de esas pruebas más tarde como un trabajo aprovechable? “En ningún caso. Las pruebas que tenemos planteadas de hecho son con ejemplos totalmente chorras. Por ejemplo una de las que tenemos es con una clínica veterinaria, que no son nuestros clientes ni especialidades. Son ejemplos cotidianos y no tienen nada de aprovechable”.
“En muchas ocasiones nos hemos encontrado con candidatos que son reticentes a hacer este tipo de pruebas. Lo entendemos. Ya no solo porque se puedan haber encontrado con situaciones de este tipo, sino también por la inversión de tiempo. Por eso para nosotros es fundamental que el candidato se pueda organizar como quiera para hacer la prueba”, comenta Iria, quien recalca, en cualquier caso, que sus pruebas oscilan entre los 15 minutos y las tres horas.
Ángela Souto trabaja también en el área de selección de personal de otra gran empresa de carácter tecnológico: Altia, consultoría y prestadora de servicios TIC. Su labor de búsqueda es igualmente proactiva y durante el proceso recurre principalmente a LinkedIn e InfoJobs, que pueden completar con plataformas internacionales. “A día de hoy un 70 u 80% consiste en búsqueda proactiva. El otro 20% pueden ser personas que se inscriben o se dirigen a nosotros a través de la web o por contactos y referencias internas. Hay que ser especialmente proactivo”, señala.
El primer peldaño para los aspirantes consiste también en una entrevista de carácter personal durante la que se atiende a cuestiones como las motivaciones o expectativas. “Con esa información continuamos o no con el candidato y se lo presentamos a los responsables técnicos del proceso de selección. Si le encaja, ya cerramos una entrevista presencial o telemática”, comenta.
¿Se aporta toda la información en la oferta? “Te mentiría si te digo que publicamos toda. Ponemos las tecnologías, pero no especificamos ni sector, ni cliente ni en qué va a consistir como tal porque muchas veces esa información es sensible —señala Ángela—. En el momento en que alguien se apunta y nos encaja, en esa primera llamada con nosotras le decimos qué proyecto es, las tecnologías… Intentamos dar la mayor información posible para que nadie se lleve un chasco”.
En cuanto al envío de pruebas técnicas, la compañía prescinde de ellas. “La filosofía es que hacemos una entrevista técnica y durante la conversación se pregunta, plantea cómo afrontar situaciones que nos permiten ver la capacidad resolutiva de la persona, su capacidad para aprender, qué problemas se ha encontrado, qué soluciones… Se trata de una entrevista para saber sus conocimientos, pero no hacemos una evaluación técnica”, detalla Souto: “Al final poner a prueba bajo un examen a alguien que ya tiene una trayectoria profesional no es la clave para detectar si es la persona que necesitamos para la compañía. Creemos que cuando una persona apuesta por nosotros y nosotros por esa persona, en el momento que llega a la empresa se aprecia muy rápido si tiene o no ese conocimiento. Se trata de confiar, de ver cómo funciona”.
El feedback con aspirantes es también fluido. “Hay procesos que se complican, que empiezan el día 1 y el 25 aún no están resueltos. En esos casos, habrá tenido dos contactos por nuestra parte”.
Gracias a su labor como responsable de operaciones y RR. HH. de KeepCoding, centro de formación en programación y tecnología, Marina Boticario aporta una visión de gran valor sobre la experiencia de los candidatos. “De lo que más se suelen quejar es de que les hacen pruebas incluso sin que haya una entrevista personal. El primer filtro es una prueba larga, a la que hay que dedicar mínimo un fin de semana. Y ahora sobre todo con el COVID-19 se está focalizando en el trabajo online. Te dan una prueba y hay veces en las que tienes que estar tres o cuatro días dedicado totalmente a hacerla —señala—. Es una manera más rápida de filtrar. Consiste solo en darle a un botón. No tienen que quedar con el candidato físicamente”.
“Las ofertas son muy amplias, es cierto. Te piden muchos lenguajes, cosas tanto de back como de front; pero creo que eso pasa en todos los ámbitos, no solo en el mundo del desarrollo. Siempre hay cierto grado de incertidumbre y no saber qué va a pasar en una entrevista. Se puede extrapolar un poco a la amplitud y generalidad que puede tener un puesto. Hay un montón de lenguajes que están en constante evolución”, abunda Boticario desde las oficinas de KeepCoding.
Un consejo: practicar, enfrentarse a retos personales, documentarse, acudir con tranquilidad a la prueba y preguntar. “Tienes que saber que es una entrevista, que lo que quieren es conocerte y ver también cómo te enfrentas a situaciones que desconoces”, comenta Marina.
Imágenes: Tim Regan (Flickr)
Ver 68 comentarios
68 comentarios
virusaco
En una empresa a la que me presenté me hicieron una batería de preguntas técnicas que tiraban a lo meramente teórico. Yo las respondí como pude, todas, y me contrataron.
Ya dentro, descubrí que el que me entrevistó era 《uno más 》, nadie especial en la empresa, y que no trabajaba en la especialidad de las preguntas que me hicieron.
Le pregunté que cómo supo que respondía lo correcto. Me dijo que no tenía ni idea de lo que yo le respondía. Buscó unas cuantas preguntas de Internet, y como veía que le respondía muy seguro, pensó que era correcto. Y recuerdo que terminé la entrevista decepcionado, porque algunas respuestas me las inventé.
Desde entonces le he perdido el miedo a las entrevistas.
Salu3
endinyat
Hace unos meses hice una prueba, y el resultado fue "0/5: no usa X librería". Aunque usara otra librería que hace lo mismo, igual de válida. Nadie me dijo que tenía que usar nada en concreto. Menuda pérdida de tiempo.
Trocotronic
“ Alguien contrataría a un actor sin realizar un casting?, ¿un deportista sin realizar pruebas físicas?”
Menuda falacia se ha marcado. Un cásting o una prueba física no duran más de 20 minutos. Lo que pide esta gente con sus “pruebas” de 3 días es lo mismo que decirle a un actor que se memorice el papel de una escena, la ensaye y salga a rodarla y grabarla.
John Appleseed
Estoy de los dos lados, y cabe mencionar que eso de los "periodos" de prueba, no es aconsejable.
Me explico, las empresas con salarios más competitivos buscan un nivel bastante alto, y usualmente las personas con ese nivel ya tienen trabajo.
Así que es bastante injusto, pedirle a una persona que renuncie a su trabajo estable, para estar 3 meses de prueba, a ver si lo contratas o no.
Es por eso que en muchas empresas de este perfil, no existe el periodo de prueba, te contratan por tiempo indefinido directamente.
duelelaverdad
Me iba gustando el artículo hasta que vi a Marina Boticario de Keepcoding. La peor experiencia que he tenido en la vida de la formación. Mucho dinero tirado para 4 directos donde no aprendes casi nada y tras reclamar (de muy buen rollo por mi parte) soluciones, solo se preocupaban en cobrar la mensualidad.
Atención malísima, aunque espectacular en la preventa ;)
Nunca más Keepcoding. Solo hay que buscar opiniones en google...
dreedu
Yo suelo rechazar ofertas que me pidan pruebas técnicas que pueda tardar más de 2h en hacerlas.
En general en el sector it hay mucha demanda y te puedes permitir rechazarlas.
Yo les digo simplemente que no puedo dedicar todo mi tiempo libre de una semana en hacerles una prueba para cobrar un poco más de lo que cobró actualmente y suelo darles la opción de que hagamos una entrevista técnica o que miren mi perfil de github y en general con eso les suele bastar.
gonzalochumillas
Por favor, dejad de trabajar gratis. Perjudica al colectivo informático. Lo que ellos llaman "la típica prueba" en el fondo es "trabajo gratis". Vamos a valorarnos un poco, no?
mad_max
Es lo bueno de que en el sector IT haya demanda y en la medida de lo posible los programadores podamos elegir. Si en una entrevista me dicen que tengo que hacer una prueba de varios dias, educadamente les digo que no hace falta que gasten mas tiempo, que busquen otro programador.
victorvidal
De esta misma mañana buscando empleo como diseñador...
01. Mando el currículum de una oferta a través de Indeed.
02. A los 30 minutos me mandan un e-mail diciéndome que debo hacer una prueba práctica sencilla para acceder a la entrevista (ni si quiera me llaman).
03. Me mandan la prueba comprendida en:
A.- Diseñar un patín unisex + diseño de packaging.
B.- Diseñar el packaging para un scooter eléctrico.
C.- Diseñar el packaging con malla fastlacing de unas protecciones de rodillas.
Sueldo: 16.000€ brutos/año
Les comento que me parece desproporcionada la prueba por la cantidad de horas que se deben invertir (no solo en creación, si no en investigación) y que por qué debo mandarles un arte final con los troqueles si solo es una prueba. A lo que solo me responden: esos archivos no tienen la menor importancia, si estás de acuerdo seguimos con el proceso. Muchas gracias, reciba un cordial saludo.
Pues qué queréis que os diga, por experiencias ya, no sólo esta, van buscando el trabajo gratuito porque se niegan a firmar un docuemto donde refleje mi actividad como prueba profesional y que esos diseños no se utilizarán total o parcialmente para fines comerciales y/o promocionales.
Lo peor de todo es que sí habrá alguien que acceda a ello y terminará con suerte dándole las gracias, no es lo que buscamos. Y con más suerte aún, si se juntan los astros, lo contratarán.
Neojate
Pues yo también estoy más que en contra de los botcamps. Los botcamps nacen de la fuerte demanda que hay y de la necesidad de conseguir más y más desarrolladores. Pero ostias, es eso, una forma de sacar programadores como churros.
En un periodo tan corto es imposible, y recalco lo de imposible, conseguir la formación y experiencia necesaria ya no sólo para desenvolverse bien, sino para saber lo que estás haciendo.
jujuan lolopez
Pienso que en España no se valora al programador en relación a su esfuerzo (tanto al que hace trabajando como al que ha hecho para llegar ahí).
black_ice
Hace como 18 meses estuve en un proceso de selección para entrar en DataDog. 6 entrevistas mas una aplicación móvil después, todo estaba yendo sobre ruedas hasta la última entrevista: Tenía que solucionar un pequeño problema (no muy difícil, la verdad), y me dieron a elegir entre hacerlo en pizarra o en el ordenador. Dado que todo había ido tan bien, me vine arriba y empezaron los problemas. Escogí pizarra (primer error, nunca escribo código sin ordenador), y encima dado que sabía que la solución trivial tenía una complejidad O(n), empecé directamente a programar una solución O(n log n). Vamos que dibujé un laberinto yo solito y me perdí dentro, y dado que no podía ejecutar el código, la solución que di fue de todo menos elegante.
Normalmente estos procesos de selección no son "democracias" sino que todos los que te han entrevistado han de dar el OK, un solo KO y estás fuera, y me quedé a las puertas por listo xD
Así que nada, lección aprendida.
Yo lo único que quiero aportar al respecto es que os metáis en algún proceso una vez al año o así. Es importante saber que no te estás quedando atrás, y sobre todo porque enfrentarte a ellas hará que dejes de tener miedo en el futuro.
david6757
Hay cosas que se pueden cribar.
Como una futura primera entrevista en la que te dicen que trabajarás para el cliente final y que solo te pueden dar su información si ellos quieren entrevistarte. Ok, pero le preguntas que herramientas utilizan, frameworks, control de versiones, como trabajan a grandes rasgos...y la respuesta suele ser: no sé, eso ya se lo tendrías que preguntar a ellos. Si pasa eso y ya tienes trabajo, creo que lo mejor es no molestarse.
O una prueba para casa después de una primera entrevista que sea un microservicio....si ya, me chupo el dedo, hasta luego.
O algún listo, y digo algún, que hace 10 años programaba y ahora está de consultor , haciéndote preguntas absurdas con un tono de superioridad.
Pero para ser honesto después de tomar yo la decisión de hacer una entrevista presencial o no, la mayoría de las empresas han sido correctas, alguna prueba esporádica en la propia oficina o casa y las mejores las que hablas mucho y ellos te hablan mucho para conocerte personalmente y técnicamente. A veces el feeling es mejor que cualquier prueba.
[EX3]
Solo he hecho 2 pruebas técnicas en mi vida profesional como programador:
1.- La primera, en un conocido estudio indie de videojuegos en Madrid. Dos partes, entrevista con batería de preguntas (lo típico, conocimientos, cuéntanos sobre tu experiencia, como harías tal cosa, etc...) y prueba técnica de 1h (en este caso coger un mini-juego hecho en Unity, rotisimo y fatalmente programado, "preparado" para arreglar una lista de requisitos y objetivos).
La primera parte, la entrevista, todo sobre ruedas, batería de preguntas de programación, temas específicos de desarrollo de juegos (con y sin Unity), y pareció que les encaje bastante bien.
La segunda parte. Tras 1h de pegarme con el código de ese mini-juego, tirar trabajo atrás a los 40 minutos y llegar con parte de la lista arreglada, la respuesta fue "le pasamos un DIFF al código y ya te decimos". Ni preguntas sobre como has razonado X problema, como te has enfrentado a Y, has visto aquello, etc... nada, un DIFF y buenos días (mi cara un poema en ese momento). Me encantaría ver como alguien es capaz de saber que has hecho o como has pensado nada pasandole un misero DIFF a un proyecto hecho con la tecnología o herramienta que sea (que no estas evaluando un Pull Request, ¡por favor!).
Actualmente se por un reciente candidato que este estudio ha abandonado hace tiempo las pruebas técnicas en sus procesos de selección por que vieron que estaban perdiendo gente valida para el puesto. Me pregunto por que sera...
2.- La segunda prueba ha sido para mi actual trabajo. Tras venderme la oferta una recruiter, me pasa la prueba a realizar, desarrollar un pequeño chat cliente-servidor con una librería concreta de websockets en modo terminal (algo muy sencillo, nada que la empresa pudiera aprovechar en el producto que desarrolla). Todo centrado en ver como usas patrones de diseño, IoC, como de limpio es tu código, buenas practicas, pruebas unitarias y como de estable es tu desarrollo (que no reviente por ningún lado, vamos).
En este caso, ademas de ir recibiendo feedback continuo de la recruiter y del RRHH con quien tuve la primera toma de contacto con la empresa, tuve después la entrevista con el equipo que iban a ser mis compañeros y quienes habían revisado la prueba técnica. Todo genial, destriparon todo el desarrollo que hice, me preguntaron por como había atacado ciertos problemas de la prueba, resaltando tanto lo bueno como lo malo, ademas de una batería de preguntas que fue de lo más ameno que he tenido en una entrevista jamas. Nada tenso y muy coloquial.
En este ultimo caso, nunca sentí haber perdido el tiempo con el proceso y la prueba, principalmente por el feedback continuo recibido, que una vez dentro de la empresa y viendo otros procesos que han realizado a futuros candidatos, veo que nunca se deja colgado al candidato, para bien o para mal, sin un feedback detallado que le pueda ser útil. Se que si no me hubieran cogido habría sabido al menos los motivos.
El otro punto, el saber evaluar una prueba técnica como es debido. Si haces cosas como en el primer caso, luego no te extrañes de que nadie pase el corte de lo que buscas (y más cuando la entrevista previa la pasas perfectamente o por encima de las expectativas). Si no eres capaz de hacer una evaluación mínima de como una persona ha desarrollado y razonado tu prueba, mejor ahorratela.
o00o
Algún día debéis explicar el misterio de Infojobs.
Llevo más de un año aplicando para "ofertas" con muy pocos aspirantes y en las que encajo como un guante por experiencia y estudios, sin embargo soy rechazado al día siguiente. El misterio es que al poco tiempo la misma empresa vuelve a "buscar" un perfil idéntico o muy parecido. Vuelvo a solicitar y vuelta a rechazar, y al poco tiempo vuelta a publicar un anuncio similar.
Empiezo a pensar que el negocio de Infojobs es suministrar datos a empresas, y que las empresas no tienen el más mínimo interés en contratar a través de Infojobs.
frangar
Que paguen las pruebas y listo.
niwghx
España: procesos de selección de 15 días, 10 entrevistas, 2 en inglés y 3 trabajos enviados para validar tus conocimientos.
Sueldo: 16.000 - 29.000 euros brutos. Es decir, 16.000 euros.
A TOMAR POR C*LO.
manolomalocalvo1
Los comentarios: “menuda falacia” , “estoy en los dos lados” ...
Yo viendo el video: bro eso se puede hacer con O(n)
palalol
Yo hago o no la prueba técnica, me explico: si me prometen el oro y el moro no me preocupa usar 10 horas esa semana en una prueba técnica, pero para una oferta sin más ni hago prueba técnica, que muchas veces parece que para ser desarrollador tengas que demostrar que sabes desencriptar datos del pentágono.
Usuario desactivado
Revisas el CV
Lo/la entrevistas
Y si pasas el corte, prueba de código remunerada.
Si la dedicación estimada es de dos horas, a la empresa le sale a 80 euros (lo que sea). No se va a arruinar, y el coste/beneficio es claramente ventajoso.
Si es una prueba de dos días, será porque la empresa necesita evaluar aspectos muy concretos o críticos. Por tanto, no le debería "doler" pagar 600 euros (lo que sea) por candidato.
Exos
Hay que distinguir lo que es una prueba de un trabajo gratuito en encubierto, quizás haya una funda línea que los separe, pero un fin de semana entero programando es trabajo gratuito, si se llega a eso hay que exigir que se pague.
Yo me he visto en situaciones similares, no en programación, fue una vez y no más Santo Tomás.
carloslópez_1
No soy programador, pero me identifico con el artículo. No es la única disciplina que se ve afectada por esta práctica. Vivo en un país pequeño y pobre y aquí es el paraíso de las malas prácticas, aquí te ponen pruebas de ventas rápidas, solo para decir luego que otro fue más rápido. Te solicitan información sobre salarios anteriores, algo que no se está obligado a declarar, pero que por obtener el empleo, la gente se ve obligada a entregar, así tienen la posiblidad de ofrecer un salario más bajo, y muchas joyas más!
gaxupin
Me siento totalmente identificado. Llevo dos meses desempleado y haciendo pruebas de este tipo. Lo peor no es las pruebas en si, si no que tras pasar 3 semanas de diversos test, pruebas técnicas y entrevistas...
Hasta la última no conoces realmente el cliente, el proyecto y la funcionalidad concreta que desarrollarás, donde en muchos casos ni el cliente ni tu es lo que esperabais ya que al menos dos empresas has pasado filtro, la de reclutacion y la contratista.
Actualmente solapado por dos procesos y teniendo una vida, me encuentro de madrugada intentando echar horas para acabar una de ellas... Me quedo con la parte de aprendizaje pero al menos que si no eres seleccionado que haya al menos un mínimo de feedback técnico.
napartar
En mi caso me ha tocado estar en las dos partes, ya que soy desarrollador y las he realizado como candidato, pero también me ha tocado preparar pruebas técnicas como parte del equipo de selección.
Por romper una lanza a favor de este tipo de pruebas, es que un código, por muy básica que sea la función que realiza, habla mucho de la persona que lo programa. Eso sí, las pruebas que yo diseñaba no pasaban de las 2-3 horas para su realización y no requerían ningún tipo de framework (solo javascript + html + css para frontend y jquery era opcional). Obviamente no se puede diseñar una prueba que la gente pueda copy-pastear, pero tampoco algo complejo (veo una barbaridad que la implementación lleve más de una tarde).
Dicho esto, obviamente la prueba se podía falsear ya que cada candidato la hacía en su casa, pero en conjunto con una entrevista técnica da una visión muy buena del perfil que pueda tener esa persona.
Otro tipo de pruebas, como son las presenciales en la propia entrevista, y las basadas en frameworks no me parecen para nada efectivas, ya que en las primeras el candidato puede estar nervioso y en las segundas la implementación se alarga mucho.
robertgarcia2
En México son cortas, y con cierta experiencia ya sabes si es una prueba o algo más.
jacal...
Llevo trabajando más de 20 años (y he pasado por unas 15 empresas como empleado o consultor/freelance), he sido candidato y entrevistador y tengo que decir que las pruebas, si se hacen correctamente, ayudan a ver cómo te desenvuelves más allá de lo que pueda poner en su cv o lo que su experiencia pueda dejar entender.
En mi caso, uso una formula simple, una entrevista técnica con un Tech lead en la que el candidato debe demostrar conocimientos generales y alguno específico (siempre derivado de lo que el comenta en la entrevista), otra con el manager (siempre técnico y haciendo una entrevista técnica) en la que el candidato demuestra sus capacidades personales y técnicas, y una vez más entrando en detalle únicamente en los temas que salen durante la entrevista. Por último, una (en realidad dos) test de código con pantalla compartida en la que desarrollas junto con el entrevistador (obviamente llevando el candidato la batuta) y usando todos los medios que consideres necesario, no hay restricciones salgo buscar directamente la solución, confrontando opiniones y ayudándose entre ellos.
Se trata de ver como piensa el candidato y como averigua cuál podría ser la solución, nada de librerías concretas o similares.
Dicho esto, me he visto en el otro lado con pruebas muy ilógicas y con resultados aún más ilógicos, como por ejemplo una en la que en lugar de dejar encontrar una solución se ponía una especificación estricta que era evidentemente ineficiente pero que entiendo que se ajustaba al estilo del leader técnico de la empresa, por lo que cualquier alternativa no era bienvenida. Es algo que no comparto, pero que puede que tenga lógica en el contexto de algunas empresas.