En una entrevista, ¿es mejor codificar una solución de fuerza bruta para una pregunta difícil o pasar la entrevista examinando la pregunta cuidadosamente? [cerrado]

A veces las preguntas de la entrevista son difíciles, ya sea que el entrevistador pretenda que lo sean o no. Puede reducirse a elegir si usar el tiempo limitado de la entrevista para codificar una solución fea, ineficiente y de fuerza bruta, o pasar el tiempo entendiendo cada aspecto del problema con el entrevistador.

Por ejemplo, el problema 91 en el Proyecto Euler puede resolverse mediante una solución de fuerza bruta no tan difícil de calcular cada triángulo posible, escribir una prueba isRightTriangle () y hacer estallar todos los triángulos que pasan la prueba en un conjunto. Pero los dos pares de coordenadas X / Y hacen que sea una solución O (x ^ 4) con un alto valor constante. Un amigo y yo acabamos de encontrar una solución que es mucho más elegante y eficiente, pero los dos pasamos 3 horas en ella y dibujamos docenas de diagramas, probamos múltiples fórmulas, examinamos múltiples enfoques, etc.

No todas las preguntas de la entrevista son justas. Además, lo que es fácil para una persona puede ser difícil para otra. Si alguien tiene problemas con una pregunta, ¿estaría más impresionado con una solución fea de fuerza bruta que funciona? ¿O excelente comprensión del problema y caminos hacia una solución elegante, pero sin solución codificada? ¿Existe una regla que indique que después de 20 minutos debería comenzar a codificar sin importar qué?

En primer lugar, una pregunta que lleva a dos desarrolladores experimentados tres horas para optimizar con elegancia es una mala elección para una pregunta de entrevista. Si lo preguntas, no debes esperar respuestas perfectas.

Por otro lado, a veces aprendes más sobre alguien cuando haces que llegue a sus límites. Es por eso que muchos cursos universitarios aumentan la dificultad y luego califican en la curva. Si todos obtienen un puntaje del 100% en cada examen, está dejando mucho aprendizaje potencial.

Mi candidato ideal probablemente haría el cálculo de complejidad primero, diga "Oh, eso es solo 6 millones de iteraciones, lo que no tomará mucho tiempo", y luego escribiría rápidamente la solución de fuerza bruta. Luego debatirían los enfoques que podrían adoptar para optimizarlo, sin implementarlos necesariamente a menos que el entrevistador se lo pidiera.

En parte, esto se debe a que muchos de los problemas de tipo euler del proyecto que surgen en el mundo real son problemas únicos que debes resolver una vez y luego olvidarte de ellos. Quiero saber que alguien a quien contrate podrá reconocer un algoritmo de fuerza bruta que demore 2 minutos en escribir y 10 minutos en ejecutarse es más eficiente que un algoritmo que demora 3 horas en escribir y 10 segundos en ejecutarse, si solo necesita para ejecutarlo esa vez.

Como gerente de contratación, si le pido que resuelva un problema con el código que está justo frente a mí, no lo hago tanto para ver el código en sí (aunque es importante) sino para determinar cómo y por qué Hiciste lo que hiciste. Una de esas cosas que puede hacer es no codificar y, en cambio, interrogarme sobre los aspectos del problema en sí, para resolverlo mejor. Eso es significativo para mí, y generalmente más significativo que la solución establecida en el código. Sin embargo, no es así como todos lo hacen, ni es lo que todos quieren ver (y de hecho, rara vez le pido a la gente que codifique en una entrevista, pero pongo problemas sobre la mesa y hablamos a través de ellos y, a veces, surge un seudocódigo , que es igual de bueno para mí ).

Tienes razón en que no todas las preguntas de la entrevista son justas, y lo que es fácil para alguien es difícil para otro, en ese entorno y con esas limitaciones, y es por eso que esas entrevistas que entienden que generalmente no buscan la solución de código (aunque , de nuevo, eso juega un papel importante), sino más bien el proceso de solución .

"¿Existe una regla que indique que después de 20 minutos deberías comenzar a codificar sin importar qué?" Contestaría esto diciendo que dentro de muy poco tiempo de pensar en el problema, al menos debería hacer algo : hacer más preguntas, esbozar un marco para una solución o decir que simplemente no puede hacerlo / No sé por dónde empezar.

