proDream

proDream

Пикабушник
1327 рейтинг 69 подписчиков 4 подписки 52 поста 2 в горячем
Награды:
С Днем рождения, Пикабу!5 лет на Пикабу
0

Taigram: Начало работы

Всем привет!

На этой неделе мы объявили о начале работы над Open Source проектом Taigram, название которому, к слову, выбрали вы в опросе.

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

Проектом занимаемся мы вдвоём: Иван и Виктор, а также с логотипом нам помог наш бессменный дизайнер Евгений. (Больше никто не захотел к нам присоединиться 😭)

Начнём мы, как водится, с самого начала...

Taigram: Начало работы IT, Программирование, Обучение, Python, Telegram, Программа, Длиннопост

Менеджер управления проектами Taiga.io

Любой проект начинается с продумывания работ, функционала и предстоящих задач. Это можно делать как в Telegram-переписке, блокноте, заметках Obsidian, так и использовать более профессиональные инструменты - менеджеры проектов.

Мы давно искали удобный (и, что немаловажно - бесплатный!) инструмент ведения проектов, который можно развернуть локально. В итоге остановились на Taiga.io.

Taiga.io - это бесплатный Open Source Self-Hosted менеджер управления проектами. Это означает, что это свободно распространяемое программное обеспечение, которое можно установить на свой собственный сервер, не беспокоясь о зависимости от какого-то крупного игрока.


Что не так с Тайгой и для чего нам нужен Taigram?

В тайге мы ведём наши проекты, включая процессы публикации статей на сайте.

Это оказалось действительно удобно, за исключением нескольких моментов и один из них - оповещения. Дело в том, что Тайга отправляет оповещения об изменении задачи только тем, кто назначен исполнителем и наблюдателем, и отправляет она их на Email, при условии, что у пользователя стоят соответствующие разрешения в его профиле. Согласитесь, это хоть и удобно (какие-никакие уведомления лучше, чем их полное отсутствие), но порой абсолютно не оперативно! Да и к тому же, вряд ли кто захочет "пачкать" свою почту.

Тогда появилась идея сделать Telegram-бота, который сможет отправлять уведомления в чат/тему чата. Мы приняли такое решение, в том числе из-за того, что Тайга предоставляет возможность подключить WebHook для отправки уведомлений и у отправляемых данных, достаточно простая структура и, в целом, этих данных достаточно - это важно. Это значит, что добавив на текущем этапе самый нужный, по нашему мнению, функционал - потом его можно дополнить. А если это можно дополнять и функционал, который мы добавим сейчас - самый нужный по нашему мнению, означает, что этого функционала может быть недостаточно для кого-то другого, под какие-то другие специфические задачи.

Если кому-то это нужно или кто-то посчитает, что знает чего сервису не хватает в настоящий момент - он сможет это дополнить. На наш взгляд это отличная идея и входящие данные для запуска работ над Open Source проектом.


Цель и функциональные требования

  1. Цель: создание сервиса, который будет отправлять уведомления об обновлении списка задач и других событий из менеджера управления задачами Taiga в Telegram

  2. Функциональные требования:

    • Настройка уведомлений через Telegram-бота:

      • Добавление/удаление администраторов бота;

      • Выбор чата/канала;

      • Добавление/удаление/изменение проектов;

      • Отображение списка проектов;

      • Отображение информации по проекту:

      • Форматирование, отправляемых сообщений.

    • Интеграция с Taiga через вебхуки.

  3. Стек технологий

    • Бэкенд: Python, FastAPI, Aiogram;

    • Работа с данными: Taiga Webhooks, MongoDB, Redis;

    • Инфраструктура: Dynaconf, Pydantic.


Планирование проекта

Мы созвонились в нашем уютном Discord-сервере (присоединяйтесь, там мы регулярно работаем, общаемся или играем!) и открыв Obsidian, начали рисовать примерный план желаемого функционала. Спойлер: уже сейчас, спустя неделю с начала часть функционала изменено до неузнаваемости, но об этом в другой раз.

Найти схему можно в нашем проекте: https://tasks.pressanybutton.ru/project/taiga-webhook-telegram-notifier/task/5

Схема казалась небольшой, мы делали и куда более объёмные и даже посчитали "да чё там делать? За пару вечеров справимся"...

