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

Algunas personas les preguntan en un intento de evaluar su capacidad y enfoque para resolver problemas. Personalmente, no creo que tales rompecabezas proporcionen un indicador preciso. En el "mundo real", tiene más de cinco minutos para averiguar si está tratando con un embalaje de contenedores vs a < a href="http://en.wikipedia.org/wiki/Knapsack_problem"> problema de la mochila , por ejemplo. Inicialmente, a veces es fácil malinterpretar el problema en cuestión hasta que esté en el 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 'rompecabezas' de entrevistas son aquellos en los que te sientas frente a una computadora para resolver un problema en el dominio en el que reclamas experiencia. También me disgusta el pensamiento "Bueno, un programador debería ser capaz de ..." porque no tiene en cuenta que las personas se ponen ansiosas cuando se las encuentra con algo inesperado en un entorno que ya es estresante. Claro, podría resolverlo si tuviera tiempo para pensar en ello ... y quizás podría resolverlo más rápido si se diera cuenta de que su vida se terminaría si no lo hiciera. ¿Quieres trabajar en algún lugar donde tu vida terminará si no puedes resolver los problemas en cinco minutos ? ¿Te despedirán si no puedes ?

¿Todos los grandes programadores también deberían ser campeones de solucionadores de sudoku? Estoy seguro de que hay muchos, pero no es un requisito previo para la competencia.

No estoy diciendo que no se debe probar no sobre cómo aborda los problemas, pero las pruebas deben ser divertidas e invitar al "mejor" que el solicitante tiene que dar, dada su área de pericia. Demostrar que eres tan inteligente como un personaje que Bruce Willis retrata parece un poco inútil, considerando que los productores gastaron una suma considerable para hacer que la escena simplemente sea correcta.

En otras palabras, si detectas que te está entrevistando alguien que tiene poca comprensión sobre lo que realmente estarás haciendo , discúlpate para ir al baño y nunca regreses.

Microsoft comenzó a usar estas preguntas a principios de los años ochenta. 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 intentaba ocupar muchos puestos técnicos pero no programados: escritores técnicos, evaluadores, asistencia telefónica, etc. Estos no eran trabajos comunes en el pasado, y personas con experiencia real en estas áreas. eran difíciles de encontrar Como alternativa, Microsoft pensó que podrían contratar a personas realmente inteligentes, inteligentes y flexibles, y capacitarlos en el trabajo. Dado que estas personas no tenían experiencia en programación, no les servía de nada hacerles preguntas sobre programación en la entrevista. Los acertijos se eligieron para tratar de identificar personas que eran inteligentes y tenían habilidades analíticas excepcionalmente buenas. En general, a los programadores se les daba problemas de programación de la pizarra blanca, aunque también se les podría preguntar acertijos durante el almuerzo o la cena.

Estas preguntas nunca debieron ser aprobadas. Tenían la intención de ser el inicio de una conversación sobre cómo abordar el problema y cómo pensaba sobre los problemas que nunca antes había visto. La única manera 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 asume , una historia de computación institucional en la década de 1950 y los años sesenta. Aparentemente, la práctica de hacer preguntas y acertijos a los candidatos para trabajos de programación se remonta a la década de 1950. Los Estados Unidos intentaban computarizar su sistema de defensa aérea e IBM estimó que necesitarían varios miles de programadores para hacer el trabajo. La respuesta fue de shock 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, reclutamiento de matemáticos como programadores, reclutamiento de jugadores de ajedrez y solucionadores de crucigramas, y cribando candidatos con acertijos y enigmas.

Eventualmente lograron reclutar suficientes programadores para completar el proyecto, pero la conclusión fue que ninguno de los métodos de selección fue mejor que la posibilidad de identificar a los reclutas que tuvieron un éxito notable como programadores.

¿Son útiles? No en realidad no. Una vez fueron tan comunes en Microsoft que incluso se llamaron "preguntas de Microsoft", y se han escrito libros sobre ellos, este en realidad es 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 pueden resolverlos, ¿cómo demuestra eso que será un buen dev / test / PM?

Por estas razones, rara vez se les pregunta en Microsoft. Es mucho mejor hacer preguntas de codificación, o preguntas de resolución de problemas que no requieran una respuesta de "truco". 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 vuelvan a rastrear cuando descubran un problema, tal vez ni siquiera encuentre una solución en el tiempo que tienen pero al menos lo haga de una manera sensata. Eso refleja el trabajo de la vida real. Nunca he tenido que medir 3 pintas con 2 cubos y una gallina (o lo que sea la pregunta).

