Fullstack Founder

Метка: разработчики

  • Как нанять разработчика: Отбор кандидатов

    Как нанять разработчика: Отбор кандидатов

    Вакансия нравится соискателям и к нам поступают десятки откликов.
    Но количество откликов не означает их качество…
    Многие разработчики не владеют навыком создания хорошего резюме. По резюме зачастую ничего не понятно.

    Мы и не ожидаем от них идеальные резюме. Каждому мы присылаем условия сотрудничества (ещё раз) и даём подробную анкету нашего образца.
    Честно пишем, что свяжемся только с теми, кто подойдёт по навыкам к конкретному проекту. Кто не подойдёт — попадёт в кадровый резерв, всё равно есть смысл заполнить анкету.

    В анкете 50+ вопросов. Спросим про часовую ставку, условия работы, работает ли с таймером, пишет ли тесты и любые другие интересные нам детали.
    Самый большой блок — отдельные вопросы про каждую технологию и навык, который может потребоваться у целевого кандидата.
    Какой опыт с _____?
    Варианты ответа: Не было опыта, Изучал/Пробовал, Практик, Эксперт.

    Кажется, что тут легко обмануть и приукрасить. Да, но навряд ли на 2 ступени. 🤡
    Любой крупный обман в анкете вскроется на интервью и реальных задачах. А если что-то приукрасил — сам будет навёрстывать.

    Разработчик с удовольствем заполнит анкету вместо 30-минутного интервью с рекрутёром. Анкету можно заполнить на текущем рабочем месте или после работы. Без стресса и спешки.

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

  • Как код попадает на сервер 2025 edition

    Как код попадает на сервер 2025 edition

    Как раньше: открыл удалённую папку на сервере по FTP, скопировал туда свои файлы — сайт работает.

    К каким проблемам это приводило:
    – Два разработчика скачали один и тот же файл, внесли правки и по очереди загрузили их на сервер. Изменения первого разработчика стёрты вторым.
    – Разработчики работают прямо на сервере. Человеческий фактор неизбежно приводит к ошибкам.

    Как это выглядит у нас сейчас:
    – Разработчик копирует код из Git-репозитория (git clone/git pull)
    – Создаёт свою ветку, в ней изменения хранятся отдельно (git checkout -b)
    – Вносит изменения в свой экземпляр (git commit)
    – Отправляет изменения обратно в репозиторий (git push)
    – Создаёт запрос на добавление своих изменений в общий код (Merge Request)
    – Робот 🤖 на новом поддомене разворачивает тестовую копию сайта с изменениями (Review Apps) и запускает тестирование
    – Менеджер, Тестировщик и другие разработчики смотрят и щупают изменения
    – Разработчик дорабатывает код, тестовый сайт автомагически обновляется
    – После принятия запроса на слияние (Merge Request) все новые изменения автоматически выкатываются на промежуточный сервер
    – С промежуточного сервера время от времени все обновления попадают на основной сервер (тоже через Merge Request)

    В итоге менеджеры могут одновременно отслеживать прогресс разных задач на тестовых доменах и давать обратную связь.
    Дополнительные бонусы: исключаем риск утечки данных (152-ФЗ) и рукожопства на сервере (🤖).