Ingeniero Senior en busca de trabajo. Sobre tareas en entrevistas técnicas y preguntas teóricas

Seguimos hablando de entrevistas técnicas (si no ha leído, mire los artículos anteriores de la serie, sobre entrevistas con RRHH y técnicos ). Esta vez habrá más experiencia subjetiva, un mínimo de consejos, así como un poco sobre tareas de prueba y preguntas teóricas. Vamos

Descargo de responsabilidad: el autor no es un desarrollador de turbo, sino un macaco web normal sin quejas. Por lo tanto, las tareas y soluciones anteriores pueden hacer que usted sonría, se mueva y desee indicarle al autor su incompetencia. ¡Espero verte en los comentarios! :)

Discusión de los ítems de prueba completados

En la última parte, describí cómo hice dos tareas de prueba: la primera en DevOps Engineer, la segunda en Ruby Developer. Te diré lo que pasó después.

Entrevista con el Desarrollador Ruby : el entrevistador ni siquiera miró mi prueba, no le hizo ninguna pregunta, no hizo un cumplido (completé la tarea mejor que todos los candidatos anteriores, al menos el reclutador me halagó). Parece que ni siquiera sabía de él. Esto me molestó un poco, porque luego comenzaron a preguntarme la teoría y, como resultado, se negaron a través de la teoría.

Entrevista sobre el ingeniero DevOps : el entrevistador examinó la tarea, hizo un cumplido (dijo que la había completado cualitativamente) y formuló algunas preguntas de control sobre la solución: ¿por qué está esta línea aquí? si reemplaza la condición con esto, ¿en qué archivo necesitará hacer esto? ¿Por qué se usa este enfoque aquí? Y así sucesivamente. Como me dijo el reclutador, algunos candidatos no hicieron tareas por su cuenta y no pudieron responder a esas preguntas. Por lo tanto, aquí lo logré sin problemas.

En el primer caso, no le pregunté al entrevistado si había visto mi tarea de prueba y qué pensaba sobre esto. ¡Pero era necesario! Si tiene una situación así, asegúrese de informar a sus entrevistados sobre esto.

Tareas de entrevista

Continuamos el tema de las tareas de prueba de la parte anterior y consideramos las tareas de codificación en las entrevistas.

Puede haber varios tipos de tareas: implementar un algoritmo, escribir una solución en pseudocódigo, refactorizar algo, etc. Nuestros ingenieros son muy aficionados a los problemas algorítmicos.

Muchas personas, incluyéndome a mí, creen que estas tareas muestran solo la capacidad del candidato para resolver tales problemas y no muestran en absoluto cómo va a hacer frente a las tareas de trabajo reales, que, por regla general, son de nivel superior. ¿Por qué todavía les están dando? Creo que la razón es simple: los entrevistadores simplemente no pueden encontrar algo mejor. Y como no podemos encontrar nada mejor, tomemos las buenas inversiones de líneas antiguas, la clasificación, el equilibrio de árboles y más.

Como las herramientas que se utilizan para la solución, el editor de código + repl + la posibilidad de colaboración es el más adecuado. De todas las opciones en el mercado, me gusta más CoderPad . Se crea una sala donde usted y los entrevistadores se conectan, puede editar, ejecutar código juntos y ver los resultados de la ejecución. Muy comodo Si no hay dinero para un teclado, entonces repl.it entra en batalla y el intercambio de pantalla es básicamente el mismo, solo que sin la posibilidad de colaboración.

Upd: mientras se traducía el artículo, repl.it agregó el modo multijugador, que permite que un número ilimitado de participantes trabajen simultáneamente con el código. Totalmente gratis! CoderPad ya no es necesario, ¡salud!

Tuve una entrevista con la compañía para el puesto de Desarrollador Java . La compañía hace algo como CRM y escribe un montón de integraciones. Me puse en contacto con un especialista técnico de Zoom y él dijo: "Comencemos con el problema algorítmico". Respondo: "Ok, haré la tarea, pero tengo una pregunta: ¿necesitas este conocimiento en tu trabajo, necesitas resolver cosas similares?" A lo que obtengo una respuesta fenomenal: "Escribimos puntos finales de descanso y conducimos json-chiki de un lado a otro, pero no es interesante hablar de eso, así que solucionemos el problema". Es decir, el propio entrevistador admitió su incompetencia. No sé quién cómo, pero desde ese momento me di cuenta de que no tendría nada que atrapar allí. Sin embargo, por interés deportivo, la conversación continuó.

