Necesitas una prueba de programación. Pero debería ser de 5 a 10 minutos. 30 minutos como máximo. No hay ninguna prueba de 2 horas que te diga exactamente lo bueno que es un programador. No podrás saber si escriben continuamente código mantenible, o si siempre comentan correctamente, o si vienen con un lío ilegible de soluciones “inteligentes” a los problemas, etc. En 2 horas, lo único que lograrás es descubrir quién está mintiendo abiertamente sobre el conocimiento de un lenguaje/programación.

Excepto que deberías ser capaz de detectar los fraudes abiertos en mucho menos tiempo que 2 horas. 5 minutos escribiendo FizzBuzz y 2-3 preguntas rápidas sobre características específicas del lenguaje te dirán si son absolutamente inútiles. Y eso es lo mejor que puedes hacer en una entrevista de trabajo.

Déjame decirte lo que pensaría si recibiera un examen de 2 horas por el privilegio de realizar una entrevista:

“O bien estas personas piensan que esto tiene valor, lo que significa que no tienen ni idea de lo que están haciendo, O bien, saben que esto es una pérdida de tiempo, pero por alguna razón (probablemente siguiendo ciegamente la burocracia de RR.HH.), están dispuestos a perder el tiempo de los candidatos antes de que el candidato sea siquiera contratado. Imagina lo que pensarán que pueden conseguir una vez que me paguen.

De cualquier manera, no quiero trabajar allí.”

Hay otra cosa que podría estar alejando a los candidatos: La duración de su proceso de entrevista. Tienes gente haciendo una entrevista telefónica. Luego una prueba para llevar a casa que tienen una semana para terminar. Luego repasas las pruebas. Luego se establece una entrevista personal con la gerencia. Luego (asumo) que haces un par de entrevistas personales. Luego te devuelves al tipo que quieres contratar. ¿Qué se necesita para eso? ¿Dos semanas? ¿Más tiempo?

En ese tiempo ya he recibido 3 ofertas. Acepté una y empiezo la semana que viene. ¿Crees que voy a hacer tu prueba de 2 horas?

Permítanme comenzar diciendo que contratar empleados en general es una ciencia patéticamente inexacta, y obtendrán varios resultados sin importar lo que intenten. Habiendo dicho eso, sentí que debía compartir mis pensamientos sobre esto.

Creo que los ejercicios de programación son un fracaso, principalmente porque conseguirás que la gente que está desesperada y tiene demasiado tiempo en sus manos lo complete. Si tienen un trabajo a tiempo completo, tendrías que preguntar cuánto tiempo/energía mental están tomando de su actual empleador para trabajar para alguien que ni siquiera les paga. ¿Quieres que te hagan cosas así?

Además, si son buenos, lo más probable es que se entrevisten con muchos empleadores. ¿Adivina a cuáles le darán prioridad? Los que no piden completar los proyectos antes de hablar por teléfono con un gerente de ingeniería.

También está el problema del plagio. Claro, se descubrirán en la entrevista en persona, pero para entonces ya habrás desperdiciado el tiempo de (presumiblemente) personas altamente remuneradas de la empresa entrevistando a esta persona.

Mi actual empresa lo hizo bien, y esta es la ruta que yo seguiría en tu posición. Déles una pequeña tarea que sólo debería llevarles unos 90-120 minutos, y dígales que justifiquen en los comentarios por qué eligieron esa forma de resolver el problema. Esto es algo que se puede hacer en una noche, y te dará una visión de su pensamiento.

Puedo decirles ahora mismo que si consigo un proyecto que me lleve más de 8 horas, les digo que gracias pero que no estoy interesado. Tengo un buen trabajo y una vida. Si un gerente lo ve como un problema, me dice que no le importaría mi equilibrio trabajo/vida en el trabajo (especialmente si no les importa antes de que lo tenga). Ninguna empresa, excepto quizás Google, Apple o Facebook, podría salirse con la suya.

En mi experiencia, los proyectos para llevar a casa no eliminan a los malos codificadores, y probablemente hacen que los buenos codificadores encuentren un trabajo en el que no tengan que pasar por un aro para hablar con el gerente de contratación.

Piénsalo de esta manera. Un buen programador puede fácilmente conseguir entrevistas telefónicas y en persona. Cada aro extra que tengan que pasar significará que tomarán la ruta más fácil y serán entrevistados (y contratados) por alguien más que pagará lo mismo. Si haces que la gente salte a través de los aros, asegúrate de que vean que vale la pena desde el principio.

Un mal programador puede tardar todo el tiempo que quiera. No los verás tomar 4 veces más tiempo, sólo verás la prueba completa. Tampoco los verás ir a Google o a su amigo para que te ayude con una declaración de if.

Mi última compañía hizo esto, y la gran mayoría de la gente que trajimos para una entrevista en persona falló Fizz buzz (alrededor del 65%). Creo que esto sucedió porque, sin querer, eliminamos a gente buena y ocupada que no necesitaba la entrevista de otra empresa y, al mismo tiempo, colgamos una entrevista fácil delante de malos programadores.

Lo que creo que deberíamos haber hecho en su lugar

En lugar de dar a la gente una tarea para llevar a casa que nos llevara 15-20 minutos de calificación, deberíamos haber hecho una entrevista por Skype de 15-20 minutos en la que hiciéramos preguntas como Fizz buzz. Esto habría tomado la misma cantidad de tiempo, pero probablemente habría eliminado a los malos programadores antes de una entrevista en persona de dos horas.

Para tu información - Aquí hay un artículo muy detallado sobre Fizz-buzz y las prácticas generales de entrevista.

Un punto de vista contrastado, de alguien en las trincheras a ambos lados de esta cuestión. Sospecho que esta respuesta atraerá votos negativos, pero es una opinión muy informada, desarrollada durante varias décadas en este negocio. Porque me gusta hacerlo, sigo escribiendo código todos los días para ganarme la vida y como hobby en mi “copioso tiempo libre”, pero también he sido el que ha tomado la decisión final de contratar a un par de docenas de programadores, y he ayudado a entrevistar y asesorar sobre la contratación de un número bastante grande más.

