Cómo Yandex me enseñó a entrevistar a programadores

Después de exponer mi historia de "empleo" en Yandex en el comentario sobre la nota sensacional "Cómo trabajé durante 3 meses en Y. Market y renunciar", sería injusto ocultar el beneficio que obtuve de mi experiencia con Yandex.Message.

Mis responsabilidades laborales incluyen entrevistas técnicas de candidatos para el puesto de Desarrollador Fullstack JavaScript / TypeScript. He participado activamente en este negocio (¿vale la pena decir que estoy un poco harto?) Durante más de un año, he tenido más de 30 entrevistas técnicas.

Anteriormente en una entrevista técnica, le hice al candidato preguntas bastante estúpidas como "qué es un cierre", "cómo se implementa la herencia en JavaScript", "hay una tabla en la base de datos con dichos índices, por favor díganos cómo puede acelerar tal y cual solicitud ", que, aunque ayudaron a identificar las habilidades de ingeniería del candidato, no les permitió concluir qué tan bien una persona puede resolver problemas y qué tan rápido puede descubrir un código existente. Lo que no pudo sino conducir a tristes consecuencias ...

Pero todo cambió después de pasar por cuatro rondas de entrevistas técnicas en Yandex.

Por lo general, las piedras vuelan al jardín de los entrevistadores de Yandex para:

1. Tareas que no tienen valor práctico;
2. La necesidad de resolver estos problemas en trozos de papel con un lápiz o en una pizarra.

Ya es el año 2019 y es hora de lanzar una línea de producción separada para lanzar calderas en el infierno para aquellos que obligan a las personas a escribir texto a mano, sin mencionar el código. Cada persona escribe de diferentes maneras, y al preparar el texto para esta nota, tuve que reescribir, por ejemplo, este párrafo en particular seis veces; si escribiera notas para Habr en papel, no escribiría notas para Habr.

Pero no estoy de acuerdo con la tesis sobre la inutilidad práctica de las tareas de Yandex. Incluso el desarrollo de rutina es no, no, pero le dará una tarea que tiene varias soluciones. No necesita pensar en uno durante mucho tiempo, pero no es óptimo en términos de tamaño de código, rendimiento o expresividad. El otro es todo lo contrario, pero requiere que el programador tenga experiencia en la construcción de algoritmos eficientes y comprensibles. Aquí hay un ejemplo de una entrevista:

/*    getRanges,    : */ getRanges([0, 1, 2, 3, 4, 7, 8, 10]) // "0-4,7-8,10" getRanges([4,7,10]) // "4,7,10" getRanges([2, 3, 8, 9]) // "2-3,8-9" 

Sobre este problema, me equivoqué seriamente y decidí que no era la forma más hermosa. La solución, lamentablemente, no se ha conservado, por lo que le daré una solución a uno de nuestros candidatos:

 function getRanges(arr: number[]) { return arr.map((v, k) => { if (v - 1 === arr[k - 1]) { if (arr[k + 1] === v + 1) { return '' } else { return `-${v},` } } else { return v + ',' } }).join('').split(',-').join('-') } 

De las desventajas: acceder a la matriz en un índice inexistente y manipulación de cadena fea: join-split-join. Esta solución también es incorrecta, porque con el ejemplo getRanges ([1, 2, 3, 5, 6, 8]), se devuelve "1-3,5-6,8" y "matar" la coma al final para aumentar aún más las condiciones al complicar la lógica y reducir la legibilidad.

Aquí hay una solución al estilo Yandex:

 const getRanges = arr => arr .reduceRight((r, e) => r.length ? (r[0][0] === e + 1 ? r[0].unshift(e) : r.unshift([e])) && r : [[e]], []) .map(a => a.join('-')).join(',') 