Abrimos el teclado de codificación y continuamos con la tarea, cuya condición me expresaron oralmente: "Encuentra la secuencia más larga de caracteres únicos en una cadena dada". Después de eso, el entrevistador dijo que "se podría asignar una tarea para la programación dinámica , pero nos limitaremos a una opción más simple". Me gustaría mirar a la persona que se encargará de la programación dinámica en las entrevistas, en serio.

Le repetí las condiciones de la tarea al entrevistador para asegurarme de que la entendía correctamente, a lo que recibí una respuesta afirmativa y comencé a trabajar. Después de 5 minutos resultó que entendí el problema de todos modos incorrectamente, porque era necesario no encontrar una subcadena, sino su longitud (esto es más fácil). Sin embargo, respondí: "Bueno, desde que comenzaron, entonces resolvamos el problema con un asterisco, y no con uno simple". El entrevistador estaba un poco confundido, porque había preparado las pruebas específicamente para sus condiciones, pero ya decidí que no daría la última y trataría de hacerlo tal como está. Le pregunté cuánto tiempo tengo (unos 40 minutos) y comencé a codificar. Noto que, a pesar del hecho de que sabía que darían tareas, no me preparé especialmente.

Entonces, inmediatamente escribí pruebas y comencé a chamanizar con índices i, j y k :) Bucles en bucles, y así sucesivamente. Después de 15-20 minutos tenía una solución a medio trabajar, pero los casos límite que dio el entrevistador no pasaron. Otros 20 minutos les tomaron, al final, todavía completé correctamente la tarea. El entrevistador parecía satisfecho y luego comenzó a preguntarme sobre las estructuras de datos. Resultó que para resolver el problema que quería dar inicialmente, sería posible usar un hash, o algo así, y esperaba esa solución, pero lo rompí todo.

Luego hablamos un poco sobre el proyecto (formularios y montones). Y luego dice: “Después de eso habrá una entrevista sobre el diseño del sistema. En general, no veo ninguna razón para llevarlo a cabo, porque no hacemos esto aquí y no necesitamos ese conocimiento, pero el orden es orden, por lo que el siguiente paso es este ". Bueno, usted comprende: se realizan dos (!) Entrevistas para comprender si el candidato puede hacer cosas que no son necesarias en el trabajo diario en esta empresa. Luego me permití hablar un poco sobre la falta de sentido de tales entrevistas. El entrevistador estuvo de acuerdo conmigo, pero nuevamente incluyó la delegación de responsabilidad y dijo: "No decido cuál debería ser el proceso, así que hacemos lo que hacemos". Agregaré que pasé por la segunda entrevista (sobre el diseño del sistema) y fue tan insignificante como la primera.

Qué error cometió el entrevistador: no arregló las condiciones de la tarea en el texto. Cuando realicé tales entrevistas, simplemente copié las condiciones de la tarea en el editor de código para que el candidato no tuviera ninguna pregunta.

Qué error cometí: inmediatamente me apresuré a escribir el código, sin especificar tres veces si entendía la condición correctamente. Si se le darán tales tareas en las entrevistas, desconéctese inmediatamente del chat y encuentre una lección más interesante; verifique varias veces si entendió la condición correctamente, escriba una prueba en el editor y recibirá una confirmación del entrevistador de que todo está correcto.

También tuve una entrevista para el puesto de Desarrollador Ruby . Después de conocer y hacer preguntas predeterminadas, me dieron la tarea de escribir el método each_slice. Para aquellos que no lo saben, esto es algo que golpea un conjunto de subconjuntos de un tamaño determinado y ejecuta para cada uno de ellos un bloque que pasamos al método, o devuelve un iterador sobre estos subconjuntos. Me senté a escribir y luego encendí el tuping. El problema es que en Ruby, durante bastante tiempo, participé con éxito solo en el maquinado web y, como lista blanca de referencia, no conocía algunas de las construcciones básicas del lenguaje. A saber: no sabía que el índice en el bucle for es inmutable (a diferencia, por ejemplo, de Java).

