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

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

Por otra parte, a veces aprendes más sobre alguien cuando haces que alcancen sus límites. Es por eso que muchos cursos universitarios aumentan la dificultad y luego califican en la curva. Si todos obtienen un 100% en cada examen, dejarán mucho potencial de aprendizaje.

Mi candidato ideal probablemente realizaría primero el cálculo de la complejidad, decir "Oh, eso es solo 6 millones de iteraciones, lo que no tomará mucho tiempo", luego escribir rápidamente la solución de fuerza bruta. Luego, analizarían los enfoques que podrían tomar 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 proyecto de euler que surgen en el mundo real son problemas de un solo disparo que debe resolver una vez y luego olvidarse de ellos. Quiero saber que alguien que yo contrate podrá reconocer un algoritmo de fuerza bruta que toma 2 minutos para escribir y 10 minutos para ejecutar es más eficiente que un algoritmo que toma 3 horas para escribir y 10 segundos para ejecutar, si solo necesita para ejecutarlo esa vez.

Como gerente de contratación, si te pido que resuelvas un problema con el código justo delante de mí, no lo estoy haciendo tanto para ver el código en sí (aunque es importante), sino para determinar el cómo y por qué hiciste lo que hiciste Una de esas cosas que podrías hacer es el código no , y en cambio me interrogas sobre los aspectos del problema en sí, para resolverlo mejor. Eso es significativo para mí, y generalmente es más significativo que la solución que figura 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 les pido a las personas que programen una entrevista en una entrevista, pero sí pongo los problemas en la mesa y hablamos a través de ellos y, a veces, surge un pseudocódigo) , lo cual 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 otra, en ese entorno y con esas limitaciones, y es por eso que las entrevistas que entienden que normalmente no buscan el código Solución (aunque, de nuevo, eso juega un papel importante), sino el proceso de solución .

"¿Hay una regla como después de 20 minutos, simplemente deberías comenzar a programar sin importar qué?" Yo respondería esto diciendo que dentro de un tiempo muy corto de pensar en el problema, deberías al menos esté haciendo algo : haga más preguntas, dibuje un marco para una solución o diga que simplemente no puede hacerlo / no sabe por dónde empezar.

Si le pongo un problema difícil y la solución que me brindó, dadas las limitaciones de tiempo y lo que tiene, fue fuerza bruta y fea, le haría una serie de preguntas sobre por qué fue eso. El caso, y qué 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 con lo que no has hecho, y poder explicarlo de manera racional, es una gran ventaja. Estrella de oro en mi libro, pero ese es el tipo de desarrolladores que busco. Por lo tanto, "la excelente comprensión de los problemas y los caminos hacia una solución elegante" también funcionaría para mí, pero no para todos.

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

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

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

Observa a alguien escribir código suficiente y discutirlo, y puedes averiguar si son adecuados para el trabajo.

  

¿Existe una regla como: después de 20 minutos, deberías comenzar a codificar sin importar qué?

No, pero si dedica 20 minutos a analizar el problema antes de ponerse a trabajar, probablemente ya esté en problemas. Un empleador que le haga una pregunta como la que mencionó está más interesado en cómo aborda un problema, pero si lo hace como un problema de codificación también querrá ver un código. Háblalas a través de tu 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 correr.   A través de todas las combinaciones de dos puntos y el origen buscando.   triángulos rectos. Eso no debería ser difícil, puedo escribir una función que   usa el teorema de Pitágoras para identificar triángulos rectángulos. Para hacer eso   Más fácil, también escribiré una función que determina la distancia.   entre dos puntos usando la fórmula de distancia ...

Escribir esas funciones debería tomar unos tres minutos. Ahora, solo unos minutos después 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:

  

