Ingeniero Senior en busca de trabajo. Cómo pasé por 15 entrevistas técnicas y qué pienso al respecto

La continuación de la historia de cómo fui entrevistado en diferentes compañías para diferentes puestos. Esta vez cerraremos algunas preguntas y comentarios sobre la primera parte y continuaremos hablando sobre tareas de prueba y entrevistas técnicas.

Para mi sorpresa, el artículo anterior sobre entrevistas con reclutadores y RR.HH. despertó un interés inesperado: más de 100.000 visitas de todas las fuentes. Recibí un montón de comentarios positivos en PM, me escribieron por antiguos colegas a quienes vi por última vez hace unos 5 años; heroínas de algunas historias; un tipo al que vendí una unidad del sistema a través de OLX hace unas semanas (análogo de Slando, - aprox. por persona) ; el baterista con el que tocamos metal en el garaje el año pasado y, por extraño que parezca, algunos reclutadores que me preguntaron qué pensaba sobre ciertos aspectos de las entrevistas y la contratación. 250 personas por alguna razón me agregaron en LinkedIn :).

Antes de ponerme a trabajar, responderé las preguntas más populares y los mensajes y comentarios personales.

Cómo organizar un salario para una entrevista


Muchos comentarios relacionados con el dinero. Deliberadamente, no le presté mucha atención a esto, porque ofertar es un tema aparte, sin embargo, los comentaristas aún lo mencionaron y señalaron las deficiencias de mi estrategia, por ejemplo, nombrar el precio de inmediato. Aquí hay dos buenos artículos que abordan este problema de una manera mucho más detallada y profesional:


Recomiendo leer antes de buscar trabajo.

Algunas reflexiones sobre el reclutamiento


De ninguna manera doy consejos a los reclutadores sobre cómo hacer su trabajo. No soy un reclutador profesional, y no sé cómo funciona su cocina interior. Cuando necesitaba buscar personal (no solo para realizar entrevistas técnicas, es decir, para buscar y contratar, un ciclo completo), estos eran puestos junior, respectivamente, no tuve ninguna dificultad especial.

En mensajes privados, me preguntaron cómo hacer el primer mensaje sobre la oferta de trabajo, para que pareciera atractivo e interesado el especialista, ¿cómo llamar la atención sobre mí?

Me parece que, desafortunadamente, nada depende del reclutador. Todo lo que un reclutador puede hacer es encontrar tantos contactos de especialistas del perfil necesario como sea posible y enviarles una oferta a todos ellos. Después de esto, debe esperar y esperar que uno de ellos esté dudando o en una búsqueda activa de trabajo. Es decir, hay un 20% del trabajo con la base y un 80% de suerte. La red tiene muchos materiales sobre cómo crear vacantes correctamente, etc., pero en cuanto a mí, el factor clave es precisamente el deseo del candidato de cambiar de trabajo.

El reclutamiento es la venta de una vacante a un candidato. Cuanto antes entiendas esto y comiences a desarrollar tus habilidades de vendedor, mejor. Oh, dije que no daré consejos :)

También estoy convencido de que durante las búsquedas de trabajo, los candidatos deben asumir todas las vacantes que sean más o menos adecuadas, porque de hecho, descubrir de qué se trata la vacante solo es posible durante una conversación con especialistas técnicos. En mis búsquedas, prácticamente no presté atención a lo que estaba escrito en la vacante, y descubrí los detalles necesarios en la etapa de una entrevista técnica. Creo que este método es el más correcto, porque las posibilidades de encontrar un proyecto genial que pueda esconderse detrás de una descripción gris estándar aumentan considerablemente. Mi experiencia solo confirma inequívocamente esta tesis. Ni una sola vez en la vacante se escribió específicamente lo que habría que hacer. Solo frases generales como "codificar el código, probar las pruebas, implementar la implementación".

Participar en una empresa o proyecto


En nuestras realidades, definitivamente para un proyecto.

Cómo elegir un título


Me posicioné como candidato a nivel de ingeniero de software sénior y superior: jefe de equipo / técnico, ingeniero principal, arquitecto de software, gerente de proyectos, gerente de personas / grupos, etc. Esto es lo que significa "arriba" con "+" en "Senior +".

Me parece que el título no significa nada. Lo único importante es lo que realmente hará, y esto solo puede averiguarlo la persona con la que trabajará.

