Pregunta

Nuestra empresa ha estado pensando en eliminar nuestros procedimientos de entrevista y reunir a cada candidato para que se siente durante 4 a 5 horas con algunos de los programadores y simplemente haga algo de programación en pareja.

En teoría, me gusta la idea, pero no estoy seguro de cómo se puede hacer que sea justa para cada candidato.¿Cómo los calificarías?¿No dependerían realmente sus aportaciones de en qué estaba trabajando cada programador ese día?

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

¡Salud!

EDITAR:

RESULTADO - SEGÚN lo solicitado

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

Hemos llegado a esta conclusión por un par de razones.Creemos que esto empoderará a los desarrolladores al darles la opción de elegir con quién están trabajando.La segunda razón es la dinámica del grupo.Creemos que es muy importante tener una buena dinámica de grupo y es difícil saber hasta después de contratar a una persona si encajará o no.

Entonces, el resultado final es que vamos a seguir adelante con las sesiones de programación en pareja, pero de una manera completamente diferente a la prevista originalmente.

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

¿Fue útil?

Solución

Espero que tengas un montón de pasos por delante de éste. Para que esto funcione es necesario una excelente hoja de vida y la pantalla del teléfono. Usted no quiere gastar montones de tiempo sobre los candidatos que no se debe hablar en primer lugar.

  

Así que usted sugiere una entrevista inicial   y posiblemente tener la segunda entrevista   mientras que el par sesión de programación? - Ted   Smith (hace 1 min)

Sí. Puede ser que incluso pensar en tener una entrevista de codificación sencilla suceda a través de Internet usando algo como CoPilot .

Otros consejos

A menos que utilice la programación en parejas ampliamente en su desarrollo en el mundo real, sería muy reticentes a utilizar esto. He conocido a cualquier número de desarrolladores profesionales de alta calidad que se han mencionado una fuerte aversión a la programación en parejas y cuya habilidad no serían bien calculada en un proceso de este tipo.

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

El problema se va a ejecutar en, es que la contratación no es como la programación. No hay un proceso paso a paso para llevar a la respuesta correcta en cuanto a quién contratar. (Se puede tener múltiples pasos para hacer más fácil la decisión). Usted tiene que evaluar cada uno de sus puntos fuertes, etc. y, esencialmente, hacer una conjetura en cuanto a cuál es el mejor para contratar. A veces te equivocas.

La otra cosa acerca de la programación en parejas que vas a tener que tener en cuenta es la cantidad de tiempo necesario para que cada candidato en esa etapa pasa por ese tipo de prueba. Si estuviera buscando un trabajo, estaría indeciso ir una entrevista en una empresa que me pedía que hacer eso. ¿Por qué? Debido a que es un montón de tiempo, y si yo estoy entrevistando a varios lugares, literalmente, podría pasar días sólo va a entrevistas para puestos de trabajo que ni siquiera puede conseguir o desean. Someplaces como Google o MS serían una excepción, pero la mayoría de los lugares no son como las dos. (Por no mencionar el hecho de que si se está trabajando en código real, que está pidiendo esencialmente a hacer el trabajo de una persona de forma gratuita).

acabo de tener una entrevista con una empresa con sede en San Francisco que se enorgullece de métodos ágiles / etc. Estaba a entrevistar al propio CEO. Tengo cerca de 20 años de experiencia en la industria, pero nunca he par programado o desarrollado 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 empezar el tipo dijo que él pensaba que yo de acuerdo en que todas las entrevistas deben hacerse de esta manera. (Que en retrospectiva no es más que una declaración arrogante era).

De todos modos, en la entrevista del ejercicio fue el desarrollo de una clase usando TDD. Me tomó un segundo para ajustar mi forma de pensar sobre todo el proceso, de nuevo ya que nunca había hecho par programado o TDD. Mientras me encontré aquí y allá lo hice bien al final. pero su respuesta fue la que no exhibió la naturaleza agresiva hacia atrás y hacia adelante que se requieren para su entorno de programación en parejas. Ahora, que también podría haber sido una forma solapada de decir que "no pensé que lo hizo grande" tipo de mensaje.

Por suerte yo no necesito el trabajo y para ser honesto la experiencia me hizo comprender que yo prefiero encontrar una carrera diferente a tener que ser un ingeniero de software que tiene que trabajar en pares, día a día, cuando se llegó a desarrollar código. Lo curioso es que en alguna ocasión he trabajado con otra persona en el código al mismo tiempo, así que cualquier cosa es posible.

En fin, supongo que era un buen resultado, ya que no creía que yo era un buen ajuste y no me importó por sus métodos de trabajo. Pero habríamos llegó a la misma conclusión tenía Hablé durante unos minutos más sobre mí mismo y me había dado un poco más de información sobre la forma en que realizan su trabajo. Lo que quiere decir que hay otras maneras de encontrar un buen candidato en forma de ponerlos por el estrés de la programación en parejas con un completo desconocido; manera falsa para medir la competencia de la OMI.

