¿Por qué las empresas tecnológicas basan las entrevistas en preguntas de codificación y algoritmos donde los entrevistados que han visto la pregunta obviamente obtendrán mejores resultados?

Esa es una pregunta que la gente hace con bastante frecuencia y es legítima. Sin embargo, hay algunos aspectos del formato de entrevista actual que las personas tienden a pasar por alto.

En primer lugar, no es tan probable que alguien que simplemente memoriza soluciones de problemas reciba una pregunta, que discutirá sin problemas.

Imagínese esto: un candidato que no es lo suficientemente bueno memoriza muchas soluciones de problemas. Va a una entrevista y consigue una de ellas. Luego escupe la solución y logra codificarla correctamente.

Lo más probable es que el entrevistador quiera saber sobre el tiempo y la complejidad de la memoria. Por lo general, también les gusta tener una discusión. Si el candidato tiene malas posibilidades es que no podrá discutir cosas fuera de la solución misma. Además, a veces a los entrevistadores les gusta torcer un poco las cosas en la declaración del problema. Si el candidato hace frente a todo eso, tal vez no sean tan malos después de todo.

Un entrevistador generalmente quiere ver el proceso de pensamiento de un candidato. Si la solución se memoriza, es probable que esto sea obvio en algún momento.

En segundo lugar, un candidato pasa por varias entrevistas. ¿Qué posibilidades hay de que obtengan la mayoría de ellos con respuestas memorizadas?

En Google, por ejemplo, es muy probable que un candidato tenga que resolver una pregunta de diseño de sistema de algún tipo. Estos son muy abiertos y requieren una discusión entre el candidato y el entrevistador. Es difícil memorizar este tipo de cosas. La discusión podría seguir muchos caminos diferentes.

En cuanto a esta parte de la pregunta:

“Esto básicamente significa que memorizas una lista de las preguntas típicas, que es lo que hace la mayoría de las personas que ingresan a Google / Facebook / Amazon o que pasas para siempre en sitios como Project Euler y Top Coder con el mismo propósito”.

No estoy seguro de que esto sea correcto. Nadie que conozco que trabaja en Google hizo esto. Por supuesto, mi muestra no es representativa, pero como dije anteriormente, para tener altas posibilidades de responder preguntas que conoces en la mayoría de las entrevistas, debes cubrir MUCHAS preguntas.

Con respecto a la parte de TopCoder / Project Euler: sí, sugeriría pasar tiempo en sitios como ese, pero no con el propósito de memorizar cosas. Al practicar en problemas reales, realmente aprende a resolver cualquier problema. Esto crea un proceso en tu cabeza, te enseña estrategias.

Un detalle importante al practicar para las entrevistas: hacerlo en papel o en una pizarra. Esto es lo que se espera que se use en una entrevista real. Confía en mí, es muy diferente a usar un IDE.

Dicho todo esto, no estoy defendiendo el formato actual de la entrevista. Solo digo que no es tan inútil como sugiere la pregunta. Especialmente, si obtienes un entrevistador experimentado, sabrán cómo separar al candidato bueno del malo.

Por supuesto, hay entrevistadores menos experimentados y los errores pueden y sucederán. Todo lo que tienes que hacer es trabajar duro, practicar mucho y tendrás muchas posibilidades de entrar. No te molestes con los otros tipos que memorizan cosas. 🙂

Esperemos que eso motive a las personas a seguir el camino correcto para aprender cosas, desarrollar nuevas habilidades y convertirse en un mejor candidato en su conjunto, en lugar de unirse al lado oscuro de memorizar toneladas de cosas. 😉

Estoy realmente en contra de este sistema de contratación de mierda. Realmente no vemos algoritmos difíciles en nuestro trabajo diario tan a menudo. De hecho, es muy común ver CERO la pregunta del algoritmo difícil en un año entero. Entonces, ¿cuál es el punto de preguntar algo que los candidatos no usarán en su trabajo diario y usarlo para “filtrarlos”? Creo que el propósito de la entrevista es averiguar qué tan bien les irá a los candidatos en el trabajo diario cuando son contratados, por lo que queremos hacerles preguntas que estén tan cerca de lo que realmente hacemos en nuestro trabajo diario como posible, no es algo que rara vez o nunca vimos.

