¿Deberíamos dejar de dar problemas de algoritmo de estilo de pizarra en las entrevistas de programador? ¿Por qué o por qué no?

El estándar de oro para encontrar los mejores programadores es contratarlos para una pasantía. Simplemente no hay comparación entre tener a alguien cerca durante varios meses trabajando con el equipo y escribiendo el código de producción, y que lo visiten para un día de entrevistas. Es por eso que muchas compañías tienen reclutadores de tiempo completo en los campus universitarios. ¡Ponerse frente a esos recién graduados es valioso!

Una vez que los pasantes se agoten y aún haya vacantes, el siguiente paso es contratar a la industria. Como Joe Forbes mencionó, una forma de simular una “pasantía” para los empleados de la industria es contratar personas por contrato. Desafortunadamente, no es probable que esto atraiga a los mejores candidatos. Si tuviera que elegir entre una oferta de contrato de alquiler y una contratación directa, y las compañías fueran igualmente deseables, ¿cuál elegiría? Esto no es cierto para las pasantías universitarias, donde realmente puedes obtener lo mejor de lo mejor.

Así que nos queda una serie de entrevistas de una hora. Están los algoritmos conocidos y la entrevista de estructuras de datos, y la entrevista alternativa que trata de aproximarse mejor a las habilidades en el trabajo. Uno de los desafíos para alejarse de las preguntas generales de CS es que filtrará a los buenos candidatos que no conocen la tecnología que está preguntando, pero podrían aprenderla rápidamente. Por ejemplo, puede estar buscando un programador de Python, pero ¿preferiría tener un programador generalista superior que no conozca Python, pero es un estudio rápido? Esto puede depender de la capacidad de la empresa para absorber algo de tiempo de aceleración, que las grandes empresas pueden hacer mejor que las pequeñas.

Christopher Burke menciona el uso de un problema de diseño. He visto que esto funciona bien cuando se usa en una entrevista de varias. Debe haber algo de codificación durante un día de entrevistas. De lo contrario, un buen conversador con habilidades de codificación débiles podría abrirse camino en un trabajo. Esto también es un riesgo del enfoque de revisión de código, mencionado por Mike Thomas y Quora User, y el enfoque de la historia del proyecto mencionado por Quora User. Es demasiado fácil para un buen comunicador convencer a las personas de que pueden hacer el trabajo ellos mismos, cuando realmente son buenos para explicar el trabajo de los demás. Hay algunas posiciones donde esa habilidad puede ser útil, pero no de la que estamos hablando.

Hay otra buena discusión sobre estos temas en Si la programación del mundo real y la programación competitiva son tan diferentes, ¿por qué las empresas siguen juzgando a los candidatos sobre la base del conocimiento basado en la codificación competitiva? Varias de las respuestas a esa pregunta señalan que solo se requieren conocimientos básicos de algoritmos y estructuras de datos en una entrevista de codificación típica. No requiere obtener un título de CS para cubrir el subconjunto de conocimiento de CS utilizado en entrevistas. La razón para usar esos temas en lugar de material específico del dominio es que son un conjunto de conocimiento común para todos los desarrolladores, independientemente de la tecnología en la que trabajen durante el día.

El efecto del carro es un fenómeno en el que la tasa de absorción de una idea en particular aumenta simplemente a través de una mayor adopción, en lugar de debido a cualquier beneficio tangible que pueda tener la idea. ¡Creo que las entrevistas en pizarra son un ejemplo perfecto de esto! Durante la última década, he visto crecer y crecer esta tendencia, aunque en realidad es perjudicial para la contratación de buenos talentos.

Hace aproximadamente una década, entrevisté para un rol de desarrollador sénior en un gran negocio (y no digamos) de Silicon Valley. Me pidieron que me dirigiera a una pizarra y resolviera un problema que el entrevistador había buscado rápidamente en Google. La pregunta, cómo invertir una cadena en C usando la menor cantidad de memoria adicional posible se ha convertido en un pilar de la cultura de las entrevistas de pizarra. Escribí una de dos posibles soluciones, pero me di cuenta de que no era la respuesta que estaba buscando el entrevistador.

Recuerdo todo el episodio hasta el día de hoy. Escribir (¡no escribir!) Código en una pizarra mientras alguien miraba por encima de mi hombro y lanzaba miradas ocasionales a su reloj.

