Si la programación del mundo real y la programación competitiva son tan diferentes, ¿por qué las empresas siguen juzgando a los candidatos sobre la base del conocimiento basado en la codificación competitiva?

Ninguna compañía prueba a sus candidatos con “conocimiento basado en codificación competitiva”.

En el mejor de los casos, puede decir que las entrevistas técnicas a menudo se centran en estructuras de datos y algoritmos, pero le resultará difícil encontrar una empresa que haga una pregunta que requiera conocimiento que solo se obtiene al ser un programador competitivo.

¿Por qué es esto? Porque muy pocas personas hacen concursos de programación.

Cuando era pasante en Google, miré la lista interna de personas que participan en TopCoder. No hay tantos Googlers que hacen TopCoder. Sospecho que este es un mito que no se ayuda debido a los programadores competitivos de alto perfil que están en Google. Petr Mitrichev, Tiancheng Lou y Tomek Czajka son tres que vienen a la mente, pero también hay muchos TopCoders rojos en Google (y también muchos TopCoders no rojos, en caso de que le preocupe que la calificación de TopCoder de alguna manera afecte sus perspectivas de conseguir un trabajo en Google)

TopCoder me dice que actualmente hay 665 TopCoders activos que representan a los Estados Unidos. Hay decenas de miles de ingenieros de software en los Estados Unidos; esos 665 TopCoders activos constituyen un porcentaje muy pequeño de los ingenieros de software. Si las empresas realmente evaluaran a sus candidatos con conocimiento competitivo de la competencia, un gran porcentaje de los empleados actualmente nunca debería haber sido empleado en primer lugar.

Entonces, ¿por qué entrevistar sobre algoritmos y estructuras de datos?

Porque los algoritmos y las estructuras de datos son temas muy convenientes para abordar las compensaciones. El enfoque típico para resolver estas preguntas es dar algún tipo de algoritmo que resuelva el problema pero que sea ineficiente. A partir de ahí, se hacen un par de observaciones que nos permiten llegar a un algoritmo superior. A veces, se le pedirá que resuelva el problema dadas diferentes restricciones (si tiene más espacio, ¿puede resolver el problema más rápidamente? Si tiene menos espacio, ¿puede mantener la misma complejidad?). Todo esto ayuda al entrevistador a determinar qué tan bien puede pensar el entrevistado.

¿Pero no es eso de lo que se trata la programación competitiva?

Realmente no. Ningún problema de programación competitiva algorítmicamente difícil aparecerá en una entrevista. ¿Por qué? Los programadores competitivos lo conseguirán mucho más rápido que los programadores no competitivos (si el programador no competitivo lo consigue), pero eso es algo que podría haber predicho con solo mirar un currículum. Compare esto con las preguntas de la entrevista, que aunque pueden resolverse utilizando “técnicas estándar” en los concursos de programación, son mucho más accesibles y pueden distinguir más poderosamente entre los entrevistados.

La programación competitiva también es mucho más esotérica que eso. Una clase de algoritmos de pregrado te enseñará de qué se trata la programación dinámica, pero la programación competitiva te hará aprender a usar la programación dinámica de formas mágicas que una clase de algoritmos de pregrado nunca podría detallar. Aprenderá sobre estructuras de datos potentes y las adaptará para resolver diversos problemas. Este conocimiento es demasiado esotérico para que una entrevista pueda evaluar a un entrevistado.

Entonces, incluso si los algoritmos y las estructuras de datos son un buen material para preguntas de entrevistas, ¿cómo se correlaciona esto con la programación del mundo real?

No tengo una prueba lógica de que estos deberían funcionar. No creo necesariamente que deba existir, porque gran parte de la programación del mundo real está completamente disociada de los algoritmos y las estructuras de datos. Por otro lado, la industria de la tecnología ha estado haciendo grandes cosas, así que voy a salir con el viejo axioma ” si no está roto, no lo arregles “. Además, si las entrevistas continúan centrándose en algoritmos y estructuras de datos, me resultará más fácil conseguir un trabajo. 🙂

