extreme-programming - practices - pair programming online

Programación de pares para una entrevista de trabajo (13)

Nuestra compañía ha estado pensando en eliminar nuestros procedimientos de entrevista y llevar a cada candidato a una sesión de 4 a 5 horas con algunos de los programadores y solo hacer algunos programas de pares.

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

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

¡Aclamaciones!

EDITAR:

RESULTADO - COMO SE SOLICITE

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

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

Por lo tanto, el resultado final es que vamos a continuar con las sesiones de programación en pareja, pero de una manera completamente diferente y de una manera completamente diferente de lo que se pretendía originalmente.

Cualquier pensamiento o crítica de este enfoque es más que bienvenido! (esta edición se publica como una respuesta a continuación, así que siéntete libre de votar si crees que este no es el mejor enfoque)

A menos que use la programación de pares extensivamente en su desarrollo en el mundo real, dudaría mucho en usar esto. Me he reunido con un número de desarrolladores profesionales de alta calidad que han mencionado una fuerte aversión a la programación en parejas y cuya habilidad no se juzgaría bien en tal proceso.

Acabo de tener una entrevista con una empresa con sede en San Francisco que se enorgullece de los métodos Agile / etc. Yo iba a entrevistar al propio CEO. Tengo aproximadamente 20 años de experiencia en la industria, pero nunca he programado o desarrollado par utilizando 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 chico dijo que pensaba que podría estar de acuerdo en que todas las entrevistas deberían hacerse de esta manera. (que en retrospectiva no era más que una declaración arrogante).

De todos modos, en la entrevista el ejercicio consistió en desarrollar una clase utilizando TDD. Me tomó un segundo para ajustar mi pensamiento en todo el proceso, una vez más, ya que nunca había emparejado TDD programado o realizado. Mientras me tropecé aquí y allá, me fue bien al final. pero su respuesta fue que no exhibí la naturaleza agresiva de ida y vuelta que requieren para su entorno de programación de pares. Ahora, esa también podría haber sido una manera deshonesta de decir que "no creo que hicieras un gran mensaje".

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

Al final, creo 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 habríamos llegado a la misma conclusión si hubiera hablado unos minutos más sobre mí y me hubiera dado un poco más de información sobre cómo se ocupan de su trabajo. Lo que quiere decir que hay otras formas de encontrar un candidato que se adapta bien que someterlo al estrés de la programación en pareja con un completo desconocido; manera falsa de medir la competencia imo.

Acabo de tener una entrevista de programación de pareja hace unos días y, para ser honesta, no me gusta. Me lo notificaron un día antes de la entrevista y luego el entrevistador me dijo que la programación en pares es lo que eventualmente haré en el trabajo. Entré en la oficina y me emparejé con alguien que es un ingeniero de software muy importante. La compañía está en San Francisco y son una compañía bien reconocida por la programación de pares, todos los programas de par en la oficina. Al principio parecía estar bien, explicó sobre todas las herramientas que utilizaron, su propio marco de prueba de unidad que construyeron 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 hacerla pasar. Al igual que un FYI, la base de código que ya existe es enorme, diría 10k líneas, no es como un proyecto super complejo, pero es complejo para alguien que simplemente intervenga y luego escriba código sin una comprensión previa de la jerarquía de clases, etc. . Me resulta muy 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 en pareja, una base de código más pequeña ayudaría. Luché un poco por navegar a través de las clases e ir de un lado a otro porque no puedo recordar los nombres de las clases ya que me abrumó la cantidad de clases / códigos que ya existen. Para ser honesto, esto realmente me hizo hacer un trabajo horrible en el proceso de la entrevista. Al final no me sentí muy bien al respecto. No he hecho la programación de pares antes, principalmente durante las tareas de mi año universitario.

Para mí, el poder de la programación de pares puede aprovecharse si ya es competente / cómodo con su par, pero no es realmente adecuado para la entrevista. A veces me gustaría hacerle preguntas a mi pareja, pero luego pensé que si hacía demasiadas preguntas, supondrían que era una estupidez y no podía actuar. Si esto ya estaba 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. , por lo que realmente no se puede pedir mucho.

