Programación de parejas para una entrevista de trabajo

Question

Nuestra compañía ha estado pensando en eliminar nuestros procedimientos de entrevista y llevar a cada candidato a una sesión de 4-5 horas con algunos de los programadores y simplemente hacer un par de programación.

Me gusta la idea en teoría, pero no estoy seguro de cómo puede realmente hacer que sea justo para cada candidato. ¿Cómo los calificarías? ¿No dependería su aporte de lo que cada programador estaba trabajando ese día?

Cualquier idea sobre si esta es una buena idea/mala idea o cómo hacer que funcione es lo que estoy buscando aquí.

¡Salud!

EDIT:

RESULTADO - Conforme a lo solicitado

Vamos a realizar los primeros pasos de la entrevista, el mismo que antes. Teléfono seguido de cara a cara. En lugar de traerlos de vuelta para una tercera y última asación, vamos a traer a 3 desarrolladores para que se sienten con los 7 miembros del equipo. Hemos decidido dejar que el equipo decida quién es contratado.

Hemos llegado a esta conclusión por un par de razones. Creemos que esto habilitará a los desarrolladores dándoles una opción sobre a quiénes están trabajando. La segunda razón es dinámica de grupo. Creemos que es realmente importante tener una buena dinámica de grupo y es difícil saber hasta después de contratar a una persona si encajarán o no.

Así que el resultado final es que vamos a seguir adelante con las sesiones de programación de par, pero de una manera completamente diferente y de una manera completamente diferente a la prevista originalmente.

¡Cualquier idea o crítica de este enfoque es más que bienvenida! (esta edición se publica como respuesta a continuación, así que no dudes en votar si sientes que este no es el mejor enfoque)

Answer 1

Espero que tengas muchos pasos por delante. Para que esto funcione, necesitas un excelente CV y ​​pantalla de teléfono. No quiere gastar montones de tiempo en candidatos con los que no debería hablar en primer lugar.

Por lo que sugeriría una entrevista inicial y posiblemente tener la segunda entrevista como el par sesión de programación? - Ted Smith (hace 1 minuto)

Sí. Incluso podría pensar en tener una entrevista simple de codificación en la web usando algo como CoPilot.

Answer 2

La manera más fácil es darle a cada persona el mismo programador para trabajar y la misma pieza de código.

El problema con el que se van a encontrar es que la contratación no es como la programación. No hay un proceso paso a paso para llegar a la respuesta correcta sobre a quién contratar. (puede tener múltiples pasos para facilitar la decisión). Debe evaluar cada uno de ellos sobre sus puntos fuertes, etc. y, en esencia, debe adivinar cuál es el mejor para contratar. A veces adivinas mal.

La otra cosa sobre la programación de pares que tendrá que tener en cuenta es la cantidad de tiempo necesaria para que cada candidato en esa etapa pase por ese tipo de prueba.Si estuviera buscando un trabajo, dudaría en ir a una entrevista en una empresa que me pida que haga eso. ¿Por qué? Debido a que es mucho tiempo, y si estoy entrevistando en varios lugares, podría pasar literalmente días yendo a entrevistas para trabajos que ni siquiera puedo obtener o querer. Algunos lugares como Google o MS serían una excepción, pero la mayoría de los lugares no son como esos dos. (Sin mencionar el hecho de que si están trabajando en un código real, esencialmente les estás pidiendo que hagan el trabajo de alguien gratis).

Answer 3

A menos que use la programación de par ampliamente en su desarrollo del mundo real, dudaría en usar esto. Conocí a un gran número de desarrolladores profesionales de alta calidad que han mencionado una fuerte aversión a la programación de pares y cuyas habilidades no serían bien evaluadas en dicho proceso.

Answer 4

¿Por qué no? Además, no es como si las entrevistas fueran siempre (o siempre) justas. Debe evaluar los resultados finales del nuevo enfoque en comparación con el enfoque tradicional basado en entrevistas.

Además, una mini entrevista antes de la sesión de programación podría ser útil para evitar perder el tiempo de los programadores con personas que no encajarían bien.

Answer 5

