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 , .

, , . , , ¬ę ¬Ľ , .

( , ), , !

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


All Articles