Experiencia de entrevista de TI: ¿Qué es lo más importante en una entrevista de programador?

Las entrevistas con programadores siempre han sido un tema candente que la comunidad está feliz de discutir. Desde mi pasantía en 2006, he trabajado en 4 empresas de software, todas ellas extranjeras, incluida una empresa de comunicaciones Fortune 500, una empresa financiera europea de tamaño medio dedicada al comercio de opciones y futuros, y alguien que desarrolló Android para una gran Fabricante de automóviles. Nuevas empresas de automóviles inteligentes. Desde que ingresé a la industria de TI, he experimentado muchas entrevistas durante el proceso de búsqueda de empleo y también he tenido la experiencia de entrevistar a otras personas muchas veces en los últimos dos años. Siento que ahora es el momento de expresar mis propios puntos de vista sobre este tema. Este artículo es una reflexión escenificada y un resumen de la experiencia de las preguntas de la entrevista del programador desde la perspectiva de un entrevistador.

Objetivo

Creo que, como muchos de mis amigos, comencé a entrevistar a otros después de convertirme en Senior después de tener varios años de experiencia laboral. En la etapa inicial, simplemente seguí mi propia imaginación y establecí los objetivos de la entrevista como "encontrar programadores con buenas habilidades básicas", "encontrar programadores con excelentes habilidades algorítmicas", "encontrar programadores con experiencia en desarrollo de Android", etc. Sin embargo, la experiencia real me dice que, especialmente aquellos reclutados de acuerdo con los objetivos de "buenos conceptos básicos" y "buenos algoritmos", al final no obtendrán buenos resultados. Por ejemplo, algunos entrevistados tienen una buena comprensión de los conocimientos y algoritmos básicos. Tienen conceptos claros como procesos, subprocesos y memoria, y están familiarizados con estructuras de datos y algoritmos básicos como hash, árboles binarios y clasificación rápida. Se desempeñan mal en el trabajo real después de unirse a la empresa. Muy mal. Más tarde, descubrí que había algún problema con el objetivo de mi entrevista. Mi método de entrevista original se parecía más al algoritmo de la universidad o al examen final del sistema operativo. Según este método, muchas personas inadecuadas aprobaron la entrevista y, al mismo tiempo, lo fue. Es posible que se hayan perdido muchas personas adecuadas.

Más tarde, mi reflexión fue que desde la perspectiva de la empresa, el propósito fundamental de las entrevistas es encontrar personas que "puedan hacer un buen trabajo", y "alta educación", "buenos algoritmos" y "buena base". " , "Experimentado" son síntomas más que fundamentales, y no pueden equipararse directamente con "buen trabajo".

Método

El objetivo es claro, pero la siguiente pregunta es asumir que el entrevistador es un sistema de caja negra. "Buen trabajo" no es una variable directamente observable. observar directamente Las variables son fundamento, algoritmo, experiencia, educación, personalidad, conversación, edad, etc. Entonces, de hecho, solo se puede inferir la probabilidad de "funcionar bien" a partir de cantidades directamente observables como "buena base" y "buen algoritmo". Esta es la probabilidad condicional de "funcionar bien" bajo la condición de "X es bueno". ". Pregunta: P (buen trabajo | X bien).

Según este modelo, es obvio qué aspectos se deben examinar en la entrevista, es decir, elegir los aspectos más diferenciadores a examinar. Por ejemplo, no tiene mucho sentido examinar las características de la forma del cuerpo del entrevistador, porque las probabilidades de P (buen trabajo | alto), P (buen trabajo | bajo), P (buen trabajo | gordo) y P ( buen trabajo | delgado) son todos iguales; por lo tanto, las características físicas no discriminan y esto no es en lo que se debe centrar la entrevista.

