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

• Сергей Удалов представляет гостя — Владимира Дементьева, спикера и автора книги «Лазай 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 контроллер не должен возвращать данные, а инициировать обновление.  

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

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

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

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