Rompecabezas lógicos difíciles: ¿son realmente útiles para evaluar las habilidades de programación? [cerrado]

En la última entrevista a la que asistí, me pidieron que resolviera un rompecabezas en el que se esperaba que midiera exactamente blah litros de agua dados dos cubos con capacidades: blah y blah litros respectivamente. No pude resolver el rompecabezas en un tiempo determinado (~ 5 minutos).

El entrevistador estaba un poco decepcionado y dijo que un programador debe tener "estas" habilidades. No entendí de qué habilidades estaba hablando.

Siempre me he sentido extraño sobre este tipo de acertijos que normalmente se hacen en las entrevistas de trabajo de programación. No entiendo cuál es, si es que existe, la conexión entre tales acertijos y la programación. ¿Exactamente qué habilidades pretenden evaluar los entrevistadores con tales rompecabezas?

Algunas personas les preguntan en un intento de evaluar su habilidad y enfoque para resolver problemas. Personalmente, no creo que tales acertijos proporcionen un indicador preciso. En el "mundo real", tiene más de cinco minutos para determinar si está lidiando con un embalaje de la papelera versus un problema de mochila , por ejemplo. Inicialmente, a veces es fácil malinterpretar el problema en cuestión hasta que esté en medio de aplicar la solución incorrecta. Eso le sucede a las personas con 1, 5, 10 o incluso 20 años de experiencia.

Los mejores 'acertijos' de entrevistas son aquellos en los que te sientas en una computadora para resolver un problema en el dominio en el que reclamas experiencia. También me desagrada el pensamiento "Bueno, un programador debería ser capaz de ..." porque no tiene en cuenta que las personas se ponen ansiosas cuando reciben un golpe inesperado en un entorno que ya es estresante. Claro, podrías resolver eso si tuvieras tiempo para pensarlo ... y tal vez podrías resolverlo más rápido si te das cuenta de que tu vida terminaría si no lo hicieras. ¿Desea trabajar en algún lugar donde terminará su vida si no puede resolver los problemas en cinco minutos ? ¿Te despedirán si no puedes ?

¿Deberían todos los grandes programadores ser también campeones solucionadores de sudoku? Estoy seguro de que hay muchos, pero no es como una especie de requisito previo para la competencia.

No estoy diciendo que no se deba evaluar cómo se abordan los problemas, pero las pruebas deben ser divertidas e invitar a los "mejores" que el solicitante tiene que dar, dada su área de especialización. Demostrando que son tan inteligentes como un personaje que interpreta Bruce Willis parece una especie de sentido, teniendo en cuenta que los productores gastan una suma bastante para conseguir que la escena simplemente correcto.

En otras palabras, si detecta que está siendo entrevistado por alguien que tiene poca comprensión de lo que realmente estará haciendo , discúlpese para ir al baño y nunca regrese.

Microsoft comenzó a usar estas preguntas a principios de la década de 1980. A medida que Microsoft tuvo un éxito notable, otras compañías comenzaron a copiarlos, pero un par de puntos clave se perdieron en la traducción.

En ese momento, Microsoft estaba tratando de ocupar muchos puestos técnicos pero no relacionados con la programación: escritores técnicos, evaluadores, soporte telefónico, etc. Éstos no eran trabajos comunes en el pasado, y las personas con experiencia real en estas áreas eran difíciles de conseguir. encontrar. Como alternativa, Microsoft pensó que podrían contratar personas realmente inteligentes, inteligentes y flexibles, y capacitarlos en el trabajo. Como estas personas no tenían experiencia en programación, hacerles preguntas de programación en la entrevista no tenía sentido. Los acertijos fueron elegidos para tratar de identificar a personas que eran inteligentes y tenían habilidades analíticas excepcionalmente buenas. En general, a los programadores se les daban problemas de programación en la pizarra, aunque también se les podría pedir acertijos durante el almuerzo o la cena.