Dicho esto, en mi época me hicieron un par de preguntas con trucos, 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, quizás algún día ...

Es posible que desee leer el libro ¿Cómo movería el Monte Fuji? . Entra en el razonamiento de que muchas personas utilizan acertijos en las entrevistas, y mi opinión es que es una combinación de comportamiento de culto a la carga ( "Microsoft lo hace, y si queremos ser tan exitosos como son, entonces mejor haz lo que hacen ") y las novatadas de fraternidad (" por Dios, ¡tuve que responder a 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 los años cincuenta. Eran una pregunta de entrevista bastante común en Silicon Valley que los entrevistadores hacían porque otros entrevistadores lo hacían (¿y tal vez sabían algo que este entrevistador no sabía?). Shockley los consideró como una prueba de inteligencia, y la pregunta con los 2 cubos estaba en uno de los originales Stanford Binet IQ prueba en 1916.

Es muy posible que las personas que realizan la entrevista realmente quieran ver cómo busca las respuestas, por lo que es imposible calcular las preguntas, como la cantidad de bombas de gasolina que hay en su ciudad. Este tipo de problemas son Fermi Problems . Dos publicaciones de blog interesantes de Jeff sobre este tema son La pregunta más difícil de rompecabezas de entrevistas jamás y ¿Qué tan bueno eres el Estimador? Parte III .

Personalmente, tengo una opinión baja sobre este tipo de preguntas, ya que generalmente las utilizan los entrevistadores que no saben lo que están haciendo, ni cómo buscar desarrolladores. A menos que vaya a trabajar para una compañía que haga acertijos / adivinanzas, estos pertenecen al fondo de la historia junto con "cuál es su mayor debilidad" (responda a la verdad y finalice su entrevista de manera incorrecta) o "por qué Las tapas de pozo son redondas "(no todas son).

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

En la primera buena entrevista que recuerdo, hablamos mucho sin prisa. Primero por una hora, en el teléfono, sobre el diseño orientado a objetos y los pros y 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 administración de configuración, equipos y responsabilidades, tecnología y diseño. Fue una entrevista de todo un 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, todas las buenas entrevistas han sido largas, de una a dos horas de conversaciones sobre el desarrollo de software. No ha habido preguntas para resolver problemas, ni rompecabezas, ni problemas de codificación.

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

1. ¿Cuáles son tus 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. ¿La integración continua no es una carga para la eficiencia?
5. Quien haya escrito un fragmento de código debería poseerlo, ¿verdad?
6. ¿Qué haces para entrar en el "flujo"?
7. ¿Cómo deben incluirse los defectos informados en un plan de proyecto?
8. ...

Esas son preguntas con más de una respuesta, y se tratan de temas sobre los cuales un desarrollador de software debería 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 efectivo de software desde Peopleware dicen que los mejores programadores son aquellos que entienden la dinámica de desarrollo de software, incluso si no tienen los coeficientes intelectuales más altos. Prefiero tener un novato que esté ansioso por aprender que alguien con n años de experiencia que se reduce a 1 año de experiencia repetido n veces. Mi tendencia 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 es, por supuesto, uno de los aspectos clave de la programación.

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

En este caso, mis expectativas son escucharle expresar su enfoque del problema. ¿Qué otros datos tratarías de reunir? ¿Cómo pondrías a prueba tus hipótesis, etc.?

Estas son solo prácticas de contratación de vudú. Otras personas hacen estas preguntas para que sientan que deben hacerlo. Saben que no responder a la pregunta es "malo" y responder es "bueno", pero no pueden decirle 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.

Esa es la razón de ser del viejo skool que debes tener para tener habilidades básicas de lógica; Cualquier otra cosa puede ser enseñada. Pero eso no es del todo cierto. Leer 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 aún pensara que la lógica era más importante que las habilidades prácticas de programación.

Descargo de responsabilidad: soy muy bueno en los rompecabezas de lógica y probablemente no habría tenido mi comienzo en esta línea de trabajo sin este razonamiento.

El entrevistador debe haberse referido a la resolución de problemas y las habilidades lógicas, que forman 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 discutir 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 solo 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 (cliente, usuario, 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 rompecabezas en las entrevistas se dividen en dos categorías: "rompecabezas lógicos" (como el que te preguntaron) y la categoría "piensa diferente". La categoría de pensar de manera diferente (no estoy seguro de que también se llamen rompecabezas laterales) suele ser de este tipo: ¿Cuántas hojas hay en ese árbol? o ¿Cuántos sastres están presentes en tu ciudad?

Estoy de acuerdo con los "rompecabezas lógicos" porque tienen una o quizás dos soluciones a lo sumo y pueden ser alcanzadas por una lógica directa. Y creo que los rompecabezas lógicos son buenos hasta cierto punto porque el proceso necesario para resolverlos es en gran medida la forma en que un programador necesita pensar en la vida real.

El tipo de "pensar de manera diferente" no me molesta porque le obligan a hacer suposiciones y luego hacen 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 tomo entrevistas no pregunto rompecabezas lógicos. Motivo: la mayoría de los candidatos, incluso aquellos con 3 a 4 años de experiencia, fracasan o se dan por vencidos cuando les pido que programen problemas simples de libros de texto, como la serie de Fibonacci o palíndromos.

El problema con los rompecabezas, en cualquier caso, es que los programadores no tan buenos saben que con solo buscar soluciones a estos rompecabezas 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 rompecabezas. Steve McConnell lo explica correctamente en "Code Complete":

   ¿Qué? ¿No tienes que ser superinteligente? No, no lo haces. Nadie es 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 enfocas tu inteligencia es más importante que la cantidad de inteligencia que tienes. Como mencionó 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ía de la programación es un intento de compensar el tamaño estrictamente limitado de nuestros cráneos. Las personas que son mejores en la programación son las personas que se dan cuenta de cuán pequeños son sus cerebros. Son humildes Las personas que son peor 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ás aprendas a compensar tu cerebro pequeño, mejor serás un programador . Cuanto más humilde seas, más rápido mejorarás.

2. Estos rompecabezas pueden ser útiles durante la entrevista, pero solo si el entrevistador observa el Proceso , no el resultado en sí mismo.

En mi opinión, idealmente, los rompecabezas deberían ser más complicados y relacionados con la programación (como un proyecto pequeño de 2 horas). La cosa 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 anterior. En la película ... Die Hard with a Vengeance ... ¿Me lo explican ...? siendo un ejemplo de saber 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 adaptarla si es necesario. Esto suele ser lo que creo que esperaría un entrevistador, lo que puede o no ser una buena idea.

2. Habilidades creativas de improvisación. Este sería el caso si no conoces una solución anterior o si reconoces que el problema es algo que uno podría modelar como una ecuación diofántica. 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 manera creativa, además de explicar por qué lo que tiene es una solución válida al problema.

O bien podría ser lo que hace que uno supere la pregunta de manera satisfactoria, aunque en cada caso también hay un poco de una prueba de las habilidades de comunicación de uno, ya que también podría intentar una respuesta de "¿Es esto realmente relevante para la posición que ¿Estoy aplicando? ¿Cuándo se usaron estas habilidades por última vez? " eso puede llevar a un diálogo interesante si el entrevistador se abre a conocer qué es exactamente lo que quieren ver, de modo que tal vez se pueda considerar que un enfoque alternativo es más efectivo aquí.

No es un problema particularmente difícil. 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 no se pueden predecir muchos de los desafíos que el trabajo podría tener en la tienda.

Por lo tanto, el empleador potencial debe adivinar sobre su desempeño 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 capacidad. Por lo tanto, el currículum puede dar una indicación de los niveles de esfuerzo / compromiso en su historia, pero nada de esto hablará de su capacidad real para resolver los 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 en algunos acertijos de lógica / matemática / CSy.

Recuerda que es un juego de adivinanzas, y la realidad es que todos somos iguales que cualquiera de nosotros preferiríamos contratar a alguien capaz de resolver esos rompecabezas que a uno que no puede.

Sí, podrías estudiar los rompecabezas de las entrevistas, pero creo que te quemarás si el rompecabezas dado no coincide con los que estudias ... y mientras no memorices los rompecabezas y sus soluciones, tal vez estudiar los rompecabezas por sí mismos te hará una persona más inteligente de una manera real, como cualquier educación real debería.