Vandaag is er een nieuwe inschrijving geopend in Moskou. De eerste fase van de training vindt plaats van 7 september tot 25 oktober. Studenten uit andere steden kunnen er op afstand of persoonlijk aan deelnemen - het bedrijf betaalt de reis en accommodatie in een hostel. De tweede, tevens laatste fase, duurt tot 3 december en kan alleen persoonlijk worden afgerond.
Mijn naam is Yulia Seredich, we hebben dit bericht samen met Sergei Kazakov geschreven. We zijn allebei interface-ontwikkelaars op het kantoor van Yandex in Minsk en afgestudeerden van SRI van voorgaande jaren.
Ter gelegenheid van de opening van de inschrijving in Moskou publiceren we een analyse van inleidende taken voor de vorige school - hier in Minsk.
Als je de geschiedenis van SRI-opdrachten nagaat, hebben we van jaar tot jaar drie belangrijke vaardigheden voor een programmeur getest:
- Indeling. Elke ontwikkelaar zou lay-out moeten kunnen doen. Het komt niet voor dat je oom Seryozha hebt die voor het hele team ontwerpt, en dat je alleen scripts schrijft. Daarom moet elke student laten zien hoe hij kan zetten.
- JavaScript. Als de kwestie zich zou beperken tot de lay-out, dan zouden we geen School voor Interfaceontwikkeling hebben, maar een School voor Lay-outontwerpers. De prachtig ontworpen interface moet nieuw leven worden ingeblazen. Daarom is er altijd een taak voor JS, maar soms is het ook een taak voor algoritmen - we houden er zoveel van.
- Probleemoplossing is misschien wel de belangrijkste vaardigheid van een ontwikkelaar. Als het gaat om het maken van interfaces, veranderen de zaken heel snel. Het is net als Lewis Carroll: "Je moet zo snel rennen als je kunt om op dezelfde plek te blijven, en om naar een andere plek te komen moet je twee keer zo snel rennen." Elke dag komen we nieuwe technologieën tegen - we moeten er rekening mee houden en ze kunnen begrijpen. Daarom stelden we in de derde taak voor om technologieën te begrijpen waar een beginnende ontwikkelaar meestal niet bekend mee is.
Bij de analyse van elke taak vertellen we u niet alleen over de juiste procedure, maar ook over veelgemaakte fouten.
Taak 1: Portefeuille
Aan de eerste taak werd gewerkt door Yandex.Collections-ontwerper Alexey Cherenkevich, die weet hoe hij de lay-out moet maken, en zijn servicecollega, interface-ontwikkelaar Sergey Samsonov.
Staat
Maak een portfoliowebsite: vertel ons over uzelf, uw werk en uw verwachtingen van de school. De site moet zoveel mogelijk overeenkomen met de voorgestelde indeling (links naar indelingen: , , , ). Wij zijn alleen geïnteresseerd in de lay-out, gebruik dus geen JavaScript.
Bij de controle houden wij rekening met:
- inkepingsgroottes, kleurcorrectheid, letterstijl, lettergrootte;
- semantische lay-out;
- de aanwezigheid van verschillende statussen van elementen: het weergeven van knoppen en links wanneer de cursor beweegt, het markeren van actieve invoervelden, enz.;
- compatibiliteit tussen browsers (getest in de nieuwste versies van populaire browsers).
Het voordeel zal zijn:
- gebruik van moderne CSS-oplossingen: flexbox, grid, etc.;
- Adaptieve lay-out;
- gebruik van pre- en (of) post-processors, assemblage, minificatie, optimalisatie van uitvoercode;
- HTML-formuliervalidatie, gestileerde knop voor het uploaden van bestanden.
De taak is behoorlijk omvangrijk, dus je kunt overslaan wat niet werkt. Hierdoor wordt uw score iets lager, maar u kunt nog steeds uw kennis aantonen. Als je klaar bent, stuur ons dan twee links: naar je portfolio en de broncode op GitHub.
De in de opdracht voorgestelde indelingen waren niet alleen met schermen voor mobiele apparaten, tablets en desktops, maar ook met echte specificaties.
Om zoveel mogelijk objectiviteit in het resultaat van de controle van de eerste taak te brengen, waren er voor deze controle veel criteria.
criteria
Ontworpen website. Dit lijkt voor de hand liggend, maar sommige jongens hebben een aantal blokken helemaal overgeslagen: ze wilden tijd besparen, of ze konden ze niet doen. De indeling is grofweg in vier hoofdschermen te verdelen: het hoofdscherm met een avatar, een blok met een lijst met verwachtingen vanuit SRI, een blok met een portfolio en een blok met contactgegevens. Ze konden in secties worden gemaakt of eenvoudigweg met behulp van div's, het belangrijkste was dat alle vier de blokken beschikbaar waren.
Overeenstemming van de lay-out met de lay-out. De ontwerper heeft een aparte specificatie gemaakt (o.a. kleuren, typografie, knopstatussen etc.) om het voor kandidaten makkelijker te maken. Onderaan stond een hint over de inkepingen en kenmerken van het eerste scherm. Ik was erg tevreden over de jongens die rekening hielden met alle wensen van de ontwerper: het eerste scherm had bijvoorbeeld minimaal de hoogte van de viewport moeten zijn.
Adaptieve lay-out - dit is wanneer de interface niet alleen zo is ingedeeld dat bij drie resoluties alles pixel-tot-pixel qua lay-out is. In tussenliggende toestanden mag de lay-out ook niet uit elkaar vallen. Sommigen vergaten de maximale breedte van de container te beperken en alles in te stellen op 1920 pixels, sommigen verknoeiden de achtergronden, maar over het algemeen konden de kandidaten deze taak goed aan.
Semantische lay-out. “Hoe vaak hebben ze de wereld verteld” dat de link moet worden ontworpen als , de knop – als . Gelukkig voldeden de meeste kandidaten ook aan deze eis. Niet iedereen herkende de verborgen lijst in de verwachtingen van de SRI, waarbij gebruik werd gemaakt van div-tags, maar zo erg is het niet. Er was een kandidaat die alle semantische tags invoegde die hij kende - waar het nodig was en waar het niet nodig was. In plaats van bijvoorbeeld een lijst - en . Semantiek gaat immers over het begrijpen van de samenstelling van uw pagina en het doel van elk blok (de meerderheid heeft het hier beheerd), evenals het gebruik van pre- en/of postprocessors (een paar hebben het hier beheerd, hoewel dit zat ook in de punten - meestal gebruikten ze minder en scss).
Werkende schuifregelaar. In de opdracht schreven we dat JS niet gebruikt kan worden. Hier werd het vermogen om problemen op te lossen getest - met behulp van een stel kon een schuifregelaar worden gemaakt en . Alle magie vindt plaats op het selectorniveau #button-N:checked ~ .slider-inner .slider-slides. Wanneer we op een van de invoerselectievakjes klikken, gaat deze naar de aangevinkte status. We kunnen hiervan profiteren en de vertaling die we nodig hebben toewijzen aan de container met de dia's: transformeren: vertalen(-33%). Je kunt de implementatie van de slider zien .
Vervolgkeuzelijsten. Hier kwam het ook allemaal op neer en een soortgelijke selector: .accordion-item input:checked ~ .accordion-item__content. Je ziet de uitvoering .
Beschikbaarheid van de statussen :hover, :active en :focu*. Een heel belangrijk punt. Comfort tijdens de interactie met de interface hing ervan af. De gebruiker moet altijd feedback krijgen op zijn acties. Dit item werd tijdens de interactie met de vragenlijst gecontroleerd. Als ik op de knop 'Bel mij' heb geklikt en er visueel niets gebeurt (ook al is het verzoek verzonden), is dit slecht, want dan klik ik er steeds opnieuw op. Hierdoor worden er tien verzoeken verzonden en word ik tien keer teruggebeld. We mogen niet vergeten dat mobiele apparaten geen muis hebben, wat betekent dat er geen sprake mag zijn van een hover. En nog een punt dat geen invloed had op degenen die het punt over de semantiek vervulden. Als uw besturing geen interactief element is, blijft de cursor standaard als u erover beweegt. Het ziet er erg slordig uit, zelfs als je een reactie hebt geschreven om te zweven. Onderschat cursor niet: aanwijzer.
Animaties. Het is belangrijk dat alle reacties die optreden met de elementen soepel verlopen. Niets in het leven is ogenblikkelijk, dus het hebben van overgangen op zweven en actief was voldoende om de interface leuker te maken. Welnu, degenen die de schuifregelaar en lijsten hebben geanimeerd, zijn over het algemeen geweldig.
Gebruikmakend van de nieuwste technologie. Veel mensen gebruikten flex, maar niemand voltooide de taak met behulp van grid. Het punt werd geteld als flex correct werd gebruikt. Als ergens de lay-out uit elkaar viel vanwege deze buigingen, kreeg je helaas geen extra punten.
Formuliervalidatie. Het enige dat nodig was, was het toevoegen van het vereiste attribuut aan elke invoer van het formulier. We hebben punten toegevoegd aan degenen die het e-mailveld als e-mail hebben gevalideerd.
Vormgeving van de knop voor het uploaden van bestanden. We verwachtten een combinatie te zien zoals: en Bestand selecteren . Vervolgens moesten we de invoer verbergen en het label opmaken. Er is nog een veelgebruikte manier: een transparante invoer maken en deze bovenop de knop plaatsen. Maar niet alle browsers staan styling toe , en een dergelijke oplossing kan niet volledig cross-browser worden genoemd. En het is semantisch correcter om een label te maken.
Compatibiliteit tussen browsers. We hebben gecontroleerd of alles in orde was in de twee nieuwste versies van moderne browsers (zonder IE - de deelnemers hadden geluk), evenals in Safari op iPhones en Chrome op Androids.
Integendeel, we trokken punten af als iemand JS of Bootstrap gebruikte: beide zouden het doel van de hele taak tenietdoen. Bovendien kregen deelnemers met Bootstrap niet alleen een minpuntje, maar verloren ze ook veel punten voor semantiek en geïmplementeerde elementen.
Degenen die hun site ergens op internet hosten, kregen geen bijzonder voordeel, maar de recensenten waren erg blij toen ze geen repository's hoefden te downloaden en deze lokaal op hun computer te draaien. Dit diende dus als een pluspunt voor karma.
De eerste taak was vooral voor de leerling erg nuttig. Degenen die we niet hebben geaccepteerd, hebben nu een voorbereid CV - u kunt het met trots aan alle reacties toevoegen of op uw gh-pagina's plaatsen.
Taak 2: Transportroute
De auteur van de taak is het hoofd van de zoekinterfacegroep Denis Balyko.
Staat
Heb je een sterrenkaart? Het toont de naam van elke ster, evenals de afstand ervan tot andere sterren in lichtseconden. Implementeer de oplossingsfunctie, die drie argumenten moet aannemen: een object waarin de sleutels de namen van de sterren zijn, en de waarden de afstanden tot de sterren zijn (eenrichtingsverkeer in de ruimte), evenals de namen van de begin- en eindpunten van het pad - respectievelijk start en finish. De functie moet de kortste afstand van de startster tot de finishster en het te volgen pad retourneren.
Functie handtekening:
const solution = function(graph, start, finish) { // Ваше решение }Voorbeeld invoergegevens:
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';Voorbeelduitvoer:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }Opmerking: het oplossingsskelet bevindt zich in de map src/. Plaats uw oplossing in Solution.js.
De verificatie van de tweede taak was het meest geautomatiseerd en objectief. De meeste jongens vermoedden dat het nodig was om het algoritme van Dijkstra te implementeren. Degenen die de beschrijving ervan hebben gevonden en het algoritme in JS hebben geïmplementeerd, hebben het goed gedaan. Bij het controleren van de opdracht kwamen we echter veel papieren tegen met dezelfde fouten. We zochten op internet naar codefragmenten en vonden een artikel waaruit deelnemers het algoritme kopieerden. Het is grappig dat veel mensen de code uit het artikel hebben gekopieerd, samen met de opmerkingen van de auteur. Dergelijke werken kregen een lage score. We verbieden het gebruik van bronnen niet, maar we willen dat iemand zich verdiept in wat hij schrijft.
criteria
Voor tests werden hoofdpunten toegekend. Soms was het duidelijk dat de jongens met de repository aan het rommelen waren, de namen van mappen veranderden, en dat tests mislukten simpelweg omdat ze de benodigde bestanden niet konden vinden. Dit jaar hebben we geprobeerd zulke jongens te helpen en alles voor hen op zijn plaats te zetten. Maar volgend jaar zijn we van plan om over te stappen op een wedstrijdsysteem, en dit zal niet langer vergeven worden.
Er waren ook ‘menselijke’, handmatige criteria. Bijvoorbeeld de aanwezigheid van één enkele codestijl. Niemand heeft punten afgetrokken voor het gebruik van tabs in plaats van spaties of andersom. Het is een andere zaak als u enkele aanhalingstekens afwisselt met dubbele aanhalingstekens volgens een bekende regel, en puntkomma's willekeurig plaatst.
Er werd afzonderlijk rekening gehouden met de duidelijkheid en leesbaarheid van de oplossing. Op alle conferenties ter wereld zeggen ze dat 80% van het werk van een programmeur bestaat uit het lezen van de code van anderen. Zelfs schoolkinderen ondergaan codereviews – van hun curatoren en van elkaar. Dit criterium had dus een aanzienlijk gewicht. Er zijn werken geweest waarin er geen variabelen waren die langer waren dan één teken - doe dat alsjeblieft niet. De commentaren van de deelnemers waren zeer bemoedigend - met uitzondering van de commentaren die identiek waren aan de commentaren van Stella Chang.
Het laatste criterium is de aanwezigheid van autotests. Slechts een paar mensen voegden ze toe, maar voor iedereen werd het een groot pluspunt in hun karma.
De juiste beslissing:
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);
};
};Taak 3: Evenementenkalender
Het is opgesteld door interface-ontwikkelaars Sergey Kazakov en Alexander Podskrebkin.
Staat
Schrijf een mini-kalender om uw planning weer te geven. Je kunt elk schema nemen dat je wilt. Bijvoorbeeld het schema van frontend-conferenties in 2019.
De kalender moet er uitzien als een lijst. Er zijn geen andere ontwerpvereisten. Maak het mogelijk om gebeurtenisherinneringen 3, 7 en 14 dagen van tevoren in te stellen. Na de eerste download van internet zou de agenda moeten openen en offline moeten functioneren.
Handige hulpmiddelen
Frontend conferentieschema:
Servicemedewerkers:
Meldingen-API:
De derde taak was het interessantst om te testen, omdat er zoveel mogelijke oplossingen waren, elk met hun eigen oplossingen. We controleerden hoe de kandidaat omgaat met onbekende technologieën: of hij weet hoe hij moet onderzoeken, of hij zijn oplossingen test.
criteria
Gevouwen kalender. Ja, het moest nog aangelegd worden. Er waren ook mensen die de voorwaarde te letterlijk namen en geen enkele regel CSS-code invoegden. Het zag er niet erg aantrekkelijk uit, maar als alles werkte, daalden de punten niet.
Een lijst met gebeurtenissen ophalen van een bron. Dit is geen lay-outtaak, dus de lijst met gebeurtenissen die daarin zijn opgenomen, is niet meegeteld. U kunt een conferentie altijd annuleren, opnieuw plannen of een nieuwe toevoegen. Het was dus nodig om data van buitenaf te ontvangen en de lay-out weer te geven op basis van de ontvangen JSON. Het was belangrijk om de gegevens op welke manier dan ook te verkrijgen (met behulp van de fetch-methode of met behulp van XMLHttpRequest). Als een persoon een polyfill voor ophalen toevoegde en zijn keuze in het leesmij-bestand markeerde, werd dit als een pluspunt geteld.
Registratie van servicemedewerkers zonder fouten en werk offline na de eerste download. servicemedewerker met schemacaching bij de eerste keer opstarten. Details over servicemedewerkers, hun mogelijkheden en manieren om met hen samen te werken (strategieën voor het werken met caches, offline werken) vindt u hier.
Mogelijkheid om een herinnering in te stellenzodat het na 3, 7, 14 dagen ook daadwerkelijk werkt. Het was noodzakelijk om de Notificaties-API te begrijpen, had gelijk zijn taak. We hadden geen specifieke implementatie verwacht die zou controleren of het tijd is om te pushen. Elke werkoptie werd geaccepteerd: opslag in localStorage, IndexDB of periodieke polling door een servicemedewerker. Het was zelfs mogelijk om een push-server te maken (hier ), maar het zou niet offline werken. Het was net zo belangrijk om een push te ontvangen nadat de pagina werd gesloten - en na enige tijd werd geopend. Als de herinnering stierf op hetzelfde moment dat de pagina werd gesloten, werd de oplossing niet meegeteld. Het is cool toen de jongens aan de recensenten dachten en het mogelijk maakten om nu een duwtje in de rug te krijgen - om niet 3 dagen te wachten.
Mogelijkheid om een pictogram op het bureaublad te plaatsen (PWA). We hebben de aanwezigheid van het bestand gecontroleerd met de juiste iconen. Sommige jongens hebben dit bestand gemaakt (of het in CreateReactApp laten genereren) - maar hebben niet de juiste pictogrammen toegevoegd. Toen ik vervolgens probeerde te installeren, trad er een fout op zoals "er is een ander pictogram nodig".
Codestyle en projectstructuur. Net als bij de tweede taak keken we naar een enkele codestijl (zelfs als deze niet samenviel met de onze). Sommige jongens hebben linters verpest, dat is geweldig.
Consolefouten. Als er in de console een indicator was dat er iets mis was, en de deelnemer lette er niet op, dan hebben we punten afgetrokken.
Resultaten van
Wat grappig is aan de beslissingen van de deelnemers:
- Eén vragenlijst bevatte de volgende tekst: “Een vriend van een programmeur heeft mij geholpen een React-applicatie samen te stellen. Ik bestookte hem met vragen over het hoe en waarom, en hij vertelde het mij. Ik vond het erg leuk, ik wil er meer over weten.” We steunden deze sollicitatie met heel ons hart, maar helaas was de vriend van de kandidaat niet erg behulpzaam bij het laten werken van de sollicitatie.
- Eén kandidaat stuurde een link naar GitHub, waar het RAR-archief zich bevond - het is moeilijk om hier commentaar op te geven. 🙂
- Een andere kandidaat gaf in de opmerking op de eerste regel van het bestand solution.js eerlijk toe dat hij het algoritme had gekopieerd.
We ontvingen sollicitaties van 76 kandidaten en selecteerden 23 mensen. We kregen niet alleen vragenlijsten uit Minsk, maar ook uit Moskou, Sint-Petersburg en zelfs Tatarstan. Sommige jongens verrasten ons met hun huidige beroep: een van hen is een forensisch expert en de ander is een geneeskundestudent.
Het resultaat was een interessante verdeling van de succespercentages bij het voltooien van taken. De deelnemers voltooiden de eerste taak met gemiddeld 60%, de tweede met 50% en de derde bleek de moeilijkste en werd met gemiddeld 40% voltooid.
Op het eerste gezicht lijken de taken complex en tijdrovend. De reden is niet dat we zoveel mogelijk kandidaten willen uitsluiten. Tijdens hun studie worden studenten geconfronteerd met taken uit het echte leven: een praatje maken, Yandex.Music voor kinderen of Yandex.Weather voor weersafhankelijke mensen. Hiervoor heb je een startbasis nodig.
Ik herinner me dat ik mijn SRI-instaptaak twee jaar geleden zag en dacht dat ik die nooit zou oplossen. Het belangrijkste op dit moment is om te gaan zitten, de voorwaarden aandachtig te lezen en ermee aan de slag te gaan. Het blijkt dat de omstandigheden bijna 80% van de oplossing bevatten. In de voorwaarde van de derde taak (de moeilijkste) hebben we bijvoorbeeld links naar servicemedewerkers en Notifications API op MDN toegevoegd. Studenten die de inhoud van de links bestudeerden, voltooiden deze zonder problemen.
Ik zou heel graag willen dat dit artikel wordt gelezen door kandidaten die van plan zijn om in de toekomst naar SRI te gaan, die niet naar de Minsk School konden gaan, of die met een andere testtaak beginnen. Zoals u kunt zien, is het heel goed mogelijk om dit te doen. Je hoeft alleen maar in jezelf te geloven en naar alle tips van de auteurs te luisteren.
Bron: www.habr.com