Lawrence tiene razón: la contratación es lamentablemente inexacta. Pero estamos mejorando con el tiempo. Más que las charlas cara a cara, más que las preguntas de trivialidad, los retos de la programación corta en el lugar son una parte cada vez más esencial de eso: no sólo por la habilidad, sino por la actitud.

Tengan en cuenta que dije “corta ”. Le damos a los candidatos un portátil con un Eclipse debidamente instalado (nuestro IDE elegido) cuando vienen a la entrevista. Instalado correctamente significa que tienen acceso a la fuente jdk, pero no tiene internet, y se les pide que no usen teléfonos celulares durante la prueba. Tienen una hora para resolver entre cero y cinco problemas, comenzando por “FizzBuzz”, y subiendo en complejidad hasta algo del orden de un simple sistema multi-hilo de productor/multi-consumidor.

Nadie ha resuelto nunca los cinco en una hora, y no espero que nadie lo haga nunca (puedo escribir soluciones para cinco en menos de una hora, pero por supuesto he visto los problemas y los he resuelto todos anteriormente, así que no soy una prueba justa).

Por cierto, hemos tenido programadores ostensiblemente experimentados fallo para acertar con FizzBuzz. Permítanme decirlo de nuevo: hemos tenido un puñado de candidatos que no han completado FizzBuzz correctamente. Normalmente por no seguir las instrucciones, pero leer las especificaciones es una parte esencial de ser un desarrollador.

Les hacemos escribir código mientras están aquí en las instalaciones en lugar de darles deberes por varias razones, en parte el riesgo de hacer trampas, y en parte para dar a cada candidato una oportunidad igual de trabajar los problemas. También rotamos los problemas dentro y fuera del conjunto de desafíos, y discutimos las soluciones con los candidatos después.

Me siento muy fuerte en este tema. Nunca he visto a un candidato rechazar un puesto o abandonar el proceso de entrevista debido a nuestra prueba de programación. Pero eso puede estar influenciado por el hecho de que les decimos a los reclutadores que nos sirven que el proceso incluye la programación en el lugar. Así que puede que no veamos a los candidatos que piensan que el hecho de que se les pida que escriban una hora de código es “trabajo no remunerado”. Si es así, que se vaya el diablo. Si piensan que una hora de código es más un “trabajo” que una hora de responder preguntas de trivialidades, o que sus respuestas a problemas de pruebas pueden producir algo útil, no necesito su actitud.

Una vez tuvimos un candidato que se quejó de la prueba, porque pensaba que era demasiado mayor para tener que probarse a sí mismo (eso no es especulación - lo dijo). Y lo hizo bien en los desafíos, y tenía toda la experiencia que queríamos. Pero era un empleado terrible: aparentemente también pensaba que era demasiado mayor para tomar dirección o aprender, y al final tuvimos que dejarlo ir.

Una de las cosas que he decidido a lo largo de los años que llevamos haciendo esto es que cualquier compañía que no haga la prueba es menos probable que me consiga como empleado. Como sus respuestas a preguntas como qué usan para el control de fuentes, etc., el hecho de que una compañía haga pruebas me dice mucho sobre lo buenos que son en el negocio del desarrollo de software.

Así que, ¿qué debería _hacer? Debería hacer lo que funciona para su organización, pero mi consejo es que continúe las pruebas, pero que las haga in situ, como parte de la entrevista. Dígales de antemano que eso es parte del proceso, y hágalo antes de que se reúnan con la alta dirección (pero debería reunirse con ellos primero para ayudar a que se sientan cómodos). Y realmente: salte la entrevista con la alta dirección si fracasan. No se preocupe por la popularidad de los candidatos o los carteles en Internet. El costo de una mala contratación es mucho peor que el costo de retrasar hasta hacer una buena contratación.

Pourquoi pas de tests à domicile ? Même si nous ignorons la possibilité de tricher et le filtre inversé qui fait que les bons et honnêtes candidats évitent les sociétés qui proposent des tests de codage à domicile, la valeur des tests de codage à domicile est limitée. Si c'est pour un poste de supérieur, un développeur senior ayant des compétences en relations humaines sera capable de dire en moins de 10 minutes si le développeur senior à l'autre bout du fil est bon ou s'il invente des choses. Nous ne saurons pas exactement à quel point il est bon, mais nous en saurons autant, voire plus, que ce que tous les tests de codage imaginables à domicile nous disent.

Si c'est pour un poste de cadre supérieur , nous n'attendons pas grand-chose en termes d'expertise technique. Nous recherchons l'enthousiasme, la volonté d'apprendre et le talent - qui ne sont pas repérés par un test de codage à domicile. Il y a trop de choses que les juniors sont autorisés à ignorer. Si nous les engageons, nous devons les former de toute façon.

Comment tester à la place ?

Comme filtre, donnez-leur 10 minutes pour résoudre une variante FizzBuzz sur place pendant la première série d'entretiens ou, si vous êtes submergé de bons CV et que vous avez besoin d'un autre filtre, faites-le sur Skype avant la première véritable série d'entretiens.

Une fois qu'ils ont passé les filtres, vous devez en savoir plus sur les capacités de codage de vos candidats. Je recommande de passer 30 minutes à 2 heures maximum de programmation en binôme ou d'examen des codes - un vrai travail, plutôt qu'un exercice. Répétez l'exercice une ou deux fois avec des partenaires différents. L'avantage de la programmation par paires et des révisions de code est que le développeur a déjà suffisamment de connaissances pour y contribuer.

Ne vous inquiétez pas du fait que le test soit différent pour chaque embauche - le but du processus d'embauche n'est pas de trouver la personne qui obtient le meilleur score dans quelques tests mesurables et répétables. L'objectif est d'engager une seule personne qui fera bien le travail.

Aquí hay otro punto que no veo cubierto en las respuestas existentes (que creo que cubren bien el tema en general). Yo miraría de cerca y seriamente cuánto tiempo le toma a la gente completarlo. He tenido cuatro entrevistas de trabajo durante las cuales tuve que completar un ejercicio de programación, cada una de las cuales se hizo de manera diferente (y cada una tuvo sus propias ventajas y desventajas). Dos de las cuatro (números 3 y 4 abajo) tomaron mucho más tiempo del que dijeron que debía, y en ambas terminé abandonando por el difícil nivel que implicaba. Los he descrito a continuación y los he clasificado de mejor a peor desde mi perspectiva.