Si pongo un problema difícil frente a usted y la solución que proporcionó, dadas las limitaciones de tiempo y lo que tiene, era la fuerza bruta y lo feo, entonces le haría una serie de preguntas sobre por qué ese fue el caso, ¿Y qué lo cambiaría a algo más elegante: más información? ¿más tiempo? un ambiente diferente? Ser consciente de sí mismo y estar en contacto con el por qué de lo que has hecho y lo que no has hecho, y ser capaz de explicarlo racionalmente, es una gran estrella de oro en mi libro, pero esos son los tipos de desarrolladores que yo buscar. Entonces, "una excelente comprensión del problema y caminos hacia una solución elegante" también funcionaría para mí, pero no para todos.

Quisiera ambas, pero pueden mostrar un "código que simplemente funciona" en una solución y luego posiblemente discutir posibles soluciones para mejorar ese problema.

Si le pide a alguien que escriba código y solo quiere hablar sobre posibles soluciones con código cero, eso sería una preocupación.

Como dijiste, alguien puede tener problemas con el problema en particular por cualquier razón, pero debes aprender cómo resolverlos. Podrían tener suerte y ya han oído hablar de una solución a un problema similar. Sucede.

Observe a alguien escribir suficiente código y discutirlo, y puede averiguar si es adecuado para el trabajo.

¿Existe una regla que indique que después de 20 minutos debería comenzar a codificar sin importar qué?

No, pero si pasa 20 minutos analizando el problema antes de comenzar a trabajar, probablemente ya esté en problemas. Un empleador que le hace una pregunta como la que citó está principalmente interesado en cómo aborda un problema, pero si lo hace como un problema de codificación, también querrá ver algún código. Hábleles a través de su proceso de pensamiento ...

Bueno, el enfoque obvio aquí es la fuerza bruta. Si tuviera una manera de reconocer un triángulo rectángulo dados los tres vértices, podría recorrer todas las combinaciones de dos puntos y el origen buscando triángulos rectángulos. Eso no debería ser difícil: puedo escribir una función que use el Teorema de Pitágoras para identificar triángulos rectángulos. Para hacerlo más fácil, también escribiré una función que determina la distancia entre dos puntos usando la fórmula de la distancia ...

Escribir esas funciones debería tomar unos tres minutos. Ahora, a los pocos minutos de la pregunta, ya ha demostrado que recuerda la geometría básica y que realmente sabe cómo escribir código. También te da algo de qué hablar:

Entonces, obviamente podríamos poner la isRightTriangle(p1, p2, p3)función en el medio de cuatro forbucles e iterar sobre todas las opciones posibles para cada uno de los dos puntos variables. Veamos ... el problema pide la cantidad de triángulos rectángulos, incluido el origen en una cuadrícula de 50x50, por lo que usar el método de fuerza bruta nos hace verificar 50 posibilidades para cada coordenada de cada punto. Son 50 ^ 4 comprobaciones ... Estoy seguro de que podemos hacerlo mejor, pero el código es obvio, así que déjenme escribirlo ...

Entonces, ahora escribe una función que usa forbucles anidados y la isRightTriangle()función que acaba de escribir. Has resuelto el problema, pero también has dejado que el entrevistador vea a dónde vas. Si su objetivo era solo ver que usted puede escribir código, podrían decirle que pare. Lo más probable es que estén felices de hablar con alguien que sepa lo que están haciendo y querrán ver hasta dónde llegas. Entonces sigues ...

Mientras escribía, se me ocurrió que podemos aprovechar la simetría. Podemos reflejar cualquier triángulo rectángulo dado alrededor de la línea de 45 °, así que si elegimos verificar uno de los puntos solo en un lado de esa línea, podemos contar cualquier triángulo rectángulo que encontremos dos veces ... una vez para el triángulo y otra vez por su reflejo Eso reduce el número de cheques a la mitad. Además, mirándolo ahora, estamos sacando una raíz cuadrada para encontrar la distancia entre dos puntos, pero luego volvemos a cuadrar eso en isRightTriangle()...

Y así. Una vez más, generalmente no quieren ver una solución perfecta, quieren ver cómo se llega a una solución. Su proceso de pensamiento no tiene que ser como el anterior: solo tener la confianza para pensar en voz alta contará mucho. No se preocupe si comete un error, solo diga "hmmm, creo que me he salido de los rieles aquí, déjeme retroceder un paso ..."

