Recientemente tuve una discusión con un compañero programador. Estaba entrevistando para un nuevo puesto y se le hizo esta pregunta:

Proporcione una secuencia de números que comience en X y termine en Y, pero falta un elemento para que N sea YX-1, encuentre el elemento que falta en O (N) o mejor.

Ahora, la respuesta es irrelevante aquí (pero interesante). Esto comenzó una discusión sobre si era incluso una buena pregunta para hacer durante una entrevista.

Un lado: los algoritmos son una parte heredada de la programación y la capacidad de los candidatos para responder a esta pregunta respalda que este candidato será un buen programador y podrá resolver problemas más grandes y podrá manejar la mayoría de las tareas de programación que en última instancia son fáciles de entender y responder.

Otro lado: la escritura de algoritmos desde cero rara vez se usa en la programación moderna y, por lo tanto, es irrelevante en la gran pregunta de si la persona será un buen programador. Una persona podría responder con éxito a esta pregunta pero aún así no podría realizar tareas de programación más comunes.

¿Tus pensamientos? Buena pregunta de entrevista o no?

Estoy de acuerdo con hacer una pregunta de algoritmo, pero no estoy de acuerdo con insistir en un nivel específico de calidad big-O.

Hacer este tipo de preguntas es interesante para ver cómo la persona aborda el problema y qué dificultades considera en su intento, pero a menos que esté escribiendo algo increíblemente incorrecto o ineficiente, el detalle real de lo que escribe no es tan revelador como el hecho de que superar los pasos de resolución / diseño de problemas de manera coherente.

Hago una pregunta similar, pero las personas con las que he tenido la mejor suerte después de la contratación son las personas que dieron respuestas erróneas pero tenían la idea correcta en su enfoque.

No estoy de acuerdo con la idea de que la capacidad de escribir algoritmos es irrelevante en la gran pregunta de si la persona será un buen programador. Incluso si nunca tiene que usarlo (lo cual es dudoso), todavía muestra si tiene la flexibilidad mental requerida para encontrar una solución lógica a un problema que es más complicado que un simple conjunto de requisitos que ya están escritos y establecidos. en detalle por el cliente.

Definitivamente no quiero contratar a alguien que no sepa cómo pensar y analizar. Eso es lo que hace la diferencia entre un mono de código y un programador de computadora.

Tengo que admitir aquí, que soy uno de los que les gusta hacer preguntas de algoritmos en las entrevistas, pero debo enfatizar que la respuesta real a la pregunta es absolutamente irrelevante. No me importa lo más mínimo si el entrevistado sabe la respuesta o no. En cambio, para mí, esta pregunta se dirige a diferentes aspectos, como los siguientes, en orden de importancia:

Requisitos

Estas preguntas están deliberadamente subespecificadas. En su ejemplo, no hay más detalles sobre la secuencia. Si tiene un entrevistado que le pregunta si estos números están realmente ordenados, entonces es una buena señal. Tiene la mentalidad correcta para preguntar a los clientes sobre más detalles, lo que ayudará a encontrar una mejor solución en menos tiempo. El candidato también puede jugar con la idea de usar el espacio O (n) para almacenar una matriz de N números, pero no debe hacerlo sin preguntar sobre más detalles sobre X e Y. Digamos que X e Y están entre 1 y 1000 , entonces seguro, adelante y encienda una solución basada en una matriz. Pero si te digo que el intervalo es de 1 y 1 billón, entonces el problema se vuelve totalmente diferente. Permítanme enfatizar nuevamente que no me importa la solución.

Técnicas estándar

No quiero contratar a un programador que ni siquiera sabe lo que significa O (n). Es absolutamente imprescindible saber si tuvo alguna educación decente en esa área. Pero también es importante no solo saber lo que significa, sino aplicar ese conocimiento. En su ejemplo, quiero que un candidato se dé cuenta de que no se le permite ordenar los datos (sin hacer más preguntas sobre la opción de una clasificación de cubeta u otros enfoques de clasificación O (n)) debido a la clasificación requerida O (n log n) en general.

Del mismo modo, otras preguntas sobre algoritmos se dirigen a técnicas estándar como el recorrido de árbol o gráfico, o recursividad. Un candidato puede resbalar en una de estas técnicas, lo que no causa una buena impresión. En tales casos, sin embargo, me gusta profundizar más para averiguar si el candidato tiene antecedentes de CS. Por supuesto, depende de cuál sea la posición de destino, pero generalmente un desarrollador que no conoce las complejidades del tiempo de ejecución, ni las estructuras de datos típicas y sus recorridos, no será de ninguna ayuda.

Mentalidad para resolver problemas

Después de hacer la pregunta, monitorea al candidato de cerca. ¿Cómo reacciona? Aquí obtienes los mejores resultados de candidatos que no tienen ni idea de cómo resolver el problema al principio . En ese sentido, la pregunta verifica qué podría suceder si una situación similar ocurre en el lugar de trabajo más tarde. Es posible que se encuentre con un problema de este tipo durante su desarrollo, y es bueno saber cómo su candidato aborda estos problemas, incluso si no es capaz de resolverlo por sí solo.

Ejemplo: ¡No desea que su candidato entre en modo silencioso durante la próxima media hora! Verifique si puede formular preguntas inteligentes (ver Requisitos), verifique si comienza a pensar fuera de la caja una vez que se da cuenta de que no puede hacerlo. Incluso una contrapregunta "divertida" como "¿Puedo usar la opción de teléfono como compañero de trabajo?" Es una buena señal.

Cómo responder

En general, las mejores respuestas que puede dar para este tipo de preguntas son contrapreguntas. Decir una respuesta de inmediato básicamente falla todo, y de hecho no es una buena respuesta en absoluto, porque todas estas preguntas apuntan a compensaciones, lo que su respuesta implica, sin que usted tenga la información requerida aún para hacer eso de manera inteligente. compensación. Por supuesto, la calidad de las contrapreguntas varía entre los candidatos.