Y ese es el problema con estos ejercicios: sacan a un programador completamente de su entorno nativo. Como resultado, es probable que sean contraproducentes, ya que no evaluarán la eficiencia del día a día. En todo caso, al hacer que alguien realice esta prueba, a menudo frustrante, en realidad está probando cuánto alguien quiere trabajar para usted, en lugar de qué tan bien podría funcionar para usted. Aunque estar motivado es obviamente una buena característica para un candidato, la prueba de esta habilidad blanda claramente no es el objetivo de un ejercicio de pizarra.

Los desarrolladores trabajan dentro de marcos diseñados para poner todo a su alcance. Codifican en un entorno de software que utiliza autocompletar. Buscan en google y otros recursos constantemente para encontrar lo que están buscando. Un gran programador es aquel que usa estos atajos para escribir un gran código. Usar las herramientas que le ayuden a lograr esto. Un gran programador no es aquel que memoriza toda la sintaxis para poder codificar en voz alta. Una gran parte de lo que un gran desarrollador sabe es dónde y cómo buscar respuestas.

Al pedirle a un programador que realice un ejercicio de codificación de pizarra, le está quitando las herramientas y el proceso que utilizan “día a día” para su trabajo. Sin este contexto, no vas a probar su aptitud en su trabajo, ¡pero su aptitud es escribir código en una pizarra!

Todo esto deja a los programadores buscando trabajo con las grandes compañías tecnológicas con un dilema bastante ridículo: continuar mejorando sus habilidades como programador, o enfocarse en mejorar en las entrevistas. Es un conjunto de habilidades diferente. Si no me crees, solo busca en Google ‘pasando una entrevista de pizarra’. ¡Existe una industria de nicho próspera vendiendo contenido para ayudarlo a pasar estas entrevistas!

Para mí, el objetivo de una entrevista es bastante sencillo: “¿Hará este candidato el trabajo para el que lo contratan y contribuirá positivamente a la cultura de la empresa”?

En la ruta escalable, la red premium independiente que ejecuto, he entrevistado a cientos de desarrolladores en los últimos 7 años. Sé que puede obtener una muy buena lectura de un candidato siguiendo los pasos a continuación, ¡sin pizarra a la vista!

1. Tómate un tiempo cara a cara. Puedes decir mucho de solo hablar con alguien. Desde la inflexión y el tono de su voz hasta su lenguaje corporal. Restringirse a un intercambio de audio o correo electrónico le niega esa valiosa percepción del personaje.
2. ¿Cuán obstinados son? Pregúnteles sobre su lenguaje de programación favorito y por qué. La forma en que respondan revelará mucho. Si alguien tiene una opinión sólida sobre un tema, es un buen indicador de que le apasiona
3. Échales un vistazo en GitHub. ¿Cuánto contribuyen a la industria en general y a los proyectos de código abierto? Además de darle una idea de su codificación, esto le da una gran idea de su mentalidad y pasión. Los proyectos de código abierto son una forma en que las personas contribuyen a la industria al ayudar a arreglar las cosas por un bien mayor. ¡Ahora eso suena como alguien que quisiera en mi equipo!
4. ¿Con qué frecuencia entregan lo que codifican? Jugar con el código es una cosa. Poder enviar un producto completo es otra. Infórmese sobre los proyectos que han terminado y los que no. Y solicite detalles sobre lo que sucedió …
5. ¿Qué tan bien hablados están? ¿Son buenos comunicadores? Necesita contratar a alguien que pueda explicar lo que está haciendo. Si se comportan como una caja negra, entonces tendrá dificultades para trabajar con ellos y contratar un equipo a su alrededor.
6. ¿Qué tan bien escriben? Esto es similar al punto anterior pero lo suficientemente distinto como para importar. Un gran escritor a menudo será mejor en su trabajo, ya sea marketing o programación. Mi consejo es simple aquí: cuando esté atrapado entre candidatos de aspecto similar, siempre contrate al mejor escritor.
7. Use un período de prueba. Es una forma segura y justa de probarlos en un proyecto. En la ruta escalable les damos a los clientes 20 horas para evaluar un desarrollador. Si al final de ese período, el cliente no está contento, no tiene que pagar. El camino escalable y el contratista acuerdan compartir el riesgo durante el período de prueba. Si el cliente invoca la cláusula, que rara vez ocurre, el desarrollador recibe el pago del 50% de su tiempo. Todo esto está estipulado por adelantado y muy claramente para que nadie tenga resentimientos (con suerte). Aumenta la honestidad, reduce el riesgo y nos ha funcionado muy bien.
8. Los proyectos de codificación de tareas generalmente requieren que alguien trabaje gratis, por lo que deben usarse de manera justa. No es ético pedirle a un programador que pase 20 horas probándote un proyecto corto. Sin embargo, son muy efectivos para identificar el nivel de habilidad de un individuo.