Por lo tanto, obviamente podríamos poner la función isRightTriangle(p1, p2, p3)   en medio de cuatro for se repite y repite todo lo posible   Opciones para cada uno de los dos puntos variables. Veamos ... el problema   pregunta por el número de triángulos rectángulos, incluido el origen en un 50x50   rejilla, por lo que usar el método de fuerza bruta nos hace verificar 50 posibilidades   para cada coordenada de cada punto. Eso es 50 ^ 4 cheques ... Estoy seguro de que podemos   hazlo mejor, pero el código es obvio, así que déjame escribirlo ...

Así que ahora escribes una función que usa for loops anidados y la función isRightTriangle() que acabas de escribir. Ha resuelto el problema, pero también ha dejado que el entrevistador vea a dónde va. Si su objetivo era solo ver que puede escribir código, es posible que le pidan que se detenga. Lo más probable es que estén contentos de estar hablando con alguien que sabe lo que están haciendo y querrán ver hasta dónde se lleva esto. Así que sigues ...

  

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

Y así sucesivamente. Una vez más, normalmente 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 de arriba, solo contar con la confianza para pensar en voz alta contará mucho. No te preocupes si cometes un error. Solo di "hmmm, creo que me he salido de las vías aquí. Déjame retroceder un paso ..."

Como gerente, si te pido que codifiques como prueba, lo que más me interesa es:

• Si puedes escribir código
• Su estilo de codificación
• El algoritmo que seleccionó
• ¿El intento indica que entendiste el problema?
• Si estoy realmente entusiasmado con una tecnología específica, ¿has demostrado que más o menos lo sabes?

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

Estilo de codificación: con eso no me refiero solo a dónde colocas tus llaves, sino a cosas como:

• ¿Escogiste la composición o la herencia para resolver ese problema? ¿Por qué?
• Para ese valor, ¿por qué eligió usar una enumeración frente a una cadena frente a un int (o la permutación que corresponda)?
• ¿Usó propiedades, campos o métodos de obtención / configuración 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 los parámetros del idioma (¿qué es ref por valor?)
• ¿Sabes cómo escribir pruebas unitarias?

Esto es lo que realmente no importa:

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

Honestamente, nunca fui muy fanático de las pruebas de codificación, excepto como herramienta para analizar el estilo.

En ese caso, avanzar hacia una solución elegante es mejor que una solución peor pero completa. Aunque ambos casos son buenos. Está absolutamente bien haber escrito pusdocode demostrando que usted entiende el problema y cómo intenta resolverlo, incluso si no tuvo tiempo para codificar el programa.

Creo que estás haciendo una pregunta para la cual 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 busque que algo funcione rápidamente y luego se optimice 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 en el algoritmo más sexy y elegante, y lo toma como una señal de debilidad de que alguna vez haya puesto las palabras "brutal" y " fuerza "dentro de 5 palabras una de la otra. También es posible que el entrevistador buscara en Google "preguntas de la entrevista" y encontró este problema en Internet 5 minutos antes de ingresar y no tenga idea de lo que quiere.

En todos los casos, lo mejor que puede hacer 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 preguntas o incluso preguntas que tengan sentido. Una entrevista es una actividad inherentemente reduccionista, muy parecida a las "citas rápidas" en las que pasa una o dos horas con alguien y ustedes dos intentan adivinar, en función de esa hora, si trabajarán bien juntos para la próxima 5 años o no. Examinado desde esa perspectiva, espero que esté más claro por qué digo que realmente no hay respuesta a su pregunta sobre una "regla".

Alguien le está haciendo una pregunta que ellos creen que le dará una idea de su competencia y se ajustará a su equipo. Debe observar su equipo, lo que sabe de ellos, la personalidad del entrevistador y muchos otros factores, y hacer una mejor estimación de qué respuestas, enfoque y proceso es probable que valoren. Personalmente, diría que deberías enfocarlo de la manera que crees que es la mejor idea. Si no están de acuerdo contigo, podría no haber terminado siendo un buen ajuste de todos modos, es más fácil darse cuenta de ello 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 logras encontrar una solución ideal, todavía tienes algo que mostrar.