Entonces, damas y caballeros, pasemos a las entrevistas técnicas.

Etapa dos Entrevistas técnicas


En esta parte habrá más de mi experiencia subjetiva y filosofía que consejos. Hay mucha información sobre lo que se pregunta en las entrevistas técnicas y cómo prepararse para ellas en Internet.

Descargo de responsabilidad: el autor no es una olimpiada de turboingenieros, por lo que algunas decisiones o comentarios pueden causar una sonrisa, un dolor en el trasero, el deseo de señalarle al autor sus errores o sus bajas calificaciones. Me complace escuchar la construcción.

En total, pasé por 15 entrevistas técnicas, lo que, para mí, no es tanto. Podría haber pasado por mucho más, pero en promedio esperaba una semana desde el primer contacto con un reclutador hasta una conversación con un especialista técnico. Esto a pesar del hecho de que prácticamente no tenía límites de tiempo. Solo una vez programé una entrevista para el tiempo para el que ya había programado otra entrevista. También noto que todas las compañías o reclutadores vinieron a mí. No envié CV a ninguna empresa primero. Esta es la cuestión de que no es el señor el que está buscando trabajo, sino el trabajo: el señor.

Tareas de prueba


Muchas compañías dan tareas de prueba antes de pasar a una conversación para descartar candidatos irrelevantes. A pesar del hecho de que a muchos no les gusta invertir su tiempo en tareas de prueba, especialmente si son bastante voluminosos, sigo pensando que esta es una buena práctica. Consideremos qué tareas de prueba pueden ser.

"Haga un proyecto desde cero (quizás utilizando una tecnología específica) y publíquelo en GitHub" , en mi opinión, la peor opción. Puede pasar mucho tiempo en una placa repetitiva, en la infraestructura alrededor de la solución, y el entrevistador, por regla general, estará interesado en algunos pequeños detalles de implementación establecidos en las condiciones de la tarea. Bueno, si tiene a mano, por ejemplo, plantillas de proyecto y puede levantar el servidor en 5 minutos y descargar rápidamente lo que necesita. De lo contrario, debe recordar todo y comenzar desde cero. También es malo si la tarea tiene una condición para usar dependencias externas, por ejemplo, una base de datos no incrustada.
Puesto de Ingeniero DevOps. Me enviaron una tarea para hacer una configuración vagabunda de varias máquinas virtuales, entre las cuales debería haber servidores web con estadísticas, un equilibrador para ellos y Jenkins. Todo esto tuvo que ser instalado y configurado usando Chef. Ahora imagine: nunca usé Vagrant, Chef y no configuré los servidores web que se requerían en la tarea. Entiendo cómo funciona todo, traté con herramientas similares, pero nunca las usé específicamente.

Tuve que sentarme durante la noche, arreglarlo todo, recoger un montón de rastrillos y finalmente completar la tarea. La principal dificultad fue que tenía un viejo MacBook Pro del año 15, que físicamente no tenía tiempo para reiniciar los contenedores, y que no tenía experiencia con Vagrant.

La esencia de la tarea, descubrir cómo instalar qué, probablemente me llevó media hora. El resto del tiempo (7 con una cola de horas) lo pasé instalando todas las herramientas, reinicio, reinicio, hurgando en las configuraciones en un intento de entender por qué no funciona, y así sucesivamente.
Probablemente haría la misma tarea en Docker Compose en una hora, tal vez incluso menos. ¿No podrías limitar al candidato a herramientas? Me parece que es posible.

¿Fue útil esta búsqueda para mí? Definitivamente si! Ahora sabré que de Vagrant y Chef debes mantenerte alejado :)

