Днес беше отворено ново записване в Москва. Първият етап на обучение ще се проведе от 7 септември до 25 октомври. Ученици от други градове ще могат да се включат в него дистанционно или присъствено – фирмата ще заплати разходите за пътуване и настаняване в общежитие. Вторият, също последен етап, ще продължи до 3 декември, може да се изпълни само присъствено.
Казвам се Юлия Середич, написахме тази публикация заедно със Сергей Казаков. И двамата сме разработчици на интерфейси в офиса на Yandex в Минск и сме завършили SRI от предишни години.
По повод откриването на регистрацията в Москва, публикуваме анализ на встъпителни задачи към предишното училище - тук, в Минск.
Ако проследите историята на заданията на SRI, от година на година тествахме три важни умения за програмист:
- Оформление. Всеки разработчик трябва да може да прави оформление. Не се случва да имате чичо Серьожа, който проектира за целия екип, а вие пишете само сценарии. Затова всеки ученик трябва да покаже как умее да пише.
- JavaScript. Ако въпросът беше ограничен до оформлението, тогава нямаше да имаме училище за разработка на интерфейси, а училище за дизайнери на оформление. Красиво проектираният интерфейс трябва да бъде съживен. Затова винаги има задача за JS, но понякога е и задача за алгоритми - толкова много ги обичаме.
- Решаването на проблеми е може би най-важното умение на разработчика. Когато става въпрос за създаване на интерфейси, нещата се променят много бързо. Това е като Луис Карол: „Трябва да бягаш възможно най-бързо, за да останеш на същото място, а за да стигнеш до друго място, трябва да бягаш два пъти по-бързо.“ Всеки ден се сблъскваме с нови технологии - трябва да ги вземем предвид и да можем да ги разберем. Затова в третата задача предложихме да разберем технологиите, с които начинаещият разработчик обикновено не е запознат.
При анализа на всяка задача ще ви разкажем не само за правилната процедура, но и за често срещаните грешки.
Задача 1: Портфолио
Първата задача беше работила върху дизайнера на Yandex.Collections Алексей Черенкевич, който знае как да прави оформление, и неговия колега по услугата, разработчик на интерфейс Сергей Самсонов.
Състояние
Създайте уебсайт за портфолио: разкажете ни за себе си, работата си и очакванията си от училището. Сайтът трябва да съответства максимално на предложеното оформление (линкове към оформления: , , , ). Интересуваме се само от оформлението, така че, моля, не използвайте JavaScript.
При проверка ще вземем предвид:
- размери на отстъпа, коректност на цвета, стил на шрифта, размер на шрифта;
- семантично оформление;
- наличието на различни състояния на елементи: показване на бутони и връзки при задържане на курсора, маркиране на активни полета за въвеждане и др.;
- съвместимост между различни браузъри (тествано в най-новите версии на популярни браузъри).
Предимството ще бъде:
- използване на съвременни CSS решения: flexbox, grid и др.;
- Адаптивно оформление;
- използване на пре- и (или) пост-процесори, асемблиране, минимизиране, оптимизиране на изходен код;
- Проверка на HTML форма, стилизиран бутон за качване на файл.
Задачата е доста обемна, така че можете да пропуснете това, което няма да работи. Това ще намали леко резултата ви, но все пак ще можете да демонстрирате знанията си. Когато сте готови, изпратете ни две връзки – към вашето портфолио и изходния код в GitHub.
Оформленията, предложени в заданието, бяха не само с екрани за мобилни устройства, таблети и настолни компютри, но и с реални спецификации.
За да се внесе възможно най-голяма обективност в резултата от проверката на първата задача, имаше много критерии за тази проверка.
критерии
Проектиран уебсайт. Това изглежда очевидно, но някои момчета пропуснаха някои блокове изцяло - или искаха да спестят време, или не можаха да ги направят. Оформлението може грубо да се раздели на четири основни екрана: основен екран с аватар, блок със списък с очаквания от SRI, блок с портфолио и блок с информация за контакт. Те могат да бъдат направени на секции или просто с помощта на div, основното е, че всичките четири блока са налични.
Съответствие на оформлението с оформлението. Дизайнерът направи отделна спецификация (включително цветове, типография, състояния на бутони и т.н.), за да улесни кандидатите. В долната част имаше намек за отстъпите и характеристиките на първия екран. Бях много доволен от момчетата, които взеха предвид всички желания на дизайнера: например, първият екран трябваше да бъде не по-малък от височината на прозореца за изглед.
Адаптивно оформление - това е, когато интерфейсът не е просто оформен, така че при три резолюции всичко да е пиксел до пиксел в оформлението. В междинни състояния оформлението също не трябва да се разпада. Някои забравиха да ограничат максималната ширина на контейнера и зададоха всичко на 1920 пиксела, някои объркаха фона, но като цяло кандидатите се справиха добре с тази задача.
Семантично оформление. „Колко пъти са казвали на света“, че връзката трябва да бъде проектирана като , бутонът – като . За щастие повечето кандидати изпълниха и това изискване. Не всички разпознаха скрития списък в очакванията на SRI, правейки го с div тагове, но не е толкова лошо. Имаше кандидат, който вкарваше всички семантични тагове, които познаваше – където трябваше и къде не трябваше. Например, вместо списък - и . В края на краищата, семантиката - става въпрос за разбиране на състава на вашата страница и целта на всеки блок (по-голямата част го управляват тук), както и използването на пред- и / или пост-процесори (няколцина го управляват тук, въпреки че това също беше в точките - най-често използваха по-малко и scss) .
Работещ плъзгач. В заданието написахме, че JS не може да се използва. Тук беше тествана способността за решаване на проблеми - може да се направи плъзгач с помощта на куп И . Цялата магия се случва на ниво селектор #button-N:checked ~ .slider-inner .slider-slides. Когато щракнем върху едно от квадратчетата за въвеждане, то преминава в отметнато състояние. Можем да се възползваме от това и да присвоим превода, от който се нуждаем, към контейнера със слайдовете: transform: translate(-33%). Можете да видите изпълнението на плъзгача .
Падащи списъци. Тук всичко се сведе до и подобен селектор: .accordion-item input:checked ~ .accordion-item__content. Можете да видите изпълнението .
Наличие на състояния :hover, :active и :focu*. Много важен момент. Комфортът по време на взаимодействие с интерфейса зависи от това. Потребителят винаги трябва да получава обратна връзка за своите действия. Този елемент беше проверяван по време на взаимодействието с въпросника. Ако щракна върху бутона „Обади ми се“ и визуално нищо не се случи (въпреки че заявката беше изпратена), това е лошо, защото тогава ще щракам върху него отново и отново. В резултат на това ще бъдат изпратени десет заявки и ще ми се обадят десет пъти. Не трябва да забравяме, че мобилните устройства нямат мишка, което означава, че не трябва да има задържане. И още една точка, която не засегна онези, които изпълниха точката за семантиката. Ако вашият контрол не е интерактивен елемент, тогава, когато задържите курсора върху него, курсорът ще остане стандартен. Изглежда много неподредено, дори и да сте написали реакция на hover. Не подценявайте cursor: pointer.
анимации. Важно е всички реакции, протичащи с елементите, да са гладки. Нищо в живота не е мигновено, така че наличието на преходи при задържане и активиране беше достатъчно, за да направи интерфейса по-приятен. Е, тези, които анимираха слайдера и списъците, като цяло са страхотни.
Използвайки най-новите технологии. Много хора използваха flex, но никой не изпълни задачата с помощта на grid. Точката беше зачетена, ако flex е използван правилно. Ако някъде оформлението се разпадна поради тези същите гъвкавости, уви, не сте получили допълнителни точки.
Валидиране на формуляр. Всичко, което се изискваше, беше да добавите необходимия атрибут към всеки вход на формуляра. Добавихме точки към онези, които потвърдиха имейл полето като имейл.
Оформяне на бутона за качване на файл. Очаквахме да видим комбинация като: и Изберете файл . След това трябваше да скрием входа и да стилизираме етикета. Има и друг често срещан начин - да направите прозрачен вход и да го поставите върху бутона. Но не всички браузъри позволяват стилизиране , и такова решение не може да се нарече напълно кросбраузърно. И семантично по-правилно е да се направи етикет.
Съвместимост между различни браузъри. Проверихме дали всичко е наред в двете най-нови версии на съвременните браузъри (без IE - участниците имаха късмет), както и в Safari на iPhone и Chrome на Android.
Напротив, приспаднахме точки, ако някой използва JS или Bootstrap: и двата ще провалят целта на цялата задача. Освен това участниците с Bootstrap не само получиха минус, но и загубиха много точки за семантика и внедрени елементи.
Тези, които хостваха сайта си някъде в Интернет, не получиха никакво особено предимство - но рецензентите бяха много щастливи, когато не им се наложи да изтеглят хранилища и да ги стартират локално на своя компютър. Така че това послужи като плюс за кармата.
Първата задача беше много полезна преди всичко за ученика. Тези, които не приехме, вече имат подготвена автобиография - можете с гордост да я прикачите към всички отговори или да я публикувате на вашите gh-страници.
Задача 2: Транспортен маршрут
Авторът на задачата е ръководителят на групата за интерфейси за търсене Денис Балико.
Състояние
Имате ли звездна карта? Показва името на всяка звезда, както и разстоянието от нея до други звезди в светлинни секунди. Приложете функцията за решение, която трябва да приема три аргумента: обект, в който ключовете са имената на звездите, а стойностите са разстоянията до звездите (еднопосочен трафик в космоса), както и имената на началната и крайната точка на пътя - съответно старт и финал. Функцията трябва да върне най-късото разстояние от началната звезда до крайната звезда и пътя, който да следвате.
Функционален подпис:
const solution = function(graph, start, finish) { // Ваше решение }Примерни входни данни:
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';Примерен резултат:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }Забележка: Скелетът на решението е в папката src/, поставете вашето решение в solution.js.
Проверката на втората задача беше най-автоматизирана и обективна. Повечето от момчетата предположиха, че е необходимо да се приложи алгоритъмът на Дейкстра. Тези, които са намерили описанието му и са внедрили алгоритъма в JS, са добри. При проверката на задачата обаче се натъкнахме на много документи със същите грешки. Потърсихме в интернет фрагменти от код и намерихме статия, от която участниците копираха алгоритъма. Странно е, че много хора копираха кода от статията заедно с коментарите на автора. Такива произведения получиха ниска оценка. Ние не забраняваме използването на никакви източници, но искаме човек да се задълбочи в това, което пише.
критерии
Основни точки бяха дадени за тестове. Понякога беше ясно, че момчетата се забъркват с хранилището, преименуват папки и тестовете ще се провалят просто защото не могат да намерят необходимите файлове. Тази година се опитахме да помогнем на такива момчета и им върнахме всичко на мястото. Но догодина планираме да преминем към състезателна система и това вече няма да ни бъде простено.
Имаше и „човешки“, ръчни критерии. Например наличието на един стил на код. Никой не отнема точки за използване на раздели вместо интервали или обратното. Друг е въпросът, ако редувате единични кавички с двойни кавички според едно известно ви правило и поставяте точки и запетая произволно.
Яснотата и четливостта на решението бяха взети под внимание отделно. На всички конференции по света казват, че 80% от работата на програмиста се състои в четене на код на други хора. Дори учениците се подлагат на прегледи на кода - от своите куратори и един от друг. Така че този критерий имаше значителна тежест. Имаше произведения, в които нямаше променливи, по-дълги от един знак - моля, не правете това. Коментарите на участниците бяха много окуражаващи - с изключение на тези, които бяха идентични с коментарите на Стела Чанг.
Последният критерий е наличието на автотестове. Само няколко души ги добавиха, но за всички това се превърна в огромен плюс в тяхната карма.
Правилно решение:
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);
};
};Задача 3: Календар на събитията
Подготвен е от разработчиците на интерфейса Сергей Казаков и Александър Подскребкин.
Състояние
Напишете мини-календар, за да покажете графика си. Можете да вземете всеки график, който желаете. Например графикът на фронтенд конференциите през 2019 г.
Календарът трябва да изглежда като списък. Няма други изисквания към дизайна. Дайте възможност за задаване на напомняния за събития 3, 7 и 14 дни предварително. След първото изтегляне от Интернет, календарът трябва да се отвори и да функционира офлайн.
Полезни ресурси
График на Frontend конференции:
Обслужващи работници:
API за известия:
Третата задача беше най-интересна за тестване, тъй като имаше толкова много възможни решения, всяко със своето. Проверихме как кандидатът се справя с непознати технологии – дали умее да проучва, дали тества решенията си.
критерии
Сгънат календар. Да, все още трябваше да се изложи. Имаше и такива, които приеха условието твърде буквално и не вмъкнаха нито един ред CSS код. Не изглеждаше много привлекателно, но ако всичко работи, точките не намаляват.
Получаване на списък със събития от източник. Това не е задача за оформление, така че списъкът със събития, включени в нея, не беше отчетен. Винаги можете да отмените конференция, да я пренасрочите или да добавите нова. Така че беше необходимо да се получат данни отвън и да се изобрази оформлението въз основа на получения JSON. Беше важно да се получат данните по какъвто и да е начин (използване на метода за извличане или използване на XMLHttpRequest). Ако човек добави полифил за извличане и маркира избора си в readme, това се отчита като плюс.
Регистрация на сервизен работник без грешки и работа офлайн след първото изтегляне. service worker с кеширане на график при първо зареждане. Подробности за сервизните работници, техните възможности и начини за работа с тях (стратегии за работа с кешове, работа офлайн) можете да намерите тук.
Възможност за задаване на напомнянетака че действително да работи след 3, 7, 14 дни. Беше необходимо да се разбере API за известия, беше точен на задачата. Не очаквахме никаква конкретна реализация, за да проверим дали е време да настояваме. Всяка работеща опция беше приета: съхранение в localStorage, IndexDB или периодично запитване от обслужващ работник. Дори беше възможно да се направи push сървър (тук ), но няма да работи офлайн. Също толкова важно беше да получиш тласък, след като страницата беше затворена - и отворена след известно време. Ако напомнянето умре по същото време, когато страницата е затворена, решението не се отчита. Страхотно е, когато момчетата помислиха за рецензентите и направиха възможно да получите тласък точно сега - за да не чакате 3 дни.
Възможност за поставяне на икона на работния плот (PWA). Проверихме наличието на файла с правилните икони. Някои момчета направиха този файл (или го оставиха генериран в CreateReactApp) - но не добавиха правилните икони. След това, при опит за инсталиране, възникна грешка като „необходима е различна икона“.
Кодов стил и структура на проекта. Както във втората задача, разгледахме един кодов стил (дори и да не съвпадаше с нашия). Някои момчета се завинтваха на линтери - това е страхотно.
Грешки в конзолата. Ако имаше индикатор точно в конзолата, че нещо не е наред и участникът не му обърна внимание, тогава отнемахме точки.
Резултати от
Какво е смешното в решенията на участниците:
- Един въпросник съдържаше следния текст: „Един приятел програмист ми помогна да съставя приложение React. Засипах го с въпроси как и защо и той ми каза. Наистина ми хареса, искам да знам повече за него. Подкрепяхме това приложение с цялото си сърце, но за съжаление приятелят на кандидата не беше много полезен, за да може приложението да работи.
- Един кандидат изпрати връзка към GitHub, където се намира RAR архивът - трудно е да се коментира това. 🙂
- Друг кандидат, в коментар на първия ред на файла solution.js, честно призна, че е копирал алгоритъма.
Получихме заявления от 76 кандидати и избрахме 23 души. Изпращаха ни въпросници не само от Минск, но и от Москва, Санкт Петербург и дори Татарстан. Някои от момчетата ни изненадаха с настоящите си професии: единият е съдебен експерт, а другият е студент по медицина.
Резултатът беше интересно разпределение на успеваемостта при изпълнение на задачите. Първата задача участниците са се справили средно с 60%, втората с 50%, а третата се оказва най-трудна и е изпълнена средно с 40%.
На пръв поглед задачите изглеждат сложни и отнемат много време. Причината не е, че искаме да отсеем възможно най-много кандидати. По време на обучението си студентите се сблъскват с реални задачи - създаване на чат, Yandex.Music за деца или Yandex.Weather за хора, зависими от времето. За целта ви трябва начална база.
Спомням си, че преди две години видях входната си задача за SRI и си помислих, че никога няма да я реша. Основното нещо в този момент е да седнете, внимателно да прочетете условията и да започнете да го правите. Оказва се, че условията съдържат почти 80% от разтвора. Например в условието на третата задача (най-трудната) добавихме връзки към обслужващи работници и API за известия в MDN. Студентите, които са изучавали съдържанието на връзките, са го попълнили без затруднения.
Наистина бих искал тази статия да бъде прочетена от кандидати, които планират да влязат в SRI в бъдеще, които не са успели да влязат в Минското училище или които започват да изпълняват друга тестова задача. Както можете да видите, това е напълно възможно. Просто трябва да вярвате в себе си и да слушате всички съвети от авторите.
Източник: www.habr.com