Es muy razonable pedir algoritmos sencillos, como revertir una lista vinculada en una entrevista, porque es mucho más probable que ese nivel de preguntas sobre algoritmos ocurra en el día a día. ¿Pero para preguntas difíciles sobre algoritmos? Definitivamente no. No los necesita en el trabajo diario, entonces, ¿por qué molestarse en preguntarles? Y muchas compañías incluso SOLO hacen preguntas difíciles sobre algoritmos durante la entrevista. Alguien lo defenderá como “queremos ver cómo aborda la pregunta”, pero de hecho todos esperan que el candidato presente una solución óptima y libre de errores en muy poco tiempo, lo que no es posible para alguien que Acabo de ver este problema por primera vez. La forma en que el candidato aborda el problema no es importante en absoluto, si no puede encontrar la solución óptima lo suficientemente rápido. Entonces, se convierte en quien memorizó suficientes algoritmos y vio que este pasa la entrevista. ¿Pero memorizar y ver más preguntas sobre algoritmos equivale a un mejor ingeniero? No, y en muchos casos eso es incluso lo contrario porque no son capaces de escribir códigos mantenibles y de buena calidad con un buen diseño, que la entrevista del algoritmo no descubre. Y, hay muchas formas de saber cómo el candidato aborda una pregunta, y todas requieren diferentes habilidades, entonces, ¿por qué algoritmo? ¿Por qué no el diseño del sistema, el diseño del código y las compensaciones entre diferentes diseños?

Otras personas lo defienden como si fuera el fundamento de la informática. Sí, pero hay otros fundamentos de la informática, y no se les pregunta. Y de nuevo, realmente solo necesita poder resolver las tareas fáciles para realizar el trabajo diario con gran calidad. En la mayoría de los casos, no necesitas los difíciles. Incluso cuando lo necesite, es probable que pueda encontrar una solución óptima en Internet en 5 minutos.

Otras cosas como OOP, diseñar el código para que se pueda mantener, depurar, refactorizar, desarrollo basado en pruebas, patrones de diseño, diseñar el sistema, son al menos tan importantes como las preguntas de algoritmos difíciles en el trabajo diario, y muy probablemente más importantes. Haré esas preguntas en una entrevista si soy el entrevistador. En lugar de hacer preguntas difíciles sobre algoritmos, haré:

1. Una pregunta de algoritmo fácil para filtrar lo malo
2. Dé un código, tal vez cien líneas con varios métodos, y pídale al candidato que señale el problema en el diseño y cómo puede mejorarlo. Le pediré que muestre cómo lo mejorará en IDE.
3. Una vez que haya terminado, pídale que agregue una nueva función al código existente. Pídale que lo haga con un desarrollo basado en pruebas.
4. Pídale al candidato que escriba un pequeño programa que se pueda hacer en 150 ~ 200 líneas de códigos. No hay algoritmo difícil involucrado. El candidato puede usar el algoritmo de fuerza bruta para todo si realmente hay un algoritmo involucrado. El propósito es ver cómo el candidato puede diseñar y escribir código de calidad y su estilo de codificación.
5. Pídale al candidato que diseñe un sistema en la pizarra.
6. Haga algunas preguntas en profundidad sobre el idioma principal del candidato. Sí, los idiomas se pueden aprender con bastante rapidez, pero si el candidato ni siquiera domina en su idioma principal, ¿cómo puedo esperar que domine otros idiomas rápidamente?

Porque

1. Casi siempre funciona filtrar a las personas con insuficiente capacidad de programación (he tenido uno o dos falsos positivos de docenas de personas contratadas en los últimos veinte años) para hacer su trabajo.

2. Funciona en un tiempo razonable. Puedo hacer tres preguntas de codificación / estructura de datos en 20 minutos con candidatos que probablemente entrenarán y todavía me quedan 40 minutos de una hora de entrevista para calibrarlos en funciones de nivel superior y presentar a la compañía, el equipo y el puesto.

3. Dado que hacer las mismas preguntas funciona tan bien, no sería un buen uso de mi tiempo (los buenos usos de mi tiempo ayudan a ganar nuevos clientes y reducir costos) para inventar nuevas preguntas de forma regular, especialmente porque no tendría calibración sobre cómo serían manejados por un grupo de solicitantes.