Tiempo empleado: 8 horas .
Desafortunadamente, no tengo más historias sobre este tipo de tarea, porque no había tantas pruebas en general :(

"Aquí hay un enlace al sitio con las pruebas: pasar por ellas" es una opción muy buena. Cual es el punto? Hay SaaS que le permiten configurar un conjunto de preguntas prácticas y teóricas, y para la solución proporcionan REPL y un editor de código directamente en el navegador, así como también le dan la oportunidad de ejecutar pruebas de verificación. Luego simplemente realiza las tareas, arregla el existente o escribe su propio código, ejecútelo y vea los resultados. Las pruebas en sí están ocultas para usted, solo ve el resultado (aprobado / reprobado) y una breve descripción de la prueba, que al mismo tiempo puede ser una pista. ¿Por qué me gusta más esta opción? Debido a que existe un criterio inequívoco para la calidad de la tarea, y el candidato sabe exactamente cuántos puntos anotó, si sus decisiones funcionan, etc. Personalmente, incluso estaba interesado en realizar estas tareas. Lo único que no veo es el punto en cuestiones teóricas como "qué sucederá si se ejecuta este código": son fácilmente google.
Ruby Software Engineer Puesto. Me envían un enlace al sitio web de TestDome , por supuesto, a una prueba personalizada. Hago clic, me meto en las pruebas reales. Me dan 2.5 horas para completar todo el conjunto, 5-20 minutos para cada pregunta. De hecho, realmente me gustó, no he pasado por esas cosas en mucho tiempo. Me gustó especialmente el enfoque TDD: codifiqué, lancé, miré lo que cayó, codificas más. Pasó con mucho gusto.

Las tareas en sí eran bastante simples: corregir el código (Ruby / JS / CSS / HTML), escribir validadores (Ruby), implementar estructuras de datos (Ruby), nada especial. Sin embargo, el hecho de que pueda verificar de inmediato si la solución funciona mucho.

Completé la tarea por 93/100 puntos en solo una hora. Desafortunadamente, este resultado no me ayudó en absoluto en el futuro.

TDD ayuda en la decisión, no es necesario perder tiempo en aumentar la infraestructura, reproducir directamente en el navegador, en resumen, muy bueno. Por el bien de esto, fue posible esperar un mes; al final, obtuve mi porción de dopamina (hizo un excelente trabajo) y adrenalina (¡el tiempo corre, el tiempo se acaba!).

Tiempo dedicado - 1 hora.
Además, la gran ventaja de este tipo de tarea es que su verificación está automatizada. Todos sabemos cómo los entrevistadores "adoran" verificar las tareas, y aquí la máquina hace todo por ellos: es muy conveniente, al menos, que no es necesario descargar el código y recopilarlo. Quizás usaré este método cuando contrate en el futuro.

"Aquí está el repositorio, hay una tarea, enviar una solicitud de extracción con una solución" - No encontré esa opción, pero mis colegas la usaron. Realmente no me gusta, porque puedes ver cómo otros candidatos realizaron la tarea (si lo fueran).

Las desventajas de este método son obvias: el probador necesita descargar el código, recopilar, ver lo que hay allí, es largo y aburrido. Por supuesto, puede ver superficialmente el código en el navegador, pero ¿por qué necesita una tarea? Vamos a escribir en el pseudocódigo entonces.

“Aquí está el repositorio, está el código, refactorícelo tanto como pueda” , una variación del anterior. Esto es mejor, porque aquí desde el principio se crea un marco para trabajar. Las desventajas son las mismas: no está claro cuándo parar. Como dijo Egor Bugaenko, cualquier programa contiene un número infinito de errores, y también pueden repararse indefinidamente.

Los autores de la tarea probablemente tenían algo en la cabeza cuando la crearon, lo más probable es que no sepamos qué fue lo principal para ellos solos. Si la tarea tuviera un criterio claro, sería genial. Por ejemplo, "hay un código, produce ese resultado en la velocidad en dicho hardware, refactorícelo para que funcione el doble de rápido". Es difícil trabajar sin criterios. En la vida real, en el trabajo real, siempre tenemos un marco y estamos buscando la solución óptima, guiados por este marco y el sentido común. El trabajo principal del desarrollador es sentir este equilibrio y encontrar la solución adecuada.

Para mi gran pesar, nadie más dio tareas de prueba, por lo que mi selección es muy pequeña. A menos que pueda recordar las pruebas que hice hace muchos años. Todos eran del primer tipo: era necesario hacer un proyecto. Curiosamente, los realicé en aquellos días en que GitHub aún no era tan popular y era necesario enviar la solución en el archivo zip por correo :)