Estas preguntas nunca pretendieron ser pasa-falla. Pretendían ser el comienzo de una conversación sobre cómo abordaría el problema y cómo pensaba sobre problemas que nunca había visto antes. La única forma segura de "fallar" era negarse a tratar de resolver el problema. En ese momento, esta era una estrategia novedosa, y no podía simplemente buscar las preguntas en Google.

Editar:

Algún tiempo después de escribir esta respuesta, leí The Computer Boys Take Over , una historia de la informática institucional en las décadas de 1950 y 1960. Aparentemente, la práctica de preguntar acertijos y acertijos de candidatos para trabajos de programación se remonta a la década de 1950. Estados Unidos estaba tratando de informatizar su sistema de defensa aérea e IBM estimó que necesitarían varios miles de programadores para hacer el trabajo. La respuesta fue de sorpresa y consternación: solo había un par de docenas de "programadores profesionales" en todo el mundo. Se probaron varios enfoques: pruebas de aptitud de programación abstracta, reclutar matemáticos como programadores, reclutar jugadores de ajedrez y resolver crucigramas, y evaluar a los solicitantes con acertijos y acertijos.

Eventualmente lograron reclutar suficientes programadores para completar el proyecto, pero la conclusión fue que ninguno de los métodos de detección fue mejor que la posibilidad de identificar a los reclutas que llegaron a ser notablemente exitosos como programadores.

¿Son útiles? No en realidad no. Alguna vez fueron tan comunes en Microsoft que incluso se les llamó "preguntas de Microsoft", y se han escrito libros sobre ellas, esta es realmente una buena lectura.

Hay 2 problemas con ellos. En primer lugar, si el solicitante investiga (y lee el libro) los conocerá de todos modos y, en segundo lugar, incluso si puede resolverlos, ¿cómo demuestra eso que será un buen desarrollador / prueba / PM?

Por estas razones, rara vez se les pregunta más en Microsoft. Es mucho mejor hacer preguntas de codificación o preguntas de resolución de problemas que no requieren una respuesta "engañosa". En otras palabras, debe hacer preguntas que le permitan explorar las habilidades y el comportamiento del solicitante mientras intentan abordar el problema: como entrevistador, quiero que hagan preguntas, encuentren soluciones y luego retrocedan cuando descubran un problema, tal vez ni siquiera encuentren una solución en el tiempo que tienen, sino que al menos lo hagan de manera sensata. Eso refleja el trabajo de la vida real. Nunca he tenido que medir 3 pintas con 2 cubos y un pollo (o lo que sea la pregunta).

Dicho esto, me hicieron un par de preguntas con trampa en mi tiempo, y ahora me considero un experto en el transporte de pollos y zorros en pequeñas embarcaciones y en el cálculo de la vida útil de una mosca que vive en un tren. Nunca he tenido que usar esta información, pero quién sabe, tal vez algún día ...

Es posible que desee leer el libro ¿Cómo moverías el monte Fuji? . Entra en el razonamiento de que muchas personas usan acertijos en las entrevistas, y mi opinión es que es una combinación de comportamiento de culto de carga ( "Microsoft lo hace, y si queremos ser tan exitosos como ellos, entonces mejor hacemos lo que ellos hacen hacer " ) y novatadas de fraternidad ( " ¡por Dios! ¡Tenía que responder esas preguntas y es mejor que creas que el próximo tipo tendrá que responderlas! " ).

La historia de estas preguntas como práctica de entrevista comenzó con William Shockley en la década de 1950. Eran una pregunta de entrevista razonablemente común de Silicon Valley que los entrevistadores hicieron porque otros entrevistadores lo estaban haciendo (¿y tal vez sabían algo que este entrevistador no sabía?). Shockley los concibió como una prueba de inteligencia, y la pregunta con los 2 cubos estaba en una de las pruebas originales de Stanford Binet IQ en 1916.

Posiblemente, las personas que realizan la entrevista realmente quieren ver cómo buscas las respuestas, por lo que plantearán preguntas imposibles de calcular, como cuántas bombas de gas hay en tu ciudad. Este tipo de problemas son los problemas de Fermi . Dos publicaciones de blog interesantes de Jeff sobre este tema son La pregunta más difícil del rompecabezas de la entrevista y ¿Qué tan buen estimador eres? Parte III .