Esa es mi opinión de todos modos, ¡espero que haya ayudado!

He realizado cientos de entrevistas y probé ambas. Hoy en día solo utilizo programación de pares para codificación y pizarra para preguntas de diseño de sistemas.
Aquí hay algunos consejos sobre cómo puede hacer que la entrevista de codificación sea más efectiva:

• Siéntate al lado del candidato, no en el lado opuesto de la mesa. Hace que el candidato sienta que desea cooperar y reduce el estrés.
• Deje que los candidatos traigan y usen sus computadoras. Es bueno para el candidato porque puede tener más confianza. También es bueno para usted porque puede ver cómo el candidato usa su computadora: qué tan rápido puede escribir, qué herramientas usa, etc. Por supuesto, hay algo de papel sobre la mesa si el candidato puede querer usarlo.
• También dejo que los candidatos usen internet. En realidad uso una pregunta cuando tienen que usar google. Este código usa una función que probablemente no conocen. Documentation, Google y Stack Overflow son amigos de los desarrolladores. Negarles estas herramientas es como enviar soldados a la guerra sin armas. Si no los dejaras usar Internet, perderías si podrían o no usar sus “armas”.
• Comprueba cómo se depuran. Qué estándares de codificación usan. ¿Utilizan algún patrón de diseño? Muchos candidatos pueden resolver un problema en teoría, pero tienen problemas para implementar el código.
• Tengo muchas entrevistas de skype. Permítanme ofrecer mi propio software para realizar entrevistas remotas: InterViewPAD

Tiendo a estar de acuerdo con las afirmaciones en el texto adicional de su pregunta.

En mi opinión, el estilo de entrevista que describe no es muy valioso a menos que el equipo escriba regularmente algoritmos estándar, en cuyo caso ese equipo puede estar perdiendo mucho tiempo reinventando la rueda. Algunos de los peores desarrolladores con los que he trabajado tenían títulos de CS, y algunos de los mejores no tenían títulos de CS (viceversa, por supuesto). Personalmente, he tenido lo que considero una carrera muy productiva y exitosa en desarrollo sin un título de CS.

Las empresas que insisten en entrevistar a las personas como si la profundidad de CS fuera lo más importante corren el riesgo de perderse a los desarrolladores con talento diferente, IMO.

También he entrevistado a muchos desarrolladores, y me resulta mucho más instructivo que me cuenten sobre proyectos pasados, y que desglosen sus historias sobre esos proyectos hasta que me haya convencido de que realmente han hecho el trabajo. Podría preguntarles qué odian de su idioma favorito. Ciertamente les pregunto qué idioma esperan aprender a continuación y por qué. Ya sabes, buena comunicación a la antigua. Para profundizar en el código real, también utilicé una técnica en la que les mostramos una pieza de código realista mal factorizada, fea y / o con errores y les pedí que la criticaran. Principalmente, estoy buscando ver si la persona tiene las cualidades necesarias para el trabajo, lo que a menudo va mucho más allá de las habilidades algorítmicas. Las preguntas de rompecabezas, las preguntas de compilación / API trivia, los algoritmos CS y similares son casi inútiles para resolver eso, IMO.

Dicho todo esto, me he concentrado en el desarrollo de software empresarial durante la mayor parte de mi carrera, y en mi experiencia eso no requiere habilidades de CS de servicio pesado en la mayoría de los casos. Su experiencia puede ser diferente.

No todas las empresas tienen ese estilo de entrevista, pero muchas sí. Conozco personas que abandonan ese tipo de entrevistas, ya que sienten que el estilo de la entrevista indica una compañía con la que serían incompatibles.

Muchos gerentes de contratación quieren confrontar a un candidato con un problema desconocido, porque no queremos observar la respuesta, queremos observar el proceso de pensamiento del candidato. Por eso también utilizamos una pizarra blanca: permite que el candidato muestre su proceso de pensamiento o trabajo.

Así es como entrevisto a candidatos técnicos, de manera diferente al “estilo actual”.

A través de la conversación, encuentro un juego de cartas o de mesa con el que el candidato está familiarizado, y luego pregunto cómo diseñaría el candidato los sistemas de software para implementar todos los componentes del juego, que podrían incluir:

• Una baraja de cartas que se pueden repartir, barajar, usar, descartar, retener para más tarde
• Un camino tortuoso pero circular entre los cuadrados del tablero que podría tener diferentes propiedades y efectos del juego.
• La tirada de 1, 2 o más dados con distribuciones estadísticas correctas de los resultados.
• Representación de la propiedad, pertenencia a diferentes tipos de cuadrados de tablero en varios conjuntos, y cómo construir estructuras de datos, etc., que permitirían consultas eficientes de los datos del juego.
• Representación de turnos y aplicación de las reglas del juego.
• Realizar un seguimiento del estado y los efectos secundarios de las misiones, misiones, etc. que pueden aparecer en el juego, por ejemplo, “Avanza tres casillas y luego haz el doble de lo que dice esa casilla” o “Roba tres cartas y dale una a la persona en tu derecho “.

Todo esto se hace conversacionalmente; discutimos opciones, algoritmos, complejidad algorítmica, jerarquías de clase, modelos de composición, fábricas, o tal vez nada de esto; todo depende de cómo va la conversación y de lo que el candidato haga sobre el diseño.

En lugar de proporcionar una pizarra blanca, le pregunto si el candidato quiere algo para trabajar desde cero: una pizarra blanca, un bloc de papel, un espacio para caminar, una computadora portátil. La forma en que el candidato responde esto me dice mucho más que si yo dijera: “Muestra tu trabajo en la pizarra”.

Una pregunta de algoritmo de estilo de pizarra permite al entrevistador evaluar muchas cosas:

1. ¿Cómo llegó el candidato a la solución? ¿Cuál fue su proceso de pensamiento?

2. ¿Cómo le va al candidato bajo presión? ¿Está nervioso? ¿Está lo suficientemente tranquilo como para corregir sus errores?

3. Finalmente, ¿qué tan buena es su solución? ¿Es capaz de expresar sus pensamientos en forma de pseudocódigo / código?

4. La programación de pares, por otro lado, se basa en el uso de un compilador para detectar errores. El candidato simplemente puede ejecutar el programa varias veces. La capacidad de recorrer un programa y razonar sobre él es una habilidad importante.

5. También se vuelve algo difícil distinguir claramente entre sus ideas y las ideas de su pareja.

Por lo tanto, probablemente me movería a la programación por pares, una vez que esté satisfecho con la capacidad de programación del candidato.

Depende del tipo de rol para el que se está entrevistando y del tipo de empresa y cultura en el que se está llevando al candidato.

Por ejemplo, cuando entrevisto a personas que necesitan saber matemáticas y programación, el problema que les doy requiere que primero resuelvan un pequeño problema matemático como parte del ejercicio, luego usen esa información para desarrollar un algoritmo o elegir datos adecuados. estructura para hacer el trabajo. Este proceso de dos pasos no es trivial en una configuración que no sea de pizarra. Particularmente porque me gusta ver a los candidatos tener éxito, no luchar demasiado (OK, no todos los que llegan al final como con mucha ayuda obtendrán el trabajo). Pero la pizarra les da la oportunidad de hablar sobre su proceso de pensamiento a medida que trabajan en los aspectos matemáticos del problema, y ​​luego discutir cómo abordarían poner las cosas en código … y puedo otorgar crédito parcial por un trabajo bien hecho si es necesario.

Como todos sabemos, la programación requiere un pensamiento crítico y estructurado. Escribir código es la parte fácil. Las cosas más importantes que probamos son cómo razonan las personas, cómo abordan el problema, qué herramientas usan para llegar a la respuesta, qué estructuras de datos y algoritmos usan, y solo finalmente, cómo codifican. Las respuestas a las preguntas de diseño que plantea, las modificaciones a la declaración del problema que realiza para descartarlas un poco, etc., le informarán mucho más (o al menos tanto) sobre el candidato durante las primeras partes de la entrevista como el código (y pruebas) lo hace al final.

Pero cada situación es diferente, y debe hacer lo que sea mejor para usted, su empresa y el puesto para el que está contratando.

Mi antiguo jefe utilizó un proceso en el que los candidatos tenían una hora para codificar una solución a un pequeño problema en una máquina con las herramientas de desarrollo ya instaladas. Esto funcionó bastante bien para eliminar a los candidatos que hablaban un buen juego pero que en realidad no podían escribir código.

Otra estrategia es traer a todos como contratistas con contratos de seis meses. De esta manera, si alguien es un verdadero pavo, puede dejarlo ir de inmediato. Si solo son regulares, puede dejarlos ir al final de su contrato. Si son realmente buenos, los contratas.