Probamos a las personas en un ejercicio de programación en pareja, y mi primer paso fue que es ridículo compararlo con la programación competitiva, pero supongo que se parecen un poco, porque tienen objetivos similares. La mejor manera de evaluar la capacidad de programación es pedirle a alguien que programe. Ahora, idealmente, si tuviéramos todo el tiempo del mundo, lo que nos gustaría saber es “qué tan productiva sería esta persona trabajando dentro de nuestra tecnología actual, convenciones y estándares, y si esta persona tuviera buenas sugerencias para aquellas áreas donde necesitamos expandir o cambiar nuestra tecnología actual? ¿Qué vamos a hacer? Echa un vistazo al currículum, dales diez minutos de pizarra y luego contrata por tres meses, después de lo cual despedimos al 90% porque no son realmente buenos programadores. No, queremos contratar personas que tengan una alta probabilidad de 1) ser buenos programadores, 2) ser generalmente inteligentes y 3) escribir código que se ajuste a nuestros estándares. ¿Cómo haces eso?

• No puede esperar que las personas tengan un conocimiento profundo de sus opciones tecnológicas, por lo que las preguntas sobre Hibernate, Guice, Guava o nuestro marco (de código abierto, pero con poca adopción externa) son una pérdida de tiempo.
• La programación es una habilidad que se transfiere fácilmente a cualquier idioma, por lo que hacer preguntas engañosas sobre el idioma eliminará a las personas que podrían resultar realmente buenas.
• Un ingeniero competente tiene mejores cosas que hacer que dedicar 40 horas a algún proyecto calificado para una empresa para la que no está seguro de trabajar, por lo que debe mantener la escala pequeña.
• Queremos probar su capacidad para hacer el trabajo, no nuestra capacidad de transmitir requisitos confusos, por lo que los problemas en algunos dominios específicos solo favorecerán a las personas que han visto cosas en ese dominio antes.

¿Qué nos deja eso? En general, la pregunta será principalmente sobre estructuras de datos o algoritmos, porque eso es todo lo que hay para programar una vez que elimine los problemas específicos del dominio y las opciones tecnológicas.

Volviendo a la pregunta, si quieres convertir la programación en un deporte, ¿qué vas a hacer? Vas a quitar todo menos la esencia de la programación, la comunidad entre personas que pueden trabajar en diferentes campos usando diferentes lenguajes. Y eso es lo mismo que esperas que alguien traiga con ellos cuando cambian de trabajo.

¿Puedo poner un enchufe aquí? Estamos contratando ingenieros de front-end y back-end en este momento.

Respuesta corta:
Falta de cualquier otra buena medida.

Respuesta larga:
¿Qué más puedes usar como métrica para juzgar a un candidato en cuestión de horas?

• CGPA ? ( Venga)
• Los rompecabezas solían ser de facto hace 5 años, personalmente creo que eran una forma terrible de juzgar a los candidatos para un puesto técnico. Al resolver acertijos, el entrevistador solo recibe una respuesta si la resuelve correctamente. En el caso de que no pueda resolverlos, no brindan información útil.
• Pregunta de diseño del sistema mientras se prueba una parte del conocimiento del candidato, tienden a ser como ensayos (puede seguir y seguir Blah Blah Blah)
• Ser bueno en la programación competitiva garantiza a las empresas que el candidato tiene la capacidad de enmarcar, reducir y resolver problemas técnicos rápidamente. Incluso si no puede resolver el problema en una entrevista, el proceso de pensamiento subyacente puede revelar mucho sobre usted.
  Aunque no es bueno en CP , no necesariamente significa que sería un asco para el desarrollo de software.

Logros como la contribución de código abierto son muy importantes. Pero no pueden probar eso en el acto, ¿verdad?

Ambas son formas de evaluar la capacidad de un programador en un corto período de tiempo.

Cuando estoy entrevistando a candidatos, me encantaría saber qué tan bien trabajan con otros, diseñar y probar su código, estimar y administrar su tiempo, y tomar cientos de pequeñas decisiones que comprenderán el día a día de un trabajo. Pero, francamente, no tengo idea de cómo averiguarlo en una conversación de una hora.

Si le pido a alguien que escriba algún código, tengo una idea de cómo piensan y resuelven los problemas, cómo se comunican y cómo se ve parte de su código. De ninguna manera es un reflejo completo de ellos como desarrollador, pero es donde “el caucho se encuentra con el camino”.