1. Durante la entrevista técnica, me sentaron en un ordenador que tenía una versión reducida de su código base y me hicieron resolver tres problemas relativamente cortos relacionados con él (encontrar y arreglar un error que habían añadido a propósito, añadir un nuevo campo a una tabla de información, etc.). Me dieron exactamente una hora para hacerlo, y después de una hora repasaron mi solución así como la forma en que abordé los problemas. Esto les dio una mayor comprensión de mí como programador, respetando mi tiempo al mantenerlo corto y al punto.
2. Durante la entrevista técnica me hicieron trabajar en un problema que habían encontrado durante el desarrollo en una pizarra, mientras que eran capaces de hacer rebotar las ideas en ellos. Esta fue la opción más corta, mientras que les daba la oportunidad de ver cómo resuelvo los problemas y cuánto puedo realmente hacer el trabajo necesario. Durante la entrevista técnica (para un puesto de desarrollo web de Ruby on Rails junior) me encargaron la tarea de construir una aplicación web desde cero que navegara a un sitio web, llenara múltiples formularios a medida que se presentaban, rascara los datos de la página resultante y se la presentara al usuario. Dijeron que este debía ser un ejercicio rápido, y puede que lo fuera para un desarrollador web de nivel superior, pero como en ese momento sólo tenía un año de experiencia profesional, pasé cuatro horas intentando que todo funcionara antes de rendirme y volver a casa (todos los entrevistadores se habían ido horas antes que yo porque era una entrevista por la tarde, dijeron que debía guardar el programa terminado cuando terminara). Esta es una tarea ridícula para el puesto indicado, no les dio ninguna idea de mis habilidades de codificación, y me pareció que sólo estaban tratando de obtener trabajo gratis del trato. No hace falta decir que ni siquiera quería el trabajo cuando me fui ese día.
3. Antes incluso de tener una entrevista técnica, me dieron la tarea de crear una aplicación web que aprovechara una API que su empresa utilizaba para “hacer algo interesante”. Esto fue exactamente tan amplio como suena. Esto requería que hiciera lo siguiente antes incluso de intentar crear la aplicación: crear una cuenta de desarrollador para la API, descargar el kit de desarrollo de la API, crear una aplicación web de acceso público (con otra cuenta de desarrollador), aprender la API y crear un repositorio de datos para acceder con la API. Esto, por supuesto, me llevó muchas horas sólo para empezar, y poco después de empezar con la aplicación web propiamente dicha, tuve una entrevista de trabajo diferente y poco después una oferta de empleo, así que dejé de trabajar en la tarea. Es una locura tener esto como parte de un proceso de entrevista porque ¿quién quiere poner todo ese tiempo y esfuerzo en el desarrollo de un programa sólo para tener una pequeña oportunidad de avanzar en el proceso de entrevista?

Así que para responder más directamente a su pregunta, ¿debería hacer un ejercicio de programación? Sí, pero asegúrese de que esté hecho a medida para probar lo que realmente le importa, y no requiera una tonelada de trabajo extra para el entrevistado. ¿Quieres saber sobre su pensamiento algorítmico? Dales un problema de algoritmos. ¿Quieres saber sobre su estilo de codificación? Dales un problema de codificación. ¿Quieres saber sobre su proceso de desarrollo? Discute su proceso con ellos mientras trabajan en un problema.

Permítanme comenzar con:

• Me han dado pruebas para completar en casa que van desde 15 minutos a 10 horas.
• Me han dado pruebas en línea para que las repase.
• Me han encargado escribir la respuesta a FizzBuzz y otras pruebas de moda en Internet en pizarras blancas.
• Me han preguntado sobre las tapas de alcantarilla cuadradas vs. redondas.

En resumen, he tratado con casi todas las formas diferentes en que los desarrolladores les gusta manejar las entrevistas. Para ser sincero, dudo seriamente que la gran mayoría de las personas que me entrevistaron hayan entendido siquiera cuáles eran los resultados potenciales de cada una de esas pruebas y, en última instancia, sólo contrataron a gente para saber si les “gustaban” o no.

Antes de que pongas una lista de trabajos deberías sentarte y repasar exactamente qué es lo que intentas contratar y “desarrollador” no es una respuesta, al menos, no es una respuesta adecuada. Una buena respuesta a esto sería algo como “experto en dominios hipotecarios”.

Encontrar a alguien que pueda escribir un poco de código o buscar en Google cómo aplicar un patrón particular es trivial comparado con encontrar a alguien que ha estado en el negocio en el que estás y puede aprovechar ese conocimiento. En otras palabras, si yo estuviera contratando para una compañía de documentación de hipotecas, tomaría a alguien que pudiera hablar de la diferencia entre un préstamo a 15 años fijo y uno ARM sobre alguien que pudiera escribir un algoritmo de clasificación de burbujas en 2 minutos. La razón es que la gente de negocios “normal” hace todo tipo de demandas extrañas y los expertos en dominios pueden llegar más fácilmente al corazón de lo que se necesita mientras que alguien que no sabe nada felizmente agregará cosas que son inútiles o que hacen que la aplicación sea realmente mala.

Volviendo a las preguntas, sólo haz preguntas de ir/no ir.

¿Es crítico que la persona pueda decirte la diferencia entre un método virtual y uno abstracto? Puede ser, normalmente no lo es. Apostaría que una buena parte de los desarrolladores apenas saben cuando usar esas palabras clave pero no son sus superestrellas, son el rango y el archivo que usan no pueden codificar sin los diseñadores visuales.

¿Es crítico detectar cuando una consulta está abierta para la inyección de sql? Para una posición Sr., absolutamente; para una posición Jr., no. Esto es algo que se puede entrenar fácilmente y se maneja a través de la revisión de código. De ahí la razón por la que quieres que el Sr. lo sepa por dentro y por fuera, para que puedan entrenar a los junior.

¿Es crítico que sepan el valor máximo exacto de un tipo de datos Int32? Normalmente no, para ese nivel de conocimiento trivial es para lo que está Google; pero tal vez su requerimiento es para codificar en dispositivos de memoria limitada, en ese caso: absolutamente.