Como gerente, si le pido que codifique como prueba, estoy más interesado en:

• Si puedes escribir código
• Su estilo de codificación
• El algoritmo que seleccionaste
• ¿El intento indica que entendió el problema?
• Si estoy realmente interesado en una tecnología específica, ¿demostraste que la conoces más o menos?

El primer elemento puede parecer una locura, pero te sorprenderías ...

Estilo de codificación: con eso no solo me refiero a dónde pones los frenos, sino a cosas como:

• ¿Elegiste composición o herencia para resolver ese problema? ¿Por qué?
• Para ese valor, ¿por qué elegiste usar una enumeración vs. una cadena vs. un int (o cualquier permutación que aplique)
• ¿Usó propiedades, campos o métodos get / set para ese valor? ¿Por qué?
• ¿Cómo manejaste el estado en tus clases?
• ¿Entiendes cómo funcionan la herencia, las interfaces y las lambdas?
• ¿Entiendes las convenciones de parámetros del lenguaje (¿qué es por ref vs por valor?)
• ¿Sabes cómo escribir pruebas unitarias?

Esto es lo que realmente no me importa:

• Que se compila (suponiendo que acabo de darte un bloc de notas y ningún compilador)
• Que sabía de memoria el orden de esos 2 parámetros en esa función
• Que puede recitar una cadena de conexión de SQL Server u Oracle de memoria
• Que puedes codificar perfectamente mientras estoy parado sobre tu hombro observando cada error.

Honestamente, nunca fui un gran admirador de las pruebas de codificación, excepto como una herramienta para analizar el estilo.

En ese caso, avanzar hacia una solución elegante es mejor que una solución peor pero completa. Sin embargo, ambos casos son buenos. Está absolutamente bien haber anotado pusdocode demostrando que comprende el problema y cómo tiene la intención de resolverlo, incluso si no tuvo tiempo para codificar el programa.

Creo que está haciendo una pregunta para la que en realidad no hay respuesta, y mucho menos una respuesta "correcta". La razón por la que digo esto es que depende completamente de lo que valore la persona que hace la pregunta.

Es posible que el entrevistador sea un pragmático incondicional que realmente busca ver que algo funcione rápidamente y luego optimizarlo como una actividad de menor prioridad si le queda tiempo. Es igualmente posible que el entrevistador esté haciendo su mejor impresión de las prácticas de contratación de Google y no esté interesado en nada más que el algoritmo más sexy y elegante, y lo tome como un signo de debilidad de que alguna vez hayas puesto las palabras "bruto" y " forzar "dentro de 5 palabras el uno del otro. También es posible que el entrevistador haya buscado en Google "preguntas de entrevista" y haya encontrado este problema en Internet 5 minutos antes de que usted ingrese y no tenga idea de lo que quiere.

En todos los casos, su mejor opción es pedir una aclaración, si no puede inferir, según la información de contexto, lo que quiere el entrevistador. Tienes razón en que no todas las preguntas de la entrevista son justas y, de hecho, no todas son buenas o incluso preguntas que tengan sentido. Una entrevista es una actividad inherentemente reduccionista, al igual que las "citas rápidas" en las que pasan una o dos horas con alguien y los dos intentan adivinar, en función de esa hora, si trabajarán bien juntos durante la próxima 5 años o no. Examinado desde esa perspectiva, espero que sea más claro por qué digo que realmente no hay respuesta a su pregunta sobre una 'regla'.

Alguien le está haciendo una pregunta que cree que le dará una idea de su competencia y encajará con su equipo. Tienes que mirar a su equipo, lo que sabes sobre ellos, la personalidad del entrevistador y docenas de otros factores, y adivinar mejor qué respuestas, enfoque y proceso podrían valorar. Personalmente, diría que debes abordarlo de la manera que creas que es la mejor idea. Si no están de acuerdo con usted, de todos modos podría no haber sido una buena opción, más fácil de resolver antes que después.

Los entrevistadores le pedirán que mejore su solución de todos modos.

Y el enfoque de "solución de fuerza bruta primero" tiene una ventaja indiscutible: si no logra encontrar una solución ideal, todavía tiene algo completado para mostrarles.