Me gusta esta idea. Sin embargo, creo que podría ser difícil, ya que requeriría que el candidato tenga algún conocimiento del proyecto con el que se emparejaría. Además, de 4 a 5 horas parece un poco largo. ¿Qué pasa si inmediatamente ves que no va a funcionar, vas a sentarte durante toda la sesión con el candidato?

Buena pregunta sin embargo. Cosas para pensar.

Answer 6

Para que sea justo, tendría que hacer que todos los miembros del personal participantes tengan un problema preparado para evaluar al candidato. Preferiblemente algo tomado del mundo real en la experiencia de su compañía, pero algo que ya se ha resuelto. Esta es una buena oportunidad para evaluar el conocimiento sobre un problema y evaluar no solo las habilidades de programación.

Odio cuando se responden preguntas demasiado específicas. Una vez, tuve una entrevista en la que un programador probaba mi conocimiento del STL, que utilicé ampliamente y estaba tratando de hacer que respondiera que se necesitaba un asignador personalizado. Había oído hablar de ellos pero nunca los usé (especialmente en las ventanas) y me hicieron sentir tonto. IOW, evita ser crítico.

Así que mi punto es que formule preguntas prácticas que no tengan tanto que ver con la prueba del conocimiento de programación, ya que puede evaluar la personalidad más cualitativa y los enfoques de resolución de problemas si usa la idea de "programación de pares".

¡Buena pregunta!

Answer 7

Honestamente, eso suena como una gran idea, aunque Jason Punyon ciertamente tiene razón en que deberías hacer una gran cantidad de desherbado antes de perder cantidades significativas de tiempo de tus desarrolladores en sacrificios. Puedes echar un vistazo a una métrica importante que de otra manera sería casi imposible de obtener en las entrevistas: cómo le gustaría trabajar a alguien.

No creo que haya ninguna necesidad de preocuparse de que sea "justo" en función del tema o tratar de presentar situaciones coherentes a diferentes candidatos, si mantiene la actitud evaluativa adecuada, que no es así. t sobre si "obtuvieron la respuesta correcta" o saltaron a través del conjunto de aros correcto, pero qué tipo de esfuerzo, resolución de problemas, aptitud de comunicación y flexibilidad mostraron. Perderías la mayor parte del beneficio del ejercicio al convertirlo en una prueba artificial, sin mencionar cambiarlo de algo de lo que tus desarrolladores puedan obtener algún beneficio (o al menos hacer un trabajo durante) a un desperdicio masivo de su tiempo.

Answer 8

Joel Spolsky tiene un excelente Guerrilla Guide to Interviewing que se refiere, entre otras cosas, a tareas de programación.

Anécdota: Joel Spolsky es un co-fundador de stackoverflow.com

Answer 9

Como anécdota personal, me golpeó en torno en una entrevista a causa de una técnica como esta. Había ido muy lejos en su proceso de entrevista; Pasó las comprobaciones del curriculum vitae, la presentación del código y esta fue la parte cara a cara de la entrevista.

Acababa de salir de la universidad y nunca antes había programado un par ni había hecho TDD. Me sentaron para hacer un ejercicio de baraja y se cayó. ¡Mal! No entendía por qué el entrevistador estaba escribiendo pruebas que parecían tan tontas * (IE "return null") y no explicaban por qué y, por supuesto, siendo ajeno a TDD, no sabía qué preguntas hacer. El resultado final fue que parecía que no podía programar mi salida de una bolsa de papel.

Si va a hacer este tipo de ejercicio, debe atender al entrevistado porque estarán en diferentes lugares con su aptitud. Esto significa que obtendrá diferentes evaluaciones que pueden no basarse en el talento real y, por lo tanto, van a estar muy sesgadas.

** Ahora que entiendo TDD, entiendo pruebas de este tipo y cómo se supone que funciona, pero el hombre hizo que cada vez parece estúpida en el momento! *

Answer 10

Una empresa particular utiliza una técnica llamada extrema entrevistando al. Para la entrevista extrema, traerán, digamos, 30 desarrolladores y los agruparán en 15 pares. Explicarán que están buscando personas que trabajen bien con los demás. Que tomarán una decisión de contratación basada únicamente en su capacidad para trabajar con otros.