El entrevistador debe determinar qué factores distinguen mejor en función de los requisitos del puesto. Por ejemplo, si desea contratar un ingeniero de desarrollo de motores de juegos 3D con un umbral técnico relativamente alto, el entrevistador A tiene experiencia en el desarrollo de motores de juegos 3D, pero su desempeño en la entrevista de conocimientos básicos y algoritmos es promedio, por el contrario; , tiene un desempeño deficiente en la entrevista de conocimientos básicos y algoritmos. Se desempeña bien, pero no tiene experiencia en desarrollo de juegos y debe elegir uno u otro. ¿A quién eliges? De hecho, estos son dos problemas de probabilidad condicional P (buen trabajo | buena experiencia, base promedio, algoritmo promedio) y P (buen trabajo | sin experiencia, buena base, buen algoritmo). Esta pregunta se deja a criterio del entrevistador. Personalmente, para puestos con umbrales técnicos más altos que requieren acumulación técnica, la experiencia es más ilustrativa.

A continuación, compartiré mis puntos de vista sobre aspectos comunes en entrevistas basadas en mi propia experiencia.

Algoritmos

Los algoritmos son el foco de las entrevistas en grandes empresas como Google y MS. Personalmente, me gustan mucho los algoritmos. Una vez participé en ACM/ICPC y obtuve el puesto 13 en la competencia de Beijing. Sin embargo, por experiencia personal, para la gran mayoría de los puestos de desarrollo con los que he estado en contacto, los algoritmos no son adecuados como factor principal para evaluar las fortalezas y debilidades de los entrevistados. Para puestos de desarrollo ordinarios no algorítmicos, probar el algoritmo del entrevistador equivale a probar si es bueno jugando tenis de mesa. La correlación con el objetivo de "buen trabajo" es demasiado baja.

Desde mi experiencia personal, casi P (buen trabajo | buen algoritmo) = 50%, lo que significa que las entrevistas de algoritmos no son muy diferenciadoras.

Incluso hay una situación muy mala que ocurre especialmente entre los entrevistados con buenos algoritmos. Yo lo llamo "solo afilar el cuchillo, no cortar leña". ¿Qué significa? Algunas personas solo están interesadas en cuestiones puramente técnicas, como el algoritmo A*, la programación asincrónica y el mecanismo de carga de clases JVM, y no tienen interés en satisfacer las necesidades del usuario. Este tipo de personas parecen tener ciertas capacidades técnicas, pero su aportación a la empresa es muy limitada, incluso inferior a aquellas con capacidades medias pero personas serias y responsables. Por lo tanto, una vez que conozca a un entrevistador con un buen algoritmo, prestaré especial atención para comprobar si es el tipo de persona que "sólo afila el cuchillo, no corta leña".

Además, aunque personalmente no conozco Google ni MS, soy escéptico sobre su estrategia de entrevistas que pone especial énfasis en probar las capacidades algorítmicas. Incluso en una empresa de clase mundial, aunque los algoritmos son importantes, es concebible que entre los diversos problemas encontrados durante la implementación del proyecto, los problemas de algoritmos no sean el principal cuello de botella la mayor parte del tiempo y no lleguen al punto en que todos sean necesarios. Todos estos son casos de maestros de algoritmos. De hecho, la verdadera dificultad de la mayoría de los proyectos no son uno o dos cuellos de botella algorítmicos, ni siquiera un solo cuello de botella técnico, sino problemas de organización, coordinación, diseño y desarrollo sistémicos. Hay una gran cantidad de problemas que no parecen ser muy importantes. Técnico. Hay muchos trabajos sucios y muchos problemas se deben a información insuficiente. No es que una gran capacidad técnica pueda superar estas dificultades. Es mejor que un equipo tenga fortalezas complementarias. Algunas personas son fuertes en algoritmos, otras son fuertes en análisis de negocios, algunas son buenas en servicios back-end y otras son buenas en interfaces front-end. con los pies en la tierra. Esto es lo mejor. Si selecciona talentos basándose en el único criterio de "buen algoritmo", definitivamente excluirá muchos talentos excelentes.

Conceptos básicos

