Цифровые профессии: Обучение
20 постов
20 постов
Всем привет!
На этой неделе мы объявили о начале работы над Open Source проектом Taigram, название которому, к слову, выбрали вы в опросе.
Для удобства отслеживания актуальных изменений по проекту рекомендуем заглядывать в тематическую рубрику у нас на сайте, где мы рассказываем о процессе разработки, объясняем наш выбор технологий, архитектуры и код.
Проектом занимаемся мы вдвоём: Иван и Виктор, а также с логотипом нам помог наш бессменный дизайнер Евгений. (Больше никто не захотел к нам присоединиться 😭)
Начнём мы, как водится, с самого начала...
Любой проект начинается с продумывания работ, функционала и предстоящих задач. Это можно делать как в Telegram-переписке, блокноте, заметках Obsidian, так и использовать более профессиональные инструменты - менеджеры проектов.
Мы давно искали удобный (и, что немаловажно - бесплатный!) инструмент ведения проектов, который можно развернуть локально. В итоге остановились на Taiga.io.
Taiga.io - это бесплатный Open Source Self-Hosted менеджер управления проектами. Это означает, что это свободно распространяемое программное обеспечение, которое можно установить на свой собственный сервер, не беспокоясь о зависимости от какого-то крупного игрока.
В тайге мы ведём наши проекты, включая процессы публикации статей на сайте.
Это оказалось действительно удобно, за исключением нескольких моментов и один из них - оповещения. Дело в том, что Тайга отправляет оповещения об изменении задачи только тем, кто назначен исполнителем и наблюдателем, и отправляет она их на Email, при условии, что у пользователя стоят соответствующие разрешения в его профиле. Согласитесь, это хоть и удобно (какие-никакие уведомления лучше, чем их полное отсутствие), но порой абсолютно не оперативно! Да и к тому же, вряд ли кто захочет "пачкать" свою почту.
Тогда появилась идея сделать Telegram-бота, который сможет отправлять уведомления в чат/тему чата. Мы приняли такое решение, в том числе из-за того, что Тайга предоставляет возможность подключить WebHook для отправки уведомлений и у отправляемых данных, достаточно простая структура и, в целом, этих данных достаточно - это важно. Это значит, что добавив на текущем этапе самый нужный, по нашему мнению, функционал - потом его можно дополнить. А если это можно дополнять и функционал, который мы добавим сейчас - самый нужный по нашему мнению, означает, что этого функционала может быть недостаточно для кого-то другого, под какие-то другие специфические задачи.
Если кому-то это нужно или кто-то посчитает, что знает чего сервису не хватает в настоящий момент - он сможет это дополнить. На наш взгляд это отличная идея и входящие данные для запуска работ над Open Source проектом.
Цель: создание сервиса, который будет отправлять уведомления об обновлении списка задач и других событий из менеджера управления задачами Taiga в Telegram
Функциональные требования:
Настройка уведомлений через Telegram-бота:
Добавление/удаление администраторов бота;
Выбор чата/канала;
Добавление/удаление/изменение проектов;
Отображение списка проектов;
Отображение информации по проекту:
Форматирование, отправляемых сообщений.
Интеграция с Taiga через вебхуки.
Стек технологий
Бэкенд: Python, FastAPI, Aiogram;
Работа с данными: Taiga Webhooks, MongoDB, Redis;
Инфраструктура: Dynaconf, Pydantic.
Мы созвонились в нашем уютном Discord-сервере (присоединяйтесь, там мы регулярно работаем, общаемся или играем!) и открыв Obsidian, начали рисовать примерный план желаемого функционала. Спойлер: уже сейчас, спустя неделю с начала часть функционала изменено до неузнаваемости, но об этом в другой раз.
Найти схему можно в нашем проекте: https://tasks.pressanybutton.ru/project/taiga-webhook-telegram-notifier/task/5
Схема казалась небольшой, мы делали и куда более объёмные и даже посчитали "да чё там делать? За пару вечеров справимся"...
Закончив схему появились две первые задачи:
Организовать доску в Тайге
Сделать репозиторий.
Доской занялся Виктор, а я пошёл делать репозиторий на GitHub.
Не смотря на то, что у нас (как у Команды проекта "Код на салфетке", так и у меня лично (Виктора)) был опыт в подготовке как проектной, так и технической документации, но делать что-то, что изначально будет в открытом доступе значит, что у проекта есть дополнительные ограничения и "ответственность".
Мы совершенно не боимся признаться что какие-то вещи у нас получаются пока что не так хорошо или какие-то процессы могут быть выстроены как-то не так, как их можно было бы выстроить и именно поэтому мы решили, что будем вести разработку полностью открыто и все задачи вести также - открыто.
Сперва нам было необходимо определиться с используемыми модулями в проектном менеджере для последующего масштабирования.
Почти сразу мы определили, что модуль "Канбана" нам не подходит, поскольку там невозможно создавать задачи в отрыве от пользовательских историй, следовательно создавать на каждую задачу пользовательскую историю "Дорожками" (не статусы) означает плодить сущности и терять контроль над "подзадачами".
Хочу повториться, что лично я не боюсь признавать свою неправоту и именно поэтому акцентирую внимание еще вот на чем: нам показалось странным, что мы не можем создавать "задачи" на канбане в отрыве от "пользовательских историй", потому что это лишает возможности оценить сложность задачи "в попугаях" (условная единица).
Вернемся к модулям, мы решили использовать:
Эпики: для стратегического планирования;
Скрам: для текущего управления спринтами;
Запросы: если у кого-то из команды или гостей проекта появится желание добавить какой-то функционал или сообщить о чем-то;
Вики: для создания первоначального хранилища базы знаний;
Как было сказано ранее, вначале у нас сложилось впечатление, что мы действительно можем управиться за пару вечеров в силу функциональных требований и сложности структуры, предъявляемой к проекту, но все осложнилось тем, что проект - Open Source и следовательно его нужно постараться сделать пригодным для последующего масштабирования и поддержки.
Поэтому составили первоначальный план, который включал следующие этапы:
Подготовительная часть:
анализ задачи;
оформление всех функциональных хотелок в виде тезисов;
прогнозирование объема работ;
определение структуры проекта;
подготовка схем структуры проекта;
подготовка схем пользовательского пути;
Базовый функционал (этап основной разработки MVP):
подготовка структуры проекта;
инициализация проекта и первичная настройка виртуального окружения, инфраструктуры;
настройка CI/CD;
создание базовых классов, необходимых для реализации бизнес-логики;
валидация данных;
создание необходимых методов, для работы с текстовыми файлами (для последующей локализации);
Локализация:
русский язык;
английский язык;
Релиз GitHub Pages:
подготовка и настройка репозитория;
настройка CI/CD;
подготовка и оформление документации;
составление инструкций;
Как показала практика: никакая задача не заслуживает, чтобы к ней относились без должного внимания и трепета, а иначе разработка и конечный продукт может включать в себя больше хаоса и меньше структуры.
При определении глобальных спринтов и пользовательских историй мной были допущены ошибки в планировании и декомпозиции задач, в следствие чего небольшие задачи, которые были взяты в разработку, выросли в полноценные, тесно связанные модули и даже пакеты. Ваня, в силу опыта, с поставленными задачами справлялся лучше - его комиты как правило включали изолированные задачи и выполнялись быстрее.
По моим наблюдениям, регулярное обновление информации по статусам задачи держит команду "в тонусе" и позволяет придерживаться "единого вектора" в разработке.
Откровениями "о взлетах и падениях" мы поделимся в последующих статьях, но считаем, что о публичном проекте, нужно говорить честно и открыто - этим объясняется существование этого подраздела.
Помимо функциональных требований, мы обсудили и технологический стек для проекта.
В качестве пакетного менеджера мы выбрали набирающий популярность uv. Как раз в новой версии PyCharm добавили его нативную поддержку. Честно, пока не заметил за ним каких-то преимуществ перед "надёжным как Швейцарские часы" Poetry, но вдруг он раскроется в будущем?
Для обработки обновлений Telegram и приёма оповещений из Тайги по WebHook был выбран микрофреймворк FastAPI. Полагаю, что он не нуждается в представлении: быстрый, надёжный и достаточно гибкий.
Сердцем Telegram-бота является aiogram. По нашему мнению - самый лучший фреймворк для написания ботов.
Поскольку в проекте не подразумевается большого количества данных для хранения, мы выбрали в качестве базы данных MongoDB с асинхронной библиотекой Motor.
Для хранения состояний и временных данных отлично подойдёт Redis. Это такой легковесный брокер сообщений / база данных.
Также, в проект был подключен pre-commit, позволяющий запускать линтеры перед коммитом. Он нужен для того, чтобы стиль кода всех разработчиков совпадал во всём проекте, ну и заодно он проверяет, что нет неиспользуемых импортов/переменных, некорректных вызовов и много, что ещё.
Создать репозиторий - буквально меньше минуты, но на пустом репозитории далеко не уедешь, да и показывать его кому-то стыдно. Поэтому для него необходимо было создать начальный проект в uv, а также ряд организационных файлов.
Проект в uv создаётся примерно также, как и в Poetry. Прописываем команду uv init taiga_wh_notifier. В результате создастся директория в которой будет основа проекта, инициализированный git и .venv. Удобно.
Перейдя в директорию сразу добавляем origin репозитория на гитхаб.
Далее нужно было создать основные файлы:
README.md - лицо всего репозитория. На данный момент оно практически пустое, мы определили основные разделы ридми файла, но пока не будет относительно рабочего функционала, заполнять ридми рано.
CONTRIBUTING.md - в этом файле описывает процесс по которому любой желающий сможет развернуть локальную версию проекта и вносить необходимые правки в код.
STYLEGUIDE.md - в этом файле описываются принципы и примеры стиля кода которому мы придерживаемся. Ничего сверхъестественного, но наличие этого файла поможет новым участникам проекта быть с нами "на одной волне".
Всё это мы писали вместе на основе нашего виденья проектов. В будущем содержимое файлов будет расширено и приобретёт полноценный вид.
В конце коммит и пуш. Первая задача закрыта, на очереди ещё сотня...
Проект создан, запушен, но не хватает одной маленькой детали - настройки репозитория на GitHub.
Что я имею ввиду? У нас есть главная ветка репозитория main и по умолчанию, каждый может в неё пушить, что является критической уязвимостью в целостности всего проекта. Да, можно откатывать коммиты и прочее, но всё это дополнительные и далеко не самые приятные действия.
Что нам нужно было сделать, дабы предотвратить хаос? Мы разработали правила работы с репозиторием!
Если над проектом работает больше одного человека - хаос неизбежен. Кто-то забудет сделать пулл актуального состояния, кто-то другой будет одновременно с третьим работать над одним файлом и вызовет конфликт веток. Что мы сделали для решения этих проблем?
Ветка main заблокирована от всех пушей, даже от имени создателя репозитория. Это решает проблему "случайного пуша в мейн", когда участник команды написал код, но забыл сменить ветку.
Участники работают каждый в своей ветке, при это ветка не постоянная, а создаётся исключительно под задачу, после чего удаляется. Это позволяет определить по названию ветки к какой задаче на доске она относится, а не выяснять по коммитам, над какой же задачей работал участник.
Для того, чтобы внести изменения в main-ветку, необходимо создать pull request. При этом, для того, чтобы сделать "мерж в мейн", необходимо одобрение минимум одного другого участника. Таким образом, в main-ветку не попадёт ничего случайно, только после код-ревью и одобрения.
Мы не сразу "притёрлись" с этой системой, так как каждый привык работать в одиночку. Однако, спустя время осознали её удобство, а когда разобрались, как всё это делать не выходя из PyCharm, стало вообще прекрасно.
Если вас заинтересовал проект и вы считаете, что могли бы принести пользу в разработке, а также, если после прочтения этой статьи или ознакомления с материалами проекта вы пришли к выводу, что вам точно известно чего не хватает этому продукту и вы знаете как его можно улучшить - мы приглашаем присоединиться к проекту и принять участие в разработке!
Для этого свяжитесь с нами
Это только самое начало, дальше начали создавать задачи и непосредственно писать код, о чём вы узнаете в следующей части.
Ссылки, касающиеся проекта:
Приветствую! Меня зовут Иван, я автор Telegram-канала и сайта «Код на салфетке».
Уверен, что большинству из вас знакомо явление «Тестовое Задание» — не на этапе приёма на работу, а гораздо раньше: при отправке отклика, ещё до собеседования с HR.
«Ёжики колются, но продолжают есть кактус» — именно так выглядит наше отношение к тестовым заданиям. Многие ругаются, плюются, но всё равно тратят часы (а то и дни) на их выполнение в надежде получить заветный «допуск»: к техническому собеседованию, а то и сразу к офферу.
Что не так с этой практикой? У меня есть чёткое мнение на этот счёт, и сегодня я готов его аргументировать.
Важно! Всё описанное в статье СУГУБО МОЁ ЛИЧНОЕ МНЕНИЕ!. Это не призыв к действию, а повод задуматься о происходящем на рынке труда. Вы можете не согласиться со мной — полностью или частично! И даже лучше, если после прочтения вы поделитесь своей точкой зрения в комментариях. Как гласит народная мудрость: «В споре рождается истина».
Прежде чем перейти к критике, попробуем взглянуть на ситуацию объективно — через призму интересов компании.
Что такое тестовое задание?
Это задача, которую кандидат должен выполнить в рамках жёстких сроков и требований потенциального работодателя". Условно их можно разделить на три типа:
Абстрактные задачи
Цель: проверить логику и креативность.
Особенности: задачи вырваны из контекста работы (например, «написать алгоритм сортировки пельменей»).
Сроки: 1 день.
Проблема: результат не имеет практической ценности для компании.
Мини-проекты под фреймворк
Цель: оценить владение конкретным инструментом (например, aiogram или requests).
Особенности: чёткий список требований («написать бота автоответчика»).
Сроки: 1–3 дня.
Проблема: опытный специалист справится за 2 часа, не ощутив никакого тестирования. Рутина.
Полноценные продукты
Цель: проверить навык создания проекта с нуля.
Особенности: подробное ТЗ с описанием архитектуры, сущностей и технологий.
Сроки: 5–7 дней.
Проблема: граница между тестовым заданием и бесплатной работой стирается.
После выполнения работа отправляется на оценку — иногда с код-ревью, иногда в чёрную дыру HR-системы.
Аргументы работодателя: зачем это нужно?
Компании объясняют тестовые задания рационально:
Фильтр «паразитов» Отсеивают тех, кто откликается «на авось»: если кандидат не готов потратить время на задание, он «недостаточно мотивирован».
Проверка навыков в деле Резюме и портфолио можно приукрасить, а тестовое покажет, как человек:
пишет код (чистый или спагетти).
соблюдает дедлайны.
взаимодействует с требованиями.
Иллюзия прозрачности Обещание обратной связи («вам подробно всё объяснят!») создаёт образ честной и открытой компании.
«Как отличить тестовое задание от проекта, который компания просто не хочет оплачивать?».
Тестовые задания НЕ ЭФФЕКТИВНЫ, а зачастую откровенно вредят. И вот почему:
Причина 1: Бесплатный труд под видом «отбора»
Компании всё чаще злоупотребляют ажиотажем на рынке труда. Вместо абстрактных задач соискателям подсовывают реальные рабочие кейсы. Результат? Ваш код, дизайн или аналитика уходят прямиком в продакшн — без договора, оплаты или даже благодарности.
Реальная история от middle-разработчика:
«Когда я был junior’ом, делал тестовые направо и налево. Через полгода мне написал сотрудник компании, для которой я «проходил отбор». Спросил: «Как у тебя в задании реализован модуль Х? Мы внедрили твоё решение, но теперь всё падает».
Оказалось, они просто скопировали мой код... но даже не потрудились сообщить, что я «не подошёл»».
Почему это порочная практика?
Соискатель тратит силы на задачу, которая уже решает бизнес-проблему компании.
Работодатель получает готовый продукт, а кандидат — шаблонное «Спасибо, мы вам перезвоним».
Это не отбор — это эксплуатация энтузиазма. Вы не соревнуетесь за вакансию, вы бесплатно закрываете чьи-то KPI.
«Если компания так ценит ваше время, почему она не оплачивает тестовые, как рабочие часы?».
Причина 2: Игра в одни ворота. Где обратная связь?
Компании, которые дают развёрнутую обратную связь по тестовым, — это миф уровня Лох-Несского чудовища. Все о них слышали, но никто не видел.
Что происходит на практике:
4. Отписка в стиле «404 Not Found»
«Спасибо, но вы нам не подходите. Успехов!» — и точка. Ни пояснений, ни советов.
5. HR-чёрная дыра
Кандидат отправляет задание — и попадает в вечный цикл: «Мы ещё проверяем» → «Решение задерживается» → тишина.
Цифры из личного опыта:
0 раз — столько мне и моим знакомым дали внятный фидбек на тестовые.
2 из 10-ти — компании, которые хотя бы прислали шаблонный отказ.
Безусловно, это не относится к абсолютно всем компаниям и тестовым. Есть случаи, когда на тестовое дают развёрнутую обратную связь, даже если не готовы продолжить отношения с соискателем. Однако, это скорее исключения из правила. Подавляющее большинство компаний либо не ответят больше ничего, либо пришлют отписку.
«Если компания не может организовать фидбек по тестовому — как она будет давать обратную связь сотруднику?».
Кто проверяет? Стажёр из HR, у которого нет технического бэкграунда? Уставший тимлид, который смотрит код между совещаниями?
Как оценивают? Субъективное «нравится / не нравится» вместо чек-листа.
Почему молчат? Страх, что аргументы раскроют некомпетентность проверяющих.
Вы теряете время в вакууме. Потратили 10 часов на задание → получили ноль информации → не поняли, как расти.
Ошибки множатся. Это как учить английский без учителя: вы годами будете неправильно ставить ударение в слове «develop» — и никто не поправит.
Доверие к рынку труда падает. Кандидаты начинают воспринимать всех работодателей как неблагонадёжных партнёров.
Причина 3: Время — не песок. Его нельзя сыпать в воронку
Нам твердят: «HR тратит на ваше резюме 10 секунд — будьте ярче!». Но когда соискатель вкладывает дни (а то и недели) в тестовое задание — это почему-то «нормально».
Пройти курс по новой технологии вместо зубрёжки под специфичные требования тестового.
Допилить пет-проект, который можно показать 10 работодателям, а не закинуть в чёрную дыру одного.
Выспаться. Серьёзно. Усталый мозг не способен на прорывные решения.
Выспавшись, изучив новую технологию или закрепив знания вы с большей уверенностью пройдёте собеседование или даже сможете претендовать на больший оклад. Время — ваш главный ресурс. Не стоит разбрасывать его на призрачный шанс найма, лучше потратить его на то, что положительно скажется на будущем поиске.
Давайте начистоту:
Тестовое в GitHub — это как чучело единорога на помойке. Никто не смотрит.
Код «для галочки» не развивается — он мёртворождённый.
Польза? Разве что для других соискателей, которые скопируют ваш код и сэкономят своё время.
Почему это порочный круг:
Вы не получаете навыков — вы получаете стресс.
Работодатель не видит вашего реального уровня — только умение подчиняться.
Даже если вы научились чему-то новому — это случайный побочный эффект, а не цель системы.
Портфолио формируют PET и OpenSource-проекты, не считая коммерческих под NDA. Именно они отражают вашу публичную сторону, показывают применяемые технологии, возможно, даже востребованность ваших проектов для третьих лиц. Нередки случаи, когда PET-проект переростает во что-то более значимое, пример, автор сайта easyoffer.ru.
Причина 4: Диктатура вместо диалога
Работодатели навязывают тестовые как единственный возможный сценарий, даже когда есть очевидные альтернативы.
HR-собеседование? Только после тестового. Вы тратите неделю на задание → проходите его → и только тогда узнаёте, что зарплата в 2 раза ниже заявленной.
Лайвкодинг? Нет, не слышали. Вместо 30-минутной сессии, где виден реальный уровень, — неделя стресса и сомнений.
Портфолио? «Это ненадёжно». Ваши 5 лет опыта и 20 проектов «менее ценны», чем абстрактная задача.
Лень оптимизировать процессы. Проще дать тестовое 100 кандидатам, чем провести 10 собеседований.
Страх ответственности. Если ошибётся HR — виноват он. Если ошибётся алгоритм тестового — виноват кандидат и его решение.
Иллюзия объективности. «Цифры не врут!» — но кто сказал, что ваше тестовое оценивают по цифрам?
Для кандидата: Он вкладывается в лотерею, где правила пишет работодатель.
Для компании: Теряет топовых специалистов, которые отказываются прыгать через унизительные обручи.
Для рынка: Таланты находят частных заказчиков и пропадают с рынка труда.
«Сдашь тестовое — потом поговорим» — это не фильтр, это симптом токсичных отношений.
Причина 1: Рынок vs. Миф о «переизбытке»
«Ломящийся от IT-специалистов рынок» — этот миф живёт в головах HR, как городская легенда.
Реальность же:
Переизбыток junior’ов при дефиците middle/senior.
Хаотичные требования: компании ищут «универсального солдата за зарплату стажёра».
Иллюзия выбора: 100+ откликов на вакансию не означают 100 адекватных кандидатов.
Но HR-отделы, заваленные резюме, включают режим «экономим время любой ценой».
Причина 2: HR-страхи и игра в горячую картошку
Тестовые задания — это страховка для HR от ошибок.
Как это работает:
Менеджер боится, что нанятый кандидат «не взлетит» → обвинят его.
Решение: переложить ответственность на алгоритмы и тестовые.
Если кандидат провалится — «виноват код», а не рекрутер.
Итог: HR-отделы превращаются в сортировочные центры, а не в партнёров для найма.
Причина 3: Отчаяние как валюта
Год поисков, 500 непросмотренных заявок, кредит за плечами — и вот кандидат уже готов:
Согласиться на тестовое на 20 часов.
Поверить в «уникальный шанс» без гарантий.
Подавить в себе мысль: «А что, если моим кодом просто бесплатно воспользуются?»
Компании это знают. Игра строится на формуле:
Отчаяние × Низкая самооценка = Бесплатная рабочая сила
К чему это привело?
Для компаний: Качество найма падает — «удобные» кандидаты ≠ талантливые.
Для индустрии: Рынок труда делится на «рабов тестовых» и топов, которые диктуют условия.
Для психики: Поиск работы превращается в квест на выживание с демотивацией в финале.
«Что если компании намеренно держат кандидатов в стрессе, чтобы снизить зарплатные ожидания?»
Даже ярый критик тестовых заданий (вроде меня) признаёт: в некоторых случаях они имеют смысл. Но только если соблюдены «правила игры».
Случай 1: Стажировка — тестовое как учебный инструмент
Почему работает:
Задачи соответствуют уровню junior: «сделать TODO-лист», «написать простой парсер».
Цель — не отбор, а диагностика навыков для дальнейшего обучения.
Обратная связь — обязательная часть процесса.
Личный опыт:
«Когда я подавал на стажировку в Академию ЛАД, тестовое заняло меньше суток. Благодаря ему я прошёл на стажировку. Это был честный старт, а не фильтр».
Важно! Если стажёрское тестовое требует неделю работы — это уже эксплуатация.
Случай 2: Гарантированная обратная связь — не обещания, а договор
Почему работает:
Компания рискует репутацией, если не выполнит обязательств.
Кандидат получает roadmap для роста, даже при отказе.
Как отличить правду от манипуляции:
HR чётко называет сроки ответа («в течение 5 рабочих дней»).
Вам дают контакты проверяющего (например, email тимлида).
Формат фидбека прозрачен: код-ревью, оценка по чек-листу, видеоразбор.
Лайфхак: Требуйте прописать условия обратной связи в письме с тестовым. Если отказываются — это красный флаг.
Случай 3: Оплата — когда время кандидата ценится
Почему работает:
Компания инвестирует в вас, а значит, серьёзно настроена на найм.
Вы получаете рычаг давления: «Я потратил 8 часов — вы заплатили. Давайте оба будем ответственны».
Пример адекватных условий:
Оплата 50-70% от часовой ставки позиции.
Даже при отказе вы получаете деньги и фидбек.
Тестовое не превышает 4 часов.
Где встречается:
Западные стартапы (чаще в ЕС/США).
Крупные IT-компании для senior-ролей.
Золотое правило:
Тестовое уместно только если оно:
Соразмерно позиции (не просите senior’а верстать лендинг).
Прозрачно по критериям.
Не нарушает баланс «время ↔ уважение».
Если хотя бы один пункт не соблюдён — смело отказывайтесь.
Перестаньте быть «удобным» кандидатом. Ваше время — не безлимитный ресурс. Вот алгоритм, как отсеять токсичных работодателей ещё до тестового:
1. Диалог с HR: жёсткие вопросы вместо вежливых улыбок
Задайте эти пункты письменно (чтобы был след):
«Тестовое оплачивается? Если да — какая ставка?»
«Сколько кандидатов его выполняют? Каков % прошедших в следующий этап?»
«Могу ли я получить примеры прошлых тестовых и критерии оценки?»
Почему это работает: Компании с честными намерениями не боятся прозрачности. Если HR уходит от ответов — вы экономите неделю жизни.
2. Альтернативы: вы не просите, вы предлагаете
Замените тестовое на взаимовыгодные форматы:
«Давайте я покажу вам свой пет-проект и расскажу, как оптимизировал его архитектуру» (доказывает экспертизу).
«Готов пройти 45-минутный лайвкодинг с вашим тимлидом» (экономит время всем).
«Давайте обсудим кейс из вашей практики — устно или на доске» (показывает мышление).
Лайфхак: Предложите подписать NDA, если компания боится утечек. Это повысит ваш статус в их глазах.
3. Жёсткие «нет»: когда бежать без оглядки
Отказывайтесь, если:
Тестовое длиннее 4 часов и на вопросы об оплате или альтернативных способах взаимодействия, компания "сливается".
Задание повторяет реальный проект компании или представляет собой полноценный продукт.
Вам дают ТЗ с ошибками и туманными формулировками. Если тестовое задание написано "из рук вон плохо" и рассчитано на то, чтобы соискатель самостоятельно продумал решение, при этом не предоставляются критерии оценки результата.
Как показать свою заинтересованность и попытаться пойти на контект иным путём:
Я заинтересован в подтверждении своей квалификации и компетенций, в связи с чем готов как к выполнению тестового задания, так и к прохождению разного рода интервью, но с условием оплаты тестового задания, если на его выполнение предполагается, что будет потрачено более 4 часов специалиста аналогичного грейда, либо если гарантируется обратная связь по результатам выполнения тестового задания
Помимо тестового задания был бы рад, если вы подробно изучите мое портфолио на GitHub, с целью понять в каком формате для вас было бы наиболее эффективно провести собеседование или сессию лайв-кодинга со мной
Тестовые задания — это зеркало отношений между компанией и кандидатом. В 95% случаев оно отражает не честный отбор, а экономию на вашем времени и проверку на покорность.
Что делать прямо сейчас:
Замените тестовые на рост Каждые 8 часов, потраченные на бесплатное задание, — это 8 часов без курсов, пет-проектов или отдыха. Инвестируйте в то, что останется с вами навсегда.
Бойкотируйте «чёрные списки» Компании, требующие тестовые до собеседования, — это динозавры рынка. Их вымирание неизбежно, если вы перестанете их кормить.
Делитесь опытом как вирус Каждая публикация о недобросовестном тестовом спасает сотни часов других специалистов.
Будущее, которое вы создаёте сегодня:
Для вас: Карьера без унизительных квестов «на одолжение».
Для компаний: Либо адаптироваться к этичному найму, либо потерять топовых кандидатов.
Для индустрии: Рынок, где код оценивают в деньгах, а не в пустых обещаниях.
Спасибо, что дочитали до конца!
Этот текст — не истина в последней инстанции, а искра для дискуссии. Если ваш опыт противоречит моим выводам — я жду вас в комментариях!
«Выбирайте компании, которые видят в вас человека, а не бесплатный ресурс».
Подписывайтесь на мой Telegram-канал, где регулярно публикуются материалы для новичков, или заходите на сайт "Код на салфетке".
Готовы проверить свои навыки программирования? Мы запускаем контест по разработке микросервиса для работы с API сайта статей. Ваше задание – создать сервис, который будет собирать данные о просмотрах статей, строить прогнозы и визуализировать данные в виде графиков.
• Реализовать запросы к API и сохранение данных.
• Построить прогнозы просмотров и графики.
• Отправить результаты через обратный API.
Контест будет проходить в течение семи дней и вот как мы это видим:
Мы проводим вводный стрим, на котором:
познакомимся с участниками;
покажем и объясним техническое задание;
проведем небольшую лайв-кодинг сессию;
создадим в телеграмм группу для участников контеста, в которой по ходу подготовки к контеста будем отвечать на возникающие вопросы;
Каждый участник в своем темпе разрабатывает необходимый функционал и по мере готовности сдает проект
Мы проводим заключительный стрим, на котором:
подведем итоги;
проведем код-ревью;
соберем обратную связь;
Ну, а чтобы было чем занять свою голову до контеста - каждый день мы будем публиковать блиц-вопросы (как тот, что прикреплен ниже) в нашем Telegram-канале, которые помогут понять к чему следует готовиться.
Для того, чтобы принять участие в контесте необходимо пройти регистрацию по ссылке.
Это отличная возможность прокачать навыки работы с API, базами данных и контейнеризацией! 💪
По окончании контеста, мы пригласим несколько человек в нашу Мастерскую Салфетки, где будем работать над совместными проектами и изучать новое.
Привет, друзья!
Мы регулярно проводим разные интерактивы, последним крупным мероприятием был конкурс на создание анти-спама для Telegram-бота на Python.
Конкурсы - безусловно, интересно, но мы решили пойти дальше! В данный момент мы планируем проведение контеста по программированию на Python.
Это мероприятие, где каждый сможет принять участие по написанию небольшого проекта по техническому заданию (ТЗ).
Помимо упомянутой выше, мы собираем команду, а-ля гильдию разработчиков! Те, кого мы возьмём в команду, получат возможность участвовать в проектах "Код на салфетке" поначалу в формате мастерской под нашим руководством, а затем в качестве полноценных, самостоятельных разработчиков. Под руководством в данном случае подразумевается:
работа в команде.
код-ревью.
помощь в изучении нового.
Помимо проектов салфетки, мы планируем выйти на рынок выполнения заказов, но об этом как-нибудь позже.
У нас уже есть планы по развитию экосистемы "салфетки". В частности, участникам предстоит познакомиться с библиотекой AIOgram для написания ботов, фреймворками Django и FastAPI для веб-разработки. Помимо прочего, будет использоваться собственный git-сервер, wiki-платформа и task-трекер.
Мы сейчас подготавливаем необходимое и определяемся с задачей, однако остаётся один незакрытый вопрос. В связи с чем мы хотим узнать:
сколько времени вы готовы уделить участию в контесте по программированию?
Свой ответ оставьте, пожалуйста, в опросе в нашем Telegram-канале.
Telegram-канал "Код на салфетке" - https://t.me/press_any_button
В этом видео мы расскажем актуальные новости про вывод Telegram звёзд, а также связанные с выводом ограничения и лимиты.
Telegram-канал "Код на салфетке" - https://t.me/press_any_button
В начале июня в Telegram ввели оплату цифровых товаров и услуг при помощи новой валюты Telegram Stars, о чём было рассказано в постах "AIOgram3 18. Подключаем оплату Telegram Stars" и "Обновление бота автоответчика и ответы на вопросы о Telegram Stars".
В конце июля, как и обещали, ввели вывод звёзд, но не всё так просто. По началу не было никакой вменяемой информации о выводе (как и нет её сейчас, собственно), однако обновления со звёздами продолжали выходить.
Баланс звёзд пользователя и канала/чата различаются.
Баланс звёзд доступен в настройках возле кнопки "Telegram Premium", если звёды есть на аккаунте. Если же звёзд нет, то и баланс не отображается. Приобрести звёзды можно при выполнении покупки в боте или на канале, например, купив платное медиа или отправив "звёздную" реакцию.
Баланс канала/бота доступен в меню (только для администраторов).
Открыв раздел баланс, отобразится история операций и три вида баланса:
Доступный баланс - Количество звёзд, доступных для вывода.
Общий баланс - Количество звёзд, полученных с последнего вывода или с момента отправки которых ещё не прошёл 21 день.
Всего поступлений - Количество звёзд, полученное каналом/ботом за всё время.
Возникает вопрос: "оплата была больше 21го дня назад, но звёзды всё ещё не появились в разделе доступный баланс, почему?". Всё дело в том, что помимо временного ограничения, существует также лимит в 1000 звёзд, о чём написано в этом разделе (надпись появилась совсем недавно и раньше её не было).
При достижении лимита в 1000 звёзд на общем балансе, а также как только все звёзды из 1000 пройдут "карантин" в 21 день, они отобразятся на доступном балансе и их можно будет вывести.
После указания желаемого количества звёзд для вывода, вы будете перенаправлены на платформу Fragment, на которой будет необходимо привязать свой TON-кошелёк и после подтверждения будет сформирована транзакция.
К сожалению, на данный момент мы пока не можем оформить вывод звёзд с канала, для демонстрации процесса, но как только это будет возможно, мы сразу же всё сделаем и напишем для вас инструкцию.
Подписывайтесь на наш Telegram-канал, чтобы не пропустить!