Aujourd'hui, une nouvelle inscription a été ouverte à à Moscou. La première étape de formation se déroulera du 7 septembre au 25 octobre. Les étudiants d'autres villes pourront y participer à distance ou en personne - l'entreprise paiera les frais de déplacement et d'hébergement en auberge. La deuxième, également dernière étape, durera jusqu'au 3 décembre et ne pourra être complétée qu'en personne.
Je m'appelle Yulia Seredich, nous avons écrit cet article avec Sergei Kazakov. Nous sommes tous deux développeurs d'interfaces au bureau Yandex de Minsk et diplômés du SRI des années précédentes.
A l'occasion de l'ouverture des inscriptions à Moscou, nous publions une analyse des tâches d'introduction à l'école précédente - ici à Minsk.
Si l'on retrace l'historique des missions SRI, d'année en année nous avons testé trois compétences importantes pour un programmeur :
- Mise en page. Chaque développeur devrait être capable de faire la mise en page. Il n'arrive pas que vous ayez l'oncle Seryozha qui conçoit pour toute l'équipe et que vous écriviez uniquement des scripts. Par conséquent, chaque étudiant doit montrer comment il sait composer.
- JavaScript. Si la question se limitait à la mise en page, nous n'aurions pas une école de développement d'interfaces, mais une école de concepteurs de mises en page. L'interface magnifiquement conçue doit être relancée. Par conséquent, il y a toujours une tâche pour JS, mais parfois c'est aussi une tâche pour les algorithmes - nous les aimons tellement.
- La résolution de problèmes est peut-être la compétence la plus importante d’un développeur. Lorsqu’il s’agit de créer des interfaces, les choses évoluent très vite. C'est comme Lewis Carroll : « Il faut courir aussi vite que possible pour rester au même endroit, et pour se rendre à un autre endroit, il faut courir deux fois plus vite. » Chaque jour, nous rencontrons de nouvelles technologies : nous devons en tenir compte et être capables de les comprendre. Par conséquent, dans la troisième tâche, nous avons proposé de comprendre des technologies avec lesquelles un développeur novice n'est généralement pas familier.
Lors de l'analyse de chaque tâche, nous vous expliquerons non seulement la procédure correcte, mais également les erreurs courantes.
Tâche 1 : Portfolio
La première tâche a été réalisée par le concepteur de Yandex.Collections, Alexey Cherenkevich, qui sait faire la mise en page, et par son collègue de service, le développeur d'interface Sergey Samsonov.
Condition
Créez un site portfolio : parlez-nous de vous, de votre travail et de vos attentes vis-à-vis de l'École. Le site doit correspondre autant que possible à la mise en page proposée (liens vers les mises en page : , , , ). Seule la mise en page nous intéresse, veuillez donc ne pas utiliser JavaScript.
Lors de la vérification, nous prendrons en compte :
- tailles d'indentation, exactitude des couleurs, style de police, taille de police ;
- disposition sémantique ;
- la présence de différents états des éléments : affichage de boutons et de liens au survol du curseur, mise en évidence des champs de saisie actifs, etc. ;
- compatibilité entre navigateurs (testée dans les dernières versions des navigateurs populaires).
L'avantage sera :
- utilisation de solutions CSS modernes : flexbox, grille, etc. ;
- Disposition adaptative ;
- utilisation de pré- et (ou) post-processeurs, assemblage, minification, optimisation du code de sortie ;
- Validation du 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 votre score, mais vous pourrez toujours démontrer vos connaissances. Lorsque vous avez terminé, envoyez-nous deux liens : vers votre portfolio et le code source sur GitHub.
Les mises en page proposées dans le cadre de la mission ne comportaient pas seulement des écrans pour appareils mobiles, tablettes et ordinateurs de bureau, mais également des spécifications réelles.
Afin d'apporter le plus d'objectivité possible au résultat du contrôle de la première tâche, de nombreux critères ont été définis pour ce contrôle.
critères
Site Web conçu. Cela semble évident, mais certains gars ont complètement sauté certains blocs - soit ils voulaient gagner du temps, soit ils n'ont pas pu les faire. La mise en page peut être grossièrement divisée en quatre écrans principaux : l'écran principal avec un avatar, un bloc avec une liste d'attentes du SRI, un bloc avec un portfolio et un bloc avec des informations de contact. Ils pourraient être réalisés en sections ou simplement en utilisant des divs, l'essentiel est que les quatre blocs soient disponibles.
Conformité du tracé avec le tracé. Le concepteur a élaboré une spécification distincte (incluant les couleurs, la typographie, l'état des boutons, etc.) pour faciliter la tâche des candidats. En bas, il y avait une indication sur les retraits et les caractéristiques du premier écran. J'ai été très satisfait des gars qui ont pris en compte tous les souhaits du concepteur : par exemple, le premier écran n'aurait pas dû être inférieur à la hauteur de la fenêtre.
Disposition adaptative - c'est à ce moment-là que l'interface n'est pas simplement conçue de manière à ce qu'à trois résolutions, tout soit pixel à pixel. Dans les états intermédiaires, la mise en page ne doit pas non plus s'effondrer. Certains ont oublié de limiter la largeur maximale du conteneur et ont tout réglé sur 1920 pixels, certains ont gâché les arrière-plans, mais dans l'ensemble, les candidats ont bien fait face à cette tâche.
Disposition sémantique. « Combien de fois ont-ils dit au monde » que le lien devait être conçu comme , le bouton – comme . Heureusement, la plupart des candidats remplissaient également cette condition. Tout le monde n'a pas reconnu la liste cachée dans les attentes du SRI, en la faisant utiliser des balises div, mais ce n'est pas si mal. Il y avait un candidat qui insérait toutes les balises sémantiques qu'il connaissait - là où c'était nécessaire et là où ce n'était pas nécessaire. Par exemple, au lieu d'une liste - et . Après tout, la sémantique - il s'agit de comprendre la composition de votre page et le but de chaque bloc (la majorité l'a géré ici), ainsi que l'utilisation de pré- et/ou post-processeurs (quelques-uns l'ont réussi ici, bien que cela était également dans les points - le plus souvent ils utilisaient moins et scss) .
Curseur de travail. Dans le devoir, nous avons écrit que JS ne peut pas être utilisé. Ici, la capacité à résoudre des problèmes a été testée - un curseur pourrait être créé à l'aide d'un groupe Et . Toute la magie se produit au niveau du sélecteur #button-N:checked ~ .slider-inner .slider-slides. Lorsque nous cliquons sur l’une des cases à cocher d’entrée, elle passe à l’état coché. Nous pouvons en profiter et attribuer la traduction dont nous avons besoin au conteneur avec les diapositives : transform:translate(-33%). Vous pouvez voir l'implémentation du slider .
Listes déroulantes. Ici aussi, tout se résumait à et un sélecteur similaire : .accordion-item input:checked ~ .accordion-item__content. Vous pouvez voir la mise en œuvre .
Disponibilité des états :hover, :active et :focu*. Un point très important. Le confort lors de l'interaction avec l'interface en dépendait. 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 rien ne se passe visuellement (même si la demande a été envoyée), c'est mauvais, car je cliquerai alors encore et encore dessus. De ce fait, dix demandes seront envoyées et je serai rappelé dix fois. Il ne faut pas oublier que les appareils mobiles n'ont pas de souris, ce qui signifie qu'il ne doit pas y avoir de survol. Et encore un point qui n'a pas affecté ceux qui ont répondu au point sur la sémantique. Si votre champ n'est pas un élément interactif, alors lorsque vous le survolerez, le curseur restera standard. Cela semble très désordonné, même si vous avez écrit une réaction au survol. Ne sous-estimez pas le curseur : le pointeur.
Animations. Il est important que toutes les réactions se produisant avec les éléments se déroulent sans heurts. Rien dans la vie n'est instantané, donc avoir des transitions en survol et actives suffisait à rendre l'interface plus agréable. Eh bien, ceux qui ont animé le slider et les listes sont généralement géniaux.
Utiliser la dernière technologie. De nombreuses personnes ont utilisé flex, mais personne n'a terminé la tâche en utilisant la grille. Le point était compté si flex était utilisé correctement. Si quelque part la mise en page s'est détachée à cause de ces mêmes flexions, hélas, vous n'avez reçu aucun point supplémentaire.
Validation du formulaire. Il suffisait d'ajouter l'attribut requis à chaque entrée du formulaire. Nous avons ajouté des points à ceux qui ont validé le champ email comme email.
Styliser le bouton de téléchargement de fichiers. Nous nous attendions à voir une combinaison comme : et sélectionnez le fichier . Ensuite, nous devions masquer l'entrée et styliser l'étiquette. Il existe une autre manière courante : créer une entrée transparente et la placer au-dessus du bouton. Mais tous les navigateurs n'autorisent pas le style , et une telle solution ne peut pas être qualifiée de entièrement multi-navigateurs. 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 ont eu de la chance), ainsi que dans Safari sur iPhone et Chrome sur Android.
Au contraire, nous déduisions des points si quelqu'un utilisait JS ou Bootstrap : les deux iraient à l'encontre du but de l'ensemble de la tâche. De plus, les participants avec Bootstrap ont non seulement reçu un moins, mais ont également perdu de nombreux points pour la sémantique et les éléments implémentés.
Ceux qui hébergeaient leur site quelque part sur Internet n'ont reçu aucun avantage particulier - mais les évaluateurs étaient très heureux de ne pas avoir à télécharger de référentiels et à les exécuter localement sur leur ordinateur. Cela a donc servi de plus pour le karma.
La première tâche était très utile principalement pour l'étudiant. Ceux que nous n'avons pas acceptés ont maintenant un CV préparé - vous pouvez le joindre fièrement à toutes les réponses ou le publier sur vos pages gh.
Tâche 2 : Itinéraire de transport
L'auteur de la tâche est le chef du groupe des interfaces de recherche Denis Balyko.
Condition
Avez-vous une carte des étoiles ? Il indique le nom de chaque étoile, ainsi que la distance qui la sépare des autres étoiles en 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 (trafic à sens unique dans l'espace), ainsi que les noms de les points de départ et d'arrivée du chemin - respectivement début et fin. La fonction doit renvoyer la distance la plus courte entre l'étoile de départ et l'étoile d'arrivée ainsi que le chemin à suivre.
Signature de fonction :
const solution = function(graph, start, finish) { // Ваше решение }Exemples de données 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 squelette de la solution se trouve dans le dossier src/, placez votre solution dans solution.js.
La vérification de la deuxième tâche était 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 en JS sont bravo. Cependant, lors de la vérification du devoir, nous sommes tombés sur de nombreux documents comportant les mêmes erreurs. Nous avons recherché des fragments de code sur Internet et trouvé un article à partir duquel les participants ont copié l'algorithme. C'est drôle que beaucoup de gens aient copié le code de l'article avec les commentaires de l'auteur. De telles œuvres ont reçu une note faible. Nous n'interdisons l'utilisation d'aucune source, mais nous voulons qu'une personne approfondisse ce qu'elle écrit.
critères
Les principaux points ont été attribués aux tests. Parfois, il était clair que les gars jouaient avec le référentiel, renommaient les dossiers, et les tests échouaient simplement parce qu'ils ne parvenaient pas à trouver les fichiers nécessaires. Cette année, nous avons essayé d'aider ces gars-là et avons tout remis à leur place. Mais l’année prochaine, nous prévoyons de passer à un système de concours, et cela ne nous sera plus pardonné.
Il y avait aussi des critères « humains », manuels. Par exemple, la présence d'un seul style de code. Personne n'a déduit de points pour avoir utilisé 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 que vous connaissez et placez des points-virgules au hasard.
La clarté et la lisibilité de la solution ont été prises en compte séparément. Dans toutes les conférences du monde, on dit que 80 % du travail d’un programmeur consiste à lire le code d’autrui. Même les écoliers subissent des révisions de code - de la part de leurs conservateurs et les uns des autres. Ce critère avait donc un poids important. Il y a eu des travaux dans lesquels il n'y avait pas de variables de plus d'un caractère - s'il vous plaît, ne faites pas ça. Les commentaires des participants ont été très encourageants, à l'exception de ceux qui étaient identiques à ceux de Stella Chang.
Le dernier critère est la présence d'autotests. Seules quelques personnes les ont ajoutés, mais pour tout le monde, cela est devenu un énorme plus dans leur karma.
La bonne décision:
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);
};
};Tâche 3 : Calendrier des événements
Il a été préparé par les développeurs d'interface Sergey Kazakov et Alexander Podskrebkin.
Condition
Écrivez un mini-calendrier pour afficher votre emploi du temps. Vous pouvez prendre n’importe quel horaire que vous souhaitez. Par exemple, le calendrier des conférences frontend en 2019.
Le calendrier devrait ressembler à une liste. Il n'y a aucune autre exigence de conception. Permettent de définir des rappels d'événements 3, 7 et 14 jours à l'avance. Après le premier téléchargement depuis Internet, le calendrier devrait s'ouvrir et fonctionner hors ligne.
Ressources utiles
Calendrier de la conférence frontend :
Travailleurs des services :
API de notifications :
La troisième tâche était la plus intéressante à tester, car il y avait tellement de solutions possibles, chacune avec la sienne. Nous avons vérifié comment le candidat gère les technologies inconnues - s'il sait rechercher, s'il teste ses solutions.
critères
Calendrier plié. Oui, il fallait encore l'aménager. Il y avait aussi ceux qui prenaient la condition trop littéralement et n’inséraient pas une seule ligne de code CSS. Cela n’avait pas l’air très attrayant, mais si tout fonctionnait, les points ne diminuaient pas.
Obtenir une liste d'événements à partir d'une source. Il ne s'agit pas d'une tâche de mise en page, donc la liste des événements qui y sont inclus n'a pas été prise en compte. Vous pouvez toujours annuler une conférence, la reprogrammer ou en ajouter une nouvelle. Il était donc nécessaire de recevoir des données de l'extérieur et de restituer la mise en page en fonction du JSON reçu. Il était important d'obtenir les données de quelque manière que ce soit (en utilisant la méthode fetch ou en utilisant XMLHttpRequest). Si une personne ajoutait un polyfill à récupérer et marquait son choix dans le fichier readme, cela était considéré comme un plus.
Enregistrement des travailleurs de service sans erreurs et travaillez hors ligne après le premier téléchargement. travailleur de service avec mise en cache planifiée au premier démarrage. Des détails sur les techniciens de service, leurs capacités et les méthodes de travail avec eux (stratégies pour travailler avec les caches, travailler hors ligne) peuvent être trouvés ici.
Possibilité de définir un rappelpour que cela fonctionne réellement après 3, 7, 14 jours. Il fallait comprendre l'API Notifications, était juste sur la tâche. Nous ne nous attendions pas à une implémentation spécifique pour vérifier s'il est temps de pousser. Toute option de travail était acceptée : stockage dans localStorage, IndexDB ou interrogation périodique par un service worker. Il était même possible de faire un serveur push (ici ), mais cela ne fonctionnerait pas hors ligne. Il était tout aussi important de recevoir un push après la fermeture de la page – et de l’ouvrir après un certain temps. Si le rappel mourait en même temps que la page était fermée, la solution n'était pas comptée. C'est cool quand les gars ont pensé aux évaluateurs et ont permis de donner un coup de pouce dès maintenant - pour ne pas attendre 3 jours.
Possibilité de placer une icône sur le bureau (PWA). Nous avons vérifié la présence du fichier avec les bonnes icônes. Certains gars ont créé ce fichier (ou l'ont laissé généré dans CreateReactApp) - mais n'ont pas ajouté les icônes correctes. Ensuite, lors de la tentative d'installation, une erreur du type « une icône différente est nécessaire » s'est produite.
Style de code et structure du projet. Comme dans la deuxième tâche, nous avons examiné un seul style de code (même s'il ne coïncidait pas avec le nôtre). Certains gars ont baisé sur les linters - c'est génial.
Erreurs de console. S'il y avait un indicateur directement dans la console indiquant que quelque chose n'allait pas et que le participant n'y prêtait pas attention, nous déduisions des points.
Les résultats de
Ce qui est drôle dans les décisions des participants :
- Un questionnaire contenait le texte suivant : « Un ami programmeur m'a aidé à créer une application React. Je l'ai bombardé de questions sur le comment et le pourquoi, et il me l'a dit. J’ai vraiment aimé ça, je veux en savoir plus. Nous soutenions cette candidature de tout notre cœur, mais malheureusement, l'ami du candidat n'a pas été d'une grande aide pour faire fonctionner la candidature.
- Un candidat a envoyé un lien vers GitHub, où se trouvait l'archive RAR - il est difficile de commenter cela. 🙂
- 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 les candidatures de 76 candidats et sélectionné 23 personnes. 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 nous ont surpris avec leur métier actuel : l'un d'eux est médecin légiste et l'autre est étudiant en médecine.
Le résultat a été une répartition intéressante des taux de réussite dans l’accomplissement des tâches. Les participants ont accompli la première tâche en moyenne à 60 %, la deuxième à 50 % et la troisième s'est avérée la plus difficile et a été accomplie en moyenne à 40 %.
À première vue, les tâches semblent complexes et chronophages. La raison n’est pas que nous voulions éliminer autant de candidats que possible. Au cours de leurs études, les étudiants sont confrontés à des tâches réelles : créer un chat, Yandex.Music pour les enfants ou Yandex.Weather pour les personnes dépendantes de la météo. Pour cela, vous avez besoin d'une base de départ.
Je me souviens avoir vu mon devoir d'entrée au SRI il y a deux ans et avoir pensé que je ne le résoudrais jamais. L'essentiel en ce moment est de s'asseoir, de lire attentivement les conditions et de commencer à le faire. Il s'avère que les conditions contiennent près de 80 % de la solution. Par exemple, dans la condition de la troisième tâche (la plus difficile), nous avons ajouté des liens vers les service Workers et l'API de notifications sur MDN. Les étudiants qui ont étudié le contenu des liens l'ont complété sans difficulté.
J'aimerais vraiment que cet article soit lu par les candidats qui envisagent d'entrer au SRI à l'avenir, qui n'ont pas pu entrer à l'école de Minsk ou qui commencent à effectuer toute autre tâche de test. Comme vous pouvez le constater, c’est tout à fait possible. Il vous suffit de croire en vous et d'écouter tous les conseils des auteurs.
Source: habr.com