Personalmente, tengo una baja opinión sobre este tipo de preguntas, ya que generalmente las usan los entrevistadores que no saben lo que están haciendo ni cómo buscar desarrolladores. A menos que vaya a trabajar para una empresa que hace acertijos / acertijos, pertenecen a la historia junto con "cuál es su mayor debilidad" (responda la verdad a esto y termine su entrevista de mala manera) o "por qué son tapas de registro redondas "(no todas lo son).

Otros han proporcionado respuestas que he votado como un deber . La razón por la que escribo otra respuesta es porque lo que quiero decir probablemente no cabe en un comentario, y porque hay que decir algo sobre cómo puede ser una buena entrevista de trabajo de programación.

En la primera buena entrevista que recuerdo, hablamos mucho, sin prisa. Primero durante una hora, por teléfono, sobre el diseño orientado a objetos y los pros y los contras de implementarlo en C ++. Luego, en el sitio, hablé con varias personas sobre sus prácticas de desarrollo de software, integración, pruebas, control de versiones y gestión de configuración, sobre equipos y responsabilidades, sobre tecnología y sobre diseño. Fue una entrevista de todo el día que incluyó el almuerzo con la gente que me entrevistó. En retrospectiva, se trataba de si encajaría productivamente en lo que ya estaban haciendo.

Desde entonces, las buenas entrevistas han sido largas, de una a dos horas, sobre el desarrollo de software. No ha habido preguntas para resolver problemas, ni acertijos, ni desafíos de codificación.

Si tuviera que entrevistar a alguien para un trabajo de programación hoy, procedería de la misma manera. Solicitaría opiniones sobre una variedad de temas, y dejaré de lado la profundidad:

1. ¿Cuáles son sus preferencias de lenguaje de programación? ¿Por qué?
2. ¿Cómo abordar el manejo de excepciones?
3. ¿No son los beneficios del diseño en capas un mito?
4. ¿No es la integración continua una carga para la eficiencia?
5. Quien haya escrito un código debe poseerlo, ¿verdad?
6. ¿Qué haces para entrar en "flujo"?
7. ¿Cómo deben incluirse los defectos notificados en un plan de proyecto?
8. ...

Esas son preguntas con más de una respuesta, y se trata de temas sobre los cuales un desarrollador de software debe tener una opinión informada. Estoy totalmente de acuerdo con las respuestas que mencionan problemas reales anteriores experimentados como tema de conversación (no como preguntas).

Los estudios más científicos sobre el desarrollo de software efectivo desde Peopleware dicen que los mejores programadores son aquellos que entienden la dinámica del desarrollo de software, incluso si no tienen los coeficientes intelectuales más altos. Prefiero tomar un novato que está ansioso por aprender que alguien con naños de experiencia que se reduce a 1años de experiencia repetidas nveces. Mi sesgo personal es hacia los candidatos que tienden a pensar fuera de la caja y, al mismo tiempo, saben cómo encajar en la caja actual (mi).

Pueden ser útiles para evaluar las habilidades de resolución de problemas , que por supuesto es uno de los aspectos clave de la programación.

Como entrevistador de muchas personas a lo largo de los años, por lo general no hago preguntas tipo gotcha como la que parece describir, pero bien puedo hacer algo y preguntar "¿cómo resolverías ...".

En ese caso, mis expectativas son oírle articular su enfoque del problema. ¿Qué otros datos tratarías de reunir? ¿Cómo probarías tus hipótesis, etc.

Estas son solo prácticas de contratación de vudú. Otras personas hacen estas preguntas para que sientan que se supone que deben hacerlo. Saben que no responder la pregunta es "malo" y responder es "bueno", pero no pueden decir por qué más allá de las no respuestas como "un desarrollador necesita estas habilidades". Son una pérdida de tiempo y un indicador de que el entrevistador no es un entrevistador competente.

Ese es el razonamiento antiguo que tienes que tener habilidades lógicas básicas; cualquier otra cosa se puede enseñar. Pero eso no es del todo cierto. Leer la lógica booleana , las condiciones y los bucles no es lo mismo que ser capaz de resolver un rompecabezas lógico .