Entrevisto y contrato desarrolladores. No envío pruebas a casa, es demasiado fácil que un amigo me ayude. No utilizo sitios de pruebas en línea - dado que la puntuación tiene que ser automatizada es trivial para el juego. No le pido a los candidatos que escriban la respuesta a la efervescencia - casi todo el mundo ha visto esa prueba y debería saber la respuesta de memoria; todos los demás entraron en el campo en el último año y son jr. de todos modos. Tampoco hago preguntas de trivialidad - ser capaz de recitar la respuesta normalmente sólo significa que has escuchado la pregunta antes.

Lo que hago para entrevistar a la gente:

• les pido que describan un proyecto previo o dos. Todo lo que me importa en este punto es hacerlos sentir cómodos y hacerlos hablar. Esto es un ir/no ir porque si no puedo entender lo que están diciendo entonces no puedo trabajar con ellos.

• Les hago algunas preguntas específicas en la tecnología que necesito que usen. Si es un servidor SQL, preguntaré sobre la actualización en un join. Si es HTML, les doy un archivo html de 10 líneas con un par de clases css y les pregunto cuál es el resultado. Estas son preguntas triviales para gente con experiencia en esas áreas y rápidamente elimina a los pretendientes.

• Si busco un Sr. Dev entonces haré preguntas de conocimiento de dominio. No cosas de casos extremos, sino más bien principios básicos. Si necesito que dirijas un proyecto de contabilidad, entonces es mejor que tengas una idea de los principios básicos de contabilidad.

• Si estoy buscando un Jr. Dev, entonces preguntaré sobre proyectos de mascotas. Todo lo que quiero saber es el tipo de tecnología utilizada. Esto debería darte una pista de lo que realmente quieren hacer. En otras palabras, un desarrollador de C# no es probable que haga proyectos favoritos en php. Honestamente no espero mucho de un desarrollador jr excepto ser entrenable. Si están trabajando activamente en un proyecto para mascotas, entonces puedo entrenarlos. Si son del tipo que necesitan que la gente les diga qué hacer, hay compañías mucho más grandes en las que estos tipos pueden trabajar.

No hago estas preguntas sobre la marcha, las respuestas potenciales se consideran con antelación y se ajustan a un patrón de ir/no ir. Si una pregunta no se ajusta a eso, entonces no es relevante. También pregunto a todos los candidatos los mismos a menos que esté 100% convencido de que no los estoy contratando, en cuyo caso detendré la entrevista.

Si por alguna razón usted todavía insiste en enviar a casa un test - asegúrese de que las habilidades requeridas para completar con éxito ese test en una cantidad razonable de tiempo son en realidad habilidades que te importan.

Tuve una compañía que me dio una prueba para llevar a casa que implicaba escribir un proveedor de servicios de criptografía personalizado. Completé la prueba porque era algo interesante; me contrataron. En ningún momento de mi vida hice nada ni remotamente relacionado con la seguridad, la criptografía o incluso las matemáticas más allá de sumar unos pocos números. Me pregunto a cuánta gente se llevaron con esa prueba.

Solía ser un firme creyente en las pruebas de codificación y en la codificación de pizarras, pero he empezado a darme cuenta de que son bastante inútiles, porque

¿Qué estás probando, de todos modos?

Una prueba de pizarra, o prueba de programación corta te da algo de conocimiento sobre el individuo, pero realmente no tanto. A menos que planees que alguien pase su tiempo escribiendo código en una pizarra o en un código al estilo de FizzBuzz.

¿Qué es lo que quieres?

Quieres a alguien que sea:

• apasionado
• dispuesto a aprender
• capaz de resolver problemas*
• resonablemente técnico
• que vaya a ayudar a tu equipo mejorar

* Nota, la mayoría de los desarrolladores resuelven sus problemas sabiendo qué términos buscar en Google.

La _última cosa que quieres contratar es alguien que no encaje bien en tu equipo porque lo arrastrarán.

• ¿Cómo puedes probar esto?

• Pregúntales sobre un proyecto que les haya gustado. Si parecen reacios a hablar de ello, intente expresar una suave incredulidad, por ejemplo: “No puedes hacer X, ¿verdad?” Si es algo que les apasiona, te corregirán. Esto también te ayudará a saber si son técnicos o no.

• Pregúntales sobre las cosas que han aprendido recientemente. O lo que aprendieron del proyecto en el que trabajaron disfrutaron.

• Pregúntales sobre la última vez (o una vez) en la que les faltó algún conocimiento. ¿Cómo obtuvieron la información que necesitaban? ¿Fueron a un compañero de equipo? ¿Buscaron en Internet?

• Pregúntales si hay algo que quisieran ver mejorado en su actual/último equipo. ¿Necesitaban mejores mensajes de compromiso? ¿Más revisiones de código? ¿Más pruebas? ¿Más automatización?

• Pregúntales qué tecnología les entusiasma, y por qué.

Si tienes a alguien que es técnicamente competente en esta conversación será lo más fácil del mundo decir si esta persona será la peor. Un ejemplo: tuvimos un niño que vino a la entrevista y dijo que en una escala del 1 al 10, sus habilidades en Java eran como un 7-8. Creo que ni siquiera sabía que el Java fue compilado en un archivo jar que luego fue compilado en lenguaje de máquina por la JVM. Yo me clasificaría tal vez como un 2 o un 3 y Yo lo sé.

Nuestro CTO le hizo la misma pregunta en una entrevista el día anterior, y nuestro CTO lo llamó y le explicó que no había manera de que fuera un 7-8.

Nuestro CTO también le preguntó sobre su proyecto favorito, que tenía que ver con los escáneres de mano. Pero no pudo explicar nada acerca de cómo funcionaban, o el hecho de que usaban las encuestas para evitar las esperas ocupadas. No pudo explicar ni una sola cosa técnica.

Ese tipo no fue contratado.

Averigua el tipo de atributos que buscas, y luego averigua cómo probar para aquellos

¡Pero yo realmente necesito ver cómo codifica!

Está bien, eso está bien - pero a menos que vaya a codificar en un silo, lo mejor será contratarla como contratista para un proyecto pequeño y bien definido. Tal vez esté agregando la capacidad de descargar algunos archivos de un FTP y luego volcarlos en su base de datos. Algo simple, que no requiere mucho/cualquier conocimiento de dominio.