¿Mis recomendaciones para los artículos de prueba?

  1. No me gusta, no me gusta. Si la tarea, por ejemplo, es completar todo el sitio o escribir un error, bueno, póngalo en la casa de baños. Las tareas deben ser cortas y enfocadas en crear contexto para la discusión que sigue, y no solo una prueba de cómo puede hacer andamios.
  2. Si la tarea es del primer tipo, agréguela al repositorio Léame, donde describa en detalle las instrucciones para comenzar, una breve anotación sobre por qué tomó esa decisión, cuáles son sus defectos, qué le gustó o no le gustó, cómo resolvería la tarea, si tuviste más tiempo, y así sucesivamente. No sé si esto realmente ayuda, pero como entrevistador, definitivamente mencionaría dicha documentación de la decisión.
  3. Escribe normalmente, pero no debes pasar mucho tiempo lamiendo partes. En cuanto a mí, es suficiente simplemente enumerar en el archivo Léame todo lo que mejorarías si fuera un código de batalla.
  4. Asegúrese de pensar qué preguntas puede tener sobre la implementación y lea la documentación adicional sobre la API que utilizó. Supongamos que no he trabajado con concurrencia durante mucho tiempo. No he practicado esto durante mucho tiempo, así que después de la decisión, revisé rápidamente todos los temas relacionados, recordé todas las tareas típicas y estuve listo para la conversación.

Bueno, prueba uno, espero que lo hayas completado con éxito, hayas pasado esta información al reclutador y, después de un tiempo indefinido, te inviten a hablar en persona.

Entrevista técnica Introducción


Para empezar, ahora rara vez son invitados a la oficina para entrevistas. Me llamaron a la oficina solo varias veces, para una entrevista en los puestos de Solution Architect, Tech Lead y una vez, para un puesto directivo. Todas las demás entrevistas tuvieron lugar a través de Skype, Zoom, Hangouts. Como en la entrevista anterior con el reclutador, las recomendaciones son las mismas: una buena cámara, un buen auricular, un buen internet. A esto también le agrego la condición de manipular la pantalla. Por lo tanto, asegúrese de no tener proyectos de trabajo abiertos (si esto es importante) y otras cosas personales que no necesita mostrar a las personas en ese extremo. Tenga a mano un navegador limpio sin pestañas y REPL para la codificación por si acaso (IDE o repl.it ).

De todos los métodos de comunicación, me gusta Zoom sobre todo. En realidad, se usó con mayor frecuencia.
Un consejo importante con respecto a la comunicación adecuada en los grupos de noticias: tenga el hábito de no hablar o escribir en el teclado cuando otra persona está hablando, y hablando por los auriculares, y no, por ejemplo, a través de un micrófono portátil externo y altavoces externos.

¿Por qué es esto importante? Muy a menudo, dos personas hablarán con usted, respectivamente, no usarán los auriculares. Cuando habla, por su parte, el software incluye un cortador de ruido que evita que aparezca el efecto de retroalimentación (fondo, silbato, eco). Cuando el cancelador de ruido está activado, su micrófono prácticamente no captará nada, por lo que no escuchará lo que le dicen.

Cuando escribe en el teclado, crea ruido que se transmite al otro lado y también incluye reducción de ruido. Como resultado de esto, las frases se rompen y se crea la impresión de una mala conexión. Por lo tanto, siempre debe esperar hasta que la gente termine la conversación. De lo contrario, simplemente no escuchará lo que querían decir (excepto cuando los interlocutores también usan el garntiru). Por extraño que parezca, muchas personas no conocen estos mecanismos. También es útil silenciar el micrófono mientras habla para que ningún sonido de su habitación llegue a las personas. Fui criado por años de trabajo en una empresa donde todos conocen estas reglas, así que para mí todo esto es obvio, pero vi muchas situaciones en las que las personas no seguían estas reglas básicas y pecaban en Internet.
Si todo está bien, los pings han ido y venido, entonces la conversación comenzará. A menudo, los propios entrevistadores proponen un plan de conversación. Sucede que no tienen un plan, pero al menos un tema siempre será relevante: "Cuéntanos sobre ti y sobre tu experiencia" .

Antes de la entrevista, vuelva a ocupar la vacante, preste atención a los requisitos que se aplican al candidato y prepare un discurso. Realicé entrevistas en Tech Lead, DevOps / SRE, Ruby / Java Software Engineer y en cada caso conté diferentes cosas que creo que serían de mayor interés para el entrevistador. Trate de no entrar en detalles, pero proporcione la información que creará un vector para una discusión adicional. No debe hablar en detalle sobre lo que hizo hace 5 años (a menos, por supuesto, que esto no fuera algo extraordinario).

Dije, por ejemplo, esto: “Durante 8 años trabajé en una oficina empresarial, principalmente con Java.Luego fui a una startup, allí me dediqué a la infraestructura. Los últimos dos años he estado escribiendo principalmente en Rails. Eso es todo, los entrevistadores tienen suficiente información y desenrollarán la conversación en la vena que les interese.