Ofrecerán un problema para que los pares resuelvan. Harán hincapié en que no están interesados ​​en la solución solo en la capacidad de cada programador para trabajar con otros. Para cada par proporcionarán un observador del par. Durante el ejercicio (de 2 a 4 horas de duración), el observador tomará notas sobre la capacidad de una persona para emparejarse ... no la solución.

Se sorprenden de cuántos programadores se centran en resolver el problema en lugar de colaborar. De los 15 pares, identificarán entre 4 y 6 desarrolladores para una segunda entrevista. A los desarrolladores se les pedirá que vuelvan y pasen una semana con el equipo (les pagan). Después de una semana, deciden a quién mantener. En general, aproximadamente la mitad de ellos (2 a 3 desarrolladores).

Cuando terminan, tienen desarrolladores que pueden colaborar y después de una semana trabajando con varios pares, el equipo tiene una fuerte indicación de quién puede desarrollar software de manera efectiva. El proceso es innovador y efectivo. Han tenido una alta tasa de éxito con los que han contratado.

Answer 11

Acabo de tener una entrevista con una empresa basada en San Francisco que se enorgullece de los métodos ágiles/etc. Tenía que entrevistar al CEO en persona. Tengo alrededor de 20 años de experiencia en la industria, pero nunca he programado o desarrollado un par usando el enfoque TDD. Me dijeron que sería una "entrevista de programación", pero no tenía idea de qué esperar, y antes de comenzar, el tipo dijo que pensaba que podía aceptar que todas las entrevistas se hicieran de esta manera. (que en retrospectiva no era más que una declaración arrogante).

De todos modos, en la entrevista el ejercicio fue desarrollar una clase usando TDD. Me tomó un segundo ajustar mi pensamiento en todo el proceso, una vez más, ya que nunca había programado o hecho un TDD. Mientras tropezaba aquí y allá, lo hice bien al final. pero su respuesta fue que no exhibí la agresiva naturaleza de ida y vuelta que requieren para su entorno de programación de pares. Ahora, eso también podría haber sido una manera solapada de decir ese tipo de mensaje "No pensé que lo hicieras genial".

Afortunadamente no necesitaba el trabajo y para ser honesto, la experiencia me hizo darme cuenta de que preferiría encontrar una carrera diferente a la de tener que ser un ingeniero de software que TIENE que trabajar en parejas, día tras día, cuando vino a desarrollar código. Lo curioso es que, en ocasiones, he trabajado con otra persona en código simultáneamente, así que todo es posible.

En fin, supongo que fue un buen resultado ya que no creían que yo fuera una buena opción y no me importaban sus métodos de trabajo. Pero hubiéramos llegado a la misma conclusión si hubiera hablado unos minutos más sobre mí y si me hubiera dado un poco más de información sobre cómo hacen su trabajo. Lo que equivale a decir que hay otras formas de encontrar un buen candidato apto que someterlas al estrés de la programación de parejas con un completo extraño; manera falsa de medir la competencia imo.

Answer 12

Desde mi experiencia limitada, mis sentimientos son mixtos. Me gusta la idea de maridar como parte de una entrevista, esp. si la compañía utiliza el emparejamiento a menudo, porque da una mejor sensación para el ajuste. Como candidato, a menudo pasé por entrevistas en las que me senté en una sala respondiendo preguntas durante unas horas, pero después no tuve una buena idea de cómo sería trabajar en su entorno. El emparejamiento puede ser más beneficioso que un ejercicio de codificación aleatoria, a menos que el entrevistador tenga la habilidad de trabajar con alguien a través de ellos. Y me gusta poder discutir cosas técnicas de ambos lados. Y como candidato, prefiero interactuar con alguien que simplemente responder preguntas o resolver problemas de código por mi cuenta.

Pero ... como han notado otros, el tiempo necesario puede ser un problema. He pasado por un par de días de entrevistas de pareja y encontré algunos períodos buenos, mientras que otros sintieron que se desperdiciaban unas pocas horas: una porque el desarrollador no estaba trabajando en algo que se prestara a emparejarse (especialmente por mi experiencia), el otro porque un problema env evitó mucho trabajo útil por un tiempo. Si el trabajo no funciona, puede ser frustrante tomarse un día o dos sin trabajar para esto.