4. Omitir preguntas de programación simples por completo no funciona. Cuando se descartó la contratación, esperaba que los empleados hicieran menos trabajo que otros en el grupo; pero descubrió que su contribución era realmente negativa, lo que requería más esfuerzo para ayudarlos a hacer sus tareas o corregir los resultados que simplemente hacer el trabajo yo mismo.

En un mundo perfecto, las personas no se graduarían con títulos en informática si no pudieran programar. En este mundo imperfecto que sucede. Tuve un profesor de estructuras de datos que calificó en función de qué tan bien funcionaba el código de los estudiantes cuando se vinculaba con el asistente de enseñanza desarrollado suites de pruebas automatizadas. Supuestamente 1/3 de la clase falló. Todas las personas que entrevisté que pasaron por la misma clase pudieron programar. El departamento decidió que no era bueno, reemplazó al profesor y nuestra tasa de rechazo en la industria fue fácilmente del 50% de los recién graduados. Supongo que se trataba de retener más dólares de matrícula fuera del estado para el departamento y me entristece, pero no me sorprende ver que otras escuelas se gradúen de esas personas.

Estas personas todavía parecen llegar lejos en la industria con currículums lo suficientemente impresionantes. Supongo que es porque sus compañeros de trabajo hacen la mayor parte del trabajo y entienden lo suficiente como para explicarlo como propio.

Pueden decir lo contrario, pero si te tomas un tiempo para resolver una pregunta o luchas sin pistas, lo que obviamente harás si nunca has visto una pregunta y no quieres tomarte más tiempo ya que la entrevista es de 30 a 45 minutos, eres definitivamente un no o en el fondo de la pila en relación con alguien que lo consiguió de inmediato.

Mi experiencia de más de 20 años en la industria es que la gran mayoría de estas preguntas son fáciles para las personas con aptitud para la programación, ya sean pasantes de verano que aún no se hayan graduado o veteranos de 30 años. Solo unas pocas personas hacen preguntas que requieren saltos lógicos / matemáticos en los que los ingenieros competentes que no hayan visto el problema antes no puedan encontrar buenas respuestas.

Si algo como invertir una cadena (<5 minutos para buenos candidatos) o una lista vinculada (<10 minutos) sin almacenamiento adicional significativo es difícil, probablemente sea mejor no trabajar en puestos donde la capacidad de hacer tales cosas es un criterio de contratación ya que los problemas que se espera que resuelva serán más difíciles y la presión probablemente sea mayor (he trabajado con ejecutivos que hicieron llorar a hombres adultos, ingenieros que renunciaron debido a los terrores nocturnos inducidos por el horario y algunos ingenieros que abandonaron el negocio por completo después de una muerte marzo)

Básicamente, esto significa que memorizas una lista de las preguntas típicas, que es lo que hace la mayoría de las personas que ingresan a Google / Facebook / Amazon

Dudo que.

Trabajé como SDE3 en Amazon en tres grupos. Las personas con las que trabajé eran lo suficientemente competentes como para no necesitar memorizar una lista de preguntas típicas. La barra de contratación fue similar a los otros grupos para los que he trabajado como empleado en los últimos 20 años, conozco a muchas de esas personas mucho mejor ya que hemos compartido hasta tres nuevas empresas, no memorizan preguntas y Nunca vi ninguna indicación de que mis compañeros de trabajo de Amazon fueran diferentes.

No estoy seguro de qué entrevistas técnicas ha estado viendo, pero la mayoría de mis preguntas de entrevistas técnicas han consistido en responder una pregunta, reconocer las compensaciones de los diferentes enfoques para responder la pregunta y luego trabajar en variantes interesantes del problema.