Como nota general sobre las preguntas de la entrevista: las contrapreguntas rara vez son algo malo. En una de mis propias entrevistas, por ejemplo, me preguntaron algo como lo siguiente: "Si tuviera que implementar X, ¿elegiría C ++ o Java para eso, y por qué?" - Simplemente respondí con "¿Estoy limitado a estos dos?". Adivina por ti mismo, qué tipo de reacción obtienes de un entrevistador para tal contra-pregunta, y qué tan fácil te resulta mostrarle al entrevistador de lo que eres capaz.

A menos que haga preguntas sobre algoritmos / fórmulas que el candidato necesita saber para el trabajo (dinámica de fluidos, por ejemplo, si el puesto lo requiere), no veo su valor. Es probable que el candidato ya esté preocupado por cómo están vestidos, cómo están hablando, etc., si pueden responder una pregunta de matemáticas en el acto no prueba otra cosa que no sea cómo les irá en un programa de televisión.

Cuando entrevisto, ni siquiera hago preguntas de 'programación' per se. Le pido al candidato que describa sus proyectos anteriores, cómo su código logró los objetivos, cuáles son sus enfoques, etc. A partir de eso, puedo decir con bastante rapidez si el candidato sabe lo que está haciendo o si es un poser.

Estoy de acuerdo en que los programadores deben conocer muy bien los algoritmos, incluso con nuevos marcos sofisticados, pero no estoy totalmente convencido de un desafío para la mente en una entrevista. Mi mayor preocupación sería que en un entorno real, escribas algoritmos en condiciones muy diferentes; aka, no bajo presión con alguien mirándote cada golpe, con al menos varios minutos para pensarlo en silencio. Para aquellos que abogan por este método de evaluación, ¿cuánto tiempo le das generalmente a la persona para que lo resuelva? Creo que el código no se trata tanto de encontrar una solución en un terror febril de 3 minutos, así que convénceme de que esta es realmente una buena manera de ver cómo alguien manejará una tarea cotidiana.

El problema con esa pregunta específica es que es casi una pregunta capciosa. Con una idea particular, fácilmente obtendrá O (n), de lo contrario tendrá dificultades para mejorar que O (n log n). Casi se reduce a "¿Has visto este antes?"

No estoy seguro de que haya buenas preguntas algorítmicas. Si le pregunta a uno basado en la teoría de gráficos, digamos, dependería de cuán familiarizado esté el entrevistado con la teoría de gráficos, y, si lo contrata, él o ella podría ponerse al día con la teoría de gráficos con bastante rapidez. Nuevamente, volvemos a "¿Has estado expuesto a esto antes?"

No hay tiempo en una entrevista regular para resolver problemas serios, y abordo las cosas de manera diferente cuando puedo sentarme, usar Wikipedia y, en general, tomarme un tiempo para resolver las cosas. Probablemente no haya tiempo para que el entrevistador discuta cuidadosamente lo que el entrevistado sabe en detalle y elija una pregunta algorítmica adecuada.

Tengo varias preguntas similares a algoritmos que uso regularmente, algunas de las cuales son muy difíciles. Los uso para ver cómo atacan mentalmente un problema y para ver si asimilan ciertos conceptos. (He visto demasiados candidatos desarrolladores que simplemente no entienden los punteros).

Desea una pregunta que le dará una idea del candidato. Una pregunta de algoritmo puede dar una buena respuesta, o puede que no. Y no me refiero a que puedan responderlo o no. Si lo resuelven y usted comprende y sigue su razonamiento, ese es un buen indicador. Si simplemente se sientan allí, no hay una respuesta real, ni siquiera parecen saber por dónde empezar, ese es un mal indicador (tal vez). El problema sería que algunas personas se congelan y puede ser difícil diferenciarlo de no tener habilidades para resolver problemas.

La gente se quejará de preguntar cualquier cosa en las entrevistas, por varias razones. El solicitante puede congelarse, el solicitante podría haber buscado esa pregunta, el solicitante puede no conocer esa particular pieza de trivia / tecnología / lo que sea. Todo esto es cierto, pero aún debe realizarse una entrevista, y muchos de nosotros en esta profesión odiamos eso. Odiamos la idea de que alguien nos juzgue. Inmediatamente evocamos razones por las cuales podríamos ser juzgados injustamente, o cómo la prueba podría ser falsa o mimada. La conclusión es que no importa.

Lo que realmente quiere es un entrevistador con la capacidad de determinar las habilidades que pueden presentarse o no durante la entrevista. Las preguntas son solo las herramientas. Para mí, todos los martillos se ven iguales. Pero para alguien lo suficientemente hábil con ellos, estoy seguro de que hay una diferencia.

Me gustan las preguntas sobre algoritmos, porque es lo que hacemos. Me gustan las restricciones, porque es lo que usamos. Big-O es especialmente relevante en mi industria.

No me gusta exigir que las respuestas a este tipo de preguntas sean "escribir el código en la pizarra". El entrevistado debe poder hablar de manera inteligente sobre el enfoque de la solución y participar en una discusión continua a medida que los entrevistadores cambian los requisitos mientras la discusión está en curso.

La pregunta original se hace, dice el entrevistado, "comience desde el principio y marche hacia el final buscando el 'agujero'". El entrevistador dice que es demasiado lento, porque N es gigantesco. El entrevistado comienza a discutir la búsqueda binaria. El entrevistador dice que, de repente, los datos ya no se ordenan. El entrevistado dice "ordenar luego buscar". "Ahora es demasiado lento". Etcétera etcétera.