Escribí el método en sí más o menos rápido, pero no funcionó y no podía entender por qué. Comencé a entrar en pánico un poco, borré todo y volví a escribir, pero mi código nuevamente no funcionó como debería.
"No fue", pensé, y les dije a mis interlocutores: "Chicos, ustedes saben, soy bueno en alojamiento web y proyectos, pero no puedo hacer nada con sus estúpidas tareas. Entiendo que esta es una tarea simple y una persona con 10 años de experiencia simplemente está obligada a hacerlo rápidamente. Así que déjame no demorarte más y nos dispersaremos. Los chicos estuvieron de acuerdo y se separaron.

Fui bombardeado seriamente porque no estaba acostumbrado a perder tan fácilmente. Para obtener de alguna manera una ventaja existencial, le escribí a un reclutador que había desglosado una tarea que no está relacionada con el trabajo real. Luego se calmó, se sentó, probó rápidamente cómo funcionan los índices en ciclos. Me di cuenta de que cometí un error menor, rehice el índice y obtuve una solución preparada. De hecho, el error que tuve fue en la misma línea. Le conté a HR sobre esto y le sugerí que pasara el enlace a la solución a los chicos si están interesados, porque todavía resolví el problema. Pero ella respondió: "No fuiste más allá porque no resolviste el problema, adiós ". Todavía entendí un poco sobre los procesos de entrevistas interrumpidas para justificarnos de alguna manera y nos separamos.

Después de eso, repensé mi actitud hacia tales tareas. Por lo general, nunca fue un problema para mí codificar algo bajo supervisión, pero varios factores funcionaron aquí: mi solicitud para una posición seria, falta de comprensión de las construcciones básicas del lenguaje (aunque nunca los necesité, y si lo fuera, podría buscar en Google la solución en 5 segundos) y el efecto del observador. Por supuesto, leí que muchas personas no pueden resolver los problemas cuando los miran, pero siempre me pareció que era una excusa para mi propia inseguridad e incompetencia, hasta que me encontré con estos tipos duros con cada corte.

También tuve una entrevista para el puesto de Desarrollador Java. Esta vez se celebró en un formato ligeramente diferente. Nos contactó Zoom y el entrevistador dijo: “Dime tu correo electrónico, te enviaré una tarea, léela, dime si todo está claro. Tendrás dos horas, estaré en silencio y no miraré lo que haces allí (no jugamos con la pantalla). Dos horas después, nos ponemos en contacto, buscamos en la pantalla y vemos lo que hiciste allí. Puedes usar cualquier cosa. Leí las condiciones de la tarea, volví a hablar con el entrevistador, apagué el video (porque la codificación de la transmisión se come la CPU) y me confundí. Abrí el IDE y comencé.

La tarea estaba relacionada con E / S: era necesario hacer una API para escribir datos en un archivo en el disco, de modo que todo fuera seguro y rápido para subprocesos, y también escribir pruebas unitarias que verificaran esto (incluida la seguridad de subprocesos). No he trabajado con concurrencia y E / S durante mucho tiempo, por lo que tuve que revisar rápidamente los muelles y recordar lo que estaba sucediendo. Escribí una solución en la frente, verifiqué que sea segura para subprocesos, y así sucesivamente. Todo sobre todo me llevó aproximadamente una hora y media. Llamé a mi entrevistador, dije que estaba listo, pero que solo había una pequeña cosa que pulir, ¿miraremos? A esto respondió: "Sentémonos otra media hora y terminemos todo lo que no ha completado". Ok, me senté y recordé todas las pequeñas cosas y asperezas, terminé el javadki, una vez más leí todo lo que pude sobre E / S y pensé cuáles podrían ser las desventajas de mi solución.

Después de media hora, nos pusimos en contacto, compartí la pantalla, mostré el código, ejecuté las pruebas, etc. La siguiente media hora, hablamos estrictamente sobre la resolución del problema y las posibles opciones para su modificación al cambiar ciertas condiciones. Quiero llamar la atención sobre el hecho de que en entrevistas anteriores (y también en las posteriores) nadie preparó la base para la conversación por tareas, siempre fue solo una especie de pieza abstracta que dio 0/1 en la salida y pasamos a la siguiente pregunta. Y aquí la tarea fue lo suficientemente simple como para que se pudiera hacer en un par de horas, pero al mismo tiempo lo suficientemente exhaustiva como para agregar condiciones y discutir con el candidato cómo finalizaría la decisión.