Haga que sus candidatos trabajen con uno o dos empleados existentes, y págueles por su tiempo. Podrás ver exactamente cómo trabajan, y lo bien que trabajan con el equipo. ¿Se comunican bien? ¿Se frustran fácilmente? ¿Son persistentes?

Hay _cosas que puedes hacer para contratar mejores empleados… pero una competencia de programación probablemente no es una de ellas.

Desde el punto de vista de una persona que busca trabajo, generalmente evito los lugares que tardan más de una hora en codificar. Una vez fui a este lugar que requería un proyecto de codificación en Java de casi 3 días. Lo hice todo y el tipo estaba incluso impresionado con ello pero me dijeron que contrataron a alguien más después de la segunda etapa de la entrevista. Así que después de eso, si vengo a una compañía ignoraría/pasaría cualquier proyecto que requiera más de un par de horas para completarlo. Mi tiempo es tan valioso como el de ellos y prefiero no desperdiciarlo en cosas que no me lleven a ninguna parte.

Dicho esto, si tu ejercicio de codificación es demasiado largo, tal vez la gente no esté dispuesta a dedicarle tiempo. Intentaría reducirlo de tal manera que tome una hora como máximo pero al mismo tiempo demuestre un entendimiento de la codificación y tal vez ponerle una fecha límite como, “Por favor complete para el COB mañana” o algo así. Pueden seguir “copiando y pegando” algo en línea, pero lo hacen difícil siendo específicos en lugar de algo que lees en línea.

Como otros han notado, algunos desarrolladores pueden ser postergados por un ejercicio de programación de 1-2 horas para solicitar un trabajo. Lo que puede funcionar mejor es tener una sesión de pizarra blanca, donde el candidato resuelve un problema en una pizarra blanca durante la entrevista. Esto le permite la oportunidad de tener una entrevista en persona, mientras que también se asegura de que tienen chuletas técnicas.

Estos problemas no deben ser extremadamente difíciles, o diseñados para hacer tropezar a un desarrollador. Un ejemplo clásico es FizzBuzz . Esto te permite ver cómo piensan, y también saber que al menos pueden programar y no necesitan buscar en Google cómo hacer un bucle.

En mi opinión, el problema que tiene aquí no es necesariamente la prueba de programación. Primero tienes la entrevista técnica telefónica y luego una prueba de trabajo desde casa antes de una entrevista cara a cara. Suena como si mantuvieras a tus candidatos a distancia y lo dejaras para el último minuto antes de conocerlos. ¿En qué momento espera que los candidatos decidan que quieren trabajar para usted?

Asumo que su anuncio de contratación es similar a la mayoría y por lo tanto se centra en la ubicación, el salario y una (deseable) lista de habilidades. Los candidatos no saben realmente en qué trabajarían, nada sobre el entorno o la gente con la que tendrían que interactuar. Aún no les has vendido el trabajo, aquí estás pidiéndoles que demuestren sus capacidades técnicas dos veces antes de que lleguen a hacer una sola pregunta sobre el trabajo.

Te sugiero que intentes cambiar el formato de la entrevista telefónica técnica para que sea una charla de 30 a 45 minutos sobre el trabajo, incluyendo muchas oportunidades de preguntas de los candidatos, y luego 15 minutos de preguntas técnicas como pantalla para que aún tengas la oportunidad de elegir a los mejores candidatos sin hacerlo demasiado oneroso.

También consideraría trasladar el desafío de la programación para que se haga en el lugar antes de las entrevistas. Parecería más factible para los candidatos, les daría un incentivo para mantenerse en el camino del proceso y usted obtendría el beneficio de observar el verdadero tiempo dedicado al desafío (creo que se sorprendería).

¿Quieres contratar programadores que no pueden programar?

Voy a aventurarme a que no lo hagas.

Contratar programadores que no pueden resolver problemas y escribir código es una buena manera de arruinar una empresa de tecnología. Y no vas a ser efectivo en eliminar a los programadores que no pueden programar (y hay _muchos de ellos) si tu proceso de contratación no incluye algún tipo de prueba de programación.

¿Estás dispuesto a bajar tus estándares porque todo el mundo está tratando de contratar programadores?

Tal vez sí, pero no creo que debas hacerlo. Como se ha señalado en los comentarios y respuestas, hay candidatos que no se van a molestar en hacer ejercicios de programación como parte de un proceso de entrevista porque simplemente no lo necesitan para conseguir un trabajo.

¿Pero son realmente esas las personas que quieres contratar de todas formas? Los que siguen el camino de la menor resistencia, hacen lo que es más beneficioso para ellos a corto plazo, y no se preocupan lo suficiente por su empresa como para completar un simple ejercicio de programación? Esos no parecen atributos positivos, y no proporcionan mucha confianza en términos de ser capaces de retener a esos candidatos a largo plazo (lo cual también es importante para una compañía tecnológica, ya que las curvas de aprendizaje tienden a ser empinadas y el costo de reemplazar el personal existente es muy alto).

Así que dejemos que esas otras empresas tengan los programadores que ni siquiera pueden ser molestados. No quieres contratarlos de todas formas. A diferencia de ellos, tú tienes un plan. Uno que no se basa en la falacia de “un programador es un programador”. Tu enfoque debe ser en la calidad y la sostenibilidad, no en el número de personas.

¿Es un problema asustar a los candidatos?

Generalmente no, siempre y cuando se les asuste por una buena razón. No quieres contratar a gente que no está a la altura. Y algunas de las personas que dicen que “no pueden ser molestadas” debido a la alta demanda podrían estar usando eso como una excusa para encubrir una situación de “no tan bueno en la programación así que necesitaría toda la semana para completar un ejercicio de 1 hora”

Es bueno asustar a esos candidatos. Quieres contratar a los candidatos capaces y motivados. Mientras no los asustes también, eres bueno.

Cada candidato que no asustas es uno que tienes que tratar de evaluar. Y eso puede ser difícil de hacer si no le das a tus candidatos técnicos ningún ejercicio técnico para usar en la evaluación.

¿Cómo puedo mejorar nuestro proceso de contratación?

Revise el contenido de su ejercicio de programación. ¿Es razonable y apropiado para un contexto de entrevista?

