Escuela de desarrollo de interfaces: análisis de tareas para Minsk y un nuevo conjunto en Moscú

Hoy se abrió una nueva matrícula en Escuela de desarrollo de interfaces Yandex en Moscu. La primera etapa de formación se llevará a cabo del 7 de septiembre al 25 de octubre. Los estudiantes de otras ciudades podrán participar de forma remota o presencial; la empresa pagará el viaje y el alojamiento en un albergue. La segunda, también etapa final, se prolongará hasta el 3 de diciembre y sólo podrá realizarse de forma presencial.

Mi nombre es Yulia Seredich, escribimos este post junto con Sergei Kazakov. Ambos somos desarrolladores de interfaces en la oficina de Yandex en Minsk y graduados de SRI de años anteriores.

Escuela de desarrollo de interfaces: análisis de tareas para Minsk y un nuevo conjunto en Moscú

Con motivo de la apertura de la inscripción en Moscú, publicamos un análisis de las tareas de introducción a la Escuela anterior, aquí en Minsk.

Si rastreamos la historia de las asignaciones SRI, año tras año probamos tres habilidades importantes para un programador:

  • Disposición. Todo desarrollador debería poder realizar diseños. No sucede que tengas al tío Seryozha que diseña para todo el equipo y tú solo escribes guiones. Por lo tanto, cada alumno debe demostrar que sabe escribir.
  • JavaScript. Si el asunto se limitara al diseño, entonces no tendríamos una Escuela de Desarrollo de Interfaces, sino una Escuela de Maquetadores. Es necesario revivir la interfaz bellamente diseñada. Por lo tanto, siempre hay una tarea para JS, pero a veces también es una tarea para los algoritmos: los amamos mucho.
  • La resolución de problemas es quizás la habilidad más importante de un desarrollador. Cuando se trata de crear interfaces, las cosas están cambiando muy rápidamente. Es como Lewis Carroll: "Tienes que correr lo más rápido que puedas para permanecer en el mismo lugar, y para llegar a otro lugar tienes que correr el doble de rápido". Todos los días nos topamos con nuevas tecnologías; debemos tenerlas en cuenta y poder comprenderlas. Por lo tanto, en la tercera tarea, propusimos comprender tecnologías con las que un desarrollador novato generalmente no está familiarizado.

En el análisis de cada tarea, te informaremos no solo del procedimiento correcto, sino también de los errores más habituales.

Tarea 1: Portafolio

En la primera tarea trabajaron el diseñador de colecciones de Yandex, Alexey Cherenkevich, que sabe diseñar, y su colega de servicio, el desarrollador de interfaces Sergey Samsonov.

Condicion

Crea un sitio web de portafolio: cuéntanos sobre ti, tu trabajo y tus expectativas de la Escuela. El sitio debe corresponder lo más posible al diseño propuesto (enlaces a diseños: 1000px, 600px, 320px, especificación). Sólo nos interesa el diseño, así que no utilice JavaScript.

A la hora de comprobarlo tendremos en cuenta:

  • tamaños de sangría, corrección del color, estilo de fuente, tamaño de fuente;
  • diseño semántico;
  • la presencia de diferentes estados de elementos: mostrar botones y enlaces al pasar el cursor, resaltar campos de entrada activos, etc.;
  • compatibilidad entre navegadores (probada en las últimas versiones de navegadores populares).

La ventaja será:

  • uso de soluciones CSS modernas: flexbox, grid, etc.;
  • Diseño adaptativo;
  • uso de preprocesadores y (o) postprocesadores, ensamblaje, minificación, optimización del código de salida;
  • Validación de formulario HTML, botón de carga de archivos estilizado.

La tarea es bastante voluminosa, por lo que puedes saltarte lo que no funcionará. Esto reducirá ligeramente tu puntuación, pero aún podrás demostrar tus conocimientos. Cuando haya terminado, envíenos dos enlaces: a su cartera y al código fuente en GitHub.

Los diseños propuestos en el encargo no sólo incluían pantallas para dispositivos móviles, tabletas y ordenadores de sobremesa, sino también con especificaciones reales.

Para aportar la mayor objetividad posible al resultado de la verificación de la primera tarea, se establecieron muchos criterios para esta verificación.

criterios

