¡Hola a todos, mis queridos lectores!
Hoy quiero compartir mis pensamientos sobre un tema que ha estado muy presente y, posiblemente, discutirlo en los comentarios.
Con bastante frecuencia encuentro artículos sobre malas prácticas en entrevistas para puestos de programador, que a mi juicio son bastante pertinentes y, espero, leídas por los departamentos de recursos humanos de grandes empresas y otras más pequeñas.
En nuestra región, por lo que he podido juzgar, hay una demanda de entidades tan interesantes como los ingenieros de DevOps. Yo soy de las personas que no perciben bien esa combinación de palabras (sí, sí, metodología DevOps, etc.), por lo que veo ciertas diferencias en las trayectorias de desarrollo de este grupo de especialistas.
Primero que nada, creo firmemente que cada persona tiene su propio círculo de intereses, incluso en el ámbito laboral, es decir, hay quienes prefieren la nube, otros se dedican a profundizar en servidores de aplicaciones, configurar Java a fondo, y otros más escriben código en Python o, Dios no quiera, código en yaml. Así surgen los llamados ingenieros de infraestructura, ingenieros de construcción, desarrolladores senior de Yaml 🙂
Todo esto, por un lado, permite encontrar a la persona más adecuada para su conjunto de tareas, pero, por otro lado, genera malentendidos en las entrevistas.
Basándome en mi experiencia personal, tras haber realizado varias decenas de entrevistas y también haber participado en diversas ocasiones como respondedor, quiero compartir mi perspectiva sobre todo lo que está sucediendo.
El primer y probablemente mi antipatía favorita es el deseo de encontrar a alguien que haga todo, o que no se tiene claro quién se necesita, y se revisa a un montón de candidatos, ahí ya se verá. Probablemente esto sea aplicable a cualquier área, pero aquí tiene sus peculiaridades.
Como he notado, las personas están más interesadas en vacantes que contienen la palabra DevOps que en Administrador de Sistemas, aunque a mi parecer, en el nivel Senior, la gama de tareas difiere enormemente entre estas dos áreas.
Cualquier empleador que realmente necesite un sysadmin escribe en el título de la oferta DevOps, enumerando en el cuerpo de la solicitud absolutamente todo lo que se le ocurra, K8S/Java/gradle/oracleDB y así sucesivamente, aunque en el fondo, la persona se dedicará al soporte del clúster K8S y al soporte de la pila OracleDB, independiente del equipo.
Entonces, ¿cuál es la interacción entre el formato de Developers/Operations?
Luego se descubre que no hay un proceso definido para interactuar con el equipo, y en general, no existe un departamento de operaciones, por lo que tendrás que configurar las computadoras de los desarrolladores.
Esta opción, de hecho, es adecuada para algunos solicitantes, pero seamos honestos, esto es para un Administrador de Sistemas Senior, así que ¿por qué no quieren escribirlo así y qué tiene de vergonzoso? ¿La diferencia en salarios entre diferentes títulos? Pero el presupuesto de la empresa es uno, y, sea cual sea el nombre del barco, navegará según su presupuesto.
He oído que ahora los candidatos automatizan todo rápidamente y se integran en el desarrollo de productos en Python; al final, Python es el mismo en todas partes. No se tienen en cuenta las diferencias en la mentalidad y en los enfoques.
Normalmente, a este nivel, diferencio el nivel de los especialistas que llegan y veo mis propios problemas de manera separada para cada uno.
Junior — para mí, un Junior DevOps es alguien que ha dominado a un nivel medio la administración de sistemas/desarrollo. Aquí es agradable diferenciar a los buenos linuxeros que quieren crecer en un nuevo campo, o a los desarrolladores que quieren hacer bien para otros desarrolladores. Fuertes, con algunas habilidades en depuración, búsqueda de logs, o con un historial de proyectos codificados.
He encontrado tanto administradores de sistemas que han probado algo y quieren tocar la nube, como aquellos que han probado front-end y back-end y, por alguna razón, han encontrado interés en los procesos de DevOps.
A este nivel, siempre me molesta cuando empiezan a mencionar una enorme pila de tecnologías, Puppet, Ansible — ¿por qué no has probado todo? K8S, K3S — ¿cuál es la diferencia? ¿Cuántos tipos de bases de datos conoces? ¿Por qué tan pocos? ¿Cómo funciona el cifrado en Java? Especialmente aquellos que vienen del desarrollo, aunque son recursos muy útiles, siempre hay trabajo para ellos en este campo.
Siempre me deja perplejo cuando ocurre esto; lo primero que quiero preguntar es — ¿por qué??? Lo segundo que me viene a la mente es — ¿está el entrevistador preparado para responder preguntas sobre una pila de tecnologías tan diversa? ¿De verdad quieren contratar a un junior y cargarle todo?
A menudo sucede en diversos body shops, cuando hay que vender a una persona para algún proyecto y se necesita más palabras impactantes para el currículum, o la empresa simplemente no quiere contratar a nadie, sino que observa qué tipos de juniors existen.
Nivel Middle
Aquí hay algunas extremos en mi opinión. En primer lugar, es difícil determinar claramente si una persona está al nivel intermedio; o bien intentan reducirla al nivel junior, o comienzan a tratarla como a un senior, tratando de conseguir un senior por el precio de un intermedio (sí, el mercado decide, nada personal).
Lo más sorprendente que he visto es que se profundiza en el código, se programa en Python, se tortura con Java GC, es decir, temas más específicos, o por el contrario, se abren las brechas en conocimientos que no se han utilizado durante mucho tiempo, se navega por redes, tipos de controladores de sistema operativo, sonriendo y maliciosamente pensando en cómo pudo olvidar eso una persona. ¡Y aquí es donde pasa lo más interesante!
En mi opinión, para alcanzar el nivel intermedio, un especialista forma un círculo de intereses y una perspectiva personal sobre con qué quiere trabajar: si desea destacar en la tecnología más reciente, insertándose en un cubo de truco, o si quiere desarrollarse para aterradoras empresas, profundizando en el rendimiento del código.
En mi opinión, aquí ya se debe preguntar sobre los procesos en los que la persona ha trabajado, qué le fue más interesante y qué no, y basándose en esos conocimientos, construir un conjunto de preguntas, mapeando necesariamente las preguntas a su tecnología. De lo contrario, después de una fascinante conversación de una o dos horas sobre la configuración de un clúster de OpenShift, se contrata a una persona y se le dice que construya la monitorización. Probablemente esto agradará a ambas partes.
Nivel Senior
Oh, mi nivel favorito.
Ante ustedes hay un experto sólido, que se ha formado en diferentes tipos de proyectos, una persona que ya sabe qué quiere y qué no le gusta tanto.
Y aquí comienza el espectáculo:
— preguntas profundas sobre administración de sistemas (ver el primer antipatente)
— preguntas profundas sobre Linux en general desde el área de teoría, lejos de conocimientos prácticos (pregunta clave sobre niveles OSI)
— preguntas académicas sobre programación (porque el propio entrevistador no sabe bien el área, simplemente le pidieron entrevistar a un extraño DevOps)
Haré aquí una pequeña anotación. Una vez, en una entrevista, me pidieron que escribiera un trozo de código. En un papel. Bueno, como a todos les gusta, escriben todos los días, el papel es todo para nosotros.
Después de afrontar la tarea y tras revisar mis notas y resolver, se emitió el veredicto de que el algoritmo sería subóptimo. Propuse que el entrevistador escribiera su propio algoritmo, a lo que recibí como respuesta: «Eso no está dentro del alcance de la entrevista». Pedí un momento, ajusté un poco el código y lo mostré, preguntando si así sería más rápido o más lento. A lo que obtuve como respuesta: «Pasemos a la siguiente pregunta». La diferencia estaba en el funcionamiento del código en un bucle y sin él, y tenía preparado un argumento sobre por qué era mejor hacerlo de una manera y no de otra. Después de eso, ya no tenía ganas de responder más preguntas ni de trabajar con esta persona.
Hay que tener en cuenta que todos somos diferentes y cualquier cosa que para usted no sea relevante puede ahuyentar al candidato.
— En general, los especialistas de nivel Senior tienen claramente definido su stack de trabajo, sin embargo, se empieza a hacer preguntas sobre tecnologías cercanas. Por ejemplo, ustedes tienen Ansible, genial, nosotros tenemos Puppet, simplemente les llamamos para preguntarles, cuéntenos sobre Puppet. ¡Espléndido! ¿Han trabajado con OpenShift? Nosotros usamos K8s, no sabemos de diferencias, pero su experiencia no es relevante. ¡Maravilloso!
También hay una subclase: personalmente, tomo pasantes con potencial para convertirse en juniors.
Me gustaría que todos entendieran que un pasante es una entidad que aún no está formada en absoluto. Me aterra cuando los pasantes empiezan a ser evaluados al nivel de un Junior sólido y luego, con una expresión satisfecha, se les ofrece una pasantía (a veces no remunerada, ¡un desastre!).
No hay necesidad de eso.
Un pasante, en mi opinión, es ya sea un estudiante de los últimos años, o bien alguien que realmente quiere 'entrar en TI'.
Con los estudiantes es simple: averiguar qué están haciendo en la universidad, qué han hecho por su cuenta, observar en qué temas se les iluminan los ojos; si se iluminan, preguntar por qué DevOps y qué saben sobre ello. Sentir a la persona y entender si será agradable trabajar con ella, si se quiere enseñar algo a esta persona en particular.
Con aquellos que quieren 'entrar en TI', es un poco más estricto: observar cuánto se autoaprenden, qué han hecho antes de llegar a la entrevista, aquí sería bueno revisar GitHub, si lo tienen, la densidad de los commits y qué ejercicios han realizado. También preguntarles por qué eligieron DevOps, ya que en frontend es más divertido y complicado.
Y, por último, me gustaría dar un consejo más: defínanse sobre quién realmente necesitan y encontrarán a la persona adecuada de inmediato. Identifiquen las necesidades, vean al especialista como un experto, identifiquen sus fortalezas y utilícenlas eficazmente en su trabajo. Sean atentos con el candidato, él vino a ustedes para una conversación, no para una competencia de quién logra hacerlo fallar o no.
Fuente: habr.com