Dicho esto, en los días de los lenguajes de procedimiento, probablemente era cierto que alguien que pudiera resolver estos problemas tendría una mayor propensión a poder aplicar cualquier problema en términos de interruptores. Pero en mi opinión, la programación OO / Funcional requiere una mentalidad de ingeniería, que es bastante diferente (aunque no contradictoria).

Personalmente, no estoy seguro de querer un trabajo en una empresa que todavía pensaba que la lógica era más importante que las habilidades prácticas de programación.

Descargo de responsabilidad: soy muy bueno en los acertijos lógicos y probablemente no habría comenzado en esta línea de trabajo sin esta lógica.

El entrevistador debe haberse referido a la resolución de problemas y las habilidades lógicas, que es parte del trabajo diario de un programador. Cuando se le presenta un problema, debe poder analizarlo, subdividirlo y escribir una solución para él utilizando el enfoque más óptimo.

Podrías argumentar qué tan bien un rompecabezas como ese representa tu habilidad para hacer esto. No veo el mérito de hacer una pregunta de rompecabezas en lugar de simplemente hacer un problema de programación de la vida real.

La programación no se trata de escribir líneas de código, se trata de resolver problemas para y de otras personas (clientes, usuarios, etc.).

Sucede que para los programadores la solución toma la forma de un programa.

Por eso es importante tener capacidades de resolución de problemas y por qué se prueba.

Dicho esto, no estoy seguro de que resolver un rompecabezas complicado sea la mejor manera de evaluar a alguien.

Los acertijos en las entrevistas se dividen en dos categorías: "acertijos lógicos" (como el que se le preguntó) y la categoría "pensar diferente". La categoría de pensar de manera diferente (no estoy seguro de si también se llaman rompecabezas laterales) son generalmente de este tipo: ¿Cuántas hojas hay en ese árbol? o ¿Cuántos sastres hay en tu ciudad?

Estoy de acuerdo con los "acertijos lógicos" porque tienen una o quizás dos soluciones como máximo y se puede llegar con una lógica directa. Y creo que los acertijos lógicos son buenos hasta cierto punto porque el proceso necesario para resolverlos es en gran medida la forma en que un codificador necesita pensar en la vida real.

El tipo de "pensar diferente" no me molesta porque te obligan a hacer suposiciones, y luego, hacer algunos cálculos basados ​​en las suposiciones. En pocas palabras, si su entrevistador está de acuerdo con su lógica pero no con sus suposiciones, o viceversa, ha perdido. Hay demasiado espacio para que el entrevistador no esté de acuerdo con su solución.

Cuando hago entrevistas no hago acertijos lógicos. Motivo: la mayoría de los candidatos, incluso aquellos con 3-4 años de experiencia, fracasan o se rinden cuando les pido que codifiquen problemas simples de libros de texto, como series de Fibonacci o palíndromos.

El problema con los acertijos, de cualquier manera, es que los programadores no tan buenos saben que solo buscando soluciones a acertijos tan comunes en la red pueden impresionar a los entrevistadores. Muy pocas personas serán lo suficientemente honestas como para decir que ya conocen la solución.

Dos puntos:

1. La programación es principalmente diferente de la resolución de acertijos. Steve McConnell lo explica correctamente en "Code Complete":

   ¿Qué? ¿No tienes que ser superinteligente? No, tu no. Nadie es realmente lo suficientemente inteligente como para programar computadoras. Comprender completamente un programa promedio requiere una capacidad casi ilimitada para absorber detalles y una capacidad igual para comprenderlos todos al mismo tiempo. La forma en que enfoca su inteligencia es más importante que la cantidad de inteligencia que tiene. Como se mencionó en el Capítulo 5, en la Conferencia del Premio Turing de 1972, Edsger Dijkstra entregó un artículo titulado "El programador humilde". Argumentó que la mayor parte de la programación es un intento de compensar el tamaño estrictamente limitado de nuestros cráneos. Las personas que son mejores en programación son las personas que se dan cuenta de lo pequeños que son sus cerebros. Son humildes Las personas que son las peores en la programación son las personas que se niegan a aceptar el hecho de que sus cerebros no son iguales a la tarea. Sus egos les impiden ser grandes programadores. Cuanto másaprende a compensar tu pequeño cerebro, mejor serás un programador . Cuanto más humilde seas, más rápido mejorarás.

