I dag åbnede et nyt sæt af i Moskva. Fra den 7. september til den 25. oktober finder første fase af træningen sted. Studerende fra andre byer vil kunne deltage i det eksternt eller personligt - virksomheden betaler for rejse og ophold på et hostel. Den anden, som også er sidste etape, varer indtil 3. december, den kan kun gennemføres personligt.
Mit navn er Julia Seredich, vi skrev dette indlæg sammen med Sergey Kazakov. Vi er begge grænsefladeudviklere på Yandex-kontoret i Minsk og kandidater fra SRI fra tidligere år.
I anledning af åbningen af registreringen i Moskva offentliggør vi en analyse af de indledende opgaver for den tidligere Skole - her i Minsk.
Hvis vi sporer historien om ShRI-opgaver, testede vi fra år til år tre færdigheder, der er vigtige for en programmør:
- Layout. Enhver udvikler bør være i stand til at typesætte. Det sker ikke, at man har en onkel Seryozha, som sætter for hele holdet, og man skriver kun manuskripter. Derfor skal hver elev vise, hvordan han kan sætte.
- JavaScript. Hvis virksomheden var begrænset til layout, så ville vi ikke have School of Interface Development, men School of Layout Makers. En smukt designet grænseflade skal genoplives. Derfor er der altid en opgave for JS, men nogle gange er det også en opgave for algoritmer – vi elsker dem så højt.
- Problemløsning er måske den vigtigste færdighed hos en udvikler. I skabelsen af grænseflader ændres alt meget hurtigt. Det er ligesom Lewis Carroll: "Du skal løbe lige så hurtigt bare for at blive på det samme sted, og for at komme til et andet sted skal du løbe dobbelt så hurtigt." Hver dag står vi over for nye teknologier – du skal regne med dem og kunne forstå dem. Derfor foreslog vi i den tredje opgave at forstå teknologier, som en nybegynder udvikler normalt ikke er bekendt med.
I analysen af hver opgave fortæller vi dig ikke kun om den korrekte procedure, men også om almindelige fejl.
Opgave 1: Portefølje
Alexey Cherenkevich, designer af Yandex.Collections, der ved, hvordan man skriver, og hans kollega i tjenesten, grænsefladeudvikler Sergey Samsonov, arbejdede på den første opgave.
Tilstand
Opret et portfolio-websted: fortæl os om dig selv, dit arbejde og forventninger fra skolen. Siden skal så vidt muligt svare til det foreslåede layout (links til layouts: , , , ). Vi er kun interesserede i layout, så brug venligst ikke JavaScript.
Når vi tjekker, vil vi overveje:
- indrykningsstørrelser, farvekorrekthed, skrifttype, punktstørrelse;
- semantisk layout;
- tilstedeværelsen af forskellige tilstande af elementer: visning af knapper og links, når du holder markøren over markøren, fremhæver aktive inputfelter osv.;
- kompatibilitet på tværs af browsere (testet i de nyeste versioner af populære browsere).
Fordelen vil være:
- brug af moderne CSS-løsninger: flexbox, grid osv.;
- Adaptivt layout;
- brug af præ- og (eller) postprocessorer, samling, minifikation, optimering af outputkoden;
- HTML formular validering, stiliseret fil upload knap.
Opgaven er ret omfangsrig, så du kan springe over det, der ikke virker. Dette vil reducere scoren en smule, men du vil stadig være i stand til at demonstrere din viden. Når arbejdet er afsluttet, send os to links - til porteføljen og kildekoden på GitHub.
De layouts, der blev foreslået i opgaven, var ikke kun med skærme til mobile enheder, tablets og desktops, men også med en reel specifikation.
For at bringe så meget objektivitet som muligt ind i resultatet af testen af den første opgave, var der en masse kriterier for denne test.
kriterier
Designet hjemmeside. Det virker indlysende, men nogle fyre sprang nogle blokke helt over - enten ville de spare tid, eller også kunne de ikke klare dem. Layoutet kan betinget opdeles i fire hovedskærme: Hovedskærmen med en avatar, en blok med en forventningsliste fra SRI, en blok med en portefølje og en blok med kontaktoplysninger. De kunne gøres i sektioner eller blot ved hjælp af div, det vigtigste er, at alle fire blokke var tilgængelige.
Overholdelse layout. Designeren lavede en separat specifikation (inklusive farver, typografi, knaptilstande osv.) for at gøre det lettere for kandidater. Nederst var et hint om indrykningerne og funktionerne på den første skærm. De fyre, der tog højde for alle designerens ønsker, var meget tilfredse: for eksempel skulle den første skærm vise sig at være ikke mindre end højden af viewporten.
Adaptivt layout - det er når grænsefladen ikke bare er lagt ud, så alt ved tre opløsninger er pixel for pixel efter layoutet. I mellemtilstande bør layoutet heller ikke falde fra hinanden. Nogen glemte at begrænse den maksimale bredde af beholderen og trak alt til 1920 pixels, nogen rodede med baggrundene, men generelt klarede kandidaterne denne opgave godt.
Semantisk layout. "Hvor mange gange har de fortalt verden", at linket skal formateres som , knappen som . Heldigvis opfyldte de fleste af kandidaterne også dette krav. Ikke alle genkendte den lurende liste i forventninger fra SRI ved at lave den med div-tags, men det er ikke så slemt. Der var en kandidat, som indsatte alle de semantiske tags, som han kun kendte – hvor det var nødvendigt, og hvor det ikke var nødvendigt. For eksempel i stedet for en liste - og . Alligevel handler semantik om at forstå sammensætningen af din side og formålet med hver blok (her gjorde størstedelen det), samt om brugen af pre- og/eller post-processorer (de færreste gjorde det her, selvom det også var i point - oftest koblede de mindre og scss) .
Arbejdsskyder. I opgaven skrev vi, at JS ikke kan bruges. Her blev evnen til at løse problemer testet - skyderen kunne laves ved hjælp af et bundt og . Al magien sker på niveau med #button-N:checked ~ .slider-indre .slider-slides vælgeren. Når vi klikker på en af afkrydsningsfeltets indgange, går den ind i den afkrydsede tilstand. Vi kan drage fordel af dette og tildele den translate, vi har brug for, til diasbeholderen: transform: translate(-33%). Du kan se implementeringen af skyderen .
Drop-down lister. Her bunder det hele i og en lignende vælger: .accordion-item input:checked ~ .accordion-item__content. Du kan se implementeringen .
At have :hover, :active og :focu* tilstande. En meget vigtig pointe. Komfort afhang af det under interaktion med grænsefladen. Brugeren skal altid modtage feedback på deres handlinger. Dette punkt blev kontrolleret gennem hele interaktionen med spørgeskemaet. Hvis jeg klikkede på knappen "Ring til mig" og visuelt ikke skete noget (selvom anmodningen blev sendt) - det er dårligt, for så vil jeg klikke på det igen og igen. Som et resultat vil der blive sendt ti anmodninger, og jeg vil blive ringet tilbage ti gange. Vi skal ikke glemme, at mobile enheder ikke har en mus, hvilket betyder, at der ikke skal være svæv. Og en ting mere, der ikke påvirkede dem, der gennemførte emnet om semantik. Hvis din kontrol ikke er et interaktivt element, vil markøren forblive standard, når du holder markøren over den. Det ser meget rodet ud, selvom du har skrevet en reaktion på at svæve. Undervurder ikke cursor: pointer.
Animationer. Det er vigtigt, at alt, hvad der sker med reaktionens elementer, er glat. Intet i livet er øjeblikkeligt, så at have overgange på svævende og aktiv var nok til at gøre grænsefladen pænere. Nå, dem, der animerede skyderen og listerne, er generelt gode.
Bruger den nyeste teknologi. Mange har brugt flex, men alligevel har ingen gjort arbejdet med grid. Pointet blev talt, hvis flex blev brugt korrekt. Hvis layoutet et eller andet sted var spredt på grund af disse meget flex - desværre fik du ikke yderligere point.
Formularvalidering. Det var kun påkrævet at tilføje den påkrævede attribut til hver input af formularen. Vi tilføjede point til dem, der validerede e-mail-feltet som e-mail.
Udformning af filupload-knap. Vi forventede at se en masse af formen: og Vælg fil . Næste trin var at skjule input og style etiketten. Der er en anden almindelig måde - at lave et gennemsigtigt input og lægge det oven på knappen. Men ikke alle browsere tillader styling , og en sådan løsning kan ikke kaldes fuldt ud på tværs af browsere. Og det er semantisk mere korrekt at lave en etiket.
Crossbrowser-kompatibilitet. Vi tjekkede, at alt er i orden i de sidste to versioner af moderne browsere (uden IE - deltagerne var heldige), samt i Safari på iPhones og Chrome på Androids.
Vi trak tværtimod point, hvis nogen brugte JS eller Bootstrap: begge gjorde hele opgaven meningsløs. Desuden fik deltagere med Bootstrap ikke kun et minus, men mistede også mange point for semantik og implementerede elementer.
De, der taggede deres side et sted på internettet, fik ikke den store fordel - men anmelderne var meget glade, da de ikke skulle downloade arkiverne og køre dem lokalt på deres computer. Så det fungerede som et plus i karma.
Den første opgave var meget nyttig primært for eleven. Dem, som vi ikke accepterede, har nu et maskinskrevet CV - du kan stolt vedhæfte det til alle svarene eller lægge det på dine gh-sider.
Opgave 2: Transportvej
Forfatteren af opgaven er lederen af søgegrænsefladegruppen Denis Balyko.
Tilstand
Du har et kort over stjernehimlen. Den viser navnet på hver stjerne, samt afstanden fra den til andre stjerner i lyssekunder. Implementer løsningsfunktionen, som skal tage tre argumenter: et objekt, hvor nøglerne er navnene på stjernerne, og værdierne er afstandene til stjernerne (envejstrafik i rummet), samt navnene på stiens start- og slutpunkter - henholdsvis start og mål. Funktionen skal returnere den korteste afstand fra startstjernen til målstjernen og den vej, der skal følges.
Funktions signatur:
const solution = function(graph, start, finish) { // Ваше решение }Input eksempel:
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';Eksempel output:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }Bemærk: løsningsramme er i mappen src/, placer din løsning i solution.js.
Kontrol af den anden opgave var den mest automatiserede og objektive. De fleste af fyrene gættede på, at det var nødvendigt at implementere Dijkstras algoritme. Dem, der fandt beskrivelsen og implementerede algoritmen i JS, er fantastiske. Men da vi tjekkede opgaven, stødte vi på mange papirer med de samme fejl. Vi søgte på internettet efter kodestykker og fandt en artikel, hvorfra deltagerne kopierede algoritmen. Det er sjovt, at mange kopierede koden fra artiklen sammen med forfatterens kommentarer. Sådanne værker fik en lav score. Vi forbyder ikke brugen af nogen kilder, men vi vil have en person til at dykke ned i, hvad han skriver.
kriterier
Hovedpointene blev givet til prøver. Nogle gange så man, at fyrene overtog depotet ved at omdøbe mapperne, og testene faldt simpelthen fordi de ikke kunne finde de nødvendige filer. I år forsøgte vi at hjælpe disse fyre og sætte alt på plads igen for dem. Men næste år planlægger vi at skifte til konkurrencesystemet, og det bliver der ikke sagt farvel til.
Der var også "menneskelige", manuelle kriterier. For eksempel tilstedeværelsen af en enkelt kodestil. Ingen trak point for at bruge tabulatorer i stedet for mellemrum eller omvendt. En anden ting er, hvis du skifter enkelte anførselstegn med dobbelte efter en regel, du kender, og sætter semikolon tilfældigt.
Separat blev der taget højde for løsningens klarhed og læsbarhed. På alle konferencer i verden siger de, at 80% af en programmørs job består i at læse en andens kode. Selv skolebørn bliver kodeanmeldt af deres kuratorer og hinanden. Så dette kriterium havde betydelig vægt. Der var værker, hvor der ikke var variable længere end ét tegn - lad være med at gøre dette. Deltagernes kommentarer var meget glædelige - med undtagelse af dem, der var identiske med kommentarerne fra Stella Chang.
Det sidste kriterium er tilgængeligheden af autotest. Kun få personer tilføjede dem, men for alle blev det et stort plus i karma.
Korrekt løsning:
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);
};
};Opgave 3: Kalender over begivenheder
Det blev udarbejdet af grænsefladeudviklere Sergey Kazakov og Alexander Podskrebkin.
Tilstand
Skriv en mini-kalender for at vise tidsplanen. Du kan tage ethvert skema, du kan lide. For eksempel tidsplanen for frontend-konferencer i 2019.
Kalenderen skal ligne en liste. Der er ingen andre designkrav. Gør det muligt at indstille begivenhedspåmindelser 3, 7 og 14 dage i forvejen. Efter den første download fra internettet, skal kalenderen åbne og fungere offline.
Nyttige ressourcer
Tidsplan for front-end konferencer:
servicemedarbejdere:
Notifications API:
Den tredje opgave var den mest interessante at tjekke, for der var mange løsninger, alle har deres egne. Vi tjekkede, hvordan kandidaten håndterer ukendte teknologier – om han kan researche, om han tester sine løsninger.
kriterier
Kompileret kalender. Ja, det skulle stadig lægges ud. Der var dem, der tog tilstanden for bogstaveligt og ikke indsatte en eneste linje med CSS-kode. Det så ikke særlig personligt ud, men hvis alt fungerede, faldt pointene ikke.
Få en liste over begivenheder fra en kilde. Dette er ikke længere en layoutopgave, så listen over begivenheder, der er syet ind i den, blev ikke talt med. Du kan altid annullere konferencen, omplanlægge den, tilføje en ny. Så det var nødvendigt at modtage data udefra og gengive layoutet baseret på den modtagne JSON. Det var vigtigt at få dataene på nogen måde (ved hjælp af hentemetoden eller ved hjælp af XMLHttpRequest). Hvis en person tilføjede en polyfill til hentning og markerede sit valg i readme, blev dette talt som et plus.
Servicemedarbejder registrering uden fejl og arbejde offline efter den første download. servicearbejder med cachelagring af tidsplan ved første opstart. Detaljer om servicemedarbejdere, deres evner og hvordan man arbejder med dem (cachestrategier, offline arbejde) kan findes her.
Mulighed for at indstille en påmindelseså det virkelig virker på 3, 7, 14 dage. Det var nødvendigt at forstå Notifications API, var lige på opgaven. Vi forventede ikke nogen særlig implementering af at tjekke, om det er tid til at skubbe. Enhver arbejdsmulighed blev accepteret: lagring i localStorage, IndexDB eller periodisk polling af en servicearbejder. Det var endda muligt at lave en push-server (her ), men offline ville det ikke virke. Det var lige så vigtigt at få et skub efter siden blev lukket - og åbnet efter noget tid. Hvis rykkeren "døde" samtidig med, at siden blev lukket, blev afgørelsen ikke medregnet. Det er fedt, når gutterne tænkte på verifikatorer og gjorde det muligt at få et skub lige nu – for ikke at vente 3 dage.
Mulighed for at flytte ikonet til skrivebordet (P.W.A.). Vi tjekkede for eksistensen af filen med de rigtige ikoner. Nogle fyre lavede denne fil (eller efterlod den genereret i CreateReactApp) - men tilføjede ikke de rigtige ikoner. Derefter, når du forsøgte at installere, opstod der en fejl som "brug for et andet ikon".
Codestyle og projektstruktur. Som i den anden opgave så vi på en enkelt kodestil (selvom den ikke matchede vores). Nogle fyre skruede linters - det er fantastisk.
Fejl i konsollen. Hvis der var en indikator direkte i konsollen om, at noget var galt, og deltageren ikke var opmærksom på det, så tog vi point.
Resultaterne af
Sjovt i deltagernes beslutninger:
- Et spørgeskema indeholdt følgende tekst: “En programmørven hjalp mig med at bygge en react-applikation. Jeg bombarderede ham med spørgsmål om hvad, hvordan og hvorfor, fortalte han. Jeg kunne rigtig godt lide det, jeg vil gerne vide mere om det. Vi rod til denne undersøgelse af hele vores hjerte, men desværre hjalp kandidatens ven ham ikke meget med at lave en fungerende ansøgning.
- En kandidat sendte et link til GitHub, hvor RAR-arkivet var placeret - det er på en eller anden måde svært at kommentere på dette. 🙂
- En anden kandidat indrømmede ærligt i kommentaren på den første linje i filen solution.js, at han kopierede algoritmen.
Vi modtog spørgeskemaer fra 76 kandidater og udvalgte 23 af dem. Vi fik tilsendt spørgeskemaer ikke kun fra Minsk, men også fra Moskva, St. Petersborg og endda Tatarstan. Nogle fyre overraskede mig med deres nuværende erhverv: en af dem er retsmediciner, og den anden er medicinstuderende.
Det viste sig en interessant fordeling af opgavernes succes. Deltagerne klarede den første opgave med et gennemsnit på 60%, med den anden - med 50%, og den tredje viste sig at være den sværeste og fuldførte den med et gennemsnit på 40%.
Ved første øjekast ser opgaverne komplekse og tidskrævende ud. Årsagen er ikke, at vi ønsker at luge så mange kandidater ud som muligt. Under uddannelsen bliver eleverne konfronteret med rigtige opgaver - at lave en snak, Yandex.Music for børn eller Yandex.Weather for vejrafhængige mennesker. Dette kræver en startbase.
Jeg kan huske, at jeg så min SRI-introduktionsopgave for to år siden og tænkte, at jeg aldrig ville løse den. Det vigtigste i dette øjeblik er at sætte sig ned, læse betingelserne omhyggeligt og begynde at gøre. Det viser sig, at forholdene indeholder næsten 80 % af opløsningen. For eksempel, i tilstanden af den tredje opgave (den sværeste), tilføjede vi links til servicemedarbejdere og Notifications API på MDN. De studerende, der studerede indholdet af linkene, klarede sig godt.
Jeg ønsker virkelig, at denne artikel skal læses af kandidater, der planlægger at gå ind i SRI i fremtiden, som ikke kunne komme ind på Minsk-skolen, eller som begynder at tage en anden testopgave. Som du kan se, er det ret realistisk at gøre det. Du skal bare tro på dig selv og lytte til alle forfatternes opfordringer.
Kilde: www.habr.com