No quieres algo que te va a llevar días (o incluso horas) para completar. Lo que quieres es algo simple para eliminar a las personas que simplemente no pueden programar, idealmente con suficiente espacio para los matices que las personas que pueden programar realmente bien puedan diferenciarse. Ten en cuenta lo que intentas conseguir (eliminar a los candidatos no cualificados y no serios), y asegúrate de que tu contenido se ajusta a ese objetivo. No se exceda.

Si ya tiene personal técnico, puede utilizarlo para comprobar la cordura (y/o ayudar a diseñar) su ejercicio.

Y también considere la forma de administrar el ejercicio. Si les das alguna documentación y les dices “aquí, haz esto durante la próxima semana y envíamelo por correo electrónico”, probablemente sólo será mínimamente efectivo.

Mejor sería si pudieras ejecutar el ejercicio a través de un portal web, que los candidatos puedan comprobar y comenzar el ejercicio, y una vez que comiencen un temporizador empiece la cuenta atrás desde 1 hora. Entonces, o bien presentan algo dentro de esa hora, o no. Eso es menos abierto, mejor mantiene el enfoque del candidato, y proporciona una fecha límite clara y una caja de tiempo para que 1) no te quedes esperando toda la semana por un resultado que nunca va a llegar, y 2) los candidatos no calificados no desperdicien una semana de su tiempo tratando de completar su ejercicio de programación. Tienen 1 hora, o resuelven el problema o no lo hacen, y sabes el resultado inmediatamente.

Y aún mejor sería traerlos para una entrevista en el lugar. Preséntales a un miembro de tu equipo de desarrollo. Enciérrenlos en una habitación junto con una estación de trabajo. Haz que tu desarrollador empiece con algunas preguntas generales/blandas de la entrevista, y luego pueden programar en pareja con el candidato para resolver el ejercicio de programación. Esto le dirá no sólo si el candidato puede codificar o no, sino también lo bien que trabaja con su equipo. Su desarrollador también debe ser capaz de obtener mucha información adicional que no obtendrá simplemente mirando un montón de código que un candidato escribió y luego le envió por correo electrónico.

En resumen

No, usted no quiere deshacerse de su ejercicio de programación. Pero tal vez quieras revisarlo para ver si tiene un contenido apropiado, asegurarte de que no toma mucho tiempo resolverlo, y también ver cómo lo encajas en tu proceso de entrevista global.

Un ejercicio autodirigido para llevar a casa probablemente no es el mejor enfoque. Pero la solución a eso no es desechar el ejercicio por completo. No a menos que estés de acuerdo en contratar programadores de mierda, en cualquier caso.

Es mejor asustar a muchos malos candidatos y a un puñado de buenos que abrir las compuertas y contratar a unos pocos malos.

Una cosa que nadie parece haber mencionado; incluso si la prueba no es tu problema, deberías buscar otras formas de atraer talentos.

Si estás buscando buenas personas basándote en sus trabajos publicados existentes, no necesitas hacerles la prueba.

Si sólo te envían personas a través de reclutadores y filtros, eres vulnerable al hecho de que tus necesidades y las necesidades de los reclutadores no se sinergizan perfectamente. Ellos quieren colocar a alguien contigo. Quieren un ingeniero de alto nivel. Si pueden encontrar a un ingeniero de alto nivel, eso es genial porque volverás con ellos, pero si no pueden (y los ingenieros de alto nivel suelen tener cosas que dejan poco tiempo para las entrevistas), se conformarán con colocar a un ingeniero moderado con un traje bonito. La pérdida para ellos es un poco de reputación a largo plazo, pero eso es menor comparado con perder sus objetivos. Si esto no es cierto en tu caso, quédate con el reclutador y nunca los dejes ir… Los reclutadores que priorizan una relación a largo plazo por encima de los objetivos son diamantes preciosos en un océano de polvo de carbón… Lo que quieres hacer es encontrar candidatos interesantes. Busca en StackOverflow y GitHub a los mejores ingenieros (he oído que StackOverflow tiene una herramienta para ayudar con esto ), busca empresas técnicamente interesantes que produzcan buen software pero que hayan fastidiado sus finanzas o monetización, y que acaben de despedir a 10 ingenieros de alto nivel. Pasa el tiempo trabajando en las universidades ayudando con los proyectos de fin de curso. Identificar buenos candidatos potenciales y entablar amistad con ellos, preferiblemente en persona, o a distancia; aunque tengan ofertas, los buenos ingenieros se juntan con buenos ingenieros. Además, pueden decirle cómo se sienten sobre su proceso de contratación.

¿Suena esto como un montón de trabajo? Debería. Una de las razones por las que contratar parece tan “difícil” es porque intentas hacerlo lo más eficientemente posible. Cuanto más tiempo, capacidad cerebral y recursos se desvían a ello, más fácil es. Si esos recursos se gastarían mejor en el envío de productos es la eterna cuestión de la gestión. Pero si estás gastando mucho tiempo en “filtración de programadores de mierda”, eso es _quemar dinero. Al menos los pasos descritos anteriormente tienen un valor inherente más allá del proceso de contratación.

(*): Diablos, contrátalos.

No me gustan las pruebas para llevar a casa como parte de las entrevistas, por muchas de las razones que la gente ya ha mencionado - extiende el proceso de contratación, devalúa el tiempo del solicitante, puede que no reciba una llamada de vuelta de todos modos, etc.

Mi principal problema es que no es realista a la forma en que el equipo trabaja realmente y hace que el proceso de entrevista sea unilateral. Un solicitante quiere saber si este lugar es un buen lugar para él, incluyendo la cultura, cómo el equipo se acerca y resuelve los problemas. Principalmente también busca la adecuación, incluyendo cómo trabajan y si tienen el conjunto de habilidades adecuadas. Un examen para llevar a casa no le da al solicitante la oportunidad de evaluar las cualidades blandas de un lugar de trabajo, y los empleadores no llegan a saber cómo el solicitante abordó el problema.

Una mejor solución podría ser darle al solicitante un problema más abierto que pueda ser resuelto de cualquier tipo de manera creativa. Incluso se podría restringir a un lenguaje X. En lugar de enviarlo por correo electrónico, invítelos a que lo presenten a usted y a la alta dirección. Les da autonomía e incentivo para hacerlo bien, porque les promete otra entrevista y demuestra que usted se preocupa por saber lo que piensan.

