¿Por qué los programadores en las entrevistas de trabajo de ingeniería de software prueban habilidades similares a un concurso de Topcoder, independientemente del hecho de que las habilidades requeridas en la industria son completamente diferentes?

Escuche esto: hay una prueba, entrevista o forma única de contratar .

Cada reclutador experimentado tendrá su forma preferida de hacer las cosas y los influenciadores hablarán principalmente sobre las mejores prácticas. Su enfoque debe diferir según el problema de reclutamiento que está tratando de resolver y depender del tipo de programador que haya logrado obtener.

En Devskiller, nos centramos en ofrecer pruebas prácticas, diseñadas para identificar desarrolladores que puedan satisfacer las verdaderas necesidades comerciales. Además, ofrecemos pruebas específicas y acceso al código propio de la compañía de entrada para ser utilizado dentro de la plataforma de prueba.

Somos los favoritos entre los desarrolladores y RR.HH. está comenzando a comprender el valor detrás de las pruebas individuales y específicas. Les encanta el tiempo que ahorran al usar la plataforma. Pero lo más importante es que también comprenden y aprecian mucho más el tiempo que los desarrolladores tienen a su disposición y, por lo tanto, buscan que el proceso sea lo más ágil posible.

Sin embargo, volviendo a lo que dije al principio, el mercado se extiende a lo largo y ancho, y es tan diverso como grande.

Si tiene un ingeniero de TI ansioso por participar en el proceso de reclutamiento a su disposición (raro); o si usted mismo es un desarrollador calificado y conocedor y está reclutando (muy raro, especialmente en empresas más grandes que no se especializan en productos de muy alta tecnología), el acercamiento a la entrevista haciendo énfasis en la entrevista basada en habilidades es un gran enfoque. Si usa una herramienta en línea o una pizarra debe depender de lo que está buscando o del negocio. Como Gayle mencionó en la respuesta anterior:

“Al usar una pizarra, se pone énfasis en los aspectos conceptuales del problema en lugar de detalles molestos, en su mayoría irrelevantes. Continúe y escriba su matriz 2D como [,] en lugar de [] [], o use .add cuando debería usar .insert. A la pizarra ya mí no nos importará.

Si, por otro lado, los aspectos conceptuales no le importan, pero está buscando contratar desarrolladores que deben estar listos para asumir el proyecto en su primer día y trabajar con éxito en un equipo de programadores, es posible que desee invertir en pruebas que prueben tecnologías y sus dependencias, utilizando herramientas de compilación y pruebas unitarias para probar la funcionalidad sin comprometer la calidad del código. No somos el único, pero somos los mejores 🙂

Siempre que las palabras “entrevista” y “desafío algorítmico” se usan en el mismo contexto, siempre hay un debate 🙂 Es parcialmente porque el término desafíos algorítmicos siempre se ha asociado con cosas como: problemas complejos de teoría de grafos, conceptos matemáticos, conocimiento predefinido de datos estructuras como árboles de sufijos, etc. y probarlos en una entrevista solo le dice cuán profundamente está alguien en la programación competitiva, que generalmente no es un indicador claro de una contratación exitosa o no.

1. Complejidad del código
Sin embargo, independientemente de cualquiera de los roles de desarrollador (front-end / backend / SE) para el que está contratado, diría que el conocimiento de algoritmos y estructuras de datos básicas es imprescindible. Incluso si usted es un desarrollador front-end que mezcla complementos jquery y crea algo nuevo, algún día tendría que escribir un código que diga … tiene que atravesar eficientemente una estructura DOM. Si no sabe qué complejidad tiene un código, no hay forma de saber cómo hacerlo más rápido o si es aún más lento.