Закончив схему появились две первые задачи:

  • Организовать доску в Тайге

  • Сделать репозиторий.

Доской занялся Виктор, а я пошёл делать репозиторий на GitHub.


Организация доски

Не смотря на то, что у нас (как у Команды проекта "Код на салфетке", так и у меня лично (Виктора)) был опыт в подготовке как проектной, так и технической документации, но делать что-то, что изначально будет в открытом доступе значит, что у проекта есть дополнительные ограничения и "ответственность".

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

Шаг 1: Определение настроек проекта

Сперва нам было необходимо определиться с используемыми модулями в проектном менеджере для последующего масштабирования.

Почти сразу мы определили, что модуль "Канбана" нам не подходит, поскольку там невозможно создавать задачи в отрыве от пользовательских историй, следовательно создавать на каждую задачу пользовательскую историю "Дорожками" (не статусы) означает плодить сущности и терять контроль над "подзадачами".

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

Вернемся к модулям, мы решили использовать:

  • Эпики: для стратегического планирования;

  • Скрам: для текущего управления спринтами;

  • Запросы: если у кого-то из команды или гостей проекта появится желание добавить какой-то функционал или сообщить о чем-то;

  • Вики: для создания первоначального хранилища базы знаний;

Шаг 2: Определение границ спринтов

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

Поэтому составили первоначальный план, который включал следующие этапы:

  • Подготовительная часть:

    • анализ задачи;

    • оформление всех функциональных хотелок в виде тезисов;

    • прогнозирование объема работ;

    • определение структуры проекта;

    • подготовка схем структуры проекта;

    • подготовка схем пользовательского пути;

  • Базовый функционал (этап основной разработки MVP):

    • подготовка структуры проекта;

    • инициализация проекта и первичная настройка виртуального окружения, инфраструктуры;

    • настройка CI/CD;

    • создание базовых классов, необходимых для реализации бизнес-логики;

    • валидация данных;

    • создание необходимых методов, для работы с текстовыми файлами (для последующей локализации);

  • Локализация:

    • русский язык;

    • английский язык;

  • Релиз GitHub Pages:

    • подготовка и настройка репозитория;

    • настройка CI/CD;

    • подготовка и оформление документации;

    • составление инструкций;

Шаг 3: Работа с доской

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

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

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

Откровениями "о взлетах и падениях" мы поделимся в последующих статьях, но считаем, что о публичном проекте, нужно говорить честно и открыто - этим объясняется существование этого подраздела.


Технологический стек

Помимо функциональных требований, мы обсудили и технологический стек для проекта.

В качестве пакетного менеджера мы выбрали набирающий популярность 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

Проект создан, запушен, но не хватает одной маленькой детали - настройки репозитория на GitHub.

Что я имею ввиду? У нас есть главная ветка репозитория main и по умолчанию, каждый может в неё пушить, что является критической уязвимостью в целостности всего проекта. Да, можно откатывать коммиты и прочее, но всё это дополнительные и далеко не самые приятные действия.

Что нам нужно было сделать, дабы предотвратить хаос? Мы разработали правила работы с репозиторием!

Правила работы

Если над проектом работает больше одного человека - хаос неизбежен. Кто-то забудет сделать пулл актуального состояния, кто-то другой будет одновременно с третьим работать над одним файлом и вызовет конфликт веток. Что мы сделали для решения этих проблем?

  1. Ветка main заблокирована от всех пушей, даже от имени создателя репозитория. Это решает проблему "случайного пуша в мейн", когда участник команды написал код, но забыл сменить ветку.

  2. Участники работают каждый в своей ветке, при это ветка не постоянная, а создаётся исключительно под задачу, после чего удаляется. Это позволяет определить по названию ветки к какой задаче на доске она относится, а не выяснять по коммитам, над какой же задачей работал участник.

  3. Для того, чтобы внести изменения в main-ветку, необходимо создать pull request. При этом, для того, чтобы сделать "мерж в мейн", необходимо одобрение минимум одного другого участника. Таким образом, в main-ветку не попадёт ничего случайно, только после код-ревью и одобрения.

Мы не сразу "притёрлись" с этой системой, так как каждый привык работать в одиночку. Однако, спустя время осознали её удобство, а когда разобрались, как всё это делать не выходя из PyCharm, стало вообще прекрасно.


