Владимир Дементьев: Почему «Злые марсиане» не нанимают мидлов?

• Сергей Удалов представляет гостя — Владимира Дементьева, спикера и автора книги «Лазай for Ruby on Rails».  

• Обсуждение напряжённого периода в работе и найма бэкенд-разработчиков.  

• Компания ищет разработчиков с опытом работы, не обязательно с Ruby.  

• Важно, чтобы кандидаты могли работать с Ruby, так как большинство проектов компании на этом языке.  

• Возможность быстрого переключения между проектами на разных языках.  

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

• Фокус на помощь стартапам в запуске и преодолении кризисов.  

• Разработка собственных продуктов, например, «Энни Кейбл».  

• «Энни Кейбл» имеет платную версию и бесплатный мини-САА.  

• Основные клиенты компании — проекты в области девелопер тулс.  

• Пример крупного клиента — Bolt.io.  

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

• Основные задачи: найм, развитие команды, управление проектами.  

• Контроль за развитием команды и использованием её ресурсов.  

• Проекты могут быть большими или небольшими, с участием одного или нескольких экспертов.  

• Примеры задач: миграция с PostgreSQL на PlanetScale, разработка отдельных сервисов и фичей.  

• Локальные задачи по повышению производительности и мониторингу.  

• Контракты минимум недельные, без учёта часов.  

• Отсутствие отслеживания времени работы.  

• Обсуждение процесса найма в компании.  

• Ранее требовался опенсорсный портфолио и опыт работы в «звёздной команде».  

• Вопрос о том, стал ли процесс найма более традиционным.  

• В компании нет понятия «мидл», только юниоры, инженеры и сеньоры.  

• Понятие «мидл» считается бессмысленным, так как не отражает реальных навыков.  

• Юниоры должны иметь возможность показать свою работу, даже если она коммерческая.  

• Наём стал проще, не требуется быть экспертом в опенсорсе.  

• Основное требование — умение показать свой код.  

• Собеседование длится долго и может быть стрессовым, но адаптируется под кандидата.  

• Собеседование подстраивается под кандидата, чтобы оценить его навыки.  

• Важен не только опыт, но и способность кандидата формулировать свои мысли.  

• Письмо от кандидата — важный этап отбора.  

• Основные темы: базы данных, Rails, Ruby.  

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

• Большое интервью длится более двух часов.  

• Лайф-кодинга нет, вместо него используется лайф-ревью.  

• Кандидатам показывают код и просят оценить его или предложить улучшения.  

• Компания утратила российское географическое положение, большинство разработчиков переехали в Европу, Японию и Америку.  

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

• Сложно найти разработчиков с необходимыми навыками за пределами СНГ и Восточной Европы.  

• Процесс адаптации новых сотрудников требует времени и ресурсов.  

• Компания откладывает перестройку процесса найма из-за нехватки спокойного времени.  

• Сеньоров не хватает, поэтому компания ищет джунов.  

• Позитивный опыт с кандидатами без большого опыта, которые быстро растут.  

• Компания не хочет выпускать таких кандидатов, считая их перспективными.  

• Компания ищет талантливых разработчиков без плохих привычек.  

• Джуны в понимании компании — это скорее мидл плюс.  

• Пример успешного найма: человек с опытом работы 1–1,5 года.  

• Юниоры должны иметь опыт работы и понимание, как делать правильно.  

• Важны алгоритмическое мышление, ясность мышления и любопытство.  

• Быстрое развитие и гибкость ума — ключевые качества.  

• Идея книги пришла после предложения от издательства.  

• Изначально планировалось написать книгу о паттернах проектирования.  

• Автор решил изменить концепцию и сделать книгу о практическом использовании паттернов.  

• Издательство «Пакт» активно ищет новых авторов через соцсети и блоги.  

• Автор сомневался в качестве книг издательства, но решил попробовать после положительного опыта с книгой Джереми Эванса.  

• Книга писалась около года с перерывами.  

• Второе издание на английском языке выйдет через неделю-две.  

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

