Sobre la contratación. Vista desde allí / Sudo Null IT News
Un breve prefacio
Me inspiré para escribir este artículo en mi reciente comunicación con RR.HH. de empresas rusas. Y mi considerable sorpresa es lo pobre, desorganizado e improvisado que parece en comparación con sus colegas del otro lado del mundo. Esto parece muy sorprendente, considerando que muchas, si no la mayoría, de las empresas rusas de software se guían por las prácticas occidentales. Pero por alguna razón esta “visión” no se transforma en endeudamiento y adaptación de prácticas de contratación, sino que cualquier empresa está formada por personas. Contratar personas es lo primero que enfrentan todos los fundadores: ¿a quién llevar consigo? ¿Quién puede hacer esto o aquello? ¿Dónde se pueden encontrar personas con la motivación adecuada? Y el dinero no siempre ayudará aquí. Parafraseando a Maquiavelo, las personas adecuadas te aportarán mucho dinero, pero dudo que mucho dinero atraiga a las personas que necesitas. Por tanto, encontrar, evaluar y contratar a las personas adecuadas es una parte muy importante de la base de la empresa y no puede ser algo malo. No se puede construir una buena casa sobre unos malos cimientos. Mi objetivo en este artículo no es simplemente criticar a las empresas rusas, sino intentar señalar problemas obvios y, tal vez, sugerir posibles soluciones. Si las empresas rusas van a volverse grandes e internacionales, y espero que así sea, entonces tenemos que trabajar en los problemas.
Una pequeña nota. No soy un oficial de personal y todo lo que escribo a continuación es mi experiencia personal de muchos años de trabajo en los EE. UU. y mi impresión, que puede diferir de la situación real.
Sobre la contratación en EE.UU. (FAANG)
Vale la pena hablar un poco sobre cómo se produce la contratación en las BigTech en EE. UU. y cómo funciona el proceso de contratación en sí.
Empecemos un poco desde lejos, es decir, con la pregunta de ¿qué hace exactamente RR.HH.? ¿Qué papel juega en la organización? ¿Cuál es su estrategia? En términos abstractos, los recursos humanos estratégicos ayudan a organizar la vida en una organización de tal manera que corresponda más claramente a los objetivos comerciales de la organización. Y cuanto más grande es la organización, más formal y detallada se vuelve la planificación de recursos humanos. RR.HH. (estratégico) no es solo la contratación, sino también la vida de un empleado en una organización en general, a saber:
Planificar la futura fuerza laboral (¿deberíamos contratar o despedir? ¿cuántos? ¿a quién? ¿cuánto costará?)
Formación y competencias (¿a quién enseñar? ¿qué enseñar? ¿cómo?)
Desempeño (¿el personal trabaja bien o mal y por qué?)
Evaluación del Estado (¿A quiénes tenemos y qué están haciendo?)
Motivación (qué tan motivados están los empleados, cuántos quieren irse y qué hacer al respecto? ¿A quién promover, etc.)
Competencia por la mano de obra (¿Cómo atraemos gente? Cómo hacerlo para atraer más, etc.)
Estas son las principales cuestiones que aborda RR.HH. a nivel organizacional.
Sobre la imitación
He visto que muchas empresas rusas copian, a veces copian muy ciegamente, las prácticas de las empresas occidentales. A veces parece muy divertido. Por favor, comprenda que estas empresas están ubicadas en los EE. UU. y están sujetas a factores legales, culturales, económicos y de otro tipo específicos de los EE. UU. El tamaño de la empresa, sus objetivos comerciales y su situación financiera, nuevamente, forman una imagen única. Todo está interconectado y afecta la forma en que las empresas grandes, y a veces no tan grandes, contratan personas. No se deben copiar prácticas a ciegas, sin tener en cuenta los detalles y la comprensión detallada de las razones por las que se introdujeron estas prácticas, cómo y bajo qué condiciones funcionan.
Sobre cultura corporativa y entrevistas psicológicas.
Las bigtech son empresas enormes. La más grande es Amazon, con 1,5 millones de empleados, la más pequeña es Meta con 65 mil empleados. Con semejantes cifras, gestionar una empresa de este tipo es como gestionar una pequeña ciudad con su propia cultura, su propia demografía, clanes y sus propios problemas. En este tipo de empresas es físicamente imposible realizar un seguimiento de todos. Es imposible leer todos los informes de todos los gerentes y decidir a quién y para qué asignar dinero y a quién despedir. Por lo tanto, la “cultura empresarial” que inculca RR.HH. juega un papel importante aquí. Esto y 14 principios de Amazoni Googleyness en Googley “Be Bold” de Meta. Genera impacto. Vivir en el futuro”, etc. Cada empresa, a partir de un cierto tamaño, comienza a desarrollar e inculcar su propia cultura, que está subordinada a los objetivos comerciales (sí, siempre se trata de dinero) y al mismo tiempo resuelve tanto los problemas de gestión como los de atracción de personas. Las empresas hacen esto no porque sean “prácticas de moda” y todo el mundo lo haga, tal vez estén felices de no tener que lidiar con toda esta “mierda”, sino que es simplemente imposible hacerlo de otra manera. (Una vez más, sobre copiar: no es necesario copiarlo a ciegas. Estas son empresas estadounidenses que operan en condiciones estadounidenses, que son muy específicas, con personas de sociedades extremadamente diferentes, lo cual también es muy específico. Es necesario comprender todo esto y desarrolle su propio enfoque.) Debido a que la cultura es muy importante para la empresa, por muy absurdo que parezca, casi todas las BigTech incluyen una ronda llamada entrevista psicológica (entrevista de comportamiento). Amazon va aún más lejos: cada ronda de entrevistas contiene una o dos preguntas sobre los 14 principios. Es imposible pasar todas las rondas técnicas pero reprobar la entrevista conductual y ser contratado. Algunos detalles sobre dicha entrevista del entrevistador Meta*
Las preguntas para cada etapa de la entrevista se seleccionan con mucho cuidado. Aquí no hay preguntas aleatorias y cada pregunta, hasta el texto, se elige de manera que reciba una u otra “señal” del candidato. Casi nunca sucede que el entrevistador se siente y, mirando al techo, piense “¿qué más debo preguntar?”. Es difícil hablar en nombre de todas las empresas, pero Google y Meta tienen sus propios grupos de preguntas que se pueden utilizar en las entrevistas. Por supuesto, se actualizan y complementan constantemente: algunas preguntas se eliminan y otras se agregan. Se mantienen estadísticas y notas sobre todos los temas.
Como resultado, el candidato es evaluado tanto desde una perspectiva técnica como psicológica/cultural, y para los ingenieros la estructura de la entrevista se parece a esto: dos o tres rondas de codificación/algoritmos, una o dos rondas de diseño y una ronda de entrevistas psicológicas. . Intentan seleccionar preguntas de tal manera que descubran una habilidad, experiencia o comportamiento específico. La empresa quiere saber quién eres y de qué eres capaz y un poco sobre tu formación. El conocimiento en sí no juega ningún papel si no se extraen conclusiones de él. Para una gran empresa resulta extraño contratar a una persona que conoce varios lenguajes de programación, pero no es capaz de dominar otro. Por otro lado, si una persona es capaz de dominar cualquier lenguaje de programación, entonces resulta extraño exigirle conocimientos de uno concreto.
Acerca de la tarea de codificación
La parte técnica, a diferencia de la psicológica, probablemente será un poco más comprensible. Esto evalúa las habilidades, la formación y la capacidad actuales del candidato para resolver problemas en general con la gama de herramientas disponibles. Dos tipos de entrevistas: codificación con algoritmos y diseño.
La parte de codificación es probablemente la más formalizada. Ante un problema, dio una solución. El código deberá escribirse en la placa, a veces en el IDE; en todas partes es diferente. El objetivo de esta o estas rondas es comprender si el candidato puede escribir código, si conoce los algoritmos más populares y si puede aplicarlos. En un caso particularmente difícil, pero aquí no estoy muy seguro, se pone a prueba la intuición y la creatividad en relación con los algoritmos y la codificación.
¿Qué se evalúa al resolver un problema? El problema, por supuesto, hay que solucionarlo, esto es lo principal, pero hay algunas reservas. Si un candidato, después de recibir una tarea, inmediatamente comienza a resolverla, es una mala señal. Se necesitan unos 45 minutos para resolver el problema, y este tiempo incluye varias etapas: plantear el problema, aclarar los requisitos, explicar el algoritmo, el código en sí, discutir la solución y probar. Saltar directamente a la solución puede reducir la calificación a negativa con el texto “El problema le resulta familiar al candidato. Hay pocas señales para evaluar”. Opcionalmente, si tienes tiempo, puedes dar una tarea más y esto será un plus. Sin embargo, si las soluciones a ambos problemas se escriben en completo silencio, esto es un gran inconveniente. La comunicación es importante. El razonamiento es importante.
Sobre la tarea de diseño
El diseño es un poco más complicado, pero aquí es donde se valora la experiencia y hay espacio tanto para el candidato como para el entrevistador. En términos relativos, el propósito de esta ronda es evaluar la capacidad del candidato para abordar problemas grandes y complejos, la capacidad de dividirlos en partes y, en última instancia, ensamblar una solución a partir de esas partes. No es necesario tener conocimientos detallados y profundos de ninguna tecnología específica, aunque esto sería una ventaja. Si tienes experiencia y la sabes, genial, pero si falta algo, entonces no es gran cosa. El punto es un poco diferente. Se trata de valorar si el candidato es capaz de ver los problemas, comprender su profundidad y encontrar o sintetizar algún tipo de solución, ser capaz de evaluar los pros y los contras de esa solución, etc. El diseño y la arquitectura son siempre diversos compromisos y priorización de diversas propiedades del sistema resultante. No hay respuestas claramente correctas o inequívocamente incorrectas, no hay dogmatismo. No es necesario que el candidato conozca SOLID o Clean Code, como el Padrenuestro, pero si surge tal tema, debe explicar por qué se eligieron estos enfoques, cuáles son sus ventajas, cuáles son sus desventajas y cómo podrían mitigarse. etc.
Algunas palabras sobre lo que NO se pregunta.
No preguntan sobre un conocimiento profundo de una tecnología en particular. Por supuesto que hay excepciones, pero en general no. No importa si conoce los detalles de cómo funciona el recolector de basura o de cuántas formas se pueden crear objetos en Java. Nadie te pide que te sepas de memoria la API de las bibliotecas estándar. No hay preguntas como “¿qué generará este código”, etc.
Por lo general, no se requiere conocimiento de ningún idioma específico. Quizás, como excepción, solo C++. Basta con conocer y saber utilizar al menos algún lenguaje: Go, Java, Kotlin, Python, C, etc. Se da por sentado que se puede dominar cualquier idioma en tres o cuatro meses.
No se requieren conocimientos específicos de herramientas. Nadie se quemará con los comandos de git con cambios de base y fusiones complicados. Nadie exige saber de memoria las configuraciones de Kubernetis o Docker o cualquier otra cosa. Microsoft, por ejemplo, tiene tantas herramientas internas que simplemente no es razonable exigir conocimiento de ellas.
Acerca de los entrevistadores y las decisiones de contratación
Los entrevistadores tampoco son personas completamente aleatorias. No se permite entrevistar a nadie. Todos reciben una formación que explica en detalle cómo comportarse durante una entrevista, a qué prestar atención y qué se puede ignorar. En algunas empresas, los entrevistadores no hacen recomendaciones para contratar o no contratar. En lugar de ello, redactan un informe que luego es revisado por el comité de contratación. Esto hace que el proceso de evaluación esté menos sujeto a las preferencias personales de los entrevistadores y menos volátil.
Etiqueta
Etiqueta comercial estándar general y respeto por el tiempo del candidato. El retraso, si ocurre, es extremadamente raro. Todo el mundo entiende que los candidatos tienen su propio horario, y es posible que alguien incluso se haya tomado un día libre sólo para la entrevista y cancelarla o posponerla sea una pérdida de tiempo y recursos. No se realizarán cancelaciones y transferencias sin un motivo válido. Todos están haciendo su trabajo. Sin preguntas sarcásticas o cáusticas, sin evaluaciones personales como “no estás lo suficientemente calificado” o “tu conocimiento de Java es pobre”. No puedes responder así, es muy grosero. Simplemente te informan que no están dispuestos a hacer una oferta y te invitan a volver a intentarlo dentro de un año.
El proceso de contratación en BigTech es complejo, intenta evaluar candidatos de todos lados y se adapta a los objetivos globales de cada empresa específica. Cuanto mayor sea el nivel del candidato, más rondas habrá. Para un principiante, por ejemplo, puede saltarse la ronda de diseño; para un desarrollador experimentado, es posible que haya dos rondas de diseño; para un líder o gerente de equipo, puede hacer una ronda de codificación, pero agregar una ronda especializada en Habilidades de liderazgo y gestión de proyectos. Este proceso funciona bien para empresas ricas con un buen presupuesto, pero las pequeñas empresas también lo utilizan en alguna versión simplificada.
Sobre la contratación en Rusia
¿Cómo van las cosas con la contratación en Rusia? En resumen, “regular”.
Falta de recursos humanos estratégicos
De todas las empresas que entrevisté, ninguna mostró signos de planificación estratégica. La mayoría de las veces, la contratación recae en el director del proyecto (o departamento), quien determina (si es que determina) la estructura de las entrevistas y los tipos de preguntas. Las empresas no planifican las necesidades de personal ni tienen planes para desarrollar las habilidades del personal existente. En la mayoría de los casos, se trata simplemente de una profanación en forma de compra de cursos que enseñan habilidades que no se utilizan en las empresas. Toda la estrategia para atraer candidatos se reduce a la cuestión de los límites salariales superiores e inferiores. Este es sin duda un parámetro importante, pero está lejos de ser el único. Por alguna razón, las cuestiones de retención de empleados se dejan en manos de los gerentes inmediatos, en ausencia de una estrategia general y un sistema de motivación a nivel organizacional. El posicionamiento de las empresas (marca RRHH) en el mercado laboral es muy débil: todo se reduce a “pagamos más” o “tenemos galletas y ping-pong”. La edad media de un promotor es 39 años, ¿qué tipo de “ping-pong” le intentas decir a una persona con una hipoteca y una familia?
Falta de estructura para el proceso de entrevista.
Pero el mayor pecado, en mi opinión, es la falta de un proceso de contratación bien estructurado y claramente definido. Sólo Yandex y Sber tienen una comprensión fragmentaria de cómo podría organizarse este proceso. Pero la mayoría de las veces no está organizado de ninguna manera, hasta el punto de que el entrevistador no sabe de antemano qué preguntas hará. Casi nadie recopila ni almacena información sobre los candidatos y los resultados de las entrevistas, y mucho menos analiza el proceso (ningún proceso, nada que analizar). Lo más probable es que simplemente se descarte la información sobre los candidatos que no pasaron la entrevista. Nadie intenta invitarlos a una segunda entrevista después de un tiempo. Como resultado, debido a la falta de un sistema de evaluación unificado, nadie rastrea el crecimiento o estancamiento del candidato en comparación con sus intentos anteriores. Como resultado, la calidad de la contratación sigue siendo cuestionable y la falta de un sistema no permite identificar áreas problemáticas y encontrar formas de eliminar las deficiencias.
Acerca de los entrevistadores
La principal diferencia, salvo algunas excepciones, entre nuestros entrevistadores es su excesiva arrogancia. A veces está justificado, pero la mayoría de las veces no. A veces, parece que el objetivo principal del entrevistador es encontrar una pregunta que el candidato no puede responder, independientemente de si la pregunta revela las cualidades deseadas o no. Con un proceso de contratación sólido, RR.HH. ciertamente no debería tolerar este tipo de comportamiento en las entrevistas. Idealmente, cada entrevistador recibirá una breve capacitación sobre entrevistas en la que se le indicará cómo realizar una entrevista correctamente. Sólo recuerda que saber programar y entender Kubernetis no es algo difícil de dominar ni que requiera mucho esfuerzo mental. Casi cualquier persona lo suficientemente diligente es capaz de dominar esto; afortunadamente, hay muchos libros de texto, vídeos de formación y otra documentación de dominio público. El resto es experiencia. En general, no tiene sentido aquí despreciar; al contrario, la arrogancia es más un signo de incompetencia que de calificaciones.
El siguiente “pecado” de nuestros entrevistadores, que a menudo se encuentra entre sus colegas en Occidente, es la falta de comprensión de QUÉ buscan en un candidato y, como resultado, no entienden CÓMO buscarlo. Como dicen, si entra basura, sale basura. Aquí, probablemente, se demuestra claramente la limitada transferibilidad de conocimientos y habilidades. Los desarrolladores que entienden bien las pruebas de programas no pueden traducir técnicas similares a las personas que realizan pruebas, ni siquiera en principios básicos como “qué estamos probando”, “qué métodos”, sin mencionar técnicas más avanzadas para evaluar la efectividad de las pruebas. En pocas palabras, la capacidad de probar programas y sistemas de software no se traduce en la capacidad de probar (probar habilidades y conocimientos) a las personas, a pesar de la similitud del proceso. Por lo tanto, no se comprende ni el propósito de las preguntas formuladas ni las respuestas recibidas.
Qué estamos buscando
Debido a los sesgos descritos anteriormente y la falta de un sistema, las preguntas de la entrevista en el mejor de los casos prueban si un candidato conoce una API específica o una sintaxis de lenguaje y hacen poco para probar sus habilidades y capacidad para resolver problemas encontrados en el trabajo real. Por supuesto, conocer las complejidades de la sintaxis del lenguaje o cualquier característica de la API utilizada es una ventaja y de alguna manera ayuda en el trabajo, pero hay un problema. Los lenguajes evolucionan y las herramientas y sus API cambian. Peor aún, los conocimientos adquiridos ni siquiera son la base para otros nuevos. Déjame aclarar un poco mi idea aquí. Sí, la familiaridad con un lenguaje de programación ayuda a aprender otro, la experiencia en el uso de una API ayuda a dominar otra. Sin embargo, se trata de una transferencia horizontal, no vertical. Un idioma no siempre es una extensión de otro, y las nuevas API a menudo utilizan modismos completamente nuevos. En este caso, al contratar basándose en conocimientos tan volátiles, la empresa corre el riesgo de conseguir un empleado irrelevante en el plazo de un año. Por supuesto, si una empresa contrata para un proyecto urgente, entonces este enfoque es bastante válido, pero más a menudo la contratación es por un período indefinido. Si un conocimiento específico rápidamente queda obsoleto y no satisface las necesidades de la empresa, ¿qué se debe preguntar en una entrevista y cómo evaluar las respuestas? Cada empresa debe encontrar la respuesta a esta pregunta en detalle, pero en general, puedes pensar y encontrar algunas recomendaciones basadas en la experiencia de colegas occidentales (adaptadas, por supuesto).
Imagen del candidato
En relación con los desarrolladores, debemos verlo en su conjunto: ¿qué hacen realmente? Se enviarán o desarrollarán varios programas, pero esto es sólo una parte de la respuesta. La segunda parte es que escriben y desarrollan estos programas basándose en descripciones verbales. A veces detallados y claros, pero más a menudo bastante extensos recibidos de no especialistas. es decir, el desarrollador es quien transforma los requisitos en un programa, aclarándolos en el camino y resolviendo los conflictos que surjan. A partir de aquí, en mi opinión, podemos determinar QUÉ estamos buscando, y de aquí se desprende el siguiente conjunto de habilidades que debe tener un candidato:
Algunos conocimientos y habilidades básicos. (La mayor parte de estos conocimientos y habilidades se obtienen en universidades especializadas. Confiar en ellas o no es un asunto personal. Sólo se puede realizar una verificación de cordura). Estos conocimientos y habilidades generalmente incluyen algoritmos básicos y estructuras de datos, conocimiento de al menos un lenguaje de programación y una cierta visión general.
La capacidad de analizar un problema, es decir, dividirlo en partes, determinar las propiedades de estas partes y sintetizar una solución.
Capacidad para transmitir tu idea.
Sea un jugador de equipo (normalmente esto sólo significa no ser conflictivo, estar abierto a las críticas y no causar problemas en general)
Comprender los objetivos de la empresa o al menos del proyecto.
Algunos requisitos adicionales dependiendo del puesto y naturaleza del trabajo, que cada empresa deberá determinar por sí misma.
Estas son aproximadamente las cualidades que la mayoría de las empresas quieren ver, incluso si no se dan cuenta. Lo ideal sería que cada parte se comprobara en una entrevista por separado, lo que probablemente encarecerá el proceso, pero la tarea será más fácil para el entrevistador. Si combina todo en una o dos entrevistas, esto creará una mayor carga para el entrevistador y requerirá más experiencia y preparación por su parte. En cualquier caso, es bueno tener tres partes claramente separadas: codificación, arquitectura/diseño y comportamiento.
Tarea de codificación
Como se mencionó anteriormente, el objetivo de la tarea es comprender qué tan habilidades de codificación tiene el candidato y cómo aplica algoritmos y estructuras de datos populares. También puedes incluir preguntas sobre el conocimiento de la sintaxis del idioma, si esto es realmente importante. Los problemas deben seleccionarse de modo que leer las condiciones no lleve demasiado tiempo y la solución no sea demasiado larga, pero tampoco demasiado corta. Asegúrese de tener dos o tres tareas en reserva, en caso de que el candidato esté familiarizado con la tarea.
No es necesario mencionar un problema que encontró hace una hora en leetcode. El entrevistador debe tener una buena comprensión de cómo se resuelve el problema, qué problemas puede haber en cada solución, qué consejos dar y cómo evaluar la solución. De lo contrario, el entrevistador simplemente no está preparado para la entrevista y corre el riesgo de reprobarla, es decir, perderse al candidato adecuado.
En general, no es necesario plantear problemas en estilo leetcode. Puede idear otro formato si le permite evaluar las habilidades requeridas del candidato. Sólo es necesario distinguir con precisión la evaluación de habilidades de la evaluación de conocimientos previos. Por ejemplo: escribir un recorrido de un árbol contando algo en cada vértice es una habilidad, pero implementar el ordenamiento por burbujas o peor aún, preguntar sobre la estructura de las cadenas en Java es un libro de referencia. Solicitar conocimientos previos, así como la implementación de un algoritmo popular, no tiene mucho sentido. No indican la habilidad de utilizar el algoritmo y poco pueden decir sobre la capacidad de construir una solución. Y esto es precisamente lo más importante.
Mis principales preguntas inútiles formuladas en las entrevistas:
Cuéntanos cómo funciona GC en Java.
Nombra las clases de java.util.concurrent o algún otro paquete o biblioteca
¿Cómo funciona Hashmap?
¿Cómo funciona el Árbol Rojo‑Negro?
¿Cuánta memoria ocupa un objeto?
Escribe un singleton. (y más adelante con todas las preguntas hasta singleton seguro para subprocesos)
Si realmente necesita que el candidato sepa estas cosas de memoria, simplemente puede pedirle que las aprenda antes de la entrevista y simplemente probar sus conocimientos en la entrevista.
Tarea de diseño y arquitectura.
Aquí, como muchos dicen, no hay respuestas correctas o incorrectas. En general, la tarea debe ser tal que no pueda cubrirse completamente durante una entrevista de una hora. Tanto en amplitud como en profundidad. La tarea se establece específicamente de la manera más amplia posible y es responsabilidad del candidato revelarla de la manera más amplia y profunda posible. Aquí debe explicar claramente lo que quiere del candidato y guiarlo suavemente en la dirección correcta si de repente “vuela hacia la estratosfera”. El objetivo es comprender cómo el candidato afronta problemas complejos y poco claros y cuánta experiencia tiene en el área de interés para la empresa. El candidato debe hablar el 90% del tiempo en esta ronda, y el entrevistador actúa más como referencia y en ocasiones hace preguntas. Como se dijo anteriormente, lo principal aquí es la capacidad de analizar el problema y sintetizar una solución. Por supuesto, dentro del área de dominio profesional del candidato. Probablemente no deberías hacerle una pregunta a un desarrollador backend sobre el diseño de una aplicación móvil. El punto no es obtener la respuesta “correcta” o una respuesta que sea similar a un sistema implementado en algún lugar; después de todo, esto es una entrevista, no un diseño de sistema; el punto es descubrir las habilidades y experiencia específicas de la persona. .
Nuevamente, las empresas pueden optar por utilizar un formato diferente que sea más relevante para sus objetivos y el área en la que operan.
¿A qué debes prestar atención en esta entrevista? La tarea se presenta en la forma más general y es necesario “revelarla”, lo que significa que se necesita comunicación. Si el candidato comienza a dibujar cuadrados en el tablero en silencio, esto es un gran inconveniente. Además, ¿qué tan realistas están delineados los límites del sistema, qué tan claros son sus requisitos, al menos en el nivel superior, y si todo esto se basa en algunas suposiciones razonables? Qué enfoques se han elegido y en qué medida estos enfoques cumplen con los requisitos del sistema. ¿Está el candidato con la cabeza en las nubes y diseñando un “sistema esférico en el vacío” o se deja llevar demasiado por los detalles en contraposición a la estructura general? Hay muchos aspectos en esta ronda y, como ya se dijo, debe estar especialmente estructurada para que sea imposible cubrir todos los aspectos durante la entrevista. Para Rusia, la especificidad de esta sección probablemente será que la industria aquí no está lo suficientemente desarrollada y opera en una escala ligeramente diferente. Y, aunque la formación de los especialistas rusos es, en promedio, muy alta, todavía tienen menos oportunidades de trabajar en proyectos verdaderamente globales y complejos. Debido a esto, algunos aspectos del diseño pueden eludir a los desarrolladores rusos o no desempeñar un papel importante.
¿Qué están haciendo mal nuestros entrevistadores aquí? La primera es una entrevista de culto al cargo. Es similar en forma, pero en esencia es completamente diferente. Probablemente, nuestros entrevistadores creen que existe una respuesta correcta y están tratando de evaluar qué tan cerca está el candidato del “ideal”. El segundo es el dogmatismo de los enfoques, lo cual es muy extraño para mí: SOLID, DRY, KISS, MVC, MVI, Clean Architecture, GRASP, SQL vs NoSQL vs NewSQL, hay una legión de ellos. De eso no se trata esta entrevista. En tercer lugar, excesiva exigencia en detalles que no son clave para la tarea encomendada. Por ejemplo, qué es mejor, lanzar una excepción o devolver un código de error y luego discutir este caso durante media hora.
De manera similar a una entrevista de codificación, al final puedes revisar la lista de verificación y darle una puntuación determinada al candidato (para ti).
Al final de la entrevista, las respuestas a preguntas como:
¿Puede el candidato codificar? ¿El candidato comprende la tarea? (a veces no entienden, pero ya están escribiendo una solución). ¿El candidato expresó el algoritmo de solución? ¿Tiene un buen conocimiento de la complejidad algorítmica? ¿Ha considerado/sugerido opciones alternativas? ¿Escucha las indicaciones del entrevistador y cómo reacciona ante ellas? Y preguntas similares. Lo que pasa es que nadie está interesado en resolver el problema.
Por cada respuesta positiva, podrás asignar un punto, que al sumar dará la nota final de esta entrevista.
Entrevista conductual
Una entrevista de comportamiento para TI rusa probablemente será la más singular y diferente a una entrevista similar en empresas occidentales. Si las empresas occidentales valoran la independencia y la apertura, así como el cumplimiento de las reglas, entonces en Rusia se puede valorar la diligencia, la obediencia y el cumplimiento de las tradiciones. En Estados Unidos la gente prefiere ser educada y teme ofender a una persona con la verdad, pero en Rusia prefieren la verdad a la cortesía. En Estados Unidos se ha desarrollado una cultura de comunicarse con indirectas y medias indirectas, mientras que en Rusia prefieren la franqueza. En Rusia, la vida y el trabajo están estrechamente relacionados, pero en los EE.UU. existe una clara frontera entre estos ámbitos. En general, existen muchas diferencias culturales que, por supuesto, conviene tener en cuenta. De lo contrario, todo depende de la empresa, de su estilo de liderazgo y de su cultura interna (o falta de ella). En cualquier caso, me parece que lo más importante de esta entrevista será la oportunidad de obtener respuestas a las siguientes preguntas:
¿Cuáles son los objetivos de una persona en general?
¿Está interesado en TI en general?
¿Está interesado en la empresa y el producto (o proyecto)?
¿Cómo interactúa con la gente?
¿Qué tan conflictivo es, digamos?
Esta no es una lista obligatoria, cada empresa la define de forma diferente. Me parece que las respuestas a estas preguntas nos permitirán formarnos una opinión definitiva sobre una persona. ¿Será conflictivo o, por el contrario, se convertirá en el alma del partido? ¿Le gusta lo que hace y tiene un orgullo profesional que no le permite hacer un mal trabajo, o simplemente trabaja por dinero (que también es bastante adecuado para algunos tipos de proyectos)? ¿Vino a la empresa porque “tu producto es una completa mierda y quiero arreglarlo” o vino porque “tu producto es genial y quiero participar”? En general, ¿esa persona aportará más cosas positivas o más negativas a la empresa? Es difícil dar aquí ejemplos concretos, todo depende en gran medida de la propia empresa.
Decisión y evaluación
Entonces, realizamos una serie de entrevistas, incluso si todo estuvo comprimido en una hora (aunque no puedo imaginar cómo puedes encajar todo en una hora y obtener señales significativas) y necesitamos decidir si contratar o no. Una de las principales propiedades de este proceso es que debe ser lo más independiente posible de las preferencias personales de los entrevistadores.
Uno de los métodos más sencillos, aunque no exento de costes, es el consenso: todos los entrevistadores deben dar una respuesta positiva o al menos no negativa. O 2 de cada tres. O 3 de 5, etc.
Otra opción es simplemente sumar las puntuaciones de cada ronda y contratar al que tenga el número más alto.
Para las grandes empresas con contratación masiva, se pueden establecer algunos estándares. Digamos que contratamos al 80% superior. Por ejemplo, calificamos cada entrevista del 1 al 5 y la puntuación para aprobar es 12 o más (80% superior). El candidato recibió un 3 en codificación, 5 en arquitectura y 4 en comportamiento. 3+4+5 = 12, lo cual es aprobado. Por supuesto, para mayor precisión, puedes ingresar más parámetros y puntos para cada ronda.
Después de contratar
Por supuesto, no termina con la contratación. Después de la contratación, también debes continuar recopilando información sobre el empleado y compararla con la información obtenida durante el proceso de entrevista para mejorar y aclarar la contratación. Por ejemplo: durante una entrevista de comportamiento, un empleado tuvo un buen desempeño, pero luego resultó que constantemente se mete en varios conflictos. Quizás necesite averiguar el motivo y cambiar la entrevista de comportamiento en consecuencia. Lo mismo en la otra dirección. Complicamos las tareas de codificación de entrevistas, pero esto no afectó la cantidad de errores por persona o, por ejemplo, la velocidad de implementación del proyecto siguió siendo la misma. Probablemente, aumentar la complejidad de las tareas no aumente la calidad de los candidatos en este parámetro. Todos estos son ejemplos ilustrativos y no deben tomarse literalmente.
Total. La estrategia de RR.HH., basada entre otros en los objetivos de la empresa, desarrolla una estructura para contratar y motivar a los empleados. Dependiendo de la estrategia adoptada, se desarrolla un sistema de análisis de la efectividad de estas acciones. Se determina un conjunto de competencias requeridas para programadores/desarrolladores. A continuación, se definen las etapas específicas de la entrevista y los resultados esperados de estas entrevistas. El objetivo es recopilar la mayor cantidad de información posible sobre el candidato y descubrir en qué nivel tiene las habilidades necesarias para desempeñar sus funciones laborales. Dependiendo del conjunto de habilidades, se seleccionan el estilo y las preguntas apropiados para cada ronda. A partir de los resultados de las entrevistas, en función de los planes y la estrategia de contratación de la empresa, se toma una decisión de contratación. Todo el proceso se analiza y optimiza periódicamente.
Por supuesto, el sistema descrito parece grande y engorroso. Y es cierto: su forma completa no es adecuada para todas las empresas, pero creo que debería existir algún tipo de sistema de contratación, aunque sea de forma más sencilla. Habiendo construido al menos un sistema simple, será posible evaluarlo y mejorar gradualmente sus parámetros. Sin un sistema, no importa cuán talentosos sean sus entrevistadores, la calidad de sus empleados siempre se verá afectada. El sistema gana al talento. Las personas son un elemento importante de la base de la empresa y la contratación de personas debe ser sistemática y de alta calidad.
* Meta y Facebook son organizaciones prohibidas en la Federación Rusa.