Para comentar su descripción del Proyecto Euler y TopCoder, el Proyecto Euler es un sitio con muchos problemas matemáticos interesantes, la gran mayoría de los cuales nunca se preguntarían en una entrevista técnica porque son muy difíciles de hacer en unas pocas horas para la mayoría de las personas. . Del mismo modo, los problemas en TopCoder abarcan una amplia gama de dificultades, desde problemas muy fáciles para programadores principiantes hasta problemas que desafían incluso a los mejores programadores de competición. Nadie se ha vuelto bueno en TopCoder simplemente memorizando soluciones, porque eso no tiene ningún sentido. Los problemas en TopCoder se revisan y se supone que son originales. Convenientemente, las personas que obtienen buenos resultados en este tipo de cosas tienden a desempeñarse mucho mejor en entrevistas técnicas (vea la pregunta ¿Por qué los programadores en las entrevistas de trabajo de ingeniería de software son evaluados en habilidades similares a un concurso de Topcoder, independientemente del hecho de que las habilidades requeridas en ¿La industria es completamente diferente?), pero la mayoría de las veces, es probable que desee contratar a alguien con fuertes habilidades para resolver problemas como lo demuestran estos concursos.

No debe romperse ningún sistema razonable de entrevistas haciendo que un estudiante memorice una lista estándar de preguntas de entrevistas. Es posible que pueda superar una entrevista técnica de primera ronda al memorizar soluciones, pero eso no es realmente un problema (esa es la razón por la que se realizan varias rondas de entrevistas). Las entrevistas de la ronda final deberían ser más completas, y lo son. Las compañías me rechazaron en las rondas finales a pesar de resolver sus problemas algorítmicos más difíciles muy rápidamente, y las compañías que me han hecho varias preguntas de diseño abiertas me han aceptado. La mayoría de las empresas que me entrevistaron el año pasado ofrecieron preguntas de primera ronda que estaban orientadas al diseño.

Si tuviera que responder su pregunta directamente, diría que es porque ese tipo de preguntas son fáciles de hacer y de evaluar. ¿El entrevistado obtuvo la solución óptima? La respuesta es sí o no. Con una pregunta de diseño, es mucho más abierto y no está tan claro cómo evaluar el desempeño del entrevistado. Si un entrevistador está haciendo una gran cantidad de entrevistas, es más fácil hacer entrevistas con ese estilo. ¿Es eso ideal? Probablemente no. Por otra parte, si su entrevistador pasara mucho tiempo haciéndole preguntas, ¿cómo haría su entrevistador para hacer algún trabajo?

Porque funciona

Más o menos. Lo que está sucediendo puede ser ligeramente diferente de lo que supone la pregunta, pero en general esto funciona bien.

Hay 3 cosas que importan al contratar para un puesto técnico:

1. ¿Eres lo suficientemente inteligente ?

2. ¿Te haces cosas ?

3. ¿Es usted una buena cultura adecuada ?

Las preguntas técnicas de codificación tienen que ver con “¿eres lo suficientemente inteligente?”. Estás tratando de eliminar a las personas que no son lo suficientemente inteligentes (en el contexto de la posición técnica). Un número sorprendentemente grande de personas falla cuando se les hacen preguntas fáciles sobre acciones, como invertir una lista vinculada, invertir una cadena, convertir una cadena en un número entero, probar si una cadena es una subcadena de otra, etc. No, en realidad, una gran cantidad de la gente falla Algunos fallan al no saber cómo describir la solución. Muchos más fallan al poder describirlo vagamente pero al no poder codificarlo. Si ha aprendido a codificar pidiendo mucha ayuda de TA, compañeros de cuarto, Google, y realmente no entiende cosas, este estilo fácil de entrevista lo expondrá.

Pero no me encantan las preguntas de codificación anteriores porque si bien son excelentes para separar lo malo de lo bueno, eso no es lo que quiero hacer. Me gustaría que mi entrevista separe lo bueno de lo excelente, que tiene un punto de corte y calibración diferente. Pero tiene valor cortar lo malo rápidamente y no perder el tiempo de todos (incluido el entrevistado).

También es beneficioso hacer la misma pregunta a muchas personas, ya que conoce el rango de resultados, qué sugerencias son útiles y qué tan bien lo ha hecho la persona.

Personalmente, hago las mismas 2 preguntas a la gran mayoría de mis candidatos (no son tan comunes en la naturaleza, pero tengo que elegir otras diferentes si alguien más las hizo en el bucle). Elegí mis preguntas de las 2 mejores preguntas de entrevista que me hicieron cuando entrevisté en muchos lugares diferentes que salían de la universidad. Además, exijo una hora para espacios de entrevista.