El algoritmo y la estructura de datos que quiero que sepan es bastante básico. Como conocer las complejidades temporales de buscar un elemento en una matriz vs. un árbol binario vs. una tabla hash. Quiero que cosas como esa sean una segunda naturaleza para ellos y puedan aplicar ese conocimiento de manera apropiada.

Estas empresas manejan enormes cantidades de datos y necesitan esa habilidad. Por lo tanto, tiene mucho sentido que sepa cómo mover bits en la memoria y obtener rápidamente los datos de donde se necesitan. Cuando Internet era nuevo, también había otros motores de búsqueda y sitios web de redes sociales, ¿puede nombrar alguno de ellos ahora? Hay una razón por la que conoce Google y Facebook, pero no Altavista o MySpace.

Sin embargo, no todas las empresas necesitan esta habilidad. Mi experiencia es en Canadá, y he trabajado para muchas compañías de tecnología como programador en los últimos años. Y fue entrevistado por muchos más. Y nunca tuve que pasar por este tipo de preguntas porque estas empresas no necesitaban este tipo de habilidades.

Me encontré con la estructura de datos de miedo y las preguntas de algoritmo por primera vez cuando me estaba preparando para Google. Trabajé bien antes de eso también y había trabajado para varias compañías. Sin embargo, antes de la preparación de la entrevista de Google, ni siquiera sabía que existían estas cosas, pero había hecho un trabajo increíble como programador para varias compañías. Podría recordar haber estudiado estas cosas en la universidad. Sin embargo, en la entrevista real de Google, y más tarde en la entrevista de Amazon, no hicieron ninguna de estas preguntas. Sin embargo, tampoco me desempeñé lo suficientemente bien en las preguntas de codificación in situ de Java, por lo que nunca tuve la oportunidad de pasar a los siguientes niveles de sus entrevistas. Probablemente pregunten estas cosas en sus próximas rondas de entrevistas técnicas.

Después de eso, había realizado otros trabajos, muchas compañías me habían entrevistado con éxito, rechazado ofertas, aceptado ofertas, pero nunca tuve que pasar por estas preguntas sobre la estructura de datos y el algoritmo. Y siempre tuve / tengo trabajos muy buenos y recientemente de alto nivel.

Hace solo unos días tuve dos entrevistas en dos organizaciones principales, nombre de una de las cuales casi todos saben (aunque no lo diré aquí). Pasé como dos semanas preparándome para estructuras de datos y algoritmos, pero en una entrevista, no hicieron ninguna pregunta técnica, y en la segunda (la famosa compañía) no preguntaron más que cómo funciona un HashMap y luego pasó a otras preguntas. Una vez que rechacé una muy buena oferta de BlackBerry (debido a otra mejor oferta, aunque todavía creo que debería haberla rechazado), la entrevista técnica fue muy difícil y desafiante, y al final obtuve la oferta. Pero tampoco había estructura de datos o preguntas de algoritmos.

Entonces, mi conclusión ha sido que depende de lo que el empleador realmente esté buscando y de la experiencia que tenga. Si ya ha realizado proyectos que requieren un trato significativo con estructuras de datos y algoritmos inteligentes, el empleador supondrá que puede hacerlo bien.

Habiendo dicho todo esto, podría no ser aplicable a los empleadores de su área 🙂

Si lees sobre computadoras en los años 60 y 70, sabrías la respuesta detrás de tu pregunta.

Las computadoras han sido, son y seguirán siendo futuristas. Si no lo fueran, no estaría haciendo esta pregunta aquí.

Los problemas del mundo real son más simples y menos exigentes a veces. Es cierto, pero entonces, ¿con qué frecuencia el mundo siempre ve problemas reales? Cada vez que se inventaba una mejor computadora / dispositivo móvil / software, muchas personas no sentían la necesidad de hacerlo. Sin embargo, sobrevivieron e hicieron que la gente se convenciera de su lugar.

Para eso están hechas las computadoras a través de la programación: elevar el listón. Y la programación competitiva es solo un arsenal más de la industria del software. Está aquí para quedarse y crecer, para siempre.

Hay una razón para esto. Si alguien es bueno en la programación competitiva, esto significa que es bueno en la gestión de algoritmos complejos y tiene una comprensión muy sólida de los límites de tiempo / memoria de los programas modernos. Esta es una muy buena línea de base. La lógica detrás de esto es que un programador competitivo tiene MEJORES OPORTUNIDADES para ser productivo en el desarrollo de software a gran escala que requiere complejidad y grandes datos, por ejemplo.