Esa es solo la experiencia que tengo de la entrevista de programación en pareja, mi sugerencia si realmente quieres hacer esto:

asegúrese de no dar al candidato a trabajar con una base de código grande, trabaje con una más pequeña y, por lo tanto, él / ella puede mostrar sus habilidades al máximo
estar al frente con el candidato antes de la entrevista de programación en pareja, ¿puedes hacer preguntas cuando estás atascado, si puedes hacer esto y eso, qué no puedes hacer?
ser lo más detallado posible

Al final, no lo sugeriría. Es difícil medir el desempeño de un candidato en la programación de pares, y también podría estar sesgado.

Como anécdota personal, recibí una paliza en una entrevista debido a una técnica como esta. Había ido lejos en su proceso de entrevista; Pasó los controles del currículum vitae, el envío del código y esta fue la parte cara a cara de la entrevista.

Acababa de salir de la universidad y nunca había programado par ni antes TDD. Me sentaron a hacer un mazo de ejercicios de naipes y se dejó caer. ¡Mal! No entendí por qué el entrevistador estaba escribiendo pruebas que parecían tan tontas * (IE "return null;") y no explicaron por qué y, por supuesto, eran ajenas al 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 sus aptitudes. Esto significa que obtendrás diferentes evaluaciones que pueden no estar basadas en el talento real y, por lo tanto, serán muy sesgadas.

** Ahora que entiendo TDD, entiendo pruebas como esta y cómo se supone que funcionan, ¡pero el hombre hizo que eso pareciera una estupidez en ese momento! *

Desde mi limitada experiencia, mis sentimientos se mezclan. Me gusta la idea de maridar como parte de una entrevista, esp. si la compañía utiliza el emparejamiento a menudo, porque le da a ambos una mejor idea del ajuste. Como candidato, a menudo he asistido a entrevistas en las que me senté en una sala respondiendo preguntas durante algunas horas, pero luego no tuve una idea clara de cómo sería trabajar en su entorno. El emparejamiento puede ser más beneficioso que un ejercicio de codificación al azar, a menos que el entrevistador tenga experiencia en trabajar con alguien a través de ellos. Y me gusta poder discutir temas técnicos de ambos lados. Y como candidato, prefiero interactuar con alguien más que solo responder preguntas o resolver problemas de código por mi cuenta.

Pero ... como otros han señalado, el tiempo necesario puede ser un problema. Pasé por un par de días de entrevistas de parejas y encontré algunos períodos buenos, mientras que otras sentí que se malgastaron algunas horas: una porque el desarrollador no estaba trabajando en algo que se prestaba a la pareja (especialmente teniendo en cuenta mis antecedentes), el otro porque un problema de env previno mucho trabajo útil por un tiempo. Si el trabajo no funciona, puede ser frustrante haber tomado uno o dos días fuera del trabajo para esto.

Un lugar donde 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 la explicación del dominio y el trabajo que se realizaría llevara demasiado tiempo, aunque sin eso el candidato no podría contribuir mucho. Así que eligieron un proyecto de código abierto en el que el empleado estaba trabajando.

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

Además, si una empresa no hace mucho emparejamiento, este tipo de entrevista puede no ser tan útil. Parece que hay beneficios al ver el código de alguien (como señala Joel Spolsky), y esta podría ser una buena manera de hacerlo. Pero si el emparejamiento no es una parte típica del trabajo, tal vez una sesión de emparejamiento completa no sea apropiada. Tal vez una versión modificada.

Me gustaría saber qué piensan las empresas que han adoptado este enfoque de los resultados. Leer algunas de las otras respuestas a esta pregunta muestra que no siempre parece ideal desde el punto de vista del candidato.

Espero que tengas un montón de pasos por delante de este. Para que esto funcione, necesitas un excelente currículum y una pantalla de teléfono. No querrás pasar un montón de tiempo con candidatos con los que no deberías estar hablando en primer lugar.