¿Google ayudará a escribir soluciones tan elegantes? Para producir dicho código, necesita dos componentes: experiencia con muchos algoritmos y excelente conocimiento del idioma. Y esto es exactamente lo que advierten los reclutadores de Yandex: le preguntarán sobre algoritmos y lenguaje. Yandex prefiere contratar desarrolladores que puedan escribir código genial. Dichos programadores son efectivos, pero lo más importante, intercambiables: escribirán sobre las mismas soluciones. Los desarrolladores con menos conocimientos teóricos en una tarea pueden dar docenas de soluciones diversas, a veces simplemente sorprendentes: uno de los candidatos para nuestra vacante envolvió una muleta que me puso los ojos en la frente.

UPD: como señaló el usuario MaxVetrov , mi solución es incorrecta:

 getRanges([1,2,3,4,6,7]) // 1-2-3-4,6-7 

Por lo tanto, yo mismo no he podido resolver adecuadamente este problema hasta ahora.

UPD2: En general, los comentarios me convencieron de que este código resultó ser malo, incluso si funcionaba correctamente.

No fue en vano que pasé tiempo traduciendo artículos en la oficina de Yandex, porque durante esta lección entendí cómo convertirme en un entrevistador efectivo. Tomé la idea y el formato de sus tareas como base, pero:

• No ofrecí escribir código en papel, pero pedí escribir en code.yandex-team.ru . Este es un editor de código en línea multiusuario sin la posibilidad de su ejecución. Quizás haya otra opción más conveniente, pero hubo una búsqueda y quedó flojera;
• No necesitaba una solución ideal, pero pidió resolverla de alguna manera;
• No requería el conocimiento del idioma de memoria, podía preguntarse la función o método deseado;
• Redujo el tiempo para una entrevista técnica a 30 minutos.

Uno de los objetivos de nuestra entrevista técnica:

 let n = 0 while (++n < 5) { setTimeout(() => console.log(n), 10 + n) } //     ? 

Creo que esta es una prueba muy importante para el desarrollador de JavaScript. Y el punto aquí no es el cierre y la comprensión de las diferencias entre preincremento y postincremento, sino que, por alguna razón inexplicable, una cuarta parte de los entrevistados cree que console.log se ejecutará antes de que termine el ciclo. No estoy exagerando. Estas personas tienen un currículum y experiencia laboral de al menos dos años, y resolvieron con éxito otras tareas que no estaban vinculadas a las devoluciones de llamadas. O bien, esta es una nueva generación de desarrolladores de JavaScript que crecieron en async / wait, que escucharon algo más sobre Promise, pero las devoluciones de llamadas para ellos, como un teléfono de disco para un adolescente moderno, marcarán el número, incluso si no es la primera vez, pero no lo entenderán cómo funciona y por qué.

Esta tarea tiene una continuación: necesita agregar el código para que console.log también se ejecute dentro de setTimeout, pero los valores 1, 2, 3, 4. se muestran en la consola. El dicho "vive, aprende" es apropiado aquí, porque una vez uno de los entrevistados propuso tal solución:

 setTimeout(n => console.log(n), 10 + n, n) 

Y luego descubrí que setTimeout y setInterval pasan el tercer argumento y los posteriores a la devolución de llamada. Es una pena, sí. Por cierto, el conocimiento resultó ser útil: he usado esta función más de una vez.

Pero tomé prestada esta tarea de Yandex como es:

 /*    fetchUrl,     .  fetchUrl     fetch,    Promise      reject */ fetchUrl('https://google/com') .then(...) .catch(...) // atch     5       fetchUrl 

Aquí hay habilidades probadas con Promise. Por lo general, pido resolver este problema con promesas puras, y luego usar async / await. Con async / await, la solución es intuitivamente simple:

 function async fetchUrl(url) { for (let n = 0; n < 5; n++) { try { return await fetch(url) } catch (err) { } } throw new Error('Fetch failed after 5 attempts') } 

También puede aplicar el dicho "vive, aprende" a esta decisión, pero con respecto a mi entrevistador de Yandex: no especificó que se puede / no se puede usar async / waitit, y cuando escribí esta solución, se sorprendió: "No trabajé con async / wait, no pensé que se pudiera resolver tan fácilmente ". Probablemente esperaba ver algo como esto:

 function fetchUrl(url, attempt = 5) { return Promise.resolve() .then(() => fetch(url)) .catch(() => attempt-- ? fetchUrl(url, attempt) : Promise.reject('Fetch failed after 5 attempts')) }'error' 