Destaqué la palabra CHANCES arriba.

He tenido experiencia en la contratación de ambos tipos de desarrolladores (con y sin antecedentes competitivos) y esta experiencia demostró que los programadores competitivos NORMALMENTE son mejores desarrolladores de software. Destaqué la palabra NORMALMENTE, contratar a alguien siempre se trata de OPORTUNIDADES, no una garantía del 100%.

Tomemos la curiosidad como otro ejemplo: un programador competitivo es alguien que ciertamente NO trata la programación como “simplemente otro trabajo”, es una INDICACIÓN de pasión. (una vez más, destaco INDICATION porque conozco a algunos matemáticos que son totalmente buenos en algoritmos competitivos pero que no tienen ningún interés en convertirse en desarrolladores de software; solo usan los algoritmos para resolver sus problemas matemáticos específicos en su investigación, pero como subproducto pueden realizar mucho mejor en programación competitiva que un buen desarrollador de software).

Básicamente, se trata de OPORTUNIDADES e INDICACIÓN de que la persona en cuestión tiene un buen nivel de curiosidad y pasión que es crucial para sobrevivir en un proyecto de software a gran escala, especialmente si se trata de un servicio web 24/7 que opera bajo gran carga y maneja grandes datos (cierto para casi todas las grandes empresas de software hoy en día).

La programación competitiva te enseña a: –

• Manejo de cajas de borde
• Resolver un problema de manera óptima
• Ser capaz de darse cuenta de qué paradigma de algoritmo (DP / gráfico / codicioso) se requiere para resolver un problema de aspecto complejo.
• Convierta sus ideas rápidamente en código.
• Habilidades de depuración muy fuertes
• Uso de conceptos básicos de programación para resolver problemas no triviales.

y obviamente todos estos son ingredientes clave para convertirse en un buen desarrollador de software.

Porque los responsables quieren repetición de memoria sin pensar.

La programación competitiva condiciona psicológicamente las soluciones repetitivas.

En otras palabras, los responsables no quieren cambios. Quieren previsibilidad. Quieren trabajadores de fábricas que no desafíen su autoridad. Esto se debe principalmente a que las personas a cargo no quieren que otros descubran sus crímenes.

La programación competitiva solo explotó en popularidad recientemente, y parece ser una reacción directa al énfasis de las entrevistas de las famosas compañías de “ingeniería”. La gente parece querer formas de perforar y calibrarse contra otros.

Solo es relevante para las entrevistas, en la medida en que las empresas están evaluando a las personas por concurso (ver también Facebook Puzzles. De todos modos, solo podrían permitirse investigar a los principales candidatos de esta manera, al igual que cualquier otra fuente de reclutamiento).

En términos de entrevistas que prueban el conocimiento de algoritmos y estructuras de datos, no creo que sea sorprendente en la entrevista de un desarrollador. Quizás la capacidad general de ingeniería de software (lo que resume la respuesta de Gayle Laakmann McDowell) probablemente esté subrepresentada, en general, en mi experiencia también. Tal vez porque es mucho más difícil de precisar en una entrevista.

Aquí hay una discusión similar sobre temas de entrevistas técnicas.

Mi respuesta: la respuesta de Duncan Smith a ¿Deberíamos dejar de dar problemas de algoritmos de estilo de pizarra en entrevistas con programadores? ¿Por qué o por qué no?

Supongo que es solo un proxy para una prueba de coeficiente intelectual, para elegir las generalmente “inteligentes”. Pero requerir una prueba de coeficiente intelectual puro es prácticamente ilegal en los EE. UU., Debido a la legislación de derechos civiles. Los empleadores solo pueden evaluar habilidades directamente relevantes para el trabajo.

Entonces hay un guiño y un guiño y le dan estos problemas de programación que son diferentes a todo lo que realmente hace en el trabajo. Pero es código y ¿qué juez sabrá mejor?

Porque cuando se trata de empujar, la compañía necesitaría que programes las cosas con prisa. Piensalo como si fueras tú. Y no quedar paralizado por el miedo. Creo que la programación competitiva se prepara para esto.