Sitio web diseñado. Esto parece obvio, pero algunos muchachos se saltaron algunos bloques por completo; o querían ahorrar tiempo o no podían hacerlos. El diseño se puede dividir a grandes rasgos en cuatro pantallas principales: la pantalla principal con un avatar, un bloque con una lista de expectativas del ISR, un bloque con una cartera y un bloque con información de contacto. Se podrían hacer en secciones o simplemente usando divs, lo principal es que los cuatro bloques estuvieran disponibles.

Cumplimiento del diseño con el diseño.. El diseñador creó una especificación separada (que incluye colores, tipografía, estados de los botones, etc.) para que sea más fácil para los candidatos. En la parte inferior había una pista sobre las sangrías y características de la primera pantalla. Quedé muy satisfecho con los muchachos que tuvieron en cuenta todos los deseos del diseñador: por ejemplo, la primera pantalla no debería haber sido menor que la altura de la ventana gráfica.

Diseño adaptativo - aquí es cuando la interfaz no está diseñada simplemente de modo que en tres resoluciones todo tenga un diseño de píxel a píxel. En los estados intermedios, el diseño tampoco debería desmoronarse. Algunos se olvidaron de limitar el ancho máximo del contenedor y configuraron todo a 1920 píxeles, otros estropearon los fondos, pero en general los candidatos hicieron frente a esta tarea.

Diseño semántico. “¿Cuántas veces le han dicho al mundo” que un enlace debe diseñarse como , un botón – como ? Afortunadamente, la mayoría de los candidatos también cumplieron con este requisito. No todos reconocieron la lista oculta en las expectativas del SRI, haciéndola usando etiquetas div, pero no es tan malo. Hubo un candidato que insertó todas las etiquetas semánticas que conocía, donde era necesario y donde no. Por ejemplo, en lugar de una lista: y . Después de todo, la semántica se trata de comprender la composición de su página y el propósito de cada bloque (la mayoría lo logró aquí), así como el uso de preprocesadores y/o posprocesadores (algunos lo lograron aquí, aunque este También estaba en los puntos: la mayoría de las veces usaban menos y scss).

Control deslizante de trabajo. En la tarea escribimos que JS no se puede utilizar. Aquí se probó la capacidad de resolver problemas: se podía crear un control deslizante usando una combinación de y . Toda la magia ocurre en el nivel del selector #button-N:checked ~ .slider-inner .slider-slides. Cuando hacemos clic en una de las casillas de verificación de entrada, pasa al estado marcado. Podemos aprovechar esto y asignar la traducción que necesitamos al contenedor con las diapositivas: transformar: traducir(-33%). Puedes ver la implementación del control deslizante. aquí.

Listas desplegables. Aquí todo también se redujo a y un selector similar: .accordion-item input:checked ~ .accordion-item__content. Puedes ver la implementación. aquí.

Disponibilidad de los estados :hover, :active y :focu*. Un punto muy importante. De ello dependía la comodidad al interactuar con la interfaz. El usuario siempre debe recibir comentarios sobre sus acciones. Este ítem fue verificado durante toda la interacción con el cuestionario. Si hice clic en el botón "Llámame" y visualmente no pasó nada (a pesar de que se envió la solicitud), esto es malo, porque entonces haré clic en él una y otra vez. Como resultado, se enviarán diez solicitudes y me devolverán la llamada diez veces. No debemos olvidar que los dispositivos móviles no tienen mouse, por lo que no debe pasar el mouse. Y un punto más que no afectó a quienes cumplieron con el punto sobre semántica. Si su control no es un elemento interactivo, cuando pase el cursor sobre él, el cursor permanecerá estándar. Se ve muy desordenado, incluso si has escrito una reacción para flotar. No subestimes el cursor: puntero.

animaciones. Es importante que todas las reacciones que ocurren con los elementos sean fluidas. Nada en la vida es instantáneo, por lo que tener transiciones activas y suspendidas fue suficiente para hacer que la interfaz sea más agradable. Bueno, quienes animaron el control deslizante y las listas son generalmente geniales.

Usando la última tecnología. Mucha gente usó flex, pero nadie completó la tarea usando grid. El punto se contaba si se utilizaba correctamente la flexión. Si en algún lugar el diseño se vino abajo debido a estas mismas flexiones, lamentablemente no recibió ningún punto adicional.