Si tiene que utilizar un test para seleccionar qué candidatos llegan a la entrevista con la alta dirección, yo incluiría el test en la entrevista para que puedan discutir su proceso de pensamiento juntos.

Creo que has formulado tu pregunta un poco mal, pero la forma en que lo has hecho refleja una idea equivocada común sobre la contratación de programadores. ¿Están los candidatos siendo “espantados” por la tarea de programación, o están filtrando a su compañía de su propia consideración debido a la tarea?

Una anécdota para demostrar mi punto: mientras buscaba trabajo no hace mucho, vi una posición para una compañía que parecía promedio. La forma en que describían su proceso de programación lo hacía parecer bastante bueno, pero había muy pocos detalles, por lo que yo era escéptico. Tal vez eran un buen lugar para trabajar, tal vez no. Pero me imaginé que vería la posibilidad de llegar a una pantalla de teléfono para poder averiguar los detalles y ver si eran tan buenos como parecían.

Hice clic en el anuncio de empleo, e inmediatamente me pidieron que escribiera una carta de presentación. Ugh. Creo que todos los candidatos odian las cartas de presentación. No conocía esta compañía ni usaba sus productos, así que, ¿qué podría decir de ellos? Los busqué en Google, leí su sitio web y sus ofertas de productos, descubrí dónde podría encajar en su organigrama si me contrataban, y encontré unos cuantos párrafos “vendiéndome” a mí mismo.

A continuación proporcioné mi currículum y acceso a mi LinkedIn - pero inmediatamente después me pidieron que rellenara mi experiencia laboral relevante con fechas y descripciones. Esta información está tanto en mi LinkedIn como en mi currículum, era ridículo tener que proporcionar la misma información 3 veces. Cerré la pestaña del navegador. 5 minutos después estaba aplicando a otra compañía que ofrecía algunos beneficios realmente geniales que la primera no ofrecía. De hecho, podría solicitar a otra compañía con mejores beneficios más rápido de lo que podría saltar a través de los aros que la primera compañía quería de mí.

Necesitas estar seguro de que tus candidatos están invertidos en tu compañía en particular antes de presentarles cualquier aros para saltar a través, o de lo contrario no saltarán. ¿Haces esto?

Ejemplos de beneficios de calidad que comúnmente veo que las compañías tecnológicas ofrecen:

1. Trabajo a distancia.
2. Computadoras/monitores gratis como bono de firma.
3. La compañía contribuye a proyectos de código abierto respetados.
4. Reembolso por formación profesional y/o conferencias.
5. Almuerzos con catering.
6. Horario flexible.
7. Oportunidad de trabajar con tecnologías nuevas o desconocidas.
8. “Cultura de arranque” - también conocida como falta de política/burocracia.
9. Capital de la compañía.
10. Reconocimiento del nombre: su compañía o su producto es conocido. A los candidatos les gusta mencionar dónde trabajan y escuchar a la gente responder con “¡Oh, genial! Me gustan sus productos”.
11. Objetivos/visión de la compañía caritativa o revolucionaria. A la gente le gusta escribir códigos que mejoren la vida de la gente.
12. Paga por encima del promedio. El dinero cubre una multitud de pecados organizacionales.
13. Esta lista no es exhaustiva, pero si su compañía no ofrece una o más cosas como las de la lista, entonces cualquier obstáculo en su proceso de contratación podría enviar a un candidato a buscar una que sí lo haga. Entonces, ¿qué puede hacer? Tengo dos alternativas que la mayoría de los candidatos preferirán sobre las tareas de programación de trabajo ocupado:

Alternativa #1 - Págueles una tarifa por hora para hacer su tarea de programación como si fueran un contratista. Esto les anima a tomarlo en serio tanto por razones profesionales como porque… les pagan. Esto les cuesta dinero, pero también lo hace cualquier forma de reclutamiento. Si eres realmente bueno, puedes incluso encontrar una manera de que ellos diagnostiquen y arreglen un error real en tu código, en cuyo caso estás obteniendo algo útil por tu dinero.

Alternativa #2 - Probablemente ya han escrito código gratis que te mostrarán si les preguntas. La mayoría de los programadores tienen código en Github, Bitbucket, sitios web de preguntas y respuestas como Stack Overflow, o podrían proporcionarte algún código que no hayan publicado ya.

¿Por qué hacer que escriban código que no les importa cuando podrías dejarles compartir un proyecto de pasión contigo en su lugar? Está garantizado que es menos aburrido que leer otra solución al mismo problema genérico por centésima vez. Y como el código ya está escrito, te ahorra a ti y a tu candidato tiempo. Además, podrás ver qué tipo de código les gusta escribir, lo que da una idea de su personalidad y de lo bien que encajan en la cultura de tu empresa.

Como respuesta directa a la respuesta de Bobo (que es la respuesta aceptada porque el tipo la escribió y la aceptó él mismo, lo que francamente me parece un poco patético):

Vienes de una premisa totalmente equivocada. No quiero trabajar para ti. ¿De dónde sacas esa idea de que alguien quiere trabajar para ti? Usted es sólo una de las muchas empresas que ofrecen un trabajo. No quiero trabajar para ti. Quiero evaluar tu compañía, y si te pones por encima de todas las demás, ahí es cuando quiero trabajar para ti.

Hay una docena de compañías en las que puedo trabajar, tú sólo estás en algún lugar de la cola. Primero miro las empresas que hay, les envío mi CV, pueden leerlo y quedar convenientemente impresionados o no, entonces normalmente tienes una rápida conversación telefónica donde me muestran que tienen un trabajo interesante y yo demuestro que tengo las habilidades, y cualquier prueba de codificación podría llegar al final.

Tu prueba de llevar a casa te pone al final de la cola. Para compensar tendrías que poner un rango salarial que es 10.000 libras más alto que otros. Encontrar un trabajo requiere mucho tiempo; alguien que lo hace diez veces más largo está al final de la lista. Si tengo que elegir entre enviar un currículum y tener una entrevista telefónica con diez empresas, y hacer los deberes por ti, adivina lo que haré.

Lo que pasa es que encuentras candidatos que quieren trabajar para ti porque no conseguirán un trabajo en otro sitio.

Realmente creo que puede ayudar a establecer quién conoce realmente los idiomas que figuran en su currículum.

