Тестові завдання для фронтенд-розробників: приклади з українських компаній

Фронтенд зараз є найбільш конкурентним напрямом на українському IT-ринку: за даними DOU, на одну позицію претендує в середньому 100 кандидатів. При цьому кількість вакансій тримається на рівні 200-250 на місяць (тоді як у 2021 році йшлося про тисячу).

Одна з можливостей проявити себе і продемонструвати експертизу роботодавцю — це виконання тестового. Тож редакція DOU поспілкувалася з українськими компаніями, які наймають Front-end спеціалістів, і отримала приклади реальних тестових завдань для різних рівнів. А також розпитала, на що роботодавці звертають увагу, оцінюючи виконані проєкти, і якими бувають причини відмов.

Приклади тестових завдань

ZONE3000

У нашому проєкті тестові завдання стосуються насамперед TypeScript. Оскільки ми розробляємо бібліотеки компонентів, важливо, щоб людина вміла експресивно описати API.

Кандидат має описати тип для пропсів компонента. Якщо variant = uncontrolled, то onChange — обов’язкова пропсу, а value — заборонена. І навпаки, якщо variant = controlled, то value — обов’язкова, а onChange — заборонена. Користувач компонента повинен розуміти, що якщо він передав variant = controlled, то він має передати value, а не onChange, і отримати відповідну помилку на це.

import * as React from "react";
// Describe props for this component
type Controlled = {
  variant: 'controlled';
  onChange: () => void;
};

type Uncontrolled = {
  variant: 'uncontrolled';
  value: string;
};

type Props = Controlled | Uncontrolled;
export const Textfield = (props: Props) => {
  if (props.variant === "controlled") {
    return <input type="text" onChange={props.onChange} />;
  }
  if (props.variant === "uncontrolled") {
    return <input type="text" value={props.value} />;
  }
};

У компонента React вже прописана невелика логіка. Ми звертаємо увагу на те, чи зможе людина скористатися підказками, які закладені в самому завданні. Більшість кандидатів з наскоку не можуть виконати це завдання. Залежно від того, які передаються властивості, типи змінюються. Зазвичай типи й компоненти простіші, але у нас таких ситуацій багато.

Ми дозволяємо кандидатам скористатися гуглом, але потрібно дати доступ до екрана. Дивлячись на те, як спеціаліст гуглить, ми розуміємо, як він мислить.

Більшість фронтенд-розробників уже працювали з TypeScript, і наша мета не в тому, щоб перевірити знання мови програмування, а побачити, як кандидат розв’язує задачі, з якими він, найімовірніше, не стикався раніше. Одного разу ми співбесідували спеціаліста з багатьма роками досвіду. Він не знав, як розв’язати задачу, і ми дозволили йому погуглити. Утім він дуже швидко здався. На цьому інтерв’ю закінчилося.

На нашому проєкті задачі такі, що потрібна наполегливість у пошуку рішень. Ми не шукаємо рокстарів і розуміємо, що мало хто працював з бібліотекою 40 годин на тиждень. Але нам важливо, щоб людина підсилювала команду, а не навпаки.

Genesis (HOLYWATER)

🟢Тестове завдання рівня Junior

Завдання — реалізувати застосунок «Календар подій», використовуючи бібліотеку React.

Новий користувач заходить у застосунок і бачить сторінку, яка складається з:

• кнопки відкриття форми та створення події (лівий верхній кут на референсі);
• фільтру за датою. За замовчанням обрано поточний місяць;
• сітки календаря обраного у фільтрі місяця, яка складається з днів (комірок).

Комірка містить:

• номер дня місяця (1, 2, 3);
• день тижня;
• список подій.

Комірка нинішнього дня має бути візуально виділена.

Референс сторінки:

Вимоги до фільтру за датою:

• Місяці мають перемикатися кнопками «<» і «>».
• Кнопка календаря відкриває date picker, де є можливість обрати рік і місяць.

Створення події:

• Клік на створення події.
• Відкривається незаповнена форма, яка складається з трьох полів:
  • Title (required)
  • Description
  • Date (required), Time (optional)
• Форму можливо закрити кліком у будь-яку зону поза формою або хрестиком.
• Кнопка Save зберігає та закриває форму. Кнопка має бути неактивною, доки обовʼязкові поля не будуть введені.

Референс форми створення події:

Редагування/видалення подій:

• Клік на подію відкриває заповнену форму в режимі редагування.
• Кнопка Save оновлює подію та закриває форму.

Умови:

• Не використовуйте готові календарі.
• Застосунок зберігає стан фільтрів після перезавантаження сторінки.
• Застосунок використовує localStorage як сховище даних.
• Застосунок може візуально відрізнятися від наведених референсів.
• Форма створення події має відкриватися не лише натисканням на кнопку, а також при кліку на комірку дня в календарі. Поле Date у такому випадку має бути заповнено автоматично.