Приглашение к разработке:

Если вас заинтересовал проект и вы считаете, что могли бы принести пользу в разработке, а также, если после прочтения этой статьи или ознакомления с материалами проекта вы пришли к выводу, что вам точно известно чего не хватает этому продукту и вы знаете как его можно улучшить - мы приглашаем присоединиться к проекту и принять участие в разработке!

Для этого свяжитесь с нами


Заключение

Это только самое начало, дальше начали создавать задачи и непосредственно писать код, о чём вы узнаете в следующей части.

Ссылки, касающиеся проекта:

  1. GitHub

  2. Доска разработки в Taiga

  3. Рубрика на сайте

Показать полностью 1
6

Тестовые задания: Ваш код ушел в прод. Ваша зарплата — нет

Введение

Приветствую! Меня зовут Иван, я автор Telegram-канала и сайта «Код на салфетке».

Уверен, что большинству из вас знакомо явление «Тестовое Задание» — не на этапе приёма на работу, а гораздо раньше: при отправке отклика, ещё до собеседования с HR.

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

Что не так с этой практикой? У меня есть чёткое мнение на этот счёт, и сегодня я готов его аргументировать.

Важно! Всё описанное в статье СУГУБО МОЁ ЛИЧНОЕ МНЕНИЕ!. Это не призыв к действию, а повод задуматься о происходящем на рынке труда. Вы можете не согласиться со мной — полностью или частично! И даже лучше, если после прочтения вы поделитесь своей точкой зрения в комментариях. Как гласит народная мудрость: «В споре рождается истина».

Тестовые задания: Ваш код ушел в прод. Ваша зарплата — нет IT, Работа, Карьера, Отдел кадров, Поиск работы, Собеседование, Длиннопост

Тестовое задание глазами работодателя

Прежде чем перейти к критике, попробуем взглянуть на ситуацию объективно — через призму интересов компании.

Что такое тестовое задание?

Это задача, которую кандидат должен выполнить в рамках жёстких сроков и требований потенциального работодателя". Условно их можно разделить на три типа:

  1. Абстрактные задачи

    • Цель: проверить логику и креативность.

    • Особенности: задачи вырваны из контекста работы (например, «написать алгоритм сортировки пельменей»).

    • Сроки: 1 день.

    • Проблема: результат не имеет практической ценности для компании.

  2. Мини-проекты под фреймворк

    • Цель: оценить владение конкретным инструментом (например, aiogram или requests).

    • Особенности: чёткий список требований («написать бота автоответчика»).

    • Сроки: 1–3 дня.

    • Проблема: опытный специалист справится за 2 часа, не ощутив никакого тестирования. Рутина.

  3. Полноценные продукты

    • Цель: проверить навык создания проекта с нуля.

    • Особенности: подробное ТЗ с описанием архитектуры, сущностей и технологий.

    • Сроки: 5–7 дней.

    • Проблема: граница между тестовым заданием и бесплатной работой стирается.

Тестовые задания: Ваш код ушел в прод. Ваша зарплата — нет IT, Работа, Карьера, Отдел кадров, Поиск работы, Собеседование, Длиннопост

После выполнения работа отправляется на оценку — иногда с код-ревью, иногда в чёрную дыру HR-системы.

Аргументы работодателя: зачем это нужно?

Тестовые задания: Ваш код ушел в прод. Ваша зарплата — нет IT, Работа, Карьера, Отдел кадров, Поиск работы, Собеседование, Длиннопост

Компании объясняют тестовые задания рационально:

  1. Фильтр «паразитов» Отсеивают тех, кто откликается «на авось»: если кандидат не готов потратить время на задание, он «недостаточно мотивирован».

  2. Проверка навыков в деле Резюме и портфолио можно приукрасить, а тестовое покажет, как человек:

    • пишет код (чистый или спагетти).

    • соблюдает дедлайны.

    • взаимодействует с требованиями.

  3. Иллюзия прозрачности Обещание обратной связи («вам подробно всё объяснят!») создаёт образ честной и открытой компании.

«Как отличить тестовое задание от проекта, который компания просто не хочет оплачивать?».


Всё вышеперечисленное — НЕ РАБОТАЕТ