Las entrevistas básicas se refieren a entrevistas que examinan conocimientos básicos como el uso de punteros y conceptos de procesos e hilos. Son muy similares a las preguntas del examen final universitario. Solía ​​​​pensar que las entrevistas básicas eran muy importantes, pero ahora no lo creo. La base es realmente importante en el trabajo, pero en el proceso de la entrevista, debe diferenciarse para que sea significativa. Es decir, la probabilidad de P (buen trabajo | buena base) es alta. Luego examine el uso de punteros y la diferencia. entre el proceso y los hilos sólo las preguntas básicas tienen su significado. Mi experiencia real es que las entrevistas básicas no son muy distinguibles. Al igual que el algoritmo, casi P (buen trabajo | buena base) = 50%. Al mismo tiempo, la entrevista básica es la más fácil de preparar. Los chinos tienen una larga experiencia en la educación orientada a exámenes, por lo que es demasiado fácil preparar algunas preguntas indicativas.

Una vez conocí a un entrevistador de este tipo. Su conocimiento básico del lenguaje C y los principios de compilación y vinculación eran muy buenos, lo que me dejó una profunda impresión. Mi conclusión de la entrevista fue: conocimiento que no tengo. No tengo un alcance amplio, solo conozco el lenguaje C, pero tengo una base sólida. Se recomienda contratarme. Los acontecimientos posteriores demostraron que la primera mitad de esa conclusión era correcta, pero la "recomendación para el empleo" estaba equivocada. Era un desastre en el trabajo real y no entendía los requisitos ni la arquitectura general; al mismo tiempo, su tiempo de trabajo no lo dedicaba a proyectos, sino a leer libros como "Autocultivo del programador". Finalmente, este colega abandonó la empresa por "inactividad" de larga duración.

La base no deja de ser importante, pero una "buena base" no es suficiente para demostrar que el entrevistador puede hacer un buen trabajo, porque la base es un conocimiento parcial, mientras que el trabajo real requiere habilidades integrales y hay una enorme diferencia entre ambos. El lenguaje C y el sistema operativo pueden obtener puntuaciones altas en los exámenes, pero ¿todavía vemos tan pocas personas en las universidades que no saben escribir programas? El desarrollo de software es como construir una casa. La capacidad integral es el diseño y la construcción del esqueleto, y el conocimiento básico es la codificación de ladrillos. Zhang Xiaolong desarrolló originalmente Foxmail en Delphi y no sabe C#. Si desea contratar a alguien para desarrollar un cliente de correo electrónico .NET, ¿tiene sentido comprobar si tiene un buen dominio de CLR? ¿Es realmente difícil para Zhang Xiaolong desarrollar una versión C# de Foxmail? ¿Es realmente más confiable que Zhang Xiaolong contratar a alguien que domine C# pero no tenga experiencia en el desarrollo de clientes de correo electrónico?

Cuando digo que los conocimientos básicos no son importantes, ¿contradice el antiguo dicho: "Un paso no puede llegar a mil millas sin acumular hoyos"? ¡Ninguna contradicción! "Wabu" y "Qianli" tienen una relación acumulativa, pero ninguna cantidad de "conocimiento básico" puede sumar una "capacidad integral". El desarrollo de software de aprendizaje debería ser como una integración continua. Al principio, es un sistema completo. Aunque no es de gran escala y tiene muchos problemas, es pequeño y tiene todos los órganos internos. Evoluciona gradualmente de sistemas pequeños a sistemas grandes. desde sistemas simples hasta sistemas complejos.

Por lo tanto, una buena base por sí sola no es suficiente para explicar demasiados problemas, y se debe examinar más a fondo la capacidad integral. Para los entrevistados que no se desempeñan bien en la entrevista básica, se debe realizar una investigación más profunda si el tiempo lo permite. Algunos entrevistadores son realmente capaces, pero no han estado completamente preparados. El estado más ideal es, por supuesto, tanto las capacidades básicas como las integrales. Si no es posible tener ambas en consideración, se debe dar prioridad a las capacidades integrales.

Experiencia