Realmente me gustó esta entrevista. Pude demostrar que no solo se resuelve el zumbido del fizz, sino que también se entiende algo en las arquitecturas. El entrevistador estaba convencido de que no estaba sentado en junio, sino de un especialista que filma algo en su trabajo. Fue la mejor entrevista técnica que he tenido. Creo que ya adivinó que el entrevistador no era uno de los nuestros :) También agregaré que lo pasé con éxito, luego dos etapas más y finalmente recibí una oferta. Pero esa es otra historia.

¿Qué tenía de bueno esta tarea?

• Proximidad al trabajo real, a lo que hacen en esa empresa.
• Límite de tiempo.
• Falta de observación.
• La capacidad de usar cualquier cosa y no una verificación de memoria.
• Creando una base para más conversación.
• Probar las habilidades del candidato para codificar, usar el IDE y pensar en general.

Desafortunadamente, de todas las entrevistas, solo tuve tres de esas tareas, por lo que la selección es pequeña. Quizás haya algunas pruebas / tareas más difíciles, pero no las obtuve.

Deficiencias típicas de las tareas de entrevista

1. La tarea no tiene nada que ver con el trabajo real. Me molesta más. Los algoritmos pueden resolverse, aunque en realidad las pilas son fascinantes. ¡Vamos a la tarea relevante, te haré un crudo! ¿Por qué necesita una persona que sepa buscar subcadenas en cadenas?
2. Organizacional: a menudo no existe una herramienta normal para una solución. Una vez que me mostraron el código en Google Docs, una vez que busqué la pantalla en repl.it, una vez fue CoderPad.
3. La tarea no crea un contexto para una conversación posterior; esto es una consecuencia del primer párrafo. ¿Por qué dar una tarea si no la discutimos más tarde?
4. No todas las personas pueden hacer frente a la tarea bajo supervisión. En consecuencia, un buen candidato puede ser eliminado en esta etapa.

Preguntas teóricas

Esta es mi parte favorita A todos les encanta preguntar teoría, repasemos esto un poco.

Por alguna razón, sucedió que, sobre todo, me preguntaron la teoría en los puestos del Ingeniero Ruby. La conocía lo peor de todo, así que constantemente llenaba las entrevistas y parecía un mes de junio hasta que me di cuenta de que ya no era adecuado continuar así. Me senté y leí un libro de texto sobre el idioma, lo que me permitió hablar mucho mejor y sin quejarme "Chicos, ¿por qué me preguntan esto? Soy un buen desarrollador, ¿cuál es la diferencia, cuál es el orden del método de búsqueda de un objeto? ¿Quién necesita esto?

La primera entrevista a la que fui como Desarrollador Ruby fue exactamente donde se realizaría la tarea de prueba, sin embargo, resultó que nadie estaba interesado. Timlid, que se suponía que debía comunicarse conmigo, no vino (estaba atrapado en un embotellamiento o algo así), así que me dieron otro. Después de la reunión, dice: "Tengo una regla: realizo todas las entrevistas en inglés, así que cambiamos a inglés". Y luego mis oídos se tuercen en un nanotubo de grafeno, porque el entrevistador tiene un acento muy fuerte. Esto me inquietó un poco (es muy difícil para mí comunicarme con mis compatriotas en inglés).

Luego vinieron las preguntas: qué es un módulo, qué es un bloque, cuál es el rendimiento, y comencé a archivar. En lugar de definir "como en un libro de texto", comencé a balbucear: "Bueno, no sé la definición exacta, pero probablemente esto sea así, lo usé así". El entrevistador estaba descontento, comencé a sentirlo y luego pensé que todos habían llegado.

Luego hubo preguntas sobre métodos específicos, a saber: "¿Cuál es el nombre del método que filtra todo el nulo en la colección?" Luego encendí el troll y respondí: "Si revisas mi memoria para conocer estos métodos, entonces no puedo decirte nada sobre lo que no he usado recientemente. Escribo en muchos idiomas y plataformas y no recuerdo todos los métodos del SDK ". Esto no satisfizo al entrevistador, y la siguiente pregunta fue algo como: “¿Qué es Enumerable? Qué métodos hay y quién lo extenderá ". "Tío, ¿no lo entendiste?", Pensé para mí mismo, pero dije en voz alta: "No estoy seguro, creo que hay algunos métodos como mapa / reducir / cortar y así sucesivamente". Tampoco le convenía.