Tampoco contrataría a un desarrollador web que no fuera lo suficientemente fluido en CS básico como para no poder pasar una entrevista de algoritmo. Una vez que pasa JQuery y necesita hacer su propia manipulación DOM, se vuelve realmente importante tener los recorridos de su árbol hacia abajo. Y los webdevs que no se dan cuenta de que las NodeLists son realmente listas (con llamadas O (N) .length) causan un mundo de dolor con sus for (var i = 0; i

2. Casos de borde
¿Cuántas veces se ha bloqueado su aplicación web o ha fallado el pago o ha aparecido un mensaje embarazoso (Captura de pantalla 1/5/14 2:24 AM) porque no se consideró un caso límite o se accedió a un índice fuera de los límites de la matriz? Un buen desafío de algoritmo captura esto.

3. Habilidad para pensar
La persona que contrata tiene que ser inteligente. Esta es una afirmación obvia, pero aún así … Pedir un algoritmo de coincidencia bi-partita en una entrevista no tiene ningún valor, pero pedirles que manipulen matrices o listas vinculadas o cualquier estructura de datos básica que cuide eficazmente todos los casos posibles es un gran indicador de qué bien están

a. capaz de analizar la declaración del problema en subproblemas
si. resolviendo cada uno de los subproblemas
C. sabiendo claramente cómo funciona su código, qué tan rápido se ejecuta y si se han manejado todos los casos
re. Solución inteligente que combina todo lo anterior: desde mi experiencia, he notado que este es un gran indicador y se extiende más allá del código. Se traduce en conocimiento del producto y pueden resolver efectivamente un problema que no es puramente de ingeniería.

Necesita los cuatro para resolver cualquier problema (ingeniería / producto).

Veo esta pregunta, de una forma u otra, con relativa frecuencia, y hoy tengo ganas de agregar mi propia respuesta. Voy a ir en contra de lo que parece ser la opinión popular en la Web y defenderé el uso de problemas de algoritmos al entrevistar a los candidatos. (Sí, soy parcial. Deje que el lector tenga cuidado).

Primero: porque funciona . Hasta donde puedo ver, todas las empresas tecnológicas más exitosas del mundo lo hacen. Después de que Microsoft comenzó a hacerlo, casi todos los demás decidieron hacer lo mismo.

Segundo: no, no lo son . Es cierto que en la industria casi nunca tendrá un límite de tiempo de 30 minutos para implementar algo fuera de CLRS. Es falso, y algo completamente diferente, afirmar que no hay superposición entre el conjunto de habilidades requerido para desempeñarse bien en una entrevista algorítmica y el conjunto de habilidades requerido para desempeñarse bien en una posición de ingeniería de software. De acuerdo, entonces, esto podría ser cierto si su trabajo consiste completamente en escribir HTML + CSS, tal vez. Sin embargo, aquí hay algunas cosas que un buen ingeniero en general debería poder hacer, que son comprobables en entrevistas algorítmicas:

1. Razón sobre la corrección . Me parece bastante obvio que un candidato que pueda explicar que su implementación de búsqueda binaria debe ser correcta porque satisface un bucle invariante será mucho mejor para escribir código libre de errores que uno que no pueda. (Sin embargo, admitiré que no pude escribir la búsqueda binaria la única vez que me lo pidieron durante una entrevista).
2. Razón sobre la eficiencia . Sé que algunas personas intentan fingir que esto no importa en el mundo real, pero creo que es una posición bastante ridícula. ¿Cómo vas a tener éxito si no puedes escalar? ¿Cómo puedes escalar sin tener algoritmos que escalen bien? Y honestamente, a nadie le importa si sabes que el tiempo de ejecución del algoritmo de Strassen es [matemática] O (n ^ {2.807}) [/ matemática]. Pero es mejor que sepa que las tablas hash han esperado un tiempo constante por operación, porque se usan en todas partes .
3. Determine las herramientas adecuadas para el trabajo correcto.

Tercero: porque es un filtro para el talento, en general . Como dice Joel Spolsky:

Estás buscando personas que son

1. Inteligente y
2. Terminar las cosas.

Si de alguna manera pudiera evaluar el trabajo pasado del candidato, eso sería mucho mejor que hacer preguntas sobre algoritmos. Pero ya no hay suficientes ingenieros con talento para satisfacer toda la demanda de ellos en la industria tecnológica, y negarse a considerar candidatos porque no puede evaluar fácilmente su trabajo anterior simplemente lo dejaría con muy pocos candidatos; te estarías perdiendo de muchas buenas personas. Por ejemplo, no puede simplemente contratar personas que han creado aplicaciones de código abierto altamente escalables y ampliamente utilizadas, aunque es obvio que el pequeño número de personas que lo han hecho son casi seguramente excelentes ingenieros de software. Entonces, ¿qué haces en su lugar? Usted hace preguntas a los candidatos que tienen más probabilidades de revelar una idea de cuán inteligentes son. En lugar de hacer preguntas sobre algoritmos, puede hacer preguntas específicas de dominio, y muchas compañías lo hacen. Pero no debe hacer solo preguntas específicas de dominio, a menos que tenga la intención de limitarse a contratar candidatos que ya tengan una amplia experiencia en el dominio. (Esta sería una forma especialmente mala de entrevistar candidatos para pasantías).

Cuarto, me gustaría señalar que los problemas de la entrevista no tienen la intención de filtrar a las personas que no hacen concursos . Por el contrario, si te tomas en serio los concursos, es simplemente un efecto secundario agradable que tus habilidades algorítmicas de resolución de problemas estén probablemente muy por encima del nivel de la mayoría de las preguntas de la entrevista. La mayoría de los problemas de la entrevista no están destinados a ser tan difíciles como los problemas de TopCoder. Es cierto que muchos problemas de entrevistas tienen soluciones óptimas que usan estructuras como árboles de segmentos que solo encontrará en concursos y prácticamente nunca en la mayoría de las empresas, pero no tiene que encontrar la solución óptima para obtener el trabajo. Su proceso de pensamiento también es importante y le permite al entrevistador evaluar su inteligencia. Los mejores problemas de entrevista son los que se pueden abordar de muchas maneras y le dan al candidato mucha flexibilidad y espacio para hablar sobre su solución y cómo se puede mejorar, incluso si no logran ver la solución que se ejecuta en un segundo para N = 100,000. Deben ser lo suficientemente difíciles de diferenciar entre candidatos inteligentes y menos inteligentes, sin ser tan difíciles que solo un programador competitivo pueda avanzar de manera razonable.

Aproximadamente partes iguales de lo siguiente.

• Porque conocer un algoritmo apropiado y poder expresarlo en código es realmente relevante. Claro, codificar en una pizarra, bajo un límite de tiempo estricto, con otros mirando, es un poco artificial. No obstante, las habilidades básicas siguen siendo importantes.
• Porque es fácil para el entrevistador. Realmente hacerlo bien , plantear el problema y las limitaciones con claridad, guiar el proceso, evaluar los resultados, es realmente muy difícil. Sin embargo, abofetear un problema básico allí arriba y luego sentarse para disfrutar de su café mientras el candidato suda es fácil. Es mucho más fácil que tratar de idear preguntas que revelen algo sobre los hábitos de trabajo o las prioridades o los rasgos de personalidad del candidato, a pesar de que a menudo son tan relevantes para el éxito en el trabajo como la habilidad de codificación pura.
• Efecto de arrastre. Este efecto también es evidente en las respuestas a varias versiones de las mismas preguntas aquí mismo en Quora. Sin embargo, las primeras respuestas van, al igual que el resto. Varias de las respuestas aquí son básicamente el mismo atractivo para la autoridad / popularidad: Microsoft lo hace, Google lo hace, debe ser una gran idea, ¿verdad?
• Hace que el entrevistador se sienta inteligente. Han estudiado el mismo problema en el tiempo libre, probablemente a través de múltiples iteraciones. Ajustaron las restricciones, posiblemente incluyendo qué lenguaje (s) de programación permitir. No tienen nada en juego. Ver a alguien más luchar para encontrar una solución que todavía sea inferior a su favorito se siente bien para ellos.

Entonces tenemos una muy buena razón, una cuestionable, dos BS totales. Hay algo de valor en esta técnica de entrevista, pero hay al menos tanto valor en otras técnicas también. No hay excusa para la forma en que este tipo de entrevista parece desplazar a otras en tantas compañías.

1. Las habilidades comprobadas se utilizan en la industria.

El código que termina es importante. Si no puede invertir una cadena solo una vez (no dos veces, terminando con el original), se perderá por completo cuando tenga cuatro tipos de máquinas de estado interactuando entre sí.

Las condiciones del borde son importantes. Si no maneja entradas de longitud cero que escriben 10 funciones de línea, tendrá rutas en 100,000 componentes de línea que tienen el mismo problema que no se prueban hasta que un cliente importante las usa.

El rendimiento a menudo importa. Su empresa tendrá problemas para obtener clientes si sus servidores de video digital no tienen restricciones de tiempo real (reemplacé el código de manejo del temporizador O (n ^ 2) de un ingeniero con un O (n log n) para deshacerse de ese problema) o si es inusualmente lento filtrado de paquetes (creo que fue O (N ^ 4). El vicepresidente de ingeniería me agradeció por señalar los problemas con sus “recursos” que evitarían en el futuro).

2. Hacemos tales preguntas porque hacen un buen trabajo al filtrar a las personas que tendrán un mal desempeño.

Poder describir algo es una habilidad completamente diferente a poder aplicarlo. Entrevisté a muchas personas (y me obligaron a contratar a algunas que no funcionaron) que no tuvieron problemas para recitar cosas como cómo funcionaban las estructuras de datos y su complejidad computacional o para describir un proyecto en el que trabajaron y supuestamente contribuyeron pero no pudieron poner eso en práctica en los problemas más simples.

3. Estamos probando aptitudes que no se pueden enseñar.

Todas las personas que desee contratar recogerán rápidamente nuevas bibliotecas e idiomas.

OTOH, hay aptitudes que parece que no podemos enseñar a las personas que carecen de ellas, pero “conocen” las palabras clave de reclutador que nos interesan, como Java2JellyBean.

Saeed Dehnadi tiene un documento sobre la aptitud más básica para formar un modelo mental consistente de asignación. El camello tiene dos jorobas con el título que hace referencia al par de golpes en lugar de una curva de campana vista en una clase de programación introductoria y menciona la recursividad y la concurrencia como otro aptitudes

La indirecta es probablemente la aptitud faltante más común entre las personas que llegan a una entrevista en persona.

Tengo una respuesta simple: no estoy seguro de que sea cierto, pero aquí va.

Las habilidades requeridas en la industria del software no se enseñan en la universidad.
Los algoritmos y las estructuras de datos son.

Los reclutadores no esperan que seas increíble en el diseño, etc. – seguro, es una ventaja si lo eres, pero no es necesario.
Sin embargo, lo que les gustaría es gente que conozca bien sus algoritmos y demás. Cosas que se usan en la industria y que ponen a prueba tu ingenio, etc.

Espero que si tiene dos años de experiencia laboral más o menos en su haber, no se le harán preguntas de estilo TopCoder en entrevistas.
Pero esto es solo mi suposición. Lo mejor es obtener aclaraciones de las personas que están reclutando.

Actualización: según un comentario a continuación, este no es el caso; aún se le hacen preguntas de estilo TopCoder incluso después de haber trabajado en la “industria del software”.

Las habilidades necesarias en las entrevistas de trabajo no son realmente tan similares a algo como TopCoder. No hay un límite de tiempo difícil, no es una competencia, debes ser capaz de explicar lo que estás haciendo, el estilo de codificación sí importa y obtienes crédito parcial.

También es al menos algo similar a lo que los desarrolladores pasan su tiempo haciendo. Sé que las personas afirman que no usan su conocimiento algorítmico en sus trabajos, pero no lo creo completamente. Utilizo mi conocimiento algorítmico en mi trabajo y mi codificación se limita al script Tcl extraño en estos días; todavía es útil saber qué estructuras de datos darán lugar a tiempos de ejecución de segundos versus cuáles darán lugar a tiempos de ejecución de horas.

La razón por la cual este estilo de entrevista ha evolucionado es porque es mucho mejor que lo que se hizo antes, que consistía principalmente en preguntar a los entrevistados sobre proyectos anteriores y tal vez hacer que leyeran un código y respondieran algunas preguntas de diseño de OO. Como era de esperar, ese tipo de entrevistas casi no tenían correlación con el desempeño laboral. Las grandes compañías que hacen un seguimiento de estas cosas creen que la forma en que las personas hacen las preguntas de codificación se correlaciona con qué tan bien escriben el código, lo que tampoco es sorprendente.

En realidad, hacer que la gente trabaje en pequeños proyectos de codificación probablemente se correlaciona aún mejor con el desempeño laboral. Algunas pequeñas empresas hacen esto. Pero es mucho más costoso de evaluar. Hacer que la gente escriba unos 10s de líneas de código en la pizarra es probablemente un medio bastante feliz entre el costo y la precisión.

En relación con la respuesta de Gayle Laakmann McDowell:

Prueba de habilidades es realmente difícil, pero es muy difícil hacerlo bien.

De hecho, creo que las empresas se están acercando a la evaluación de habilidades de esta manera para evaluar si un candidato tiene una base sólida de CS y es capaz de resolver problemas en el acto. Sin embargo, creo que esto termina filtrando a las personas que podrían no ser aptas para un determinado rol, pero podrían ser una buena opción para otro.

No voy a decir que tengo la respuesta perfecta, pero así es como me he acercado a la contratación en el último año o dos.

Primero, me encuentro con candidatos y les dejo hablar sobre ellos mismos y sus pasiones. Trato de identificar lo que les gusta hacer, independientemente de si pueden ser lo suficientemente buenos o no. La motivación, en mi opinión, es de donde surgen las verdaderas capacidades de resolución de problemas: puede obtener el mejor y más hábil ingeniero del planeta, si no les importa o creen en lo mismo que su empresa, no aportarán mucho valor.

En cuanto a la evaluación de habilidades, procedo de la siguiente manera:

1. Les doy una lista de repositorios de código abierto de GitHub que nos interesan, y les pido que hagan una solicitud de extracción que resuelva un problema o implemente una nueva característica.

2. Si el código enviado es de nuestro agrado, nos reunimos por segunda vez con el liderazgo técnico de la empresa y discutimos el código enviado.

Hay muchas razones por las que creo que este es un enfoque superior:

1. Usamos GitHub y queremos contratar personas familiarizadas con él.

2. A veces aporta valiosas contribuciones a la comunidad de la que formamos parte y, en general, promueve el desarrollo de software de código abierto.

3. Los mantenedores de esos repositorios a menudo no somos nosotros: por lo tanto, también podemos ver sus comentarios sobre el código enviado.

4. La prueba se parece más a una pregunta abierta: muéstranos qué sabes hacer mejor y cómo lo haces.

5. No somos dueños de los resultados de la prueba. Si terminamos sin contratar a alguien, aún tienen acceso al código que han escrito y pueden usarlo para impresionar a otra compañía a la que quieran postularse.

6. Si nos reunimos con ellos una vez más para discutir su contribución, se les llama a explicar su código de una manera muy similar a la que probablemente tendrían que explicar su código mientras trabajan con nosotros.

Hay otras ventajas en este proceso que no abordaré, pero lo que me ha sorprendido hasta ahora es la poca advertencia que tiene este proceso de evaluación de habilidades.

Entiendo que mi respuesta no es directa a la pregunta que se hace aquí, pero espero que pueda brindar una perspectiva a quienes consideran las pruebas de habilidad como una forma de evaluar a los candidatos.

Contestaré en base a mi propia experiencia, algunas de las cuales implican hablar con reclutadores y gerentes de contratación que usan la calificación TopCoder. Las empresas están tratando de evaluar la aptitud en varias áreas: pensamiento crítico, pensamiento divergente y dominio de los conceptos. Existen varias compañías que usan una calificación de TopCoder de la misma manera que usted podría usar un GPA de una universidad o colegio.

Creo que entienden bien las limitaciones que puede tener este tipo de preguntas, pero generalmente tienen un gran grupo de talentos y necesitan clasificar a los candidatos rápidamente. Al final del día, la alternativa (que se basa en atributos de currículum como: títulos, universidades, GPA y empleadores anteriores) tiende a favorecer más el pedigrí que la capacidad.

Dicho todo esto, he visto a muchas compañías implementar mal este proceso de preguntas de entrevistas amables.

1. Declaración del problema
La receta definitiva para el desastre es un calendario completo de entrevistas no estructuradas. Se convierte en un encuentro social y saludo. Y en una situación puramente social, desafortunadamente los buenos entrevistadores a menudo realmente disfrutan hablando con malos candidatos.

2. Solución
Tienes que ver al candidato pensar. Necesita ver cuánta ayuda necesita para resolver un problema. ¡Porque si contratas a este bromista, tú (o las personas que ya conoces son buenas) vas a proporcionar la ayuda!

En comparación con las entrevistas sociales, cualquier tipo de entrevista técnica es una gran mejora.

Creo que los algoritmos están bien. No importa tanto Un buen gerente de contrataciones evitará “problemas”: problemas fijos que detectan a las personas que se han preparado obsesivamente para las entrevistas. Lo último que desea hacer es contratar a un dron que haya pasado seis meses memorizando las respuestas correctas a una larga lista de preguntas. Cuando era gerente de contratación no me importaban las preguntas que hacía. Les pediría a los candidatos que nombraran su propio proyecto pasado favorito y luego que me explicaran el trabajo. Te sorprendería saber cuántas personas no parecen entender su propio trabajo muy claramente. *

Este sistema está lejos de ser perfecto. Sin embargo, es mucho mejor que no tratar de evaluar la capacidad de los candidatos.

3. Malos gerentes de contratación
Un gerente realmente malo contratará malos candidatos. Si hacen entrevistas técnicas, las preguntas pueden no tener respuesta (como las preguntas de secuencia en Quora: 2, 3, 7, 11, 10, ¿qué sigue?), El nivel de dificultad puede no tener sentido, los entrevistadores pueden no entender claramente el preguntas o cómo responderlas o cuáles son los temas clave.

Esto apesta y no debería suceder … pero eliminar la entrevista técnica no hará que la entrevista con una organización disfuncional sea más agradable. Además, al hacer esto, el gerente ha inclinado su mano. Sabes que la organización está en mal estado. Solo respire aliviado cuando salga por el día, y si recibe una oferta, rechace de inmediato.

---

* Esto no fue principalmente una prueba de habilidad para comunicarse. Seguía preguntando sobre las partes del trabajo de las que sabía algo, hasta que llegaba a un punto en el que estaba claro que nos estábamos comunicando. Si tomó tiempo extra, eso no fue una penalización. Muchas personas muy inteligentes no tienen la habilidad de explicar claramente en cualquier momento, y aunque eso es valioso … para un ingeniero no es tan importante como la capacidad técnica.

Totalmente de acuerdo en que el conjunto de habilidades requerido en la industria es muy diferente del conjunto de habilidades requerido en las competencias de programación.

Esas fueron buenas noticias. Las malas noticias son que las habilidades requeridas para la industria son casi imposibles de evaluar en varias horas.

Mi forma favorita de contratar personas es comenzar con ellos por pago por hora durante los primeros 2 ..3 meses. Luego usa el truco de Zappos: pagar de más y dejar ir o hacer un trato a largo plazo.

Sin embargo, las grandes corporaciones no tienen este lujo. Tienen que conformarse con la mejor opción disponible.

Por otro lado, a pesar de las diferencias de habilidades, alguien exitoso en la programación de competencias probablemente tenga la inteligencia, la disciplina y la pasión para tener éxito en la industria. Si bien alguien con muchas certificaciones y recomendaciones tiene una posibilidad decente de carecer de estos rasgos 😉

Debido a que la industria no ha encontrado nada más de lo que puedan obtener una señal razonable de la cual
1) toma ~ 45 minutos por entrevista,
2) es repetible en varios candidatos.