La experiencia mencionada aquí no se mide por el número de años de trabajo, sino que se refiere principalmente a la experiencia del entrevistador, por ejemplo, si ha implementado completamente un software o como El desarrollador principal ha completado un proyecto. La importancia de la experiencia radica en su capacidad para ilustrar las capacidades generales de una persona. A partir de la naturaleza, escala y dificultad del proyecto, el entrevistador puede juzgar aproximadamente la capacidad general del entrevistador. Si un entrevistador ha sido responsable del desarrollo y mantenimiento de un pequeño módulo en una gran empresa, básicamente se puede juzgar que no tiene la capacidad para emprender un proyecto de forma independiente o como desarrollador principal, y solo es apto para hacer cosas similares. cosas en otra gran empresa. Para puestos con umbrales más altos que requieren acumulación técnica a largo plazo, la experiencia relevante es aún más importante, como desarrollo del kernel de Linux, desarrollo de JVM, desarrollo de motores de juegos, implementación de bases de datos, UX avanzado, etc. Para este tipo de puesto, incluso si un entrevistador sin experiencia tiene buenas cualidades generales, necesitará mucho tiempo de estudio y acumulación para estar calificado. Entonces, básicamente, si se determina que su puesto cae en esta categoría, entonces la experiencia relevante debería ser sin duda el factor de primera elección. En otras palabras, la probabilidad de P (buen trabajo | buena experiencia relevante) es muy alta.

Es más confiable juzgar los méritos de un entrevistador a través de la experiencia del proyecto que a través de pruebas básicas y algorítmicas. Por lo tanto, durante el proceso de la entrevista, el entrevistador debe dedicar más tiempo a escuchar al entrevistador presentar la experiencia y la conducta del proyecto. -Análisis en profundidad Discutir y comunicarse para comprender el conocimiento, la capacidad de pensamiento, la capacidad de expresión, etc. Al mismo tiempo, puede hacer algunas preguntas sobre conocimientos básicos y algoritmos según el proyecto. Por ejemplo, si el entrevistador ha realizado un proyecto relacionado con C ++, puede preguntarle cómo administrar la memoria. ¿Está familiarizado con los punteros inteligentes? Si la respuesta del entrevistador no es satisfactoria, básicamente se puede juzgar que su proyecto no va muy bien.

Cabe señalar que la experiencia también es algo multidimensional. Por ejemplo, el sistema de middleware de negociación de acciones C++ implica tres dimensiones (C++, middleware y acciones). Supongamos que el entrevistador A ha trabajado en un cliente de negociación de acciones de C ++ y el entrevistador B ha trabajado en el middleware de negociación de acciones de C. Desde la perspectiva del idioma, A es la mejor opción y desde el punto de vista de la naturaleza del proyecto, B es la mejor opción. Esta es la cuestión de qué dimensión es más importante entre múltiples dimensiones. En lo que respecta a este ejemplo, personalmente prefiero B porque creo que la experiencia en desarrollo de middleware es la principal contradicción y cambiar de C a C++ no es un problema. Por lo tanto, el entrevistador debe determinar qué experiencia es primaria y cuál es secundaria. Por ejemplo, estamos contratando desarrolladores de aplicaciones de Android. El umbral técnico de Android para este puesto no es alto. La verdadera dificultad radica en crear una buena experiencia de usuario (UX). Por lo tanto, si un entrevistador no tiene experiencia en Android, somos aceptables, pero espero que tenga experiencia en UX y al menos haya realizado desarrollo de aplicaciones móviles para otras plataformas.

Carácter

Ahora, déjame hablar de lo que creo que es el factor más importante: el carácter. Esto puede resultar inimaginable para muchos amigos que son entrevistadores por primera vez. ¿Cómo puede ser que la personalidad sea lo más importante? Para ser honesto, ¡yo mismo me sorprendí cuando me di cuenta de esto! Para decirlo sin rodeos, P (buen trabajo | buena personalidad) tiene la mayor probabilidad. Mi experiencia real es que si una persona tiene una buena personalidad, tiene mayores posibilidades de hacer un buen trabajo. Una buena personalidad es mucho más confiable que una buena base y un buen algoritmo.