Luego me hizo una pregunta estándar sobre dónde poner la lógica en MVC. Le respondí que en el modelo, y si no encaja en el modelo, en otras clases. Resultó que los llamados Objetos de Servicio fueron la respuesta correcta (¿esta basura también llegó aquí?). Murmuré algo en respuesta, como, bueno, puedes llamarlo así, pero no me gusta.

Luego hizo la pregunta predeterminada sobre SQL, que ya pude responder correctamente, luego preguntó sobre RSpec, que no usé, eso es todo. En Rails (y solo tenían rails) no recibí una sola pregunta. Además, no he recibido una sola pregunta sobre mi experiencia previa.

Después de eso, me preguntó qué opino sobre los stand-ups diarios. Luego decidí no dar las respuestas socialmente esperadas (¡el granero se quemó, quemar y chocar!), E inmediatamente dije que era una pérdida de tiempo y se practicaba en equipos donde el gerente no podía garantizar la transparencia y la facilidad de informar sobre el progreso. Y agregó que Scrum es basura en aceite vegetal, y nadie normalmente trabaja de acuerdo con el scrum, pero todos fingen. Obviamente, todavía tomé las desventajas.

Además, sugirió hacerle preguntas (aparentemente por cortesía), y yo, por mi propia cuenta, le pregunté sobre el proceso, la arquitectura, etc. Lo que escuché no me gustó, porque hicieron mucho ciclismo para tareas típicas. Quería dejarle claro al tipo que no solo era un desarrollador, sino que podía hacer un poco más, pero todo fue en vano, y pronto dijo que tenía que ir al rally y zarpar.

Al día siguiente, un reclutador me escribió y me informó de la negativa. "Y gracias a Dios", pensé, pero todavía un poco quemado. Tengo la impresión de que el entrevistador tenía algunos prejuicios desde el principio, no lo sé. Por cierto, esta fue la misma oficina que se demoró un mes desde el primer contacto hasta una entrevista técnica.

Entonces, me rechazaron porque no sabía los conceptos básicos del idioma (Ruby). Ok, sigamos adelante.

Otra entrevista en Ruby Debeloper , dos entrevistadores ya. Es bueno que al menos uno se hable en ruso, el segundo, en ucraniano, por lo que no tuve que romper mi cerebro. Para mi sorpresa, comienza la misma historia: qué son los módulos, qué son los bloques. Todavía no había leído el libro de texto, así que volví a nadar en las respuestas. Además preguntó sobre los tipos de asociaciones en Rails. «- -», — , . ( ), , : « ». , — each_slice. , , . : « , - Rack middleware?». , . , , ( Java Servlets, middleware - Laravel/Express), . , .

, , . . , , rack middleware, , .

. — . , , , , …

Ruby Developer. , . , , . Proc, , :) : « , , , - ». 100% , - , . .

: « require». Rails Grape, , , . « , ». , . - -, « , ?». ActiveRecord — , .

concurrency ( ). , concurrency Ruby — . , , . , MRI — JVM , volatile synchronized , . , , ( !) concurrency . ? ?

, - SOLID. , « — », . , . , . - , . , « ». .

? . , , , . , ! ( ). , , Cracking Ruby Interview, . , - «» , , , :)

.

Fullstack Java Developer. — . , . , , Java.

, , , - . , , , , . , , .

. . , , , undefined null, var. JS WAT-. : «, WAT . , , , ». , -. «JavaScript: The Good Parts», .

, , . (?) , ( , ) , . . , :)

- , , . jQuery, . :)

DevOps Engineer , . : « ?». - :) , , — . , . , , , . . ( )?

( MVC). (-) 5-10 . ( GoF) . . Ruby-, , — , , ( MVC ActiveRecord ). Java- .

SOLID , , : Ruby-, — Java. DRY :)

?

1. , .
2. , .
3. , .
4. , .

, , :

• / . , . : « -AOP AspectJ Spring?» :) , , .
• LeetCode , .

, , . , , « » , .

( , ), , !