Son usuales las quejas cruzadas entre entrevistados y entrevistadores cuando se trata de puestos orientados a la programación.
Los primeros apuntan al escaso entendimiento técnico del entrevistador, a su apego a una lista incongruente o inútil de preguntas o a un cuestionario del tipo examen multiple choice sobre detalles técnicos que -por suerte- internet nos ha relevado de recordar, entre otras.
Los segundos recalcan cierta altanería de la gente del sector (en épocas de vacas gordas), poca o mala predisposición a hacerse entender cuando se rozan temas técnicos y sobre todo un tufillo a desprecio por cualquier competencia más allá de las puramente técnicas: puntualidad, presencia, formalidad, comunicación, etc.
Que para muestra baste un botón, aunque tengo la sensación de haber leído varios ejemplos más estos días.
Me he puesto a imaginar qué preguntaría yo en calidad de entrevistador. Aclaro que no tengo mucha experiencia como tal, aunque sí bastante de entrevistado. Éste es un seleccionado armado a partir de las preguntas que recuerdo, más algunas modificaciones.
0. El saludo, la mirada, la ropa, todo eso.
No me considero muy capacitado para examinar estos detalles en fino, así que dejo los consejos al entrevistado a cargo de los expertos.
Lo que sí puedo mencionar es un par de puntos que ayudan a ubicarse y a ver mejor al entrevistador "desde este lado": si no tiene conocimientos técnicos hay que aclararlo de entrada (el entrevistado debe poder y saber ubicarse). Tener tiempo disponible, prestar la debida atención, interrumpir con amabilidad, no discutir y en lo posible tampoco expresar desacuerdos (vale para entrevistados, también: dejar que el otro se entierre sólo). Si viene al caso, exponer las razones del desacuerdo una sola vez y objetivamente.
¿Por qué buscas un nuevo trabajo?
Me gusta esa pregunta para romper el hielo, suele ser una de las típicas, por lo que no sorprende al entrevistado (¿para qué hacerlo sentir incómodo?) y su respuesta nos brinda un panorama de sus principales motivaciones, gustos y preferencias. También pueden observarse detalles interesantes: ¿No está dando una respuesta "de compromiso"? ¿Parece tenerla preparada?
Una búsqueda de trabajo necesariamente implica algún tipo de malestar respecto de la situación actual -creo-. ¿Parece sincero al expresarlo?
¿Cómo es el proyecto en el que trabajas o el último en el cual has participado?
Puede ser personal o laboral (habrá que ver hacia dónde apunta). ¿Es correcto en la utilización de las palabras técnicas? ¿Se esfuerza y logra evitarlas cuando su interlocutor no tiene suficientes conocimientos? ¿Puede resumir un proyecto complejo en unas pocas palabras?.
¿Cuál es el problema más difícil al que te has enfrentado y cómo lo has resuelto (si lo has logrado)?
De vuelta habrá que ver si logra ubicarse y hacerse entender sin entrar en excesivos detalles. También está el tema de la sinceridad: puede que no haya logrado resolver el problema sólo, o que no lo haya hecho en lo absoluto. Es una forma de explorar sus recursos: ¿utiliza internet? ¿bibliografía? ¿pide ayuda a otras personas o prefiere investigar por su cuenta? Resolvemos problemas todo el tiempo, y en todo desarrollo habrá algo, por más mínimo que sea, que nunca hemos hecho.
¿Podrías escribir un breve resumen de (lo que es o de lo que te imaginas que es) un día de trabajo "normal"?
Todos los programadores podemos leer y escribir código. Más fácil, más difícil, más o menos enmarañado, eso sólo implica más o menos tiempo y esfuerzo para entenderlo, finalmente sabremos qué es lo que hace. Por otro lado, el código es un tema que probablemente el entrevistador no esté capacitado para evaluar.
¿Pero puede escribir decentemente en lenguaje natural? En el quehacer cotidiano hay mucho que escribir aparte de código: hay que producir comentarios, documentación, notas o pautas de diseño que otras personas (o uno mismo luego de mucho tiempo) deben poder decodificar. También hay que reportar errores, intercambiar correos sobre cuestiones complicadas, a veces comunicarse directamente con personas ajenas al equipo.
Éste es para mí uno de los puntos más importantes (ver Del desarrollo de software como sistema de comunicación y la importancia de poder leer y escribir). Una nota mal escrita hace un mes implica rehacer todo un trabajo de investigación por no poder decodificarla. Un error mal reportado no puede corregirse. Una tarea mal especificada o mal decodificada son horas o días de trabajo perdido. Un mail hacia fuera del equipo con faltas de ortografía -o directamente incomprensible- es motivo de bochorno para el equipo o la empresa... ¡y ni que hablar de un error de ortografía en un mensaje de la aplicación!
De más está decir que quien escribe correctamente suele leer más que correctamente, por lo que con este breve examen abarcamos todo.
Ok, no tiene que ser Borges, pero... El contenido también demostrará qué es lo que espera de un día de trabajo "normal", qué situaciones le parecen comunes, y permitirá compararlo contra el ambiente en el que efectivamente se desenvolverá.
Una situación hipotética...
Creo que ésta es una pregunta que se hace mucho, con sus variaciones. Comienza con una historia breve: "Tienes tu primera tarea asignada, eso implica demostrar de qué eres capaz. Ves que no estás logrando resolverla en tus horas normales de trabajo. De seguir así no cumplirás con los tiempos comprometidos"... ¿Qué haces?
¿Avisa? ¿Se queda hasta más tarde hasta resolverla? ¿Busca ayuda? ¿A un compañero, al jefe, a quién? ¿Intenta ocultarlo?
Creo que con esto se cubre más o menos explícitamente todo lo importante para un programador, más allá de lo técnico, y en las respuestas y en los modos está el resto.
¿Qué les parece? ¿Alguno de uds. tiene su propio método?
5 comentarios:
Me ha gustado el post.
No es que tenga demasiada experiencia en entrevistas,así que, solo tengo experiencia en las 2 primeras. Quizás alguna vez también me hayan planteado la tercera pero las dos últimas nunca.
Me acuerdo de una entrevista con el dueño de una empresita en el que yo le tenía mas fe en la empresa que el mismismo dueño: le dije que dentro de 2 años quería cobrar en acciones y me saco a "empujones" verbales.
¿Conviene decir que queremos espacio para instalarnos con una carpa y vivir dentro de la empresa, sin olvidarnos de exigir abundante cafe para trabajar 22 horas diarias?
Pensar que hay personas que trabajan de entrevistadores, como habran ingresado? Gran misterio, :P
Mi modesta opinión es que damos demasiadas vueltas con un tema trivial. Trivial o inútil, de acuerdo por donde se lo mire.
Digo esto porque no podemos caer bajo la ilusión de tener la situación en control: nadie sabe como es una persona por hablar una hora, particularmente si el otro es al menos un poco hábil. El que se piensa capaz o se está autoengañando o se está engañando.
Cualquier psicópata (loco de mierda) puede pasar por persona normal y ejemplar vecino y padre de familia por unos minutos.
Improbable: es verdad, la gente con la que trabajo y yo mismo somos la prueba más fehaciente de ello. :-)
Ahora en serio. Eso si pensamos la entrevista como un filtro de locos o mentirosos.
Si partimos de la base de que la entrevista puede ser una evaluación mutua en la que ambas partes se benefician diciendo la verdad (porque la información obtenida les permite tomar mejores decisiones en algo tan importante), no es ni trivial ni inútil.
Ni al evaluado le conviene ingresar en un puesto que no le guste o convenga (en nuestro rubro y en la coyuntura actual, cambiaría nuevamente en menos de un par de meses) ni al evaluador, ya que implica un retrabajo (más selección, más entrevistas, etc.)
Por lo menos hasta donde yo sé, los reclutadores ofrecen algún tipo de "garantía" sobre el postulante que promocionan. Si el contrato no pasa la fase de prueba el reclutador tiene que seguir buscando, sin cobrar nuevamente.
Si es así les conviene ser abiertos y sinceros en cuanto al puesto a cubrir.
Cuando estaba en el rubro aprendí que en general es la empresa la que no tiene muy en claro qué perfil busca y por eso el reclutador es el que tiene que "tantear" u "olfatear".
Eso implica no poder brindar demasiada información al entrevistado, cayendo en las situaciones delirantes que todos conocemos.
¿Esto sigue siendo así? Supongo que sí. Por lo menos en mi experiencia, uno no sabe cómo viene la mano hasta que se entrevista con algún futuro compañero de trabajo. Ahí sí la charla es más distendida y abierta, se habla de cómo se trabaja realmente, de qué se hace, de cómo es la idiosincrasia de la empresa, etc.
No, no digo que la entrevista sea inútil. Es sumamente útil cuando se encuentran dos personas honestas que hablan abiertamente de sus expectativas y de lo que tienen para ofrecer.
Lo que me parece de una inutilidad insultante es la lista de consejos que anduvieron proliferando estos días en algunos blogs, donde alguien mezcla cosas obvias (del tipo no le hagas un comentario a la selectora del estilo 'wow... que culo tenés, aunque deberías invertir en tetas') con cosas que le gustan unicamente al que escribe (del estilo de debe llevarse una corbata salmón y gemelos plateados). En la entrevista conviene ser honesto y claro, a ambas partes.
El resto, es adorno que puede gustar o no dependiendo de quien tengas delante.
Al momento de entrevistar, puede ser útil tener una lista de preguntas. Pero, particularmente la gente de RRHH, puede terminar entrevistando gente que las dobla en experiencia y que tiene más batallas luchadas (perdidas y ganadas) que las que tiene quien entrevista y en ese caso mejor ser flexible.
Poner nervioso o apretar al candidato?. (acá voy a usar una de las ventajas de escribir con un seudónimo: ser algo altanero) Tal vez, si algún día me entreviste alguien de Korn Ferry logre ponerme nervioso.
Pero diría que intentarlo no tiene caso. Es una entrevista, todos sabemos que no es real, no te da una pauta de como actuará bajo presión salvo que sea un loco hiperreactivo. Es fácil para cualquiera controlarse cinco minutos, lo difícil es hacerlo dos semanas.
Publicar un comentario