¿Por qué las entrevistas de programación a menudo implican preguntas que solo se pueden resolver de manera eficiente utilizando algún algoritmo de conocimiento previo?

Su pregunta es esencialmente preguntar: “ ¿Por qué necesito entender los métodos estándar utilizados en mi industria, en lugar de limitarme a ellos cuando abordo los problemas? ”

Si un estudiante de física se quejara de la necesidad de aprender cálculo para estudiar física y dijera que no debería hacerlo, ¿comprarías ese argumento? ¡Pero caramba, el cálculo es difícil y le tomó mucho tiempo y energía a algunas personas muy inteligentes! Realmente, muchos problemas de física son un poco injustos, si no conoces el cálculo.

En los detalles de su pregunta, menciona que se le preguntó el algoritmo de tortuga y liebre. Para ser justo con usted, su entrevistador no debería haber esperado que lo supiera. Ese algoritmo en particular no ve mucho uso práctico y, en el mejor de los casos, prueba su conocimiento de la programación, no su capacidad de programación. Comprueba si has leído lo suficiente como para haber leído sobre el problema. No creo que sea una muy buena prueba. Tu entrevistador la jodió.

Dicho esto, lo que sucedió no justifica su línea general de razonamiento aquí. Hay ciertos algoritmos fundamentales, ampliamente conocidos y ampliamente utilizados que solo se espera que conozcas , incluso si esos algoritmos fueron muy sorprendentes y no triviales cuando se inventaron por primera vez.

La dificultad de adquirir este conocimiento es parte de la razón por la cual, como ingeniero de software, es posible que le paguen seis cifras (algún día, si no ahora). Si este campo fuera fácil, mucha más gente estaría en él, y no habría una gran oportunidad para repasar, acertar la entrevista y ganar mucho dinero en un trabajo intelectual gratificante.

No es necesario que conozca un algoritmo bien establecido y la gente que dispara y afirma que las entrevistas apestan porque tales cosas suceden simplemente están mal.

En una entrevista, no se espera ni se requiere que demuestre algoritmos súper eficientes o un vasto conocimiento de algoritmos bien conocidos.

Tortuga y liebre podrían ser una pregunta perfectamente válida, pero en realidad solo si el entrevistado no conoce el algoritmo de antemano . Dado que es una pregunta bien conocida, eso lo hace malo, porque el objetivo de la entrevista es recopilar datos sobre la capacidad de las personas para codificar, razonar, improvisar, hacer una lluvia de ideas, etc. y si obtienes una solución pre-masticada, la entrevista no tiene valor.

Ahora, teniendo esto en cuenta, la eficiencia tampoco es absolutamente clave. Quiero verte salir por la fuerza bruta de un problema desconocido, luego recoger pistas sobre cómo optimizarlo o adoptar un enfoque completamente diferente, luego reimplementar y luego reiterar.

Entonces, si le pedí que encontrara un bucle en una lista vinculada, proponga cualquier tipo de solución, codifíquelo y haga que funcione y lo tomaremos desde allí. Si le pedí que encontrara una ruta óptima en un gráfico para que cada nodo se visite una vez, no podrá decir “oye, ese es un vendedor ambulante y no puedo hacerlo de manera eficiente, así que me doy por vencido”. No, señor, lo codificará de cualquier manera imaginable y luego tratará de mejorarlo con heurísticas razonables, etc.

Entonces, está pensando que está completamente equivocado: estas preguntas no apestan porque tiene que conocer una solución de antemano. No, tu no. Pero, al ser problemas famosos, la probabilidad de que realmente conozca el algoritmo más eficiente lo convierte en una mala pregunta para la entrevista.

Esta frustración es exactamente el problema comercial no trivial de reclutamiento. Has dado en el clavo directamente en la cabeza.

Para demostrarlo, permítanme recapitular el problema. Imagina que eres Google (sí, la gran cosa) y tienes un problema de maximización: maximiza la probabilidad de que tu empresa gane más dinero del que cuesta contratar a X, dada la condición de que la persona contratada sea X.