Si una persona tiene deficiencias técnicas y experiencia insuficiente, pero tiene buena personalidad, será fácil que otros ocupen su lugar en el equipo, y le será fácil a él ir llenándolo poco a poco; por el contrario, si una persona tiene mal carácter, todas sus ventajas técnicas y de experiencia no se pondrán en juego, e incluso pueden tener un efecto negativo. Además, las deficiencias de carácter son difíciles de cambiar. Siempre he dicho que lo que requiere el trabajo práctico es una capacidad integral, y el carácter es crucial para el desarrollo de esta capacidad integral. Los proyectos no solo encontrarán problemas técnicos, sino que también implicarán comunicación y coordinación. Diferentes personas y diferentes departamentos tendrán cooperación y fricciones. Cómo lidiar con estas cosas requiere un buen carácter. Se puede decir que lo que te hace único en un equipo de desarrollo no es la escuela en la que te graduaste ni tu experiencia pasada, sino tu personalidad.

Por supuesto, la personalidad es algo complejo que incluye muchos aspectos, y no es necesario centrarse en todos en las entrevistas con programadores. Mi experiencia es que puedes centrarte en examinar estos aspectos:

1) ¿La actitud es positiva o negativa? Algunos entrevistadores naturalmente le darán un sentimiento positivo y motivado en su conversación, o puede encontrar sus factores positivos en sus experiencias. Estos no son demasiado difíciles de ver. Al contrario, se pueden sentir claramente las emociones negativas de algunos entrevistadores. La positividad es muy importante en el trabajo. Las personas positivas pueden aportar vitalidad al equipo y facilitar la cooperación. Básicamente, si se determina que el entrevistador tiene una actitud positiva, la posibilidad de que pase mi prueba aumentará mucho, por el contrario, si se determina que el entrevistador tiene una actitud negativa, seré muy cauteloso incluso si el entrevistador tiene una actitud negativa; La capacidad técnica es buena.

2) Coeficiente intelectual. Mi experiencia es que, en general, las personas inteligentes se desempeñan mejor en el trabajo. Para comprobar si una persona es inteligente durante una entrevista, no es necesario encontrar algunas preguntas de inteligencia especiales para evaluar el coeficiente intelectual como Google y MS. De hecho, solo necesita ver si es muy lógico al discutir los problemas y si es inteligente. Es rápido en pensar y hablar. Puede emitir un juicio aproximado. Además, los ojos son las ventanas del alma humana, ya sea que una persona sea inteligente o no, los ojos pueden hablar. Sin embargo, ser inteligente no es del todo una ventaja. Por ejemplo, cuando una empresa o un proyecto encuentra dificultades, a menudo son las personas inteligentes las que huyen primero, y las que tienen un coeficiente intelectual promedio tienden a quedarse.

3) Capacidad de expresión del lenguaje. La capacidad de expresión lingüística también es una cualidad muy importante para los programadores, que está relacionada con una comunicación fluida en el proyecto. El entrevistador puede ver si puede utilizar un lenguaje conciso para presentar claramente los proyectos en los que ha trabajado, si puede captar los puntos clave y si puede tener en cuenta los antecedentes relevantes del oyente. En términos generales, las personas con fuertes habilidades de expresión lingüística no tienen habilidades generales deficientes.

4) Si tiene conocimiento del usuario. Algunas personas dicen que los programadores hacen investigación y desarrollo, entonces, ¿dónde están los usuarios? Sólo el personal de ventas y marketing tratará con los usuarios. De hecho, esto es un completo error. Escribes un módulo, o incluso una API, y siempre que alguien más lo use, son tus usuarios. Algunos programadores siempre están acostumbrados a considerar un módulo o una pieza de software desde la perspectiva del usuario y hacerlo lo más conveniente posible para el usuario. Esta es una especie de buena conciencia del usuario. Las personas con una buena conciencia del usuario son más capaces de considerar los sentimientos y las necesidades generales de otras personas, en lugar de simplemente pensar en los problemas desde su propia perspectiva local. Cuando el entrevistador habla sobre experiencias pasadas en proyectos, a menudo puede hacer preguntas desde la perspectiva del usuario y observar si tiene un buen conocimiento del usuario en el proceso.