🟡Тестове завдання рівня Middle

Застосунок — Quiz. Необхідно реалізувати, використовуючи бібліотеку React. Посилання на дизайн.

Summary

Користувач застосунку має змогу обрати зручну для себе мову на початку проходження вікторини, відповісти на запитання та ввести свій email. Після завершення вікторини, є можливість завантажити csv-файл з відповідями та пройти квіз ще раз.

Новий користувач застосунку заходить на сторінку вікторини, потрапляє на перше запитання та обирає мову.

Вікторина продовжується тією мовою, яку обрав юзер. Всі екрани мають бути локалізовані (quiz, loader, email, thank-you).

• Доступні локалізації: English, French, German, Spanish.
• Приклад локалізованого запитання (French):
  

Сторінка вікторини складається з:

• Поточного запитання (single-select / multiple-select / bubble etc.)
• При кліку на відповідь додається анімація, юзер переходить до наступного запитання.

• Header, який містить:
  
  • Progress bar
  • Номер поточного запитання
  • Кнопку для повернення на попереднє запитання

Після завершення вікторини, показується лоадер від 0 до 100%. Час завантаження лоадера — 5 секунд.

Юзер переходить до введення email.

• Кнопка «Next» має бути недоступна при некоректному/пустому email;
• Email має валідуватися. При некоректному введенні треба показувати текстову помилку та змінювати колір поля введення. Приклад:

Після успішного введення пошти, юзер потрапляє на екран Thank-you.

Кнопка «Retake quiz» дозволяє пройти вікторину ще раз. Користувача направляє на перше запитання, всі його дані та відповіді мають очиститись.

Кнопка «Download my answers» дозволяє завантажити csv файл. Файл містить інформацію про відповіді юзера та складається з 4 колонок:

1. order — номер запитання;
2. title — текст запитання;
3. type — тип запитання;
4. answer — відповідь юзера;

Приклад csv файлу:

Виконане завдання необхідно відправити посиланням на GitHub з відкритим доступом.

🔴Тестове завдання рівня Senior

Завдання 1

Застосунок — Quiz. Треба реалізувати його, використовуючи бібліотеку React.

Summary

Користувач застосунку має змогу обрати зручну для себе мову на початку проходження вікторини, відповісти на запитання та ввести свою електронну скриньку. Після завершення вікторини є можливість завантажити CSV-файл з відповідями та пройти квіз ще раз.

Новий користувач застосунку заходить на сторінку вікторини, потрапляє на перше запитання та обирає мову.

Вікторина продовжується тією мовою, яку обрав користувач. Всі екрани мають бути локалізовані (quiz, loader, email, thank-you).

• Доступні локалізації: English, French, German, Spanish.
• Приклад локалізованого запитання (French):

Сторінка вікторини складається із запитання (single-select / multiple-select / bubble etc.). При натисканні на відповідь додається анімація, користувач переходить до наступного запитання:

Header повинен містити:

• progress bar;
• номер запитання;
• кнопку для повернення на попереднє запитання.

Після завершення вікторини показується лоадер від 0 до 100%.

• Час завантаження лоадера — 8 секунд.
• Лоадер має симулювати завантаження даних із сервера, зупиняючись на певних відсотках (наприклад, 25%, 50%, 75%) на кілька мілісекунд, щоб створити відчуття реального процесу завантаження.
• Лоадер повинен показувати динамічний контент, такий як випадкові цитати, поради або факти, що змінюються під час завантаження. Це зробить процес очікування цікавішим для користувача.

Користувач переходить до введення імейлу.

• Кнопка «Next» має бути недоступна при некоректному/порожньому імейлі.
• Треба реалізувати функцію debounce на чистому JavaScript, не використовуючи сторонні бібліотеки.
• Функція має викликати перевірку імейлу після затримки (наприклад, 300 мс) з моменту останнього введення символу.
• Валідація імейлу: у разі некоректного введення скриньки рамка поля повинна змінювати колір на червоний, а під полем має з’являтися текстова помилка.

Приклад:

Після успішного введення скриньки користувач потрапляє на екран Thank-you.

Кнопка Retake quiz дає змогу пройти вікторину ще раз. Користувача скеровує на перше запитання, всі його дані та відповіді мають очиститись.

Кнопка Download my answers дає змогу завантажити CSV-файл. Файл містить інформацію про відповіді користувача та складається з чотирьох колонок:

order — номер запитання;

title — текст запитання;

type — тип запитання;

answer — відповідь користувача.

Завдання 2