Validación de formulario. Todo lo que se necesitaba era agregar el atributo requerido a cada entrada del formulario. Agregamos puntos a quienes validaron el campo de correo electrónico como correo electrónico.

Aplicar estilo al botón de carga de archivos. Esperábamos ver una combinación como: y Seleccionar archivo. A continuación, necesitábamos ocultar la entrada y aplicar estilo a la etiqueta. Hay otra forma común: hacer una entrada transparente y colocarla encima del botón. Pero no todos los navegadores permiten aplicar estilo a y esta solución no se puede llamar completamente para varios navegadores. Y semánticamente es más correcto hacer una etiqueta.

Compatibilidad entre navegadores. Comprobamos que todo estaba bien en las dos últimas versiones de los navegadores modernos (sin IE, los participantes tuvieron suerte), así como en Safari en iPhone y Chrome en Android.

Por el contrario, dedujimos puntos si alguien usaba JS o Bootstrap: ambos anularían el propósito de toda la tarea. Además, los participantes con Bootstrap no sólo recibieron un negativo, sino que también perdieron muchos puntos en semántica y elementos implementados.

Aquellos que alojaron su sitio en algún lugar de Internet no recibieron ninguna ventaja particular, pero los revisores estaban muy contentos de no tener que descargar repositorios y ejecutarlos localmente en su computadora. Entonces esto sirvió como una ventaja para el karma.

La primera tarea fue muy útil principalmente para el alumno. Aquellos a quienes no aceptamos ahora tienen un currículum preparado; puede adjuntarlo con orgullo a todas las respuestas o publicarlo en sus páginas de gh.

Tarea 2: Ruta de transporte

El autor de la tarea es el jefe del grupo de interfaces de búsqueda Denis Balyko.

Condicion

¿Tienes un mapa estelar? Muestra el nombre de cada estrella, así como la distancia entre ella y otras estrellas en segundos luz. Implemente la función de solución, que debe tomar tres argumentos: un objeto en el que las claves son los nombres de las estrellas y los valores son las distancias a las estrellas (tráfico unidireccional en el espacio), así como los nombres de los puntos inicial y final del camino: inicio y final, respectivamente. La función debe devolver la distancia más corta desde la estrella inicial hasta la estrella final y el camino a seguir.

Firma de función:

const solution = function(graph, start, finish)  {
    // Ваше решение
} 

Datos de entrada de ejemplo:

const graph = {
  start: { A: 50, B: 20 },
  A: { C: 40, D: 20 },
  B: { A: 90, D: 90 },
  C: { D: 160, finish: 50 },
  D: { finish: 20 },
  finish: {}
};
const start = 'start';
const finish = 'finish'; 

Salida de ejemplo:

{
    distance: 90,
    path: ['start', 'A', 'D', 'finish']
} 

Nota: El esqueleto de la solución está en la carpeta src/, coloque su solución en solución.js.

La verificación de la segunda tarea fue la más automatizada y objetiva. La mayoría de los chicos supusieron que era necesario implementar el algoritmo de Dijkstra. Quienes encontraron su descripción e implementaron el algoritmo en JS están bien hechos. Sin embargo, al revisar la tarea, nos encontramos con muchos trabajos con los mismos errores. Buscamos fragmentos de código en Internet y encontramos un artículo en el que los participantes copiaron el algoritmo. Es curioso que mucha gente haya copiado el código del artículo junto con los comentarios del autor. Estos trabajos recibieron una puntuación baja. No prohibimos el uso de ninguna fuente, pero queremos que una persona profundice en lo que escribe.

criterios

Se otorgaron puntos principales por las pruebas. A veces estaba claro que los chicos estaban jugando con el repositorio, cambiando el nombre de las carpetas y las pruebas fallaban simplemente porque no podían encontrar los archivos necesarios. Este año intentamos ayudar a estos muchachos y les devolvimos todo a su lugar. Pero el año que viene planeamos cambiar al sistema de concursos, y esto ya no nos lo perdonarán.

También había criterios manuales “humanos”. Por ejemplo, la presencia de un estilo de código único. Nadie dedujo puntos por usar tabulaciones en lugar de espacios o viceversa. Otra cuestión es si alternas comillas simples con comillas dobles de acuerdo con una regla que conoces y colocas punto y coma al azar.