5) Cómo afrontar las dudas y la presión. El entrevistador debe cuestionar razonablemente sus respuestas y proyectos anteriores para ver cómo responde. Una vez, un entrevistador habló sobre su experiencia en la creación de un servidor de inicio de sesión para juegos y le pregunté: "¿Qué debo hacer si el servidor de inicio de sesión falla?" Dijo que aunque no había considerado este tema originalmente, podía mejorarlo de alguna manera. De hecho, todo el mundo entiende que hay varias imperfecciones en el proyecto y que hay muchas razones para ello. Siempre que puedas afrontar con calma las dudas y la presión y trabajar duro para pensar y resolver en una buena dirección, no hay necesidad de hacerlo. Cubre los defectos y no debería haber emociones. He conocido a algunos entrevistados una vez que planteas preguntas sobre sus proyectos, inmediatamente se vuelven rebeldes, se sienten infelices o no admiten que hay un problema. Es fácil ver de un vistazo que no lo toleran. Cuestionamientos y críticas en el trabajo. Es difícil cooperar con estas personas.

6) Características de la personalidad. A muchos entrevistadores les gusta escribir "Competente en C++/Linux" en sus currículums. Estas palabras hacen que la gente se sienta insensible. Si alguien escribe "Me gusta C++/Linux", sentiré que mis ojos se iluminan. "Competente" es una narrativa sin emociones, mientras que "me gusta" contiene la personalidad del entrevistador. Prefiero ver la personalidad del entrevistador. Creo que la pasión genuina por algo es mucho más importante que tu nivel actual de dominio sobre ello. De hecho, N años de experiencia nos dicen que aunque los estudiantes de la misma clase y los colegas del mismo equipo de proyecto aprenden el mismo conocimiento y trabajan con el mismo trabajo todos los días, de hecho, las diferencias en las calificaciones y el desempeño de todos son muy obvias. de. Entonces, ¿cuál es la diferencia esencial? De hecho, es la personalidad de cada uno. Es la personalidad lo que hace que algunas personas jueguen a la pelota en su tiempo libre, algunas personas lean libros en su tiempo libre, a algunas personas les guste Linux y a otras les guste Mac. El papel de una persona en el equipo también tiene mucho que ver con su personalidad. El entrevistador debe guiar al candidato para que revele su personalidad y determinar si será beneficioso para el equipo.

Resumen

Finalmente, mi experiencia es: 1) El objetivo del entrevistador es encontrar personas que sean “buenas en el trabajo” y la entrevista debe realizarse en torno a este objetivo. malentendido al considerar la entrevista como un examen final de algoritmos o sistemas operativos; 2) El proceso de la entrevista consiste en juzgar de manera integral la probabilidad de que el entrevistador "haga un buen trabajo" a través de factores comprobables como calificaciones académicas, personalidad, base, experiencia y algoritmos; 3) Entre varios factores, personalidad > experiencia > fundamento > algoritmo. El carácter es lo más importante. Si el carácter no es bueno, todas las habilidades técnicas se reducirán considerablemente y los defectos técnicos son fáciles de compensar, pero los defectos de carácter son difíciles de cambiar. La experiencia refleja la capacidad integral de una persona y se puede juzgar; El entrevistador de su experiencia pasada. ¿Qué tipo de trabajo se puede y no se puede hacer? Los conceptos básicos y los algoritmos sirven principalmente como referencias auxiliares. Los programadores con buenos conceptos básicos generalmente son más adaptables y pueden aprender nuevas tecnologías más rápido, pero es importante no juzgar. persona basada únicamente en la capacidad básica.