Після завершення розробки основної функціональності застосунку треба проаналізувати продуктивність і покращити швидкість його завантаження і загальний UX.

• Використати інструменти аналізу продуктивності (наприклад, Google Lighthouse).
• Реалізувати розділення коду (code splitting) для зменшення розміру основного бандлу і прискорення завантаження сторінок.
• Оптимізувати роботу з даними, використовуючи memoization і хуки.
• Реалізувати відкладене завантаження (lazy loading) для компонентів, які не відразу потрібні під час старту застосунку.

Умови

Від кандидатів рівня Senior ми очікуємо пропозиції щодо можливих продуктових поліпшень застосунку та впровадження їх у тестове завдання.
Обовʼязковою є адаптивність інтерфейсу для різних типів пристроїв (mobile, tablet, desktop). Треба забезпечити кросбраузерну сумісність застосунку для основних браузерів (Chrome, Safari, Edge).

Важливо, щоб список із запитаннями був винесений на конфіг і легко кастомізувався. Щоб додати ще одне запитання до вікторини, треба лише оновити конфіг (order, title, question_type тощо), а не додавати ще один компонент із запитанням.

Буде плюсом, якщо застосунок типізований з використанням TypeScript.

Передбачити зміну місця зберігання даних, наприклад, на REST API (з найменшими змінами в коді).

«Додаткові бали» можна отримати за те, що квіз розгалужений (наступне запитання залежить від відповіді на попереднє). Приклад розгалуження — залежно від відповіді на запитання про вік (/quiz/3), кастомізуємо топіки на екрані /quiz/5.

На що ще звертають увагу компанії

Для Junior-спеціалістів тестові завдання допомагають перевірити базові знання і навички HTML, CSS і JavaScript, а критеріями оцінки є чистота коду, спосіб розв’язання задачі та дотримання вимог. Оскільки кандидатів на вакансії Junior багато, тестові завдання пришвидшують рекрутинговий процес, зазначає Ярослава Комаренко, Global Recruitment Partner в ALLSTARSIT. У Genesis від кандидатів рівня Junior очікують уважності та реалізації завдання відповідно до вимог.

Тестові завдання для Middle-рівня мають на меті перевірити знання фреймворків та бібліотек і здатність розв’язувати складні технічні задачі, зазначають в компанії ALLSTARSIT. Кандидати мають знати сучасні технології, використовувати патерни проєктування, а якість коду для них критичніша, ніж для Junior. У HOLYWATER від кандидатів рівня Middle очікують самостійності в ухваленні технічних рішень і гнучкого масштабованого підходу до архітектури.

Від Senior-спеціаліста очікують експертні знання в технологіях, з якими він працює, у системному дизайні, оптимізації продуктивності, поглиблених концепціях JavaScript, глибоке розуміння CI/CD-процесів. Тестові завдання для Senior можуть перевіряти, чи зможе кандидат працювати з особливостями домену проєкту. Велику роль в ухваленні рішення відіграє вміння аргументувати свою думку і обстоювати її.

«Для Senior-спеціалістів, — розповідає Ярослава Комаренко з ALLSTARSIT, — тестове завдання рідко є окремим етапом рекрутингового процесу. Частіше це частина технічного інтервʼю з членами проєктної команди».

Сергій Носко, Front-end Developer в ZONE3000, вважає, що кандидати більш лояльно ставляться до тестових, які потрібно зробити під час співбесіди, ніж до тих, які дають виконати до інтерв’ю.

У HOLYWATER під час наймання Senior-спеціалістів має значення, щоб на попередніх місцях роботи кандидат був візіонером змін і постійно вдосконалював свій продукт і навички.

Чому компанії відмовляють після тестового

Найчастішою причиною відмови за підсумками тестового є «недостатній рівень технічних навичок», зазначає Олексій Величко, Full Stack Developer у HOLYWATER. Втім, зауважує, що в компанії готові дати змогу доопрацювати завдання, якщо рішення кандидата не критично відрізнялось від очікувань.

Також компанія звертає увагу на важливість дотримання домовлених дедлайнів:

«Якщо виникають непередбачувані обставини, важливо, щоб кандидат попередив про можливу затримку або відмову виконувати завдання», — зазначає Talent Researcher з HOLYWATER Елеонора Бондаренко.

Водночас трапляються випадки, коли кандидати не завершили тестове, але пройшли на наступний етап.

«Ми можемо рекомендувати навіть людину, яка чогось не знала, але сподобалась особистими рисами. Навіть якщо спеціаліст не до кінця розв’язав задачу, але продемонстрував вміння шукати інформацію та рухався у правильному напрямку, це однозначно плюс», — зазначає Сергій Носко з ZONE3000.

Як ставитеся до тестових ви? Поділіться своїми прикладами в коментарях!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU