Задания и тесты

Практические задания по HTML и CSS, JavaScript, Python, базам данных, DevOps и веб-разработке. Выполняйте их, проверяйте себя и собирайте портфолио.

1. HTML и CSS

2. JavaScript

3. Python

4. Базы данных (SQL)

5. DevOps

6. Веб-разработка

7. Как проверять себя

Самый честный способ самопроверки: вернитесь к своему коду через день и объясните вслух каждую строчку. Если что-то объяснить не можете — загляните в соответствующий урок.

8. Проекты для портфолио

Отдельные задания доказывают навык, а собранный проект — умение доводить работу до конца. Выберите 2–3 задачи из предыдущих разделов и превратите их в полноценные мини-проекты:

Как структурировать портфолио: главный проект на обложке, рядом два-три поддерживающих. Для каждого укажите строку о задаче и строку о стеке. Хороший ридми в репозитории читают как объяснение: как запустить, что внутри, куда смотреть.

Один доделанный проект ценнее пяти «наполовину». Критерий готовности простой: вы можете показать его незнакомому человеку и объяснить за минуту.

9. Ошибки и их разбор

Ошибаться нормально: даже опытные разработчики пишут баги. Разница в том, как ошибка разбирается. Сохраните привычку вести «дневник ошибок»: записывайте, что пошло не так и что помогло.

  1. воспроизведите ошибку и запишите её текст (читайте консоль/логи до конца);
  2. сузьте круг: спрячьте половину кода и проверьте, исчезла ли проблема;
  3. найдите опечатку в имени переменной или URL — это причина трети «магических» багов;
  4. переформулируйте ошибку своими словами и поищите по ключевой фразе;
  5. после исправления объясните причину вслух или текстом в дневнике.
«Починилось само» — так бывает редко. Если вы не поняли причину, ошибка вернётся. Вернитесь к шагу 2, даже если код уже работает.
«Висящие» ошибки записывайте в todo-файл рядом со своей задачей: через неделю описанная проблема решается за десять минут, а не за день разбора.
Использование искусственного интеллекта допустимо, но сначала объясните проблему себе: формулировка от руки часто сразу обнажает ответ.

10. Как получать обратную связь

Ревью кода — быстрый путь роста, но просить его нужно правильно. Покажите работу тому, кто уже прошёл этот путь: коллеге, наставнику или сообществу.

Практические площадки: GitHub-ревью на своих репозиториях, телеграм-чаты по направлениям, хакатоны с разбором проектов. Не ждите «правильной» порции критики — задавайте наводящие вопросы, чтобы ревьюер рассказал, как бы он реализовал это сам.

Начните с малого: попросите ревью одной функции или файла. Полученные замечания применяйте сразу, а не «на следующий проект».
Хорошая обратная связь не всегда та, что вас хвалит. Благодарите за критику: именно она двигает качество вперёд.

11. Гонка на время: спринт-челленджи

Спринт — это задача, рассчитанная на 25–40 минут работы под таймер. Ограничение по времени дисциплинирует: вы учитесь быстро принимать решения, а не «вылизывать» каждую строчку. Главная ценность спринта — честная проверка автоматизации привычных действий.

# Пример спринта: сумма цифр в строке
def sum_digits(text: str):
    return sum(int(c) for c in text if c.isdigit())

Тренируйтесь на задачах разделов 1–6: пока укладываетесь в отведённое время, усложняйте условие — добавьте граничный случай, которого не было в постановке.

Спринты хороши как «разминка» перед серьёзной работой: 30 минут гонки разогревают мозг и снимают страх перед пустым файлом.
Сначала правильность, потом скорость: быстрая ошибка стоит дороже медленного решения.

12. Кросс-курсовые задания

Отдельные навыки — независимые «кирпичи», но карьера строится на стыках: верстальщик, понимающий бэкенд, ценнее верстальщика «в вакууме». Соединяйте два направления в одной задаче.

Кросс-курсовые задания сложнее обычных: разбивайте их на шаги и коммитьте каждый отдельно. Так проще находить ошибки, а сам процесс уже напоминает командную работу.

Заведите список «мостов» между курсами — какие пары технологий вы уже пробовали вместе. Это будущая карта портфолио.
Стыки направлений — сильнейший аргумент на собеседовании: удачная связка выделяет работу из сотни одинаковых решений.

13. Ревью кода: работа рецензентом

Проверять чужой код — отдельный навык, который прокачивает и ваш собственный. Начните с ревью работ сокурсников или собственных старых решений: взгляд со стороны находит то, что в гуще кода не видно.

  1. прочитайте код и сформулируйте, что автор хотел сделать, своими словами;
  2. ищите проблемы по порядку: читаемость, дублирование, ошибки на граничных случаях;
  3. пишите комментарии «здесь непонятно, почему…», а не «перепиши»;
  4. предлагайте хотя бы одно улучшение с объяснением, зачем оно.
# Плохо: «исправь»
# Лучше: «что должна вернуть функция при пустой строке?»

Правило рецензента: критиковать решение, а не человека. Конструктивное замечание всегда содержит вопрос или причину, а не оценку «у тебя плохо».

Не подсказывайте готовое решение сразу: наводящим вопросом дайте автору найти проблему самому. Обучающее ревью стоит больше готового исправления.
Идеально — ревью в паре: сеньор подскажет архитектуру, новичок укажет на непонятный код. Оба взгляда ценны.

14. Мини-проекты на 2–3 часа

Между одиночным заданием и большим портфолио-проектом есть «золотая середина»: компактный продукт с понятной целью и ограниченной областью. Здесь вы впервые работаете планировщиком: решаете, что войдёт в задачу, а что осознанно отсечёте.

ЭтапЧто делаем
Постановкаодной фразой фиксируем продукт и его пользователя
Сокращениеубираем всё, без чего продукт не «умрёт»
Сборкаработаем по шагам, коммитим каждый
Проверкапрогоняем чек-листы разделов 7 и 9

Примеры для «золотой середины»: страница с погодой по API, личный планировщик задач, скрипт резервного копирования, дашборд продаж из собственной таблицы. Главный критерий — продукт можно показать незнакомому человеку.

Ставьте таймер на 3 часа и не превышайте: ограничение времени тренирует фокус и умение сокращать объём прямо во время работы.
Два-три таких мини-проекта заменяют одно «большое» долгострой: труднее бросить, проще доработать после паузы.

15. Мини-квиз: быстрая самопроверка

Квиз — это 10–15 коротких вопросов по пройденному разделу: «что выведет код», «какой тег для заголовка», «где хранится состояние». Цель — не оценка, а выявление пробелов до того, как они станут дорогими.

Готовые варианты с проверкой и объяснениями — на странице Тесты HTML и CSS: 16 вопросов по разметке, селекторам, flexbox, grid, цвету и доступности.

Пример вопросов по разделу HTML:
1. <h1> заголовок страницы — сколько раз допустим?
2. <p> и <div>: в чём отличие по умолчанию?
3. Что делает <form action="">?

Правило интервального повторения: повторение материала через день, неделю и месяц закрепляет знания лучше, чем час заучивания подряд.

Ошиблись — не листайте дальше: перечитайте раздел урока, связанный с вопросом, и пройдите квиз ещё раз.
Квиз — только старт проверки. Код пишется не в тесте, а в задании: квиз показывает «знаю», задание — «могу».

16. Сдача задания через Git и pull request

В реальной работе код сдают в репозиторий через pull request (merge request): это история изменений, ревью и автоматические проверки. Приучайте себя к этому процессу на заданиях.

git init
git add .
git commit -m "Задание 4: калькулятор"
git push origin main
# Из UI GitHub: New pull request → Review
  1. репозиторий на каждый модуль, ветка — на каждое задание;
  2. заголовок PR = номер задания + краткое «что сделано»;
  3. в описании — как запускать и что проверять;
  4. ревьюер оставляет замечания — исправляете и перезаливаете.

Это формирует навыки, которые спросят на собеседовании: чистая история коммитов, понятные описания, умение принимать замечания.

Коммиты делайте маленькими: «добавил функцию», «исправил баг» — отдельно. История читается как документация.
Не заливайте «секретные» данные: ключи и пароли в коде — повод отказать в ревью и в собеседовании.
Git не страшен: десять заданий по этой схеме — и операции станут автоматическими.

17. Парное программирование по таймеру

Парное программирование — два человека вместе пишут одно решение: один «водитель» набирает код, второй «навигатор» смотрит шире — на структуру, крайние случаи, следующий шаг. Правило: роли меняются каждые 20–25 минут.

1. Включите таймер на 25 минут
2. Водитель пишет, навигатор направляет
3. По таймеру — поменяйтесь ролями
4. В конце — 5 минут разбора решений

Парная работа не заменяет сольную: сольные задания прокачивают самостоятельность, парные — коммуникацию. Чередуйте оба формата.

Начните с лёгкой задачи: первая сессия — о знакомстве с подходом, а не о рекордах скорости.
Не «залипайте» на правках мелких деталей в паре: заметили — запишите и двигайтесь. Ревью вернётся к ним позже.

18. Проектная неделя и мини-хакатон

Кульминация курса — компактный хакатон на 3–5 дней: маленькая команда (2–4 человека) собирает работающий прототип с нуля. Это генеральная репетиция реального проекта со всеми его этапами.

ДеньФокус
1идея, роли, план на скриншот/доску
2–4сборка по веткам, ежедневная короткая сверка
5финал: презентация прототипа и разбор решений

Правила успеха хакатона: ограниченный объём (работает хуже идеально, но прилично), одна интеграционная ветка, честные роли, в конце — демо неидеального продукта.

Презентация — половина оценки: коротко «проблема → решение → как запустить». Пару раз проверьте демо до показа.
Предвосхищайте «эффект отсутствия интернета»: на случай сбоя подготовьте бэкапы и локальные данные заранее в первый же день.
Проектная неделя — лучший срез «готовности к работе»: здесь видны и код, и планирование, и коммуникация разом.

Что дальше

Соберите решённые задания в один репозиторий — это готовое портфолио для первых стажировок и собеседований. Продолжайте по урокам: HTML, CSS, JavaScript, Python, SQL. Когда почувствуете уверенность — переходите к веб-разработке и Docker.

← Вернуться к курсам