Como anécdota personal, me di un golpe en una entrevista en torno a causa de una técnica como esta. Yo había ido demasiado lejos en su proceso de entrevista; pasado los controles del curriculum vitae, la presentación de código y esta fue la cara a cara porción de la entrevista.

Yo estaba recién salido de la universidad y nunca había programado par antes ni hecho TDD. Me sentaron a hacer una cubierta de ejercicio de la tarjeta y que fracasaron. ¡Mal! Yo no entiendo por qué el entrevistador estaba escribiendo pruebas que parecían tan tonto * (IE "return null;") y que no explicó por qué y por supuesto ser extranjero a TDD no sabía qué preguntas hacer. El resultado final fue que parecía como si no pudiera programar mi manera de salir de una bolsa de papel.

Si vas a hacer este tipo de ejercicio que necesita para atender al entrevistado porque van a estar en diferentes lugares con su aptitud. Esto significa que obtendrá diferentes evaluaciones que no pueden estar basadas en el talento real y por lo tanto van a ser muy sesgada.

** 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! *

Sólo tenía una entrevista de programación en pareja hace unos días y para ser honesto, no me gusta mucho. Me notificó de este un día antes de la entrevista y el entrevistador me dijo que la programación en parejas es lo que finalmente voy a hacer de todos modos en el trabajo. Fui a la oficina y estaba en pareja con alguien que es un ingeniero de software de muy alto nivel. La compañía está en San Francisco y que son una compañía bien conocida por la programación en parejas, todos los programas de pares en la oficina. Al principio parecía estar bien, nos explicó todas las herramientas que utilizan, su propio marco de pruebas de unidad que se construyen, y un poco del proyecto. A continuación, básicamente escribió un montón de pruebas unitarias y yo quería trabajar en la puesta en práctica de hacer pasar. Así como un FYI, la base de código que ya existe es enorme, yo diría 10k líneas, no es como un proyecto muy complejo, pero es complejo para alguien que acaba de intervenir y luego escribir código sin conocimiento previo de la jerarquía de clases, etc. . me parece muy difícil de creer que alguien que espera para saltar de inmediato en una línea de 10k de código fuente que ya existe. Simplemente no coincide para una entrevista de la programación en parejas, una base de código más pequeño ayudaría. Me ha costado un poco de navegación a través de las clases y el ir y venir porque no puedo recordar nombres de clases como me sentí abrumado por la cantidad de clases / código que ya existe. Para ser honesto, esto realmente me hizo hacerlo horrible en el proceso de la entrevista. Al final no me siento muy bien al respecto. No he hecho la programación en parejas antes, en su mayoría es sólo durante las tareas en mi último año de universidad.

Para mí el poder de la programación en parejas pueden aprovecharse si ya estás competentes / cómodo con su pareja, pero no es realmente adecuado para la entrevista. A veces me gustaría hacer preguntas a mi pareja, pero luego pensé si pido demasiado preguntas, entonces ellos asumen yo fuera estúpida y no pueden realizar. Si esto ya estaba en un trabajo de verdad, no me atrevo a preguntar, pero en una entrevista es difícil .. te quiero preguntar porque su pareja pueden serle de ayuda cuando estás atascado, pero al mismo tiempo es una entrevista , por lo que no se puede pedir mucho más.

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

  1. asegúrese de que usted no da el candidato para trabajar con una gran base de código, trabajar con una  uno más pequeño y por lo tanto él / ella puede mostrar sus habilidades / ella al máximo
  2. estar en la delantera con el candidato antes de la entrevista la programación en parejas, puede hacer preguntas cuando estás atascado, debe ser capaz de hacer esto y lo otro, lo que no puede hacer
  3. ser tan detallada como sea posible

Al final, yo no lo recomendaría. Es difícil medir el rendimiento de un candidato en la programación en parejas, y podría estar sesgada también.

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

Proporcionarán un problema para que las parejas lo resuelvan.Enfatizarán que no están interesados ​​en la solución, solo en la capacidad de cada programador para trabajar con otros.Para cada pareja proporcionarán un observador de la pareja.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.

Les sorprende saber cuántos programadores se centran en resolver el problema en lugar de colaborar.De las 15 parejas, identificarán entre 4 y 6 desarrolladores para una segunda entrevista.A esos desarrolladores se les pedirá que regresen y pasen una semana con el equipo (se les paga).Después de una semana, deciden con quién quedarse.Generalmente alrededor de 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 eficaz.Han tenido una alta tasa de éxito con aquellos que han contratado.

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

Buena pregunta, sin embargo. Cosas que pensar.

¿Por qué no? Además, no es como entrevistas son siempre (o nunca) justo. Debe evaluar el resultado final del nuevo enfoque contra el enfoque tradicional basado en la entrevista.

Además, una mini entrevista antes de la pareja sesión de programación podría ser bueno para evitar la pérdida de tiempo de los programadores con la gente que sería un mal ajuste.