2. Dichos acertijos pueden ser útiles durante la entrevista, pero solo si el entrevistador observa el Proceso , no resulta el resultado.

Pero, idealmente, los rompecabezas deberían ser más complicados y estar relacionados con la programación (como un pequeño proyecto de 2 horas), en mi opinión. La cuestión es que los entrevistadores son personas y no tienen "habilidades de entrevista" perfectas.

Hay un par de formas diferentes de examinar estos problemas:

1. Conocer una solución previa. En la película ... Muere duro con una venganza ... ¿explícame esto ...? siendo un ejemplo de conocer una solución para el caso donde los blahs son 4,3 y 5 respectivamente. Algunas personas podrán aprovechar rápidamente su conocimiento interno de una solución pasada y adaptarlo si es necesario. Esto es generalmente lo que creo que un entrevistador esperaría, lo que puede o no ser una buena idea.

2. Habilidades de improvisación creativa. Este sería el caso si no conoce una solución anterior o incluso reconoce que el problema es algo que uno podría modelar como una ecuación de diofantina. Por lo tanto, la pregunta es qué tan rápido puede usar lo que se le da y encontrar una solución al problema de una manera creativa, junto con explicar por qué lo que tiene es una solución válida para el problema.

Cualquiera de los dos puede ser lo que le hace a uno pasar la pregunta de manera satisfactoria, aunque en cada caso también hay una prueba de sus habilidades de comunicación, ya que también podría intentar una respuesta de "¿Es esto realmente relevante para la posición en la que estoy aplicando? ¿Cuándo se usaron estas habilidades por última vez? " eso puede conducir a un diálogo interesante si el entrevistador se abre sobre qué es exactamente lo que quieren ver, que tal vez un enfoque alternativo podría ser visto como más efectivo aquí.

No es un problema particularmente complicado. Solo se requieren tres pasos, y solo hay dos opciones en cada paso. Me sorprendería si alguno de mis colegas no pudiera resolverlo en muy poco tiempo. No presentamos tales problemas en las entrevistas, pero creo que es razonable hacer tales preguntas. Sin duda, son más útiles que las preguntas detalladas sobre sintaxis o bibliotecas.

OTOH, creo que los problemas de programación son más útiles.

Debe recordar que no hay forma de saber con absoluta certeza que alguien será bueno en un trabajo. Especialmente un trabajo de CS ya que muchos desafíos que el trabajo podría tener en la tienda no se pueden predecir.

Por lo tanto, el posible empleador debe adivinar su rendimiento futuro.

Se pueden obtener grados, recomendaciones y GPA con tiempo / esfuerzo e ingeniería social, la experiencia laboral puede ser embellecida y / o falsa, y las pruebas estandarizadas son francamente demasiado básicas para ser demasiado indicativas de habilidad. Por lo tanto, el currículum puede dar alguna indicación de los niveles de esfuerzo / compromiso en su historia, pero nada de eso hablará de su capacidad real para resolver problemas difíciles que surgen en el mundo de la informática. No puedo pensar en una mejor manera de predecir ese tipo de habilidad que algunos buenos acertijos de lógica / matemática / CSy.

Recuerde que es un juego de adivinanzas, y la realidad es que todas las cosas iguales a cualquiera de nosotros preferiría contratar a alguien capaz de resolver esos acertijos que uno que no pueda.

Sí, podría estudiar rompecabezas de entrevistas, pero creo que se quemará si el rompecabezas dado no coincide con los que estudia ... y siempre que no memorice los rompecabezas y sus soluciones, tal vez estudie los rompecabezas. ellos mismos te harán una persona más inteligente de una manera real, como cualquier educación real debería.