Llamo a bs por cualquier otro motivo (perdón :().

No he visto ningún estudio que muestre una fuerte correlación entre tener un buen desempeño en la industria y tener un buen desempeño en los concursos de programación (no estoy hablando del 99% de archivos en este último).

No estaría de acuerdo con su evaluación de que las habilidades requeridas en la industria son completamente diferentes. Las preguntas de Topcoder miden su capacidad para escribir código estricto, resolver un problema rápidamente, encontrar una solución eficiente a un problema, conocer las compensaciones entre el espacio y el tiempo. La mayoría de las carreras de ingeniería requieren esto.

Algunos algoritmos ejercitan sus habilidades de pensamiento matemático / lógico que son muy necesarios en la industria. Siempre se puede aprender un nuevo lenguaje o marco con facilidad. Por lo tanto, las pruebas en idiomas específicos no tienen sentido. Los algoritmos de Topcoder / estructuras de datos parecen haber evolucionado como la forma viable de * objetivamente * medir cuán inteligente es un individuo. También son independientes del lenguaje y ayudan a los entrevistadores a evaluar su proceso de pensamiento.

¿Necesitamos también otras habilidades en la industria? Ciertamente: la capacidad de leer el código de otros, la capacidad de comprender interrelaciones complejas entre sistemas / subsistemas, desarrollar código que se pueda mantener, etc.

¿Deben probarse otras habilidades? Por supuesto, iría con habilidades básicas de informática. Todo ingeniero debe creer que “no hay magia”: debe ser capaz de describir / rastrear la secuencia de eventos que se desarrollan cuando presionan una tecla y hacen que aparezca una letra en la pantalla desde el nivel de registro (o nivel de puerta lógica o nivel de transistor) al nivel de arquitectura del sistema al nivel del sistema operativo al nivel de la aplicación. Esto es filosóficamente importante, pero también es de interés práctico para los desarrolladores que necesitan descubrir cómo hacer que un sistema haga lo que quieren que haga.

Mira, esto es lo que pienso y depende de mi opinión personal.
Supongamos que X está siendo contratado para un trabajo de Ingeniería de Software, después de ser contratado necesita construir algo para mil millones de personas o decir un millón, debería saber qué usar, como qué técnica de clasificación debería usar, e incluso tiene algún código que debería ser capaz de entenderlo, también puede ver si usa el tipo de burbuja lo que sucede, puede decir que puede aprender después de ser contratado, pero X es contratado para trabajar y no para aprender.
¿Qué pasa si X usa la búsqueda lineal para mil millones de personas?
Imagina que los algoritmos de Facebook realizan búsquedas lineales en lugar de búsquedas gráficas, espero que entiendas mi punto.
Los problemas de Topcoder simplemente prueban sus habilidades para resolver problemas, su capacidad de aplicar lo que sabe en un nuevo contexto,

Porque los gerentes no son analistas.
Y ellos son narcisistas.
Las personas narcisistas tienen más probabilidades de emerger como líderes

gran tema

No sé si hay datos emperical sobre este tema, si no, es un gran tema de investigación.

Por supuesto que después de una licenciatura, maestría y doctorado casi terminado en CS, desearía poder conseguir el trabajo. Sin embargo, la vida no funciona así.

En otras palabras, esto es lo que se requiere, así que si tengo que actualizar algunos temas, que así sea. por ejemplo, no me gustó el GRE pero era un requisito para la escuela de posgrado.

Ahora, creo que si te gusta codificar como yo, es divertido prepararlo. siempre existe el miedo a no funcionar bien, pero así es la vida

Una pregunta diferente si este método funciona o no. Quizás no hay nada mejor. Tal vez lo hay.

También proporciona un gran negocio o ingresos adicionales para algunos. Puede ser una situación de ganar-ganar.

quién sabe

para ser más específico a la pregunta, mientras que las compañías pueden variar el enfoque para evaluar a su candidato, incluso si usaron una versión simplificada del codificador superior, creo que está bien.

tal vez también se necesiten algunas preguntas de alto nivel, tales como: da un ejemplo concreto (tal vez con código) por qué es importante usar interfaces (por ejemplo), que no son necesarias en la mayoría de los tipos de competencia de programación como el codificador superior u otros.

Creo que dos preguntas para las que no tengo respuesta relacionadas con este tema son:

1. ¿El éxito de una entrevista (como en Microsoft) predice el resultado del empleado?

2. Si no (1), ¿puede estar perdiendo la diversidad necesaria para crear proyectos increíbles?

Más importante si los datos son públicos (probablemente no), ¿cuáles son las estadísticas para contratar a Soft Eng de las principales empresas (google …) en términos de duración de la retención, promociones, etc. tal vez esta es una pregunta que me gustaría preguntar aquí en quora.

Toda la pregunta sobre algoritmos y teoría en las entrevistas es poco convincente. Por mi parte, soy horrible con los problemas técnicos en un escenario de entrevista. Un trabajo está en la línea, mis cuentas / familia están en mi mente, estoy en ropa incómoda en un entorno inusual. Pero ese soy yo. Déjame un problema o una tarea y patearé el culo a cualquiera que piense que es genial porque puede memorizar una fórmula de árbol de búsqueda binaria. Lo hice en la universidad y no habría aprobado con un promedio de casi 5.0 si no pudiera entenderlo. Prefiero buscar soluciones de Google e investigar una búsqueda eficiente si lo que estoy usando no es eficiente y usar una biblioteca que sí, francamente, mucha más gente inteligente que yo ya descubrí. Para la mayoría de las posiciones de software, esto es más que un simple, y ser ingenioso, dedicado y determinado es infinitamente mejor que un geek que tiene autoestima para memorizar log (n) = búsqueda binaria. No necesita recitar algoritmos de ingeniería de software o una gran notación O para crear una aplicación increíble que ahorre a la compañía miles de dólares en productividad que de otro modo se desperdiciarían con pasos manuales.

Creo que todo el concepto de estas preguntas de teoría técnica es un grupo de seguidores tontos que piensan que esa es la forma correcta de incomodar a un entrevistado. Tal vez filtra algunos de los trapos, pero si no pueden explicar o describir sus proyectos en los que han trabajado, eso es más que suficiente para proporcionar que son capaces. Quizás soy yo. Por mi parte, si no puedo resolver algo, pasaré cada minuto de mi tiempo fuera del trabajo asegurándome de entender lo que necesito entender para hacer mi trabajo.

En general, un gran reconocimiento a toda esta noción de tratar de probar a las personas en cosas en las que ya demostraron ser comprensivos al obtener un título.

puede ser para probar su habilidad rápidamente y completar una tarea determinada