Тестовые задания НЕ ЭФФЕКТИВНЫ, а зачастую откровенно вредят. И вот почему:

Тестовые задания: Ваш код ушел в прод. Ваша зарплата — нет IT, Работа, Карьера, Отдел кадров, Поиск работы, Собеседование, Длиннопост

Причина 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: Диктатура вместо диалога

Работодатели навязывают тестовые как единственный возможный сценарий, даже когда есть очевидные альтернативы.

Как это выглядит:

  1. HR-собеседование? Только после тестового. Вы тратите неделю на задание → проходите его → и только тогда узнаёте, что зарплата в 2 раза ниже заявленной.

  2. Лайвкодинг? Нет, не слышали. Вместо 30-минутной сессии, где виден реальный уровень, — неделя стресса и сомнений.

  3. Портфолио? «Это ненадёжно». Ваши 5 лет опыта и 20 проектов «менее ценны», чем абстрактная задача.

Почему работодатели так делают:

  • Лень оптимизировать процессы. Проще дать тестовое 100 кандидатам, чем провести 10 собеседований.

  • Страх ответственности. Если ошибётся HR — виноват он. Если ошибётся алгоритм тестового — виноват кандидат и его решение.

  • Иллюзия объективности. «Цифры не врут!» — но кто сказал, что ваше тестовое оценивают по цифрам?

Почему это тупик для всех:

  • Для кандидата: Он вкладывается в лотерею, где правила пишет работодатель.

  • Для компании: Теряет топовых специалистов, которые отказываются прыгать через унизительные обручи.

  • Для рынка: Таланты находят частных заказчиков и пропадают с рынка труда.

«Сдашь тестовое — потом поговорим» — это не фильтр, это симптом токсичных отношений.


Почему это стало нормой? Триггеры токсичного цикла

Тестовые задания: Ваш код ушел в прод. Ваша зарплата — нет IT, Работа, Карьера, Отдел кадров, Поиск работы, Собеседование, Длиннопост

Причина 1: Рынок vs. Миф о «переизбытке»

«Ломящийся от IT-специалистов рынок» — этот миф живёт в головах HR, как городская легенда.

Реальность же:

  • Переизбыток junior’ов при дефиците middle/senior.

  • Хаотичные требования: компании ищут «универсального солдата за зарплату стажёра».

  • Иллюзия выбора: 100+ откликов на вакансию не означают 100 адекватных кандидатов.

Но HR-отделы, заваленные резюме, включают режим «экономим время любой ценой».

Причина 2: HR-страхи и игра в горячую картошку

Тестовые задания — это страховка для HR от ошибок.

Как это работает:

  1. Менеджер боится, что нанятый кандидат «не взлетит» → обвинят его.

  2. Решение: переложить ответственность на алгоритмы и тестовые.

  3. Если кандидат провалится — «виноват код», а не рекрутер.

Итог: HR-отделы превращаются в сортировочные центры, а не в партнёров для найма.

Причина 3: Отчаяние как валюта

Год поисков, 500 непросмотренных заявок, кредит за плечами — и вот кандидат уже готов:

  • Согласиться на тестовое на 20 часов.

  • Поверить в «уникальный шанс» без гарантий.

  • Подавить в себе мысль: «А что, если моим кодом просто бесплатно воспользуются?»

Компании это знают. Игра строится на формуле:
Отчаяние × Низкая самооценка = Бесплатная рабочая сила

К чему это привело?

  • Для компаний: Качество найма падает — «удобные» кандидаты ≠ талантливые.

  • Для индустрии: Рынок труда делится на «рабов тестовых» и топов, которые диктуют условия.

  • Для психики: Поиск работы превращается в квест на выживание с демотивацией в финале.

«Что если компании намеренно держат кандидатов в стрессе, чтобы снизить зарплатные ожидания?»


Когда тестовые уместны? Три исключения из правила

Тестовые задания: Ваш код ушел в прод. Ваша зарплата — нет IT, Работа, Карьера, Отдел кадров, Поиск работы, Собеседование, Длиннопост

Даже ярый критик тестовых заданий (вроде меня) признаёт: в некоторых случаях они имеют смысл. Но только если соблюдены «правила игры».

Случай 1: Стажировка — тестовое как учебный инструмент

