Antipatrones de entrevistas de DevOps

¡Saludos a todos ustedes, mis queridos lectores!

Hoy quiero compartir mis pensamientos sobre un tema de larga data y tal vez discutirlo en los comentarios.
Muy a menudo me encuentro con artículos sobre malas prácticas en entrevistas para el puesto de programador, que en mi opinión son bastante relevantes y, espero, sean leídos por los departamentos de recursos humanos de empresas grandes y no tan grandes.

En nuestra zona, hasta donde yo sé, existe una demanda de entidades tan interesantes como los ingenieros de DevOps. Soy de esas personas que realmente no entienden esta frase (sí, metodología DevOps, etc.), por eso veo algunas diferencias en los caminos de desarrollo de este grupo de especialistas.
En primer lugar, creo firmemente que cada persona tiene su propia gama de intereses, incluso en el área laboral, es decir, a algunos les gusta la nube, a otros les gusta profundizar en los servidores de aplicaciones, configurar Java profundo y algunos escribir código en Python. o Dios no lo quiera código yaml. Es decir, aquí aparecen los llamados ingeniero de infraestructura, ingeniero de construcción y desarrollador senior de Yaml :)
Todo esto permite, por un lado, encontrar a la persona que mejor se adapta a su conjunto de tareas y, por otro, genera malentendidos durante las entrevistas.
Basándome en mi experiencia personal, he realizado decenas de entrevistas, y también he participado en varias como imputado, quiero compartir mi visión de todo lo que está pasando.

El primero y probablemente mi antipatrón favorito es el deseo de que alguien haga todo, o no está claro a quién se necesita, miraremos a un grupo de candidatos y lo entenderemos. Probablemente esto se aplica a cualquier ámbito, pero tiene sus propias características.
Como noté, la gente está más ávida de trabajos con las palabras DevOps que de Administrador de sistemas, aunque en mi opinión, en el nivel Senior, el alcance de las tareas difiere lo más posible en estas dos áreas.
Cualquier empleador que realmente necesite un administrador del sistema escribe devops en el título de la vacante, enumerando absolutamente todo en el cuerpo de la solicitud, K8S/Java/gradle/oracleDB, etc. en la lista, aunque desde adentro la persona tendrá que lidiar con el soporte del clúster K8S y el soporte de la pila OracleDB de forma aislada del equipo.
Bueno, es decir, ¿qué tipo de interacción hay entre el formato Desarrolladores/Operaciones?
Además, resulta que no existe tal proceso de interacción con el equipo y, en general, no hay operaciones como departamento y hay que configurar las computadoras de los desarrolladores.
Esta opción en realidad se adapta a algunos solicitantes, pero seamos honestos, este es un administrador de sistemas senior, entonces, ¿por qué no quieren escribir así y qué tiene de vergonzoso? ¿Diferencias de salario entre diferentes puestos de trabajo? Pero la empresa tiene un presupuesto y, sin importar cómo se llame el barco, navegará con su propio presupuesto.
Bueno, incluso escuché sobre esto, ahora el candidato automatizará todo rápidamente y se unirá al desarrollo de un producto en Python, cuál es la diferencia, Python es igual en todas partes. No se tienen en cuenta las diferencias en cosmovisión y enfoques.

A continuación, suelo diferenciar el nivel de especialistas que vienen y ven sus problemas por separado para cada uno.
Junior: para mí personalmente, Junior DevOps, es una persona que domina la administración/desarrollo de sistemas a un nivel medio. Aquí es bueno diferenciar entre usuarios fuertes de Linux que quieren crecer en un área nueva, o desarrolladores que desean hacer el bien a otros desarrolladores. Fuerte, con algunas habilidades en depuración, búsqueda de registros o con cierto stock de proyectos codificados.
Conocí tanto a administradores de sistemas que intentaron algo y querían tocar las nubes, como a aquellos que lo intentaron por delante y por detrás y por alguna razón encontraron interés en los procesos DevOps.
A este nivel, siempre me confunde cuando empiezan a lanzar una gran cantidad de tecnologías, Puppet, Ansible. ¿Por qué no lo intenté 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 los que vienen de desarrollo, aunque son personal muy útil, siempre hay trabajo para ellos en esta área.
Siempre estoy en estupor cuando esto sucede, lo primero que quiero preguntar es ¿por qué??? Lo segundo que me viene a la mente es: ¿está el propio entrevistador preparado para responder preguntas sobre un conjunto tan diverso? ¿Realmente quieren tomar a June y culparlo todo?
A menudo esto sucede en todo tipo de talleres de carrocería, cuando necesitas vender a una persona para algún proyecto y necesitas más palabras interesantes para tu currículum, o la empresa no quiere contratar a nadie, solo mira qué tipo de jóvenes hay.