La claridad y legibilidad de la solución se tuvieron en cuenta por separado. En todos los congresos del mundo dicen que el 80% del trabajo de un programador consiste en leer código de otras personas. Incluso los escolares se someten a revisiones de códigos, tanto de sus curadores como de los demás. Por tanto, este criterio tenía un peso significativo. Ha habido trabajos en los que no había variables de más de un carácter; no hagas eso. Los comentarios de los participantes fueron muy alentadores, a excepción de aquellos que eran idénticos a los comentarios de Stella Chang.

El último criterio es la presencia de autotests. Sólo unas pocas personas los agregaron, pero para todos se convirtió en una gran ventaja en su karma.

La decisión correcta:

const solution = function(graph, START, FINISH)  {
    // Всё не бесплатно в этом мире
    const costs = Object.assign({[FINISH]: Infinity}, graph[START]);

    // Первая волна родительских нод
    const parents = { [FINISH]: null };
    Object.keys(graph[START]).reduce((acc, child) => (acc[child] = START) && acc, parents)

    const visited = [];
    let node;

    // Ищем «дешёвого» родителя, отмечаем пройденные
    do {
        node = lowestCostNode(costs, visited);
        let children = graph[node];
        for (let n in children) {
            let newCost = costs[node] + children[n];

            // Ещё не оценена или нашёлся более дешёвый переход
            if (!costs[n] || costs[n] > newCost) {
                costs[n] = newCost;
                parents[n] = node;
            }
        }
        visited.push(node);
    } while (node)

    return {
        distance: costs[FINISH],
        path: optimalPath(parents)
    };

    // Возврат назад по самым «дешёвым» родителям
    function optimalPath(parents) {
        let optimalPath = [FINISH];
        let parent = parents[FINISH];
        while (parent && parent !== START) {
            optimalPath.push(parent);
            parent = parents[parent];
        }
        optimalPath.push(START);
        return optimalPath.reverse();
    }

    // Минимальная стоимость из текущей ноды среди непросмотренных
    function lowestCostNode(costs, visited) {
        return Object.keys(costs).reduce((lowest, node) => {
            if (lowest === null || costs[node] < costs[lowest]) {
                if (!visited.includes(node)) {
                    lowest = node;
                }
            }

            return lowest;
        }, null);
    };
};

Tarea 3: Calendario de eventos

Fue preparado por los desarrolladores de interfaces Sergey Kazakov y Alexander Podskrebkin.

Condicion

Escribe un mini calendario para mostrar tu agenda. Puedes tomar el horario que quieras. Por ejemplo, el calendario de conferencias frontend en 2019.

El calendario debería verse como una lista. No hay otros requisitos de diseño. Permita configurar recordatorios de eventos con 3, 7 y 14 días de anticipación. Después de la primera descarga de Internet, el calendario debería abrirse y funcionar sin conexión.

Recursos útiles

Calendario de conferencias frontend:
confs.tech/javascript?topics=javascript%2Bcss%2Bux

Trabajadores de servicios:
desarrollador.mozilla.org/ru/docs/Web/API/Service_Worker_API/Using_Service_Workers
desarrolladores.google.com/web/fundamentals/primers/service-workers

API de notificaciones:
desarrollador.mozilla.org/ru/docs/Web/API/Notifications_API

La tercera tarea fue la más interesante de probar, porque había muchas soluciones posibles, cada una con la suya propia. Comprobamos cómo el candidato maneja tecnologías desconocidas: si sabe investigar, si prueba sus soluciones.

criterios

calendario plegado. Sí, todavía era necesario diseñarlo. También hubo quienes tomaron la condición demasiado literalmente y no insertaron una sola línea de código CSS. No parecía muy atractivo, pero si todo funcionaba, los puntos no disminuían.

Obtener una lista de eventos de una fuente. Esta no es una tarea de diseño, por lo que no se contó la lista de eventos incluidos en ella. Siempre puedes cancelar una conferencia, reprogramarla o agregar una nueva. Por lo tanto, era necesario recibir datos del exterior y representar el diseño según el JSON recibido. Era importante obtener los datos de cualquier forma (usando el método fetch o usando XMLHttpRequest). Si una persona agregaba un polyfill para buscar y marcaba su elección en el archivo Léame, esto se contaba como un plus.