Desde mi limitada experiencia, mis sentimientos se mezclan. Me gusta la idea de sincronización, como parte de una entrevista, esp. Si la empresa utiliza el emparejamiento con frecuencia, ya que da a la vez una mejor idea de la forma. Como candidato, a menudo he ido a través de entrevistas donde yo estaba sentado en una sala de responder a las preguntas de un par de horas, pero después no tener una buena idea de lo que sería realmente se desea trabajar en su entorno. El emparejamiento puede ser más beneficioso que un ejercicio de codificación aleatoria, a menos que el entrevistador es experto en trabajar a alguien a través de aquellos. Y me gusta ser capaz de discutir cuestiones técnicas de ambos lados. Y como candidato, prefiero interactuar con alguien que simplemente responder a las preguntas o resolver problemas de código por mi cuenta.

Pero ... como han dicho otros, el tiempo necesario puede ser un problema. He pasado por un par de días de entrevistas de emparejamiento y encontré algunos períodos buenos, mientras que otros se sentían como un par de horas fueron desperdiciados: (. Esp dado mi fondo) uno porque el promotor no estaba trabajando en algo que se prestaba a la vinculación, el otro, porque un problema env impidió mucho trabajo útil durante un tiempo. Si el trabajo no funciona, puede ser frustrante haber tomado un día o dos de trabajo para esto.

Un lugar tratando este enfoque no estaba seguro de si se debe tener a alguien fuera de la compañía trabajando en el proyecto de un cliente. También preocupa que explicar el dominio y el trabajo que se realiza sería demasiado largo, aunque sin que el candidato no puede ser capaz de aportar mucho. Así que eligieron un proyecto de código abierto que el empleado estaba trabajando.

Esto parece ser un punto clave: es necesario que haya una tarea bien elegido que el candidato puede entender rápidamente y ser capaz de contribuir a La última parte dependerá en cierta medida de las habilidades del candidato.. Otra de las claves sería la capacidad del empleado para evaluar a alguien con este enfoque. No todo el mundo es grande en la entrevista normal, y eso es probablemente más cierto en una entrevista de emparejamiento.

Además, si una empresa no hace mucho emparejamiento entonces este tipo de entrevista puede no ser tan útil. Hay que parecen beneficio en ver código de alguien (como notas de Joel Spolsky), y esto podría ser una buena manera de hacer eso. Pero si el acoplamiento no es una parte típica del trabajo, entonces tal vez una sesión de sincronización completa no es apropiado. Tal vez una versión modificada.

Sería curioso lo que las empresas que han adoptado este enfoque pensar en los resultados. Leer algunas de las otras respuestas a esta pregunta demuestra que no siempre parece ideal desde el punto de vista del candidato.

Para mantenerlo justo, que tendría que hacer cada miembro del personal que participa tiene un problema preparado para evaluar al candidato en. Preferiblemente algo que se da forma al mundo real en su experiencia de la empresa, sino algo que ya ha sido resuelto. Esta es una buena oportunidad para evaluar el conocimiento sobre un problema y evaluar no sólo conocimientos de programación.

Lo odio cuando se responde a las preguntas demasiado específicas. Tenía una entrevista, una vez que un programador estaba poniendo a prueba mis conocimientos de la STL que he usado extensamente y estaba tratando de conseguir que responda a eso se necesitaba un asignador personalizado. Había oído hablar de ellos, pero nunca los utiliza (especialmente en las ventanas) y se le hizo sentir tonto. IOW, evitar ser crítico.

Así que mi punto es, hacer preguntas prácticas que no son tanto sobre la prueba de conocimientos de programación como se puede evaluar la personalidad más cualitativo y enfoques para resolver problemas si utiliza la idea de "programación en parejas".

Buena pregunta!

Sinceramente, eso suena como una gran idea, aunque Jason Punyon es ciertamente correcto que se debe hacer un montón de escarda antes de perder una cantidad significativa de tiempo de sus desarrolladores en sacrificios. Se obtiene un vistazo a una importante métrica de ella que es lo contrario casi imposible de obtener en las entrevistas:. Lo que alguien se siente al trabajar con

No creo que no hay realmente ninguna necesidad de preocuparse acerca de que sea "justo", basada en la materia o tratando de presentar situaciones constantes para diferentes candidatos, si se mantiene la actitud evaluador derecho - que no es acerca de si "tiene la respuesta correcta" o saltaron a través del conjunto adecuado de aros, pero ¿qué tipo de esfuerzo, resolución de problemas, capacidad de comunicación y la flexibilidad que mostraron. Se perdía la mayor parte del beneficio del ejercicio al convertirlo en una prueba artificial, por no hablar de que el cambio de algo que los desarrolladores pueden obtener algún beneficio de (o al menos aún trabajar un poco durante) a una pérdida masiva de su tiempo.

Joel Spolsky tiene una excelente de entrevistar a que habla, entre otras cosas, tareas de programación.

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top