Este ejemplo puede mostrar qué tan bien una persona entiende las promesas, esto es especialmente importante en la parte posterior. Una vez que vi el código JavaScript de un desarrollador que no entendió completamente las promesas, preparé una promesa para la transacción de secuencia de la siguiente manera:

 const transaction = Promise.resolve() for (const user of users) { transaction.then(() => { return some_action... }) } 

Y preguntándose por qué solo un usuario aparece en su transacción. Se podría usar Promise.all, pero se podría saber que Promise.prototype.then no agrega otra devolución de llamada, sino que crea una nueva promesa y será así:

 let transaction = Promise.resolve() for (const user of users) { transaction = transaction.then(() => { await perform_some_operation... return some_action... }) } 

Este caso me hizo pensar en complicar la tarea de comprender las promesas, pero el candidato que se negó a resolver los problemas me ayudó a formular una nueva tarea, los llamó literalmente basura y dijo que estaba acostumbrado a trabajar con código real, que rebusqué durante un par de minutos. en el código fuente de uno de nuestros proyectos, le dio el código real:

 public async addTicket(data: IAddTicketData): Promise<number> { const user = data.fromEmail ? await this.getUserByEmail(data.fromEmail) : undefined let category = data.category if (category === 'INCIDENT' && await this.isCategorizableType(data.type)) { category = 'INC_RFC' } const xml = await this.twig.render('Assyst/Views/add.twig', { from: data.fromEmail, text: data.text, category, user, }) const response = await this.query('events', 'post', xml) return new Promise((resolve, reject) => { xml2js.parseString(response, (err, result) => { if (err) { return reject(new Error(err.message)) } if (result.exception) { return reject(new Error(result.exception.message)) } resolve(result.event.id - 5000000) }) }) } 

Y se le pidió que elimine las palabras clave async / wait. Desde entonces, esta tarea fue la primera y, en la mitad de los casos, la última en la entrevista, a menudo está realmente abrumado.

Yo mismo nunca he resuelto este problema antes de escribir esta nota y lo hago por primera vez por tercera vez (la primera es demasiado larga y en la segunda no noté que quedaba una espera):



¿Qué conclusión se puede sacar de todo esto? Las entrevistas son interesantes y útiles ... Por supuesto, si no está buscando trabajo con urgencia.

Al final, te daré otra tarea de la historia con Yandex, todavía no se la he mostrado a nadie ^* , me he ocupado de lo que se llama un caso especial. Hay un conjunto de pancartas, cada pancarta tiene un "peso", que indica con qué frecuencia se mostrará la pancarta en relación con otras pancartas:

 const banners = [ { name: 'banner 1', weight: 1 }, { name: 'banner 2', weight: 1 }, { name: 'banner 3', weight: 1 }, { name: 'banner 4', weight: 1 }, { name: 'banner 5', weight: 3 }, { name: 'banner 6', weight: 2 }, { name: 'banner 7', weight: 2 }, { name: 'banner 8', weight: 2 }, { name: 'banner 9', weight: 4 }, { name: 'banner 10', weight: 1 }, ] 

Por ejemplo, si hay tres pancartas con los pesos 1, 1, 2, su peso combinado es 4, y el peso del tercero es 2/4 del peso total, por lo que debe mostrarse en el 50% de los casos. Es necesario implementar la función getBanner, que al azar, pero teniendo en cuenta los pesos, devuelve un banner para mostrar. La solución se puede verificar en este fragmento , donde se muestra la distribución esperada y real.

UPD: comenzaron no solo a menos el artículo en sí, sino también a quemar karma a pasos agigantados y lo oculté ocultando material, que es feo en relación con los comentaristas. Corrijo este mudaquismo de mi parte.