Resolver este problema resuelve el problema de contratación. Para resolver esto, observamos un montón de “algoritmos” de contratación o “criterios de selección”, etc. El primer enfoque, y algo ingenuo, es hacerlo de la manera de “hablar con Microsoft antes de la entrevista” (entrevista de Microsoft). candidatos y elegirlos en función de quién mejor “vibra”. Así es como los abogados obtienen sus primeros trabajos legales, es decir, excluyendo los efectos de red. Esto corresponde a que el candidato piense que es casi un 100% de suerte, y es casi toda suerte a menos que sea súper carismático, lo cual estoy seguro de que es, pero esto puede no maximizar nuestra probabilidad de objetivo de ganancias.

El trabajo pionero realizado por Microsoft, según el artículo de Wikipedia, es reemplazar esto con una prueba de codificación con la que la mayoría de las personas en trabajos de codificación están familiarizadas. Aquí es donde debe reconocer que si fuera Google o Microsoft , haría lo mismo. No menos porque esto se correlaciona mejor con la capacidad de codificación y luego (con suerte) de ganancias, sino porque también parece eliminar mejor los prejuicios personales del proceso. Y a pesar de las muchas frustraciones que las personas tienen con el sistema, probablemente sea mucho mejor eliminar los prejuicios personales o inmateriales de lo que pensamos. (Imagine las diferencias psicológicas entre “contratar personas que son excelentes en la codificación” versus “usted ejerce un poder total y total sobre la contratación, haga lo que quiera”)

Pero el problema cambia a qué pregunta hacer. Esta es la parte interesante: porque no solo debemos maximizar la probabilidad de obtener ganancias, ahora tenemos que minimizar el costo de reclutamiento, es decir, el tiempo dedicado. Otras compañías hacen esto al reducir el costo del entrevistador (es decir, solo usan recursos humanos para entrevistar), pero las compañías de tecnología generalmente usan entrevistadores técnicos de mayor costo.

¡Sin embargo! Las ganancias de los codificadores se obtienen a lo largo de la vida del empleo en una empresa (por ejemplo, ¡varios meses en tecnología!), Pero el intervalo de tiempo de la entrevista es muy corto en comparación. Además, la “capacidad” también varía con la duración de la instantánea: un candidato puede parecer bueno cuando se le hacen preguntas breves sobre un API de lenguaje, pero es posible que no pueda desempeñarse de manera sostenida, y un investigador graduado en aprendizaje automático puede no saber lo mismo ¡API de lenguaje para hacer las tareas básicas necesarias para la realización práctica de ganancias!

Entonces, ¿dónde estamos? Es posible que haya pensado que tenía una panacea para este gran problema en la vida corporativa y el mundo corporativo, ¡pero desafortunadamente no! Este problema no puede evitarse mediante una evaluación automática de recuadro negro, no existe una solución de bala de plata que diga “use esta pregunta” (porque si la hubiera, ¿no todos la aprenderían de memoria?)

La solución real es externalizar esto a una empresa que se especializa en la construcción de problemas que detectan o se correlacionan con grandes atributos de codificador corporativo, y se incentiva para ayudar a realizar tanto el potencial total de los candidatos como las empresas. Es un negocio completo, que aún no está debidamente ocupado para el reclutamiento de tecnología de alto nivel.

Si eres un programador que quiere aprender a superar la entrevista de codificación, o una empresa que necesita encontrar codificadores que maximicen los resultados corporativos deseados, o simplemente para ver mi solución al problema: Google Candidacy dot io 😉

Tomaré una conjetura y diré que es porque los empleadores creen que, si está familiarizado con las convenciones y los métodos ya establecidos, será un empleado más rentable. Quieren un buen código rápido, y prefieren pagarle a una persona para que use de manera rápida y eficiente algoritmos que ya están en uso para resolver un problema, que pagar por la investigación y la planificación que se dedica al descubrimiento / creación de nuevos. Algunos lugares en los que vería esta diferencia serían Google, Facebook y otras compañías pesadas de algoritmos que quisieran ver a alguien hacer algo nuevo.

Descargo de responsabilidad: esto no es de ningún tipo de experiencia, solo una corazonada