Un lugar que intentaba este enfoque no estaba seguro de si deberían tener a alguien fuera de la empresa trabajando en el proyecto de un cliente. También les preocupaba que explicar el dominio y el trabajo que se estaba llevando a cabo llevaría demasiado tiempo, aunque sin eso el candidato no podría contribuir mucho. Entonces eligieron un proyecto de código abierto en el que el empleado estaba trabajando.

Este parece ser un punto clave: tiene que haber una tarea bien elegida que el candidato pueda entender rápidamente y poder contribuir. La última parte dependerá en cierta medida de las habilidades del candidato. También sería clave la capacidad del empleado para evaluar a alguien con este enfoque. No todos son excelentes en las entrevistas normales, y eso es probablemente más cierto en una entrevista de emparejamiento.

Además, si una empresa no hace mucho maridaje entonces este tipo de entrevista puede no ser tan útil. Parece beneficioso ver a alguien codificar (como señala Joel Spolsky), y esta podría ser una buena forma de hacerlo. Pero si el emparejamiento no es una parte típica del trabajo, quizás una sesión de emparejamiento completo no sea apropiada. Tal vez una versión modificada.

Me gustaría saber qué compañías piensan en los resultados. Leer algunas de las otras respuestas a esta pregunta muestra que no siempre parece ideal desde la perspectiva del candidato.

Answer 13

Acabo de tener una entrevista de programación de par hace unos días y para ser sincero, realmente no me gusta. Me lo notificaron un día antes de la entrevista y luego el entrevistador me dijo que la programación de pares es lo que eventualmente voy a hacer de todos modos en el trabajo. Entré en la oficina y me emparejé con alguien que es un ingeniero de software muy experimentado. La compañía se encuentra en San Francisco y es una compañía reconocida por la programación de pares, todos combinan programas en la oficina.Al principio parecía estar bien, explicó sobre todas las herramientas que usaban, su propio marco de pruebas de unidades que construían y un poco del proyecto. Luego, básicamente, escribió un montón de pruebas unitarias y quería que trabajara en la implementación para que pasara. Solo como un FYI, la base de código que ya existe es enorme, diría 10k líneas, no es como un proyecto supercomplejo, pero es complejo para alguien simplemente intervenir y luego escribir código sin una comprensión previa de la jerarquía de clases, etc. Me resulta realmente difícil creer que espera que alguien salte de inmediato en una línea de código fuente de 10k que ya existe. Simplemente no coincide con una entrevista de programación de pares, una base de código más pequeña ayudaría. Me costó un poco navegar a través de las clases e ir y venir porque no recuerdo los nombres de las clases ya que estaba abrumado por la cantidad de clases/código que ya existe. Para ser honesto, esto realmente me hizo hacer horrible en el proceso de entrevista. Al final no me sentí muy bien al respecto. No he hecho programación de pares antes, la mayoría es solo durante las asignaciones en mi año universitario.

Para mí, la potencia de la programación de pares se puede aprovechar si ya dominas/eres cómodo con tu pareja, pero no es realmente adecuado para una entrevista. A veces me gustaría hacerle preguntas a mi pareja, pero luego pensé que si hacía demasiadas preguntas, supondrían que era estúpido y que no puedo actuar. Si esto ya fuera en un trabajo real, no dudaría en preguntar, pero en una entrevista es difícil ... quieres preguntar porque tu pareja debería ayudarte cuando estás atascado, pero al mismo tiempo es una entrevista , entonces realmente no puedes preguntar mucho.

Eso es sólo mi experiencia que tengo de la entrevista de la programación en parejas, mi sugerencia si realmente quiere hacer esto:

1. estar seguro de que usted no da el candidato para trabajar con una gran base de código , trabaje con un más pequeño y, por lo tanto, puede mostrar sus habilidades al máximo
2. póngase por delante con el candidato antes de la entrevista de programación de pares, puede hacer las preguntas cuando esté estancado, si puede para hacer esto y aquello, lo que no puede hacer
3. sea tan detallado como sea posible e

Al final, no lo recomendaría. Es difícil medir el rendimiento de un candidato en la programación de pares, y también puede ser parcial.