Una de ellas es una pregunta de algoritmo muy fácil de resolver en la que estoy buscando explícitamente diferentes soluciones (en lugar de la solución más óptima). Obligo al entrevistado a encontrar múltiples soluciones y compararlas, y especifico las restricciones al principio para que cualquier solución que brinden no sea “la solución óptima” bajo las restricciones completamente especificadas. No le pido a la gente que codifique en esta pregunta, solo para pensar en voz alta y encontrar muchas soluciones diferentes (al menos 3 en las que estoy pensando desde el principio y voy a insinuar, pero hay docenas más). Siempre estoy contento cuando escucho una solución completamente nueva para mí. Lo cual es raro haber preguntado a cientos de candidatos, pero ciertamente me da “puntos de bonificación”.

El segundo es engañosamente difícil (mucho más difícil que las preguntas sobre acciones que enumeré anteriormente) y obliga a codificar con punteros y árboles y recurrencia. La pregunta es lo suficientemente difícil como para que si tiene que pensar en la sintaxis y en cómo programar y cómo funcionan los punteros o la recursión mientras está pensando en el algoritmo, probablemente esté en problemas. Pero si se trata de una segunda naturaleza, el algoritmo es complicado, pero puede resolverse en 15-30 minutos. Especialmente si le insinúo o le doy un codazo a la persona (un poco está bien, ya que está ayudando a depurar un error menor; es muy probable que muchas insinuaciones resulten en una no contratación, pero es posible con un candidato con dificultades).

En ambos no estoy evaluando llegar a una respuesta lo más rápido posible (aunque rápido y correcto es bueno en el segundo y rápido y creativo y correcto es bueno en el primero). Principalmente estoy evaluando cómo piensas sobre los problemas. Obtener una solución correcta es sin duda una gran parte de eso. Pero también lo son preguntas como: ¿Cuáles son sus suposiciones o preocupaciones? ¿Puedes pensar en múltiples soluciones? ¿Cómo evalúa mentalmente las ideas que son proto-soluciones que pueden o no conducir a una solución? ¿Salta al código o piensa en algoritmos y datos de muestra (y qué datos de muestra)? ¿Cómo depuras mentalmente tu código? ¿Qué tan defensivo es tu código? ¿Piensas en casos extremos? ¿Cuál es tu estilo de codificación?

La parte no técnica de la entrevista trata de llegar al “¿haces las cosas?” Y “¿eres un buen candidato cultural?”. Para el primero, a menudo mira el currículum, el proyecto de codificación, las referencias y pregunta sobre ejemplos pasados. Para este último, puede ser específico de la empresa, pero casi siempre incluye un aspecto de “me gustaría trabajar con esta persona”.

Pero la pregunta más importante es la primera (también la que reduce el mayor porcentaje de candidatos, al menos cuando se le pregunta secuencialmente es la mayor fuga de embudo). Porque la peor contratada (al menos en una empresa de tamaño decente) es la que falla 1 pero oscila 2 y 3 porque entonces tienes a alguien que a todos les gusta, que propaga rápidamente el caos de mala calidad, y como Drew Eckhardt señaló que obtienes un gran contribución negativa Si falla 2, pero pasa 1 y 3, obtiene una persona básicamente inofensiva pero ineficaz (un pensador, no un hacedor). Fallar 3 debería ser fatal en todas partes, y sin duda es la peor contratación en una pequeña empresa, pero en una gran empresa si rockea 1 y 2 pero falla 3 probablemente al menos contribuirá con un producto de trabajo positivo por un tiempo hasta que se desencante y / o tus defectos culturales se vuelven demasiado difíciles de manejar. Pero sí, ¡no contrates a alguien a menos que pasen las 3 preguntas!

Dividamos esto en dos:

1. ¿Por qué hacer preguntas de codificación / algoritmos?

¡Ni siquiera están relacionados con el trabajo!

Mucho se ha escrito sobre esto. Vea esta respuesta de Quora para una perspectiva profunda.

