Aujourd'hui, un nouvel ensemble a ouvert ses portes à
la Yandex School of Interface Development de Moscou. Du 7 septembre au 25 octobre, la première étape de la formation aura lieu. Les étudiants d'autres villes pourront y participer à distance ou en personne - l'entreprise paiera la route et l'hébergement à l'auberge. Deuxièmement, c'est la dernière étape qui durera jusqu'au 3 décembre, elle ne peut être complétée qu'en personne.
Je m'appelle Julia Seredich, nous avons écrit ce post avec Sergey Kazakov. Nous sommes à la fois développeurs d'interfaces au bureau de Minsk de Yandex et diplômés du SRI des dernières années.
À l'occasion de l'ouverture des inscriptions à Moscou, nous publions une analyse des tâches d'entrée à l'école précédente - ici à Minsk.
Si nous retraçons l'historique des tâches SRI, nous testons d'année en année trois compétences importantes pour un programmeur:
- Disposition. Chaque développeur doit pouvoir composer. Il n’arrive pas que vous ayez Oncle Seryozha qui compose pour toute l’équipe, et vous n’écrivez que des scripts. Par conséquent, chaque élève doit montrer comment il sait composer.
- Javascript Si l'affaire se limitait à la composition, nous n'aurions pas une école de développement d'interface, mais une école de mise en page. La belle interface repliée doit être relancée. Par conséquent, il y a toujours une tâche sur JS, mais parfois c'est aussi une tâche sur les algorithmes - nous les aimons tellement.
- La résolution de problèmes est peut-être la principale compétence du développeur. Tout change très rapidement dans la création d'interfaces. C’est comme Lewis Carroll: "Il faut courir aussi vite juste pour rester au même endroit, mais pour arriver à un autre endroit, il faut courir deux fois plus vite." Chaque jour, nous sommes confrontés à de nouvelles technologies - il faut compter avec elles et pouvoir les comprendre. Par conséquent, dans la troisième tâche, nous avons proposé de comprendre les technologies avec lesquelles un développeur novice n'est généralement pas familier.
Dans l'analyse de chaque tâche, nous parlerons non seulement de la procédure correcte, mais également des erreurs courantes.
Tâche 1: portefeuille
La première tâche a été réalisée par le designer de Yandex.Collections Alexei Cherenkevich, qui sait composer et son collègue du service, le designer d'interface Sergey Samsonov.
Condition
Créez un site portfolio: parlez-nous de vous, de votre travail et des attentes de l'école. Le site doit correspondre autant que possible à la mise en page proposée (liens vers les mises en page: 1000px , 600px , 320px , spécifications ). Nous ne sommes intéressés que par la mise en page, veuillez donc ne pas utiliser JavaScript.
Lors de la vérification, nous prendrons en compte:
- tailles de rembourrage, précision des couleurs, style de police, taille de la taille;
- disposition sémantique;
- la présence de divers états d'éléments: affichage des boutons et des liens lorsque vous survolez, mettez en surbrillance les champs de saisie actifs, etc.;
- compatibilité entre navigateurs (vérifiée dans les dernières versions des navigateurs populaires).
Le plus sera:
- utilisation de solutions CSS modernes: flexbox, grille, etc.;
- mise en page adaptative;
- utilisation de pré et (ou) post-processeurs, assemblage, minification, optimisation du code de sortie;
- Validation de formulaire HTML, bouton de téléchargement de fichier stylisé.
La tâche est assez volumineuse, vous pouvez donc ignorer ce qui ne fonctionnera pas. Cela réduira légèrement le score, mais vous pouvez toujours démontrer vos connaissances. Une fois terminé, envoyez-nous deux liens - vers le portfolio et le code source sur GitHub.
Les dispositions proposées dans la mission ne concernaient pas seulement des écrans pour appareils mobiles, tablettes et ordinateurs de bureau, mais également une véritable spécification.
Pour ajouter autant d'objectivité que possible au résultat du test de la première tâche, il y avait beaucoup de critères pour ce test.
Critères
Site terminé . Cela semble évident, mais certains gars ont complètement raté certains blocs - soit ils voulaient gagner du temps, soit ils ne pouvaient pas les faire. La mise en page peut être conditionnellement divisée en quatre écrans principaux: l'écran principal avec un avatar, un bloc avec une liste des attentes du SRI, un bloc avec un portefeuille et un bloc avec des informations de contact. Ils peuvent être faits en sections ou simplement en utilisant un div, l'essentiel est que les quatre blocs soient disponibles.
Disposition de mise en page correspondante . Le concepteur a fait une spécification distincte (y compris les couleurs, la typographie, les états des boutons, etc.) pour le rendre plus facile pour les candidats. Vous trouverez ci-dessous une astuce sur l'indentation et les caractéristiques du premier écran. Très satisfait des gars qui ont pris en compte tous les souhaits du concepteur: par exemple, le premier écran aurait dû être au moins à la hauteur de la fenêtre.
Disposition adaptative - c'est lorsque l'interface n'est pas seulement constituée de sorte qu'à trois résolutions, tout était pixel par pixel selon la disposition. Dans les états intermédiaires, la disposition ne doit pas non plus s'effondrer. Quelqu'un a oublié de limiter la largeur maximale du conteneur et a tout tiré à 1920 pixels, quelqu'un a gâché les arrière-plans, mais dans l'ensemble, les candidats ont bien fait ce travail.
Disposition sémantique . «Combien de fois ont-ils dit au monde» que le lien devrait être encadré comme <a>, le bouton devrait être encadré comme <button>. Heureusement, la plupart des candidats ont satisfait à cette exigence. Tout le monde n'a pas reconnu la liste cachée dans les attentes du SRI en la faisant à l'aide de balises div, mais ce n'est pas si effrayant. Il y avait un candidat qui a inséré toutes les balises sémantiques qu'il savait seulement - où c'était nécessaire et où ce n'était pas nécessaire. Par exemple, au lieu d'une liste, <section> et <article>. Pourtant, la sémantique - il s'agit de comprendre la composition de votre page et le but de chaque bloc (la majorité l'a fait ici), ainsi que l'utilisation de pré et / ou post-processeurs (peu l'ont fait ici, bien que ce soit également en points - moins et scss étaient le plus souvent connectés) .
Curseur de travail . Dans la mission, nous avons écrit que JS ne peut pas être utilisé. Ici, la capacité de résoudre des problèmes a été testée - le curseur pouvait être créé à l'aide des connecteurs <input> et <label for = ”# id”>. Toute magie opère au niveau du sélecteur # bouton-N: vérifié ~ .slider-inner .slider-slides. Lorsque nous cliquons sur l'une des cases à cocher d'entrée, il passe à l'état vérifié. Nous pouvons l'utiliser et affecter la traduction souhaitée à notre conteneur avec slides: transform: translate (-33%). Voir l'implémentation du curseur
ici .
Listes déroulantes . Tout se résumait à <input name = "accordéion" type = "radio"> et à un sélecteur similaire: .accordion-item input: vérifié ~ .accordion-item__content. Voir l'implémentation
ici .
La présence des états: hover,: active, et: focu * . Un point très important. Le confort dépendait de lui lors de l'interaction avec l'interface. L'utilisateur doit toujours recevoir des commentaires sur ses actions. Cet élément a été vérifié tout au long de l'interaction avec le questionnaire. Si j'ai cliqué sur le bouton «Appelez-moi» et que visuellement, rien ne s'est produit (même si la demande a été envoyée) - c'est mauvais, car je vais cliquer dessus encore et encore. En conséquence, dix demandes seront envoyées et je serai rappelé dix fois. N'oubliez pas qu'il n'y a pas de souris sur les appareils mobiles - ce qui signifie qu'il ne devrait pas y avoir de vol stationnaire. Et encore une chose qui ne concernait pas ceux qui respectaient le point sur la sémantique. Si votre contrôle n'est pas un élément interactif, alors lorsque vous le survolez, le curseur reste standard. Cela semble très désordonné, même si vous avez prescrit une réponse au vol stationnaire. Ne sous-estimez pas le curseur: pointeur.
Des animations Il est important que tout ce qui se passe avec les éléments de réaction soit fluide. Il n'y a rien d'instantané dans la vie, donc la présence de transitions en vol stationnaire et actif suffisait à rendre l'interface plus agréable. Eh bien, ceux qui ont animé le curseur et les listes sont généralement bien faits.
Utilisation des dernières technologies . Beaucoup ont utilisé flex, mais personne n'a terminé la tâche en utilisant la grille. Un élément compté si flex a été utilisé correctement. Si quelque part, à cause de ces mêmes flexions, la disposition se séparait - hélas, vous n'avez pas reçu de points supplémentaires.
Validation du formulaire . Tout ce qui était requis était d'ajouter l'attribut requis à chaque formulaire d'entrée. Nous avons ajouté des points à ceux qui ont validé le champ e-mail comme e-mail.
Stylisation du bouton de téléchargement de fichiers . Nous nous attendions à voir un tas du formulaire: <input type = "file" id = "file" name = "file" class = "inputfile" /> et <label for = "file"> Sélectionnez le fichier </label>. En outre, il était nécessaire de masquer l'entrée et de nommer l'étiquette. Il existe une autre façon courante - de faire une entrée transparente et de la placer au-dessus du bouton. Mais tous les navigateurs n'autorisent pas le style <input type = ”file”>, et une telle solution ne peut pas être appelée entièrement cross-browser. Et il est sémantiquement plus correct de faire une étiquette.
Compatibilité entre navigateurs . Nous avons vérifié que tout allait bien, dans les deux dernières versions des navigateurs modernes (sans IE, les participants étaient chanceux), ainsi que dans Safari sur iPhones et dans Chrome sur androïdes.
Au contraire, nous avons marqué des points si quelqu'un a utilisé JS ou Bootstrap: les deux ont rendu la tâche vide de sens. De plus, les participants avec Bootstrap ont non seulement reçu un moins, mais ont également reçu beaucoup de points pour la sémantique et les éléments implémentés.
Ceux qui ont balisé leur site quelque part sur Internet n'ont pas obtenu un avantage particulier - mais les inspecteurs étaient très heureux de ne pas avoir à télécharger les référentiels et à les exécuter localement sur leur ordinateur. Donc cela a servi de plus au karma.
La première tâche a été très utile principalement pour l'étudiant. Ceux que nous n'avons pas acceptés maintenant ont un résumé résumé - vous pouvez fièrement le joindre à toutes les réponses ou le mettre sur vos pages gh.
Tâche 2: itinéraire de transport
L'auteur de la tâche est Denis Balyko, chef du groupe d'interface de recherche.
Condition
Vous avez une carte du ciel étoilé. Il montre le nom de chaque étoile, ainsi que la distance qui la sépare des autres étoiles en quelques secondes-lumière. Implémentez la fonction solution, qui doit prendre trois arguments: un objet dans lequel les clés sont les noms des étoiles, et les valeurs sont les distances aux étoiles (dans le trafic à sens unique dans l'espace), ainsi que les noms des points de départ et d'arrivée du chemin - début et fin, respectivement. La fonction doit renvoyer la distance la plus courte entre le début de l'étoile et la fin de l'étoile et le chemin sur lequel il est nécessaire d'aller.
Signature de la fonction:
const solution = function(graph, start, finish) {
Exemple d'entrée:
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';
Exemple de sortie:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }
Remarque: le framework de solution se trouve dans le dossier src /, placez votre solution dans solution.js.
La vérification de la deuxième tâche a été la plus automatisée et la plus objective. La plupart des gars ont deviné qu'il était nécessaire d'implémenter l'algorithme de Dijkstra. Ceux qui ont trouvé sa description et implémenté l'algorithme sur JS sont super. Cependant, lors de la vérification de l'affectation, nous avons rencontré beaucoup de travail avec les mêmes erreurs. Nous avons recherché des fragments de code sur Internet et trouvé un article d'où les participants ont annulé l'algorithme. C'est drôle que beaucoup de gens aient copié le code de l'article avec les commentaires de l'auteur. Un tel travail a reçu un score faible. Nous n'interdisons l'utilisation d'aucune source, mais nous voulons que la personne se penche sur ce qu'il écrit.
Critères
Les principaux points ont été attribués aux tests. Parfois, il était évident que les gars se trompaient sur le référentiel en renommant les dossiers, et les tests tombaient simplement parce qu'ils ne trouvaient pas les fichiers dont ils avaient besoin. Cette année, nous avons essayé d'aider ces types et avons tout remis à leur place. Mais l'année prochaine, nous prévoyons de passer à un système de concours, et cela ne sera pas pardonné.
Il y avait aussi des critères manuels «humains». Par exemple - la présence d'un style de code unique. Personne n'a réduit les points pour utiliser des tabulations au lieu d'espaces ou vice versa. C'est une autre affaire si vous alternez des guillemets simples avec des guillemets doubles selon une règle connue et que vous mettez des points-virgules séparément.
Séparément, la clarté et la lisibilité de la solution ont été prises en compte. Lors de toutes les conférences à travers le monde, ils disent que le travail du programmeur consiste à 80% à lire le code des autres. Même les écoliers passent par une révision du code - avec leurs conservateurs et entre eux. Ce critère avait donc un poids important. Il y avait des travaux dans lesquels il n'y avait pas de variables de plus d'un caractère - veuillez ne pas le faire. Les commentaires des participants ont été très satisfaits - à l'exception de ceux qui étaient identiques aux commentaires de Stella Chang.
Le dernier critère est la disponibilité des autotests. Ils n'ont été ajoutés que par quelques personnes, mais pour tout le monde, cela est devenu un énorme avantage en karma.
La bonne décision:
const solution = function(graph, START, FINISH) {
Tâche 3: Calendrier des événements
Il a été préparé par les développeurs d'interfaces Sergey Kazakov et Alexander Podskrebkin.
Condition
Écrivez un mini calendrier pour afficher le calendrier. Vous pouvez prendre n'importe quel horaire que vous aimez. Par exemple, le calendrier des conférences frontales en 2019.
Le calendrier doit ressembler à une liste. Il n'y a aucune autre exigence de conception. Permet de définir des rappels d'événement sur 3, 7 et 14 jours. Après le premier téléchargement avec Internet, le calendrier devrait s'ouvrir et fonctionner hors ligne.
Ressources utiles
Calendrier des conférences front-end:
confs.tech/javascript?topics=javascript%2Bcss%2Bux
Travailleurs des services:
developer.mozilla.org/en/docs/Web/API/Service_Worker_API/Using_Service_Workers
developers.google.com/web/fundamentals/primers/service-workers
API de notifications:
developer.mozilla.org/en/docs/Web/API/Notifications_API
La troisième tâche a été la plus intéressante à tester, car il y avait tellement de solutions, chacune ayant sa propre solution. Nous avons vérifié comment le candidat gère les technologies inconnues - s'il sait comment enquêter, s'il teste ses solutions.
Critères
Le calendrier composé . Oui, il avait encore besoin d'être maquillé. Il y avait ceux qui comprenaient la condition trop littéralement et n'inséraient pas une seule ligne de code CSS. Cela n'avait pas l'air très personnel, mais si tout fonctionnait, les points ne diminuaient pas.
Récupération d'une liste d'événements à partir d'une source . Ce n'est pas une tâche de composition, donc la liste des événements qui y sont cousus n'a pas été comptée. Vous pouvez toujours annuler la conférence, la reprogrammer, en ajouter une nouvelle. Il était donc nécessaire de recevoir des données de l'extérieur et de rendre la disposition déjà basée sur le JSON reçu. Il était important de toute façon (en utilisant la méthode fetch ou en utilisant XMLHttpRequest) d'obtenir les données. Si une personne a ajouté un polyfill à récupérer et a marqué son choix dans le fichier Lisez-moi, cela comptait comme un plus.
Enregistrement d'un travailleur de service sans erreur et travail hors ligne après le premier démarrage.
Voici un exemple de service worker avec mise en cache planifiée au premier démarrage. Des détails sur les employés de service, leurs capacités et leurs façons de travailler avec eux (stratégies pour travailler avec le cache, travailler hors ligne) peuvent être trouvés
ici .
La possibilité de définir un rappel pour qu'il fonctionne vraiment après 3, 7, 14 jours. Il était nécessaire de comprendre l'API Notifications, dont le
lien était directement dans la tâche. Nous n'avons pas attendu d'implémentation spécifique pour vérifier si le moment était venu de pousser. Toute option de travail a été acceptée: stockage dans localStorage, IndexDB ou interrogation périodique par un technicien de service. Vous pourriez même créer un serveur push (voici
un exemple ), mais cela ne fonctionnerait pas hors ligne. Il était également important d'obtenir une poussée après la fermeture de la page - et son ouverture après un certain temps. Si le rappel "est mort" en même temps que la page était fermée, la décision ne comptait pas. C'est cool quand les gars ont pensé aux inspecteurs et ont profité de l'occasion pour faire pression - pour ne pas attendre 3 jours.
La possibilité de faire l'icône sur le bureau (PWA). Nous avons vérifié le fichier
manifest.json avec les icônes correctes. Certains gars ont créé ce fichier (ou ont laissé celui généré dans CreateReactApp) - mais n'ont pas ajouté les icônes correctes. Ensuite, lors de la tentative d'installation, une erreur comme «besoin d'une autre icône» s'est produite.
Style de code et structure du projet . Comme dans la deuxième tâche, nous avons examiné un style de code unique (même s'il ne correspondait pas au nôtre). Certains gars ont vissé des linters - c'est super.
Erreurs dans la console . S'il y avait un indicateur directement dans la console que quelque chose n'allait pas et que le participant n'y avait pas prêté attention, alors nous avons pris des points.
Résumé
Drôle dans les décisions des participants:
- Un questionnaire contenait le texte suivant: «Un ami programmeur a aidé à assembler l'application React. Je lui ai posé des questions sur quoi, comment et pourquoi, a-t-il dit. Je l'ai beaucoup aimé, je veux en savoir plus. » Nous avons soutenu sans réserve ce questionnaire, mais malheureusement, l'ami du candidat ne l'a pas vraiment aidé à faire une demande de travail.
- Un candidat a envoyé un lien vers GitHub, où se trouvait l'archive RAR - il est difficile de commenter cela d'une manière ou d'une autre. :)
- Un autre candidat dans le commentaire sur la première ligne du fichier solution.js a honnêtement admis avoir copié l'algorithme.
Nous avons reçu des questionnaires de 76 candidats et sélectionné 23 d'entre eux. Des questionnaires nous ont été envoyés non seulement de Minsk, mais aussi de Moscou, de Saint-Pétersbourg et même du Tatarstan. Certains gars ont été surpris par leur profession actuelle: l'un d'eux est médecin légiste et l'autre est étudiant à l'université de médecine.
Il s'est avéré une répartition intéressante du succès dans l'accomplissement des tâches. Les participants ont accompli la première tâche en moyenne de 60%, la seconde - de 50%, et la troisième s'est avérée être la plus difficile et elle a été accomplie en moyenne de 40%.
À première vue, les tâches semblent compliquées et prennent du temps. La raison n'est pas que nous voulons éliminer autant de candidats que possible. Pendant la formation, les étudiants sont confrontés à de vraies tâches - faire un chat, Yandex.Music pour les enfants ou Yandex.Weather pour les personnes dépendantes de la météo. Pour ce faire, vous avez besoin d'une base de départ.
Je me souviens de la façon dont j'ai vu mon introduction au SRI il y a deux ans et j'ai pensé que je ne pourrais jamais le résoudre. L'essentiel en ce moment est de s'asseoir, de lire attentivement les conditions et de commencer à faire. Il s'avère que les conditions contiennent près de 80% de la solution. Par exemple, dans l'état de la troisième tâche (la plus difficile), nous avons ajouté des liens vers les techniciens de service et l'API Notifications sur MDN. Les étudiants qui ont étudié le contenu des liens se sont débrouillés sans difficulté.
Je veux vraiment que cet article soit lu par les candidats qui envisagent d'entrer dans le SRI à l'avenir, ne pourraient pas entrer à l'école de Minsk, ou commencer à faire toute autre tâche de test. Comme vous pouvez le voir, il est tout à fait possible d’agir. Il suffit de croire en soi et d'écouter tous les conseils des auteurs.