Registro de trabajadores de servicios sin errores. y trabajar sin conexión después de la primera descarga. He aquí un ejemplo Trabajador de servicio con almacenamiento en caché programado en el primer arranque. Puede encontrar detalles sobre los trabajadores de servicios, sus capacidades y formas de trabajar con ellos (estrategias para trabajar con cachés, trabajar sin conexión) aquí.

Posibilidad de configurar un recordatoriopara que realmente funcione después de 3, 7, 14 días. Era necesario entender la API de Notificaciones, enlace al cual estaba en lo cierto. No esperábamos ninguna implementación específica para comprobar si es momento de impulsar. Se aceptó cualquier opción de trabajo: almacenamiento en localStorage, IndexDB o sondeo periódico por parte de un trabajador del servicio. Incluso fue posible crear un servidor push (aquí ejemplo), pero no funcionaría sin conexión. Era igualmente importante recibir un empujón después de cerrar la página y abrirla después de un tiempo. Si el recordatorio murió al mismo tiempo que se cerró la página, la solución no se contabilizó. Es genial cuando los muchachos pensaron en los revisores e hicieron posible recibir un empujón ahora mismo, para no esperar 3 días.

Posibilidad de colocar un icono en el escritorio. (PWA). Comprobamos la presencia del archivo. manifest.json con los iconos correctos. Algunos chicos crearon este archivo (o lo dejaron generado en CreateReactApp), pero no agregaron los íconos correctos. Luego, al intentar instalar, ocurrió un error como "se necesita un ícono diferente".

Estilo de código y estructura del proyecto.. Como en la segunda tarea, analizamos un único estilo de código (incluso si no coincidía con el nuestro). Algunos chicos atornillaron linters, eso es genial.

Errores de consola. Si había un indicador directamente en la consola de que algo andaba mal y el participante no le prestaba atención, entonces deducíamos puntos.

resultados

Lo curioso de las decisiones de los participantes:

  • Un cuestionario contenía el siguiente texto: “Un amigo programador me ayudó a crear una aplicación React. Lo bombardeé con preguntas sobre cómo y por qué, y me lo dijo. Realmente me gustó, quiero saber más sobre esto”. Apoyamos esta solicitud con todo nuestro corazón, pero desafortunadamente, el amigo del candidato no ayudó mucho a que la solicitud funcionara.
  • Un candidato envió un enlace a GitHub, donde se encontraba el archivo RAR; es difícil comentar sobre esto. 🙂
  • Otro candidato, en el comentario de la primera línea del archivo solucion.js, admitió honestamente que copió el algoritmo.

Recibimos solicitudes de 76 candidatos y seleccionamos a 23 personas. Nos enviaron cuestionarios no sólo desde Minsk, sino también desde Moscú, San Petersburgo e incluso Tatarstán. Algunos de los chicos nos sorprendieron con sus profesiones actuales: uno de ellos es experto forense y el otro es estudiante de medicina.

El resultado fue una distribución interesante de las tasas de éxito al completar las tareas. Los participantes completaron la primera tarea con una media del 60%, la segunda con un 50% y la tercera resultó ser la más difícil y fue completada con una media del 40%.

A primera vista, las tareas parecen complejas y requieren mucho tiempo. La razón no es que queramos eliminar tantos candidatos como sea posible. Durante sus estudios, los estudiantes se enfrentan a tareas de la vida real: crear un chat, Yandex.Music para niños o Yandex.Weather para personas que dependen del clima. Para ello necesitas una base de partida.

Recuerdo haber visto mi tarea de ingreso al SRI hace dos años y pensar que nunca la resolvería. Lo principal en este momento es sentarse, leer atentamente las condiciones y empezar a hacerlo. Resulta que las condiciones contienen casi el 80% de la solución. Por ejemplo, en la condición de la tercera tarea (la más difícil), agregamos enlaces a los trabajadores del servicio y a la API de notificaciones en MDN. Los estudiantes que estudiaron el contenido de los enlaces lo completaron sin dificultad.

Realmente me gustaría que este artículo lo lean los candidatos que planean ingresar al SRI en el futuro, que no pudieron ingresar a la Escuela de Minsk o que están comenzando a realizar cualquier otra tarea de prueba. Como puede ver, es muy posible hacerlo. Solo necesitas creer en ti mismo y escuchar todos los consejos de los autores.

Fuente: habr.com

Añadir un comentario