En resumen, la cultura actual de preguntas de codificación y algoritmos en las entrevistas existe, no porque sea la mejor manera de entrevistar, sino porque es la forma más conveniente de entrevistar.

Eso es cierto especialmente a escala, donde una empresa está contratando 10s (por ejemplo, Box) o 100s (por ejemplo, Uber) o 1000s (por ejemplo, Google) de ingenieros por trimestre.

2. ¿Por qué hacer preguntas cliché con las que alguien con preparación puede mejorar?

* Es muy difícil formular buenas y nuevas preguntas técnicas para entrevistas.

Toma horas, si no días, llegar a una pregunta adecuada, que se puede resolver en 30-45 minutos dentro de un entorno de entrevista.

Vemos nuevas preguntas que en su mayoría solo surgen de grandes compañías, y que también principalmente G y F. Los entrevistadores en casi todas las otras compañías reutilizan preguntas que han visto recientemente. Mucho más fácil que adivinar y probar una nueva pregunta por su cuenta.

* Si no te preparas, entonces puedes perder el tiempo durante mucho tiempo y llevar al entrevistador a la frustración.

Como entrevistador, 8 de cada 10 candidatos que conoces no pueden resolver ni siquiera los problemas más básicos. Después de un tiempo, eso comienza a pesar negativamente en ti y la entrevista se convierte en una carga aburrida. Y quieres dejar de entrevistar.

En cambio, preferiría tener una conversación con usted después de que esté preparado, en lugar de antes . No quiero perder el tiempo viéndote buscar cosas simples. Aún así, 8 de cada 10 personas lo hacen, y es muy frustrante sentarse allí y verte luchar durante 30 minutos.

Entonces, si no fuera por otra cosa, solo por mi cordura, me gustaría que se prepare y tenga una conversación de calidad conmigo.

por ejemplo, si le pido que atraviese un árbol de directorios para buscar archivos duplicados, es extremadamente frustrante verlo tropezar con la navegación del árbol. Prefiero que discutas las estrategias de los recorridos (DFS vs BFS, Stack vs Recusion), etc., y debatirlos con el caso de uso en mente, en lugar de tratar de adivinar uno en tus pies (o rendirte).

* Si no permitimos y esperamos la preparación, entonces estamos diciendo que creemos en el talento sobre la preparación, lo cual es falso.

Creo en el talento / habilidad inherente, pero solo cuando se trata de ser lo mejor de lo mejor.

Pero las entrevistas no buscan lo mejor de lo mejor. Las entrevistas solo buscan buenos ingenieros, y ser un mejor ingeniero es factible con la preparación. Quiero darte la oportunidad de prepararte antes de venir, y espero que el tipo correcto de preparación te lleve a ser un mejor ingeniero.

Si veo que está bien preparado en una entrevista, lo profundizaré en el problema, discutiré las ventajas y desventajas de las soluciones disponibles y, en general, lo conoceré mejor como persona. Eso me daría una señal mucho más fuerte de ti.

Por otro lado, incluso después de la preparación, si encuentro que te falta, eso nos da a los dos mucha más confianza en el rechazo.

Porque eso es lo que generalmente surge cuando la gente busca en Google preguntas de entrevistas de programación.

En serio, la programación de entrevistas es innecesariamente larga y agotadora. A menudo, no son representativos de cómo harías tu trabajo. Las entrevistas son largas porque un ingeniero de software representa un gasto significativo, por lo que es un gran riesgo contratar a uno malo.

Últimamente hemos intentado la programación de pares para posiciones y creo que resultó bien. Los entrevistados pueden usar una computadora portátil real y pueden buscar respuestas en Internet. De esta forma, pueden resolver los problemas de forma natural como lo hacemos nosotros y mitigamos las probabilidades de perder un buen candidato, además de evitar contratar a alguien que no podría manejar el puesto.

Si quieres ser un buen programador, solo programa cada día durante dos años, serás un excelente programador. Si desea ser un programador de clase mundial, puede programar todos los días durante diez años, o puede programar todos los días durante dos años y tomar una clase de algoritmos . [1]

Estas preguntas evalúan las habilidades de análisis de algoritmos. Las soluciones para lo esencial pueden ser bien conocidas [2], pero es fácil hacer una pregunta de seguimiento que no sea una de las soluciones conocidas.