Y ahora un hecho inesperado.

Nadie lee tu currículum


Honestamente, esto resultó ser un gran descubrimiento para mí. Bueno, los reclutadores no leen el perfil en LinkedIn, ya que puede que no se actualice, RR.HH. tiene la capacidad de ver currículums en diagonal y resaltar lo más importante para usted. Pero las personas que realizan una entrevista técnica, ciertamente no leerán su currículum. No uno, enfatizo, ni una sola vez no sentí que la gente al menos con un ojo mirara lo que escribí allí. Sospecho que, por regla general, descubrieron que necesitaban realizar una entrevista técnica un día antes de la entrevista real, y decidieron leer el CV 5 minutos antes de la llamada, y ya estaría allí de alguna manera.
: « , ». , ( , ). , , .

, .

, , 10 . CV, , , .

CV , . , , .
Y nuevamente expresaré mi disgusto con esta actitud. Yo y usted, si ya somos un tomate senior, somos especialistas de un nivel relativamente serio en su campo (les recuerdo que tengo esta calumnia y montones). No hay muchas personas como nosotros en el mercado, así que muestre respeto y familiarícese con lo que hice. Leí sobre su empresa, proyecto, cliente. Espero ser tratado como una persona. ¿Por qué sucede lo contrario?

Nadie te necesita


Pero esto me molesta más. En el 80% de los casos, traté con introvertidos enojados, somnolientos y cansados ​​que claramente no estaban interesados ​​en contratar a nadie. Eran personas técnicamente competentes y buenos especialistas, pero por alguna razón no deseaban contratar a un colega, no deseaban contratar a un buen ingeniero para que los ayudara.

Estoy convencido de que se trataba de personas a las que simplemente colgaron la obligación de realizar entrevistas. Varias veces me dijeron que la persona adecuada estaba de vacaciones, que no tenía tiempo para llegar, que estaba ocupada o algo más. Ya tienen muchas cosas que hacer, problemas en la producción, no tenemos tiempo para correr, se reúnen con el cliente y, de nuevo, el próximo candidato se metió en problemas, ¿qué debo hacer con él? El problema se deriva de esto: los entrevistadores no lo consideran como la persona con la que tendrán que trabajar, sino que simplemente tratan de evaluar si es normal o no desde su punto de vista. La situación era bastante frecuente cuando "oh Timlid está ocupado ahora, por lo que otra persona se entrevistará".

Tuve solo unas pocas conversaciones con los ingenieros, que demostraron que sí, que realmente necesitan personas, que quieren contratar a un buen especialista, que tienen un plan para mí, etc. Y así pasamos al siguiente párrafo.

No hablarás con tu futuro jefe o líder de equipo


Esta es una consecuencia de la anterior. Estoy profundamente convencido de que debes hablar con aquellos a quienes obedecerás, formal o informalmente. Todas las organizaciones tienen algún tipo de jerarquía, ya sea un equipo Scrum o una empresa sangrienta. En todas partes hay una persona que lo cuidará (al menos al principio).

Desafortunadamente, no puedes hacer nada al respecto. Yegor Bugaenko en su publicación "Por qué no hablo con los reclutadores de Google" describió muy bien esta situación. Si exige una conversación con su futuro jefe, simplemente no obtendrá ninguna entrevista.

Me parece que ahora este es uno de los mayores problemas de contratación con nosotros. Quizás esto esté dictado por los detalles de los proyectos: la subcontratación, donde la gente hace algo en la transmisión. Quizás la cultura de comunicación generalmente pobre y una mentalidad misantrópica, no lo sé.
Los blogs en inglés a menudo escriben que la contratación es una de las áreas clave vitales para construir una empresa exitosa. Creo que nuestras empresas necesitarán mucho tiempo para llegar a esto y formar la cultura correcta. Mientras tanto, los clientes tienen que externalizar esto.
. , CTO CEO. , . , , . , .
, , (, ).
Hasta ahora, todo, muchos materiales y pensamientos, Longrid volvió a salir, sin importar cómo lo intenté. En la siguiente parte, continuaremos considerando el tema y avanzaremos hacia temas y técnicas específicos que se utilizan en entrevistas técnicas.

Source: https://habr.com/ru/post/es434864/


All Articles