Si ese es realmente su objetivo, consideraría un enfoque diferente. Como otras respuestas indicaron, SÍ, siempre debes tener una pregunta de codificación, pero las preguntas de codificación rara vez entran en detalles del idioma. Algunas preguntas que he visto que son útiles para probar esto:

1. Compara y contrasta Java y C (o cualquier otro lenguaje que sea relevante, que esté en el currículum del candidato, etc.)
2. (O mejor aún, ¿qué opina sobre este particular cambio propuesto/reciente del lenguaje?)

Los ingenieros que han visto una o dos cosas saben cómo responder a estas preguntas con bastante facilidad, y en sólo unos minutos.

¿Cuál es su problema de negocios?

Descontando todos los argumentos a favor o en contra de determinados exámenes, todo se reduce a una compensación - más filtros ahuyentarán a algunos buenos candidatos, menos filtros dejarán pasar a los candidatos pobres que usted podría tener que reemplazar poco después de la contratación.

Todo se reduce a mirar la situación de su negocio en lugar de las prácticas generales.

¿Tiene actualmente un problema en el que carece de candidatos calificados y no puede contratar tan rápido como necesita para cumplir con sus objetivos de negocios? Necesita deshacerse de esta tarea de programación inicial.

¿Tiene actualmente un problema en el que no está satisfecho con la calidad de sus recientes contrataciones? Entonces necesita implementar más filtros como este.

¿Tiene _ambos problemas, y ambos son igualmente dolorosos? Felicitaciones, ha encontrado el equilibrio correcto para este intercambio.

IMHO hay casi un 0% de posibilidades de que un recién graduado universitario sea capaz de hacer un código de programación difícil en un nivel de entrada. Si su prueba de codificación toma una semana para completarse, entonces deberían mencionar claramente en su requerimiento que están buscando programadores con al menos 2+ años de experiencia, porque creo que se debería requerir mucha experiencia para completar un trabajo de código que requiere una semana para completarse. Y creo que si están buscando recién graduados, entonces diseñen su prueba de acuerdo a eso y pueden encontrar muchas ideas en Internet o pueden pedirle a los programadores senior que trabajan para ustedes que diseñen una prueba adecuada para los recién graduados.

Pensé que respondería a esta pregunta, ha pasado un año desde que fue publicada, y nos hemos ceñido a ella.

Hallazgos

Positivos de acercamiento

1) Lleva a casa la prueba desarraiga a los candidatos desmotivados, y los reemplaza por candidatos que realmente quieren trabajar para ti. Esto por sí solo hace que valga la pena ya que personas motivadas = empleados productivos. Si no se pueden molestar en hacer una tarea de una hora, eso dice mucho sobre su actitud para conseguir el trabajo.

2) Estoy de acuerdo con otros, que el test para llevar a casa no debe ser más largo que una hora - el mío es muy simple. He obtenido los siguientes resultados al añadirlo al proceso de reclutamiento…

a) Algunos candidatos no lo completan. No vale la pena contratarlo.

b) Algunos candidatos lo intentan pero lo completan mal. No vale la pena contratarlo.

c) Algunos candidatos hacen trampa, en cuyo momento vale la pena hacer preguntas de seguimiento sobre su asignación. Hicimos esto con un candidato reciente que no se molestó en responder a nuestro correo electrónico sobre la tarea. No vale la pena contratarlo.

d) Algunos candidatos al escuchar que hay una tarea técnica, de repente retiran su solicitud, donde antes mostraban MUCHO interés. Probablemente esquivó una bala.

e) Algunos candidatos lo hacen extremadamente bien, comentan su código y en una o dos ocasiones proporcionan documentación. **1) El abandono de las solicitudes de los candidatos que se ven postergados por la tarea de llevar a casa hace que sea más largo encontrar a alguien adecuado. Pero por otro lado es positivo para la empresa ya que reduce la probabilidad de una mala contratación, lo cual es peligroso.

2) No siempre puedo decir si alguien ha hecho trampa, pero es por eso que a menudo es respaldado con una entrevista telefónica técnica.

Resultado de este enfoque

Uno de nuestros empleados que contraté usando este enfoque ha resultado ser un empleado estrella. Sigue trabajando para nosotros después de más de un año. Es confiable y técnicamente talentoso.

Un ratón desconocido o una disposición de teclado inesperada (especialmente Mac vs PC), o un IDE diferente pueden ralentizar el rendimiento de forma dramática sin ninguna diferencia en la competencia. Además, una aplicación completa a menudo requiere mucho código de calderilla que un desarrollador puede no tener suficiente tiempo para escribir o incluso no recordar. Iniciar una nueva aplicación completamente desde cero es en realidad una tarea muy poco frecuente; la mayor parte del trabajo se concentra en ampliar o mejorar el código existente.

Por lo tanto, sugiero dar sólo tareas muy cortas y más cuidadosamente preparadas durante la entrevista. Lo mejor es pedir escribir una función que debe tomar determinados parámetros y devolver el resultado explicado y que yo aconsejaría hacer en papel, evitando en absoluto el ordenador.

Los enviaría a un concurso en línea donde puedes filtrar a la gente que no tiene ni idea. Al menos tendrías una idea de si saben de lo que hablan.

Al principio de mi carrera los cazatalentos me dijeron “te enfrentas a gente que lee la caja y pone una solicitud en su currículum”. Asumo que esto todavía puede pasarle a los jóvenes e ingenuos, pero una vez que te destrozan en unas cuantas entrevistas te das cuenta de que es un mal consejo…

Hace poco me hicieron un examen para llevar a casa. Era una aplicación completa que necesitaba conectarse a un servidor de socorro que tenía que simular una alimentación lenta. El cliente se actualizaba dinámicamente, podía cancelar el feed, y escribir y leer XML.

De todas formas quiero aprender sockets ya que estoy pensando en usarlos para un servidor de póquer que estoy escribiendo.

Quería aprender XMLreader y XMLwriter.

Al principio pensé en olvidarlo. Pero luego lo vi como una oportunidad para probar lo que puedo hacer. No tengo un título de CS, así que me pierdo algunas cosas teóricas. Me preguntaron cuáles son los 3 pilares de OOP y querían decir a quién le importa.

Mi mensaje es que la gente que quiera el trabajo debe completar la prueba.