Un truco para las preguntas algorítmicas es escribir código en Python (lenguaje de programación) en lugar de cualquier lenguaje de producción que usen. Simplemente ahorra mucho tiempo. F # (lenguaje de programación) también podría ser divertido. 😉

[1] Introducción a los algoritmos (SMA 5503 / 6.046J) – Lectura de una transcripción. Por el profesor Charles Leiserson
[2] Hackear una entrevista de Google

Porque el conocimiento de tu algoritmo demostrará cuánto eres eficiente para resolver problemas en el futuro. Sin el conocimiento del algoritmo, me gustaría decir que no hay programadores, pero hay muchos codificadores. Y hay mucha diferencia entre programadores y codificadores.

Creo que tener conocimiento de algoritmos te hará diferente de los demás.
Si usted es maestro en algoritmos, significa que podrá resolver cualquier tipo de problema de programación o podrá crear aplicaciones o software en pocas ocasiones. Y así es como hace que un programador sea diferente a otros.

El algoritmo es la parte más importante de la programación, el resto es solo traducir su algoritmo a diferentes lenguajes.

¿Qué es un buen código orientado a objetos si no resuelve un problema? Las empresas venden cosas, cosas que resuelven problemas. A los clientes generalmente no les importa si se hace con objetos o funciones o pequeños demonios que presionan interruptores dentro de una caja negra.

El algoritmo es la solución. El algoritmo es lo que hace el dinero. El algoritmo te paga.

La respuesta clásica es que lo mejor que puede hacer para acelerar su código es elegir el algoritmo correcto. Hazlo bien y puedes arruinar casi todo lo demás y aún así tener un tiempo de ejecución razonable. Haz eso mal y no importa qué más hagas bien.

El problema con esa visión es que la mayoría de los programadores que trabajan pasarán años sin necesidad de tomar una decisión algorítmica de ninguna consecuencia. Las opciones de algoritmos son irrelevantes porque su código no es sensible al rendimiento o porque está utilizando un lenguaje moderno que ha implementado algoritmos razonables en sus bibliotecas.

Si tuviera mi preferencia, nos tomaríamos el tiempo que pasamos enseñando algoritmos y enseñamos a las personas cómo usar sus depuradores.

Suponga que está contratando para su empresa y encuentra 5 personas que tienen las “habilidades para resolver problemas” que necesita.

Pero solo tiene presupuesto para contratar uno.

¿Cómo filtrarás lo mejor en esos 5?

Déles algunos problemas y descubra quién obtiene “la respuesta más rápida a un problema de algoritmo común / cliché”.

Entonces este es un filtro, formado por geniales profesionales de la tecnología.

Cuando miras desde su perspectiva, sabrás el dolor.

La programación es solo el vehículo mediante el cual puede completar su tarea de la vida real, es decir, hacer que la computadora funcione en consecuencia, pero cuando se realiza una tarea de la vida real, diferentes procesos funcionan simultáneamente, por lo que para escribirla en forma de código se requiere un conocimiento adecuado de la descomposición del problema. es decir, algoritmo. La programación es solo un lenguaje para escribir código que es comprensible para nosotros y para la computadora. El mismo problema podría resolverse en muchos idiomas diferentes, pero lo único que permanece constante es el algoritmo.

Le hago preguntas de codificación y algoritmos para ver cómo maneja nuevas situaciones bajo presión.

Si es obvio para mí que has visto mi pregunta antes y te has preparado, te haré una pregunta diferente hasta que encuentre una nueva para ti.

Memorizar las soluciones de memoria no te ayudará, solo me molestará y evitará que aprenda lo que necesito sobre ti durante la entrevista.

Esto es muy simple.

Es porque son imbéciles.

No les importa si tienen éxito. Si fallan, entonces serán “experimentados” y obtendrán más dinero la próxima vez.

Y si tienen éxito, es sobre todo suerte, o tal vez es su capacidad de persuadir a todos de que su nuevo y excelente idioma, que está hecho de Santorum y cinta de pato, es tan maravilloso y revolucionario.

Y todos los fanboys que han ganado algunos dólares siguiendo la tendencia les darán analingus.