¿Así que sugiere una entrevista inicial y posiblemente tenga la segunda entrevista como la sesión de programación en pareja? - Ted Smith (hace 1 minuto)

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

Honestamente, eso suena como una gran idea, aunque Jason Punyon ciertamente tiene razón en que debes hacer mucha eliminación antes de desperdiciar una cantidad significativa del tiempo de tus desarrolladores en sacrificios. Usted obtiene una visión de una métrica importante que, de otro modo, es casi imposible de obtener en una entrevista: con qué le gusta trabajar a alguien.

No creo que sea realmente necesario preocuparse porque sea "justo" en función del tema o tratando de presentar situaciones coherentes a diferentes candidatos, si mantiene la actitud evaluadora correcta, no se trata de si "obtuve la respuesta correcta" o salté a través del conjunto correcto de aros, pero qué tipo de esfuerzo, resolución de problemas, aptitud para la comunicación y flexibilidad mostraron. Perdería la mayor parte del beneficio del ejercicio convirtiéndolo en una prueba artificial, sin mencionar el cambio de algo de lo que sus desarrolladores pueden obtener algún beneficio (o al menos aún realizar algún trabajo durante) a una enorme pérdida de recursos. su tiempo.

Joel Spolsky tiene una excelente Guía de Guerrilla para Entrevistas que habla, entre otras cosas, de las tareas de programación.

Trivia: Joel Spolsky es cofundador de .com

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

El problema con el que se encontrará es que la contratación no es como la programación. No hay un proceso paso a paso que conduzca a la respuesta correcta sobre a quién contratar. (Puede tener varios pasos para facilitar la decisión). Tienes que evaluar cada uno en función de sus fortalezas, etc. y, básicamente, hacer una suposición informada sobre cuál es la mejor para contratar. A veces adivinas mal.

La otra cosa sobre la programación de pares que tendrá que vigilar 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 pidiera que lo hiciera. ¿Por qué? Debido a que es mucho tiempo, y si me estoy entrevistando en varios lugares, podría pasar literalmente días yendo a entrevistas para trabajos que ni siquiera puedo obtener o desear. 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á pidiendo que hagan el trabajo de alguien de forma gratuita).

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

Buena pregunta sin embargo. Cosas para pensar.

Para ser justos, tendría que hacer que cada miembro del personal participante tenga un problema preparado para evaluar al candidato. Preferiblemente, algo tomado del mundo real en la experiencia de su empresa, 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 estaba probando mi conocimiento de la STL que usé extensivamente y estaba tratando de 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.

Entonces, lo que quiero decir es que formule preguntas prácticas que no sean tanto para evaluar el conocimiento de la programación como para evaluar más enfoques cualitativos de personalidad y resolución de problemas si utiliza la idea de "programación de pares".

¡Buena pregunta!

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

Además, una mini entrevista antes de la sesión de programación en pareja podría ser buena para evitar perder el tiempo de los programadores con personas que serían una mala elección.

Una empresa en particular utiliza una técnica llamada entrevista extrema . Para la entrevista extrema traerán, por ejemplo, 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.

Ellos proporcionarán un problema para que las parejas lo resuelvan. Harán hincapié en que no les interesa la solución, solo la capacidad de cada programador para trabajar con otros. Para cada pareja proporcionarán un observador de la pareja. Durante el ejercicio (de aproximadamente 2 a 4 horas de duración), el observador tomará notas sobre la capacidad de la 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 de 4 a 6 desarrolladores para una segunda entrevista. Se les pedirá a esos desarrolladores que regresen y pasen una semana con el equipo (se les paga). Después de una semana, deciden a quién seguir. En general, aproximadamente la mitad de ellos (2 a 3 desarrolladores).

Cuando terminan, tienen desarrolladores que pueden colaborar y, después de una semana de trabajo con varios pares, el equipo tiene una clara 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.