Nivel medio
Aquí hay varios extremos, en mi opinión, en primer lugar, probablemente sea difícil determinar claramente qué se siente atraído por una persona para ser el medio, o intentan desperdiciarlo hasta junio o comienzan a conducirlo como un mayor, tratando de agarrarlo. un senior al precio de un middle (sí, el mercado decide eso, nada personal)
Lo más sorprendente que he visto es profundizar en la codificación, jugar con Python, atormentar el GC de Java, es decir, con temas más específicos, o viceversa, revelando lagunas en el conocimiento que no se ha utilizado durante mucho tiempo. , conduciendo a través de redes, tipos de controladores de sistema operativo, sonriendo y regodeándose, ¿Cómo podría una persona olvidar esto? ¡Y aquí sucede lo más interesante!
En el nivel medio, en mi opinión, un especialista desarrolla una gama de intereses y una visión personal de con qué quiere trabajar: promocionar la última pila, meter un truco en un cubo o apostar por una empresa terrible. profundizando en el rendimiento del código.
En mi opinión, vale la pena preguntar aquí sobre los procesos en los que trabajó la persona, preguntar qué fue lo más interesante y qué no, y con base en este conocimiento, construir un grupo de preguntas, generalmente agregando preguntas a su pila. De lo contrario, después de tener una conversación fascinante durante una o dos horas sobre la configuración de un clúster de OpenShift, contrate a una persona y asígnele la tarea de crear monitoreo. Probablemente les guste a ambas partes.

Nivel superior
Oh mi nivel favorito.
He aquí un fuerte especialista que se ha criado en diversos tipos de proyectos, una persona que ya sabe lo que quiere y lo que no le gusta.
Y así comienza el espectáculo:
— preguntas profundas sobre la administración del sistema (ver el primer antipatrón)
— preguntas profundas sobre Linux en general desde el campo de la teoría, lejos del conocimiento práctico (pregunta principal de los niveles OSI)
— preguntas académicas sobre codificación (porque el entrevistador no conoce realmente el campo, simplemente le pidieron que entrevistara a un extraño tipo de Devops)
Haré un pequeño comentario aquí. Un día, durante una entrevista, me pidieron que escribiera un código. En un trozo de papel. Bueno, como a todos les encanta, escriben todos los días, el folleto es nuestro todo.
Una vez completada la tarea, después de ver mi hoja de papel y la solución, se llegó al veredicto de que el algoritmo no sería óptimo. Le sugerí al entrevistador que escribiera su propio algoritmo, a lo que recibí la respuesta "Esto no está dentro del alcance de la entrevista". Pedí un minuto, cambié un poco el código y lo mostré, preguntando, ¿será más rápido o más lento? A lo que recibí respuesta, pasemos a la siguiente pregunta. La diferencia estaba en cómo funcionaba el código en bucle y sin bucle, y tenía una respuesta preparada de por qué era mejor hacerlo de esta manera y no de otra. Bueno, después de eso ya no quise responder preguntas ni trabajar con esta persona.
Hay que tener en cuenta que todos somos diferentes y un candidato puede desanimarse por cualquier cosa que no sea importante para usted.
— por lo general, los especialistas de alto nivel tienen una descripción clara de la pila de trabajo, pero no, necesitas comenzar a usar algo cercano a ti, por ejemplo, tienes Ansible escrito, genial, pero tenemos Puppet, te acabamos de llamar, así que dínoslo. nosotros sobre Marionetas. ¡Perfecto! ¿Has trabajado con OpenShift? Tenemos K8, no conocemos las diferencias, pero tu experiencia es irrelevante. ¡Asombroso!

También existe una subclase de este tipo: yo personalmente tomo alumnos para que se conviertan en juniors.
Me gustaría que todos entendieran que un pasante es una entidad que aún no se ha formado en absoluto. Me asusta muchísimo cuando empiezan a empujar a los alumnos al fuerte nivel Junior y luego, con una mirada de satisfacción, les ofrecen una pasantía (a veces sin remuneración, ¡una pesadilla!).
No hagas eso.
Un pasante, en mi opinión, es un estudiante de último año o alguien que realmente quiere "entrar en TI".
Con los estudiantes, todo es simple: es genial saber qué hace en la universidad, qué hizo él mismo, ver qué preguntas se le iluminan los ojos; si se iluminan, preguntar por qué en Devops y qué se sabe generalmente al respecto. Sienta a la persona y comprenda si será agradable seguir trabajando con ella, si quiere enseñarle algo a esa persona en particular.
Con aquellos que quieren "entrar en TI", todo es un poco más estricto: vea cuánto se estudia una persona a sí misma, qué hizo antes de llegar a su entrevista, aquí una buena opción sería mirar Github, si lo hay, por supuesto. Por supuesto, la densidad de compromisos y qué ejercicios se realizaron. Pregunte también por qué es Devops, porque es más divertido e intrincado en la interfaz.

Y por último, me gustaría darte un consejo una vez más: decide a quién necesitas realmente y encontrarás inmediatamente a la persona adecuada. Identifique las necesidades, mire al especialista como especialista, encuentre sus fortalezas y utilícelas con éxito en su trabajo. Esté atento al entrevistado, él vino a usted para conversar y no para una competencia para ver quién falla a quién o no.

Fuente: habr.com

Añadir un comentario