• Автор находит время для работы благодаря свободному графику.  

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

• В начале работы над книгой не было чёткого плана, концепция сформировалась позже.  

• Книга разделена на три части.  

• Первая часть посвящена основам Rails: принципам проектирования и базовым идеям.  

• Цель — понять Rails, чтобы эффективно расширять его возможности.  

• Rails предлагает простой и понятный интерфейс для разработки.  

• Важно использовать паттерны и абстракции, чтобы новый код соответствовал стилю Rails.  

• Гипертрофированный стиль Rails упрощает работу с кодом.  

• При росте проекта возникают задачи, выходящие за рамки фреймворка.  

• Неправильное решение проблем усложняет работу с приложениями.  

• Книга помогает избежать ошибок и сохранить логику Rails.  

• Книга начинается с разбора моделей и их декомпозиции.  

• Обсуждаются популярные проблемы: авторизация, идентификация.  

• Второе издание включает новые главы и обновления.  

• Автор учитывает обратную связь от читателей и обновления в Rails и Ruby.  

• Книга адаптируется к новым версиям технологий.  

• Примеры обновлений: использование ActionCable вместо абстрактных SMS.  

• MVC включает модель, view и контроллер.  

• В Rails контроллер может напрямую взаимодействовать с view.  

• Модель в Rails инкапсулирует бизнес-логику, а не только данные.  

• Логика формирования данных может быть расположена в модели.  

• Представление данных ближе к слою view.  

• Различие между данными и моделью: данные — это дейта, модель — это домен.  

• Контроллер реагирует на запросы и инициирует обновление представления.  

• В MVC контроллер не должен возвращать данные, а инициировать обновление.  

• Пример контроллера — сущность, которая принимает запрос и выполняет действия.  

• Модель должна отражать бизнес-область, включая отчёты и другие сущности.  

• Равенство «модуль = актив-рекорд» должно быть пересмотрено.  

• Отчёты должны быть частью модели, а не отдельной концепцией.  

• Разделение отчётов и сущностей по разным папкам усложняет понимание концепции.  

• Важно связывать отчёты с сущностями на уровне файловой системы.  

• Логика клонирования объектов должна быть частью модели.  

• Бизнес-правила должны быть выражены в модели, а не в отдельных концепциях.  

• Разделение по зонам ответственности улучшает тестируемость кода.  

• Иерархия папок помогает локализовать информацию.  

• Вертикальное разделение большого приложения требует отдельного обсуждения.  

• Горизонтальное масштабирование кодовой базы — большой шаг.  

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

• Система от компании Gasta предлагает модулярность без использования эндженов.  

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

• Этот подход пока не получил широкого распространения из-за отсутствия строгости.  

• Эксперименты с ручными типами помогают выстраивать границы между паками.  

• Частичная типизация используется для передачи данных между модулями.  

• Задача — избежать передачи объектов-рекордов как публичных интерфейсов.  

• Предлагалось экспериментальное решение с использованием RBST и разделением сигнатур.  

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

• Решение работало на небольших энджинах, но требовало полного покрытия типами.  

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

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

• Тесты помогали отслеживать ошибки типизации.  

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

• Разделение кода готовило к выделению микросервисов.  

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

• Интерфейс определял ожидания от объекта, независимо от его происхождения.  

• Публичные сигнатуры экспортировались наружу, приватные оставались внутренними.  

• Пример с пользователем иллюстрировал использование одной сигнатуры в нескольких модулях.  

• Статические методы использовались для демонстрации интерфейса репозитория.  

• В реальных проектах репозитории имеют состояние и конфигурирование.  

• Рекомендовалось использовать инстансы для вспомогательных методов.  

• Проект «Злые марсиан» закрылся из-за отсутствия прибыли и сложностей с постингом в соцсети.  

• Проект был полезен для тестирования внутренних идей и дизайна.  

• Сейчас команда создаёт микропроекты на Rails для внутренних задач.  

• Сообщество Ruby активно и диверсифицировано, нет зависимости от конкретных лидеров.  

• Проводятся конференции, где обсуждаются современные идеи и решения.  

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

• Проект Task Tracker выпущен с открытым кодом, но лицензия запрещает монетизацию сервисов на его основе.  

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

• Код Ruby открыт для использования, что делает его опенсорсным.  

• Критика опенсорса за невозможность заработка на проекте не имеет смысла.  

• Сообщество Ruby активно развивается за пределами официальных организаций.  

• Лидеры Ruby выполняют свою роль, их замена не требуется.  

• Маса играет символическую роль, его идеи реализуются другими людьми.  

• Развитие Ruby происходит свободно, любой может предложить изменения.  

• В Rails иногда появляются новые функции, которые не всегда соответствуют ожиданиям сообщества.  

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

• В Ruby новые функции чаще выделяются в отдельные гемы.  

• В сообществе Ruby нет чёткой культуры опенсорса.  

• Модель развития Rails отличается от Ruby: в Rails решения принимаются более авторитарно.  

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

• Action Cable жёстко привязан к своей реализации Event Loop для сокетов.  

• Предлагается разделить транспорт и бизнес-логику, как в Job.  

• Рефакторинг уже прошёл этапы ревью и вынесен в отдельный гем.  

• Изменения в Action Cable требуют тщательной проверки и тестирования.  

• Большие компании, такие как Shopify и GitHub, тестируют новые функции на своих проектах.  

• Action Cable не используется крупными компаниями, что усложняет его тестирование.  

• Требуется установить правила для внесения изменений в Action Cable.  

• Большие компании должны тестировать новые функции на реальных проектах перед их внедрением в Rails.  

• Action Cable должен быть отдельным гемом или библиотекой для более эффективного тестирования.  

• Action Cable в Rails зависит от других компонентов, включая контроллеры.  

• Изменения в фреймворке требуют обновления всех компонентов, включая Action Cable.  

• Синхронизация компонентов внутри одного проекта проще, чем в микросервисах.  

• Вход в IT становится сложнее, требуются самые талантливые кандидаты.  

• Важно правильно построить карьеру и профессиональный рост.  

• Успешные инженеры должны сохранять свой тренд для долгосрочного успеха.  

• Начинать с малого, не стремиться сразу к высоким позициям.  

• Разнообразие навыков помогает лучше адаптироваться на рынке.  

• Не зацикливаться на одном направлении, искать разные возможности.  

• Автор начал с рисования анимаций для курсов профподготовки.  

• Важно искать работу, даже если она не соответствует ожиданиям.  

• Не стоит заранее знать, какое направление вам подойдёт.  

• Публичность помогает компании и лично автору.  

• Выступления на конференциях и публикация статей мотивируют разработчиков.  

• Деление опытом с сообществом способствует развитию навыков.  

• Обратная связь важна, но не является первостепенной целью.  

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

• Желание получить положительную обратную связь остаётся важным фактором.  

• Мотивация к созданию контента связана с желанием делиться знаниями и получать обратную связь.  

• Публичность помогает сохранить знания и избежать их потери.  

• Создание контента для широкой аудитории требует особого подхода и усилий.  

• Автор стремится сохранить свой уникальный стиль в книгах и статьях.  

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

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

• Книга получила положительный отклик от единомышленников.  

• Внутри команды нет единого стиля работы, каждый выбирает свои методы.  

• Опенсорс и внутренние мероприятия способствуют формированию общего подхода.  

• Команда остаётся единой независимо от работы над проектами.  

• Обмен знаниями и обсуждение проектов помогают поддерживать связь.  

• Ротация сотрудников и подключение к другим проектам способствуют обмену опытом.  

• Изоляция на отдельных проектах может привести к выгоранию и потере связи с командой.  

• Ротация помогает избежать изоляции и поддерживать мотивацию.  

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

• Разбирайтесь в устройстве фреймворка на концептуальном уровне.  

• Разрабатывайте так, будто ваш код будет лежать в репозитории.  

• Стремление к высоким стандартам улучшает качество кода и дизайн приложений.