Como contratamos desarrolladores en Treehouse

Traducción del post de http://wellbredgrapefruit.com escrita por Tommy Morgan @duwanis

(Post original http://wellbredgrapefruit.com/blog/2013/06/01/how-we-hire-developers-at-treehouse/ )

Me siento muy feliz por el proceso de contratación en Treehouse. A lo largo de mi carrera, he pasado y conducido por entrevistas desde un rango bastante extremo hasta algo muy simple (¿Por qué las tapas de alcantarilla son redondas?) hasta algo mucho más intenso como (“Estos son los problemas de código. Tienes 10hrs. Empieza.”). He filtrado curriculums y escuchado compañeros de trabajo explicar porque piensan que tal candidato no encajaría (“Porque no parece entender como funciona un motor a diesel”).

Contratar desarrolladores en Treehouse es bastante indoloro, en parte porque hemos sido muy cuidadosos para construir un equipo sólido, pero también porque nos preocupamos mucho de quitar todo lo que no aporta valor en el proceso de entrevista.

Paso 1: Las preguntas

Cuando alguien está interesado en aplicar para formar parte del equipo de desarrollo en Treehouse, les hacemos 4 preguntas para nosotros. Estas nos sirven como filtro inicial:

1. ¿Por qué quieres trabajar para Treehouse? La parte más importante al construir un buen equipo es entender las motivaciones de tus empleados, por lo que está la primera pregunta que hacemos. A menudo decidimos no proseguir en el proceso a pesar del talento de los candidatos basado en la respuesta a esta pregunta.

2. ¿Nos puedes compartir un ejemplo de código del que estes orgulloso, o que piensas que representa una parte importante de tu filosofía para el código? ¡Dos preguntas por el precio de una! Obtenemos la primera vista al código del candidato, y también podemos escuchar que piensan ellos que es importante sobre como programar.

3. ¿Puedes decirnos acerca de un problema difícil que tuviste que resolver, y como lo resolviste? Esta pregunta es mayormente para darnos una idea sobre el proceso mental del aplicante, e históricamente nos ha dado las respuestas más interesantes. He visto respuestas del rango de “aquí está un problema con algoritmo interesante que tuve que resolver” a “bueno, pues mi esposa y yo estábamos tratando de encontrar un departamento…”

4. ¿Podrías darnos una breve descripción de tus conocimientos previos (No curriculum)? La misión de Treehouse es ayudar a las personas a educarse a sí mismas en una mejor carrera, por lo que casi parecería hipócrita de nuestra parte poner un énfasis significativo en educación formal y experiencia, razón por la cual no pedimos curriculums. Al mismo tiempo, es de gran ayuda saber de donde viene el aplicante o candidato.

Yo sirvo como el primer filtro para las respuestas a estas preguntas de parte de los aplicantes. Hay algunas circunstancias donde descartaré candidatos que esten siendo evaluados – Si se comunican pobremente en sus respuestas, malentienden las preguntas (es sorprendente cuanta gente me envia su curriculum inmediatamente), o de otra manera indican que ellos no serían la mejor opción para encajar en el equipo, entonces la entrevista termina ahí. Si no, entonces sus respuestas pasan hacia el resto de nuestro equipo.

Paso 2: Las entrevistas

Si el resto del equipo revisa las respuestas y están contentos con el aplicante, organizo una llamada con ellos. Esto es lo típico y aburrido: explico el puesto, los beneficios, contesto a las preguntas que tengan respecto a como trabajamos. La meta aquí es asegurarnos que entienden a lo que están aplicando y como funciona el resto del proceso de entrevista, y si están interesados podemos seguir adelante antes de tomar más tiempo de ellos.

Si siguen interesados, agendamos entrevistas con el resto del equipo. Estas entrevistas son mayormente orientadas a validar si puede encajar el candidato en nuestro equipo. Esto es importante, porque encajar es una de las cosas más difíciles de arreglar si no existe química – puedes entrenar a gente en tecnología y puedes cultivar el talento, pero diferencias en personalidad son prácticamente imposibles de eliminar.

Si el candidato ha hablado con los otros miembros del equipo y todos están de acuerdo en continuar con el proceso de entrevista, nos movemos al siguiente paso: darles un contrato de proyecto.

Paso 3: El proyecto

Para mí, esta es la fase más interesante en nuestro proceso de entrevista. Hasta aquí hemos determinado que el candidato es alguien que encaja bien en el equipo, y el candidato está interesado en lo que podemos ofrecer. El último paso en el proceso es escencialmente  un manera de visualizar como sería si la persona fuera contratada.

Tratamos de encontrar un proyecto que podamos darle al aplicante. En el mejor de los casos, el proyecto encaja con el siguiente criterio:

• Es un proyecto real – eso es, que cuando el aplicante complete su trabajo en el proyecto, tenemos la intención de mover el código a producción en el sitio de Treehouse.

• Es suficientemente grande, pero no demasiado – nosotros típicamente apuntamos a que sea un proyecto que puede tomar de 10 a 20 horas de esfuerzo, como eso es suficientemente grande que requerirá bastante razonamiento pero no tanto que tomé semanas el proceso de entrevista.

• No es parte crítica del proceso común de la compañia – como el aplicante estará trabajando en este proyecto en su propio tiempo libre en la mayoria de los casos, ellos necesitan poder ejecutarlo a su propio ritmo. De manera que podemos ayudar a preservar que no demos proyectos de alta prioridad para la compañia por ahora, por lo que con esto no habrá ninguna tentación de presionar para que sea finalizado más pronto.

• Requiere coordinación –  a menudo nos salimos del camino al tratar de buscar proyectos que se encargan de partes complicadas de nuestro código base o que requieren interacción con nuestro equipo de diseño de manera que podamos tener el sentir de como trabajaran todos juntos.

Le damos el proyecto al candidato y acordamos compensarlos por el tiempo utilizado a la tarifa (razonable) que ellos escojan. Aún si no se elige al candidato para contratarlo, ellos hacen un trabajo que agrega valor para nosotros y queremos asegurarnos que reciban una compensación justa por ello. El aplicante hace su trabajo – preferentemente en un Github pull request, de manera que podamos darle seguimiento.

La parte genial de esto, es que puede ser una técnica de entrevista de doble filo: no solo nosotros podemos ver como el candidato interactuará con nuestro código y cooperará con nuestro equipo en un proyecto real, pero además el aplicante podrá probar el tipo de trabajo que estaremos haciendo. Además se darán una idea del estado de nuesro código (nadie ha salido corriendo aún) y ver como el equipo se comporta afuera de un ambiente de entrevista muchas veces estéril. Es un ganar-ganar, y si todos salen felices del proceso entonces sabemos que obtuvimos un candidato al que quisieramos hacerle una oferta.

Resúmen

Ese es entonces nuestro proceso de entrevista. Es un poco más largo y más involucrado que otros, pero nos ha servido bien y me parece que hace un buen trabajo ayudando al candidato para representarse a ellos mismos con nosotros, y ayudándonos a representarnos nosotros ante el candidato al mismo tiempo. Aunque no puedo tomar el crédito de construir este proceso – eso va para Alan – y de hecho me gusta y pienso que nos ha ayudado a construir un equipo sólido hasta ahora. Pero, como siempre estoy abierto a sugerencias 🙂 Por favor dejénme saber si creen que existen otras formas que podrían mejorar nuestro proceso.

Posteado por Tommy Morgan – 1ero de Junio, 2013

(Post original http://wellbredgrapefruit.com/blog/2013/06/01/how-we-hire-developers-at-treehouse/ )