Почему работает:

  • Задачи соответствуют уровню junior: «сделать TODO-лист», «написать простой парсер».

  • Цель — не отбор, а диагностика навыков для дальнейшего обучения.

  • Обратная связь — обязательная часть процесса.

Личный опыт:

«Когда я подавал на стажировку в Академию ЛАД, тестовое заняло меньше суток. Благодаря ему я прошёл на стажировку. Это был честный старт, а не фильтр».

Важно! Если стажёрское тестовое требует неделю работы — это уже эксплуатация.

Случай 2: Гарантированная обратная связь — не обещания, а договор

Почему работает:

  • Компания рискует репутацией, если не выполнит обязательств.

  • Кандидат получает roadmap для роста, даже при отказе.

Как отличить правду от манипуляции:

  • HR чётко называет сроки ответа («в течение 5 рабочих дней»).

  • Вам дают контакты проверяющего (например, email тимлида).

  • Формат фидбека прозрачен: код-ревью, оценка по чек-листу, видеоразбор.

Лайфхак: Требуйте прописать условия обратной связи в письме с тестовым. Если отказываются — это красный флаг.

Случай 3: Оплата — когда время кандидата ценится

Почему работает:

  • Компания инвестирует в вас, а значит, серьёзно настроена на найм.

  • Вы получаете рычаг давления: «Я потратил 8 часов — вы заплатили. Давайте оба будем ответственны».

Пример адекватных условий:

  • Оплата 50-70% от часовой ставки позиции.

  • Даже при отказе вы получаете деньги и фидбек.

  • Тестовое не превышает 4 часов.

Где встречается:

  • Западные стартапы (чаще в ЕС/США).

  • Крупные IT-компании для senior-ролей.

Золотое правило:

Тестовое уместно только если оно:

  • Соразмерно позиции (не просите senior’а верстать лендинг).

  • Прозрачно по критериям.

  • Не нарушает баланс «время ↔ уважение».

Если хотя бы один пункт не соблюдён — смело отказывайтесь.


Как защитить себя как соискателя? Правила выживания

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

Тестовые задания: Ваш код ушел в прод. Ваша зарплата — нет IT, Работа, Карьера, Отдел кадров, Поиск работы, Собеседование, Длиннопост

1. Диалог с HR: жёсткие вопросы вместо вежливых улыбок

Задайте эти пункты письменно (чтобы был след):

  • «Тестовое оплачивается? Если да — какая ставка?»

  • «Сколько кандидатов его выполняют? Каков % прошедших в следующий этап?»

  • «Могу ли я получить примеры прошлых тестовых и критерии оценки?»

Почему это работает: Компании с честными намерениями не боятся прозрачности. Если HR уходит от ответов — вы экономите неделю жизни.

2. Альтернативы: вы не просите, вы предлагаете

Замените тестовое на взаимовыгодные форматы:

  • «Давайте я покажу вам свой пет-проект и расскажу, как оптимизировал его архитектуру» (доказывает экспертизу).

  • «Готов пройти 45-минутный лайвкодинг с вашим тимлидом» (экономит время всем).

  • «Давайте обсудим кейс из вашей практики — устно или на доске» (показывает мышление).

Лайфхак: Предложите подписать NDA, если компания боится утечек. Это повысит ваш статус в их глазах.

3. Жёсткие «нет»: когда бежать без оглядки

Отказывайтесь, если:

  • Тестовое длиннее 4 часов и на вопросы об оплате или альтернативных способах взаимодействия, компания "сливается".

  • Задание повторяет реальный проект компании или представляет собой полноценный продукт.

  • Вам дают ТЗ с ошибками и туманными формулировками. Если тестовое задание написано "из рук вон плохо" и рассчитано на то, чтобы соискатель самостоятельно продумал решение, при этом не предоставляются критерии оценки результата.

Как показать свою заинтересованность и попытаться пойти на контект иным путём:

Я заинтересован в подтверждении своей квалификации и компетенций, в связи с чем готов как к выполнению тестового задания, так и к прохождению разного рода интервью, но с условием оплаты тестового задания, если на его выполнение предполагается, что будет потрачено более 4 часов специалиста аналогичного грейда, либо если гарантируется обратная связь по результатам выполнения тестового задания

Помимо тестового задания был бы рад, если вы подробно изучите мое портфолио на GitHub, с целью понять в каком формате для вас было бы наиболее эффективно провести собеседование или сессию лайв-кодинга со мной


Заключение: Почему молчание — ваш главный враг

Тестовые задания — это зеркало отношений между компанией и кандидатом. В 95% случаев оно отражает не честный отбор, а экономию на вашем времени и проверку на покорность.

Что делать прямо сейчас:

  1. Замените тестовые на рост Каждые 8 часов, потраченные на бесплатное задание, — это 8 часов без курсов, пет-проектов или отдыха. Инвестируйте в то, что останется с вами навсегда.

  2. Бойкотируйте «чёрные списки» Компании, требующие тестовые до собеседования, — это динозавры рынка. Их вымирание неизбежно, если вы перестанете их кормить.

  3. Делитесь опытом как вирус Каждая публикация о недобросовестном тестовом спасает сотни часов других специалистов.

Будущее, которое вы создаёте сегодня:

Тестовые задания: Ваш код ушел в прод. Ваша зарплата — нет IT, Работа, Карьера, Отдел кадров, Поиск работы, Собеседование, Длиннопост
  • Для вас: Карьера без унизительных квестов «на одолжение».

  • Для компаний: Либо адаптироваться к этичному найму, либо потерять топовых кандидатов.

  • Для индустрии: Рынок, где код оценивают в деньгах, а не в пустых обещаниях.

Спасибо, что дочитали до конца!
Этот текст — не истина в последней инстанции, а искра для дискуссии. Если ваш опыт противоречит моим выводам — я жду вас в комментариях!

«Выбирайте компании, которые видят в вас человека, а не бесплатный ресурс».

Подписывайтесь на мой Telegram-канал, где регулярно публикуются материалы для новичков, или заходите на сайт "Код на салфетке".

Показать полностью 8

Мастерская.Контест: Анонс

Мастерская.Контест: Анонс Обучение, IT, Программирование, Python, Конкурс, Программист, Разработка, Длиннопост

🚀 Приглашаем на контест по разработке микросервиса!

Готовы проверить свои навыки программирования? Мы запускаем контест по разработке микросервиса для работы с API сайта статей. Ваше задание – создать сервис, который будет собирать данные о просмотрах статей, строить прогнозы и визуализировать данные в виде графиков.

🌟 Ваша задача:

• Реализовать запросы к API и сохранение данных.
• Построить прогнозы просмотров и графики.
• Отправить результаты через обратный API.

Контест будет проходить в течение семи дней и вот как мы это видим:

День 1:

Мы проводим вводный стрим, на котором:

  • познакомимся с участниками;

  • покажем и объясним техническое задание;

  • проведем небольшую лайв-кодинг сессию;

  • создадим в телеграмм группу для участников контеста, в которой по ходу подготовки к контеста будем отвечать на возникающие вопросы;

День 2-6:

Каждый участник в своем темпе разрабатывает необходимый функционал и по мере готовности сдает проект

День 7:

Мы проводим заключительный стрим, на котором:

  • подведем итоги;

  • проведем код-ревью;

  • соберем обратную связь;

Ну, а чтобы было чем занять свою голову до контеста - каждый день мы будем публиковать блиц-вопросы (как тот, что прикреплен ниже) в нашем Telegram-канале, которые помогут понять к чему следует готовиться.

Мастерская.Контест: Анонс Обучение, IT, Программирование, Python, Конкурс, Программист, Разработка, Длиннопост

Для того, чтобы принять участие в контесте необходимо пройти регистрацию по ссылке.

Это отличная возможность прокачать навыки работы с API, базами данных и контейнеризацией! 💪

По окончании контеста, мы пригласим несколько человек в нашу Мастерскую Салфетки, где будем работать над совместными проектами и изучать новое.

Показать полностью 1
1

Мастерская: Контест

Мастерская: Контест Обучение, IT, Программирование, Программист, Python, Telegram бот

Привет, друзья!

Мы регулярно проводим разные интерактивы, последним крупным мероприятием был конкурс на создание анти-спама для Telegram-бота на Python.

Конкурсы - безусловно, интересно, но мы решили пойти дальше! В данный момент мы планируем проведение контеста по программированию на Python.

В чём суть контеста?

Это мероприятие, где каждый сможет принять участие по написанию небольшого проекта по техническому заданию (ТЗ).

Какая цель?

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

  • работа в команде.

  • код-ревью.

  • помощь в изучении нового.

Помимо проектов салфетки, мы планируем выйти на рынок выполнения заказов, но об этом как-нибудь позже.

Чем можно будет заниматься в команде?

У нас уже есть планы  по развитию экосистемы "салфетки". В частности, участникам предстоит познакомиться с библиотекой AIOgram для написания ботов, фреймворками Django и FastAPI для веб-разработки. Помимо прочего, будет использоваться собственный git-сервер, wiki-платформа и task-трекер.

В чём вопрос?

Мы сейчас подготавливаем необходимое и определяемся с задачей, однако остаётся один незакрытый вопрос. В связи с чем мы хотим узнать:
сколько времени вы готовы уделить участию в контесте по программированию?

Свой ответ оставьте, пожалуйста, в опросе в нашем Telegram-канале.

Показать полностью

Telegram Stars: Вывод и лимиты звёзд

В этом видео мы расскажем актуальные новости про вывод Telegram звёзд, а также связанные с выводом ограничения и лимиты.

Telegram-канал "Код на салфетке" - https://t.me/press_any_button

Показать полностью

Telegram Stars лимиты и вывод

Telegram Stars лимиты и вывод IT, Программирование, Python, Обучение, Telegram Stars, Длиннопост

В начале июня в Telegram ввели оплату цифровых товаров и услуг при помощи новой валюты Telegram Stars, о чём было рассказано в постах "AIOgram3 18. Подключаем оплату Telegram Stars" и "Обновление бота автоответчика и ответы на вопросы о Telegram Stars".

В конце июля, как и обещали, ввели вывод звёзд, но не всё так просто. По началу не было никакой вменяемой информации о выводе (как и нет её сейчас, собственно), однако обновления со звёздами продолжали выходить.

Как узнать баланс звёзд?

Баланс звёзд пользователя и канала/чата различаются.

Баланс звёзд доступен в настройках возле кнопки "Telegram Premium", если звёды есть на аккаунте. Если же звёзд нет, то и баланс не отображается. Приобрести звёзды можно при выполнении покупки в боте или на канале, например, купив платное медиа или отправив "звёздную" реакцию.

Баланс канала/бота доступен в меню (только для администраторов).

Telegram Stars лимиты и вывод IT, Программирование, Python, Обучение, Telegram Stars, Длиннопост
Telegram Stars лимиты и вывод IT, Программирование, Python, Обучение, Telegram Stars, Длиннопост

Открыв раздел баланс, отобразится история операций и три вида баланса:

  • Доступный баланс - Количество звёзд, доступных для вывода.

  • Общий баланс - Количество звёзд, полученных с последнего вывода или с момента отправки которых ещё не прошёл 21 день.

  • Всего поступлений - Количество звёзд, полученное каналом/ботом за всё время.

Лимит на вывод.

Возникает вопрос: "оплата была больше 21го дня назад, но звёзды всё ещё не появились в разделе доступный баланс, почему?". Всё дело в том, что помимо временного ограничения, существует также лимит в 1000 звёзд, о чём написано в этом разделе (надпись появилась совсем недавно и раньше её не было).

Telegram Stars лимиты и вывод IT, Программирование, Python, Обучение, Telegram Stars, Длиннопост
Telegram Stars лимиты и вывод IT, Программирование, Python, Обучение, Telegram Stars, Длиннопост

При достижении лимита в 1000 звёзд на общем балансе, а также как только все звёзды из 1000 пройдут "карантин" в 21 день, они отобразятся на доступном балансе и их можно будет вывести.

Как выводить?

После указания желаемого количества звёзд для вывода, вы будете перенаправлены на платформу Fragment, на которой будет необходимо привязать свой TON-кошелёк и после подтверждения будет сформирована транзакция.

К сожалению, на данный момент мы пока не можем оформить вывод звёзд с канала, для демонстрации процесса, но как только это будет возможно, мы сразу же всё сделаем и напишем для вас инструкцию.

Подписывайтесь на наш Telegram-канал, чтобы не пропустить!

Показать полностью 4
Отличная работа, все прочитано!