Введение
За 2 года мне посчастливилось посетить более сорока собеседований в качестве кандидата на позицию «Middle Python-разработчик». На последних пятнадцати собеседованиях я понял необходимость задавать вопросы работодателю, чтобы в дальнейшем не столкнуться с неожиданностями по работе. Помимо базовых вопросов, которые обычно задают кандидаты работодателю я решил сформировать свои вопросы. Когда я задавал эти вопросы на собеседованиях, я получал самые различные реакции со стороны собеседующих. Кто-то говорил, что я дотошный, кто-то считал эти вопросы слишком банальными, а кто-то даже начинал нервничать(краснеть) и немедленно прерывать собеседование с нелепой отговоркой о том, что у него совещание. В этой статье я хотел бы рассказать об общих идеях посещения таких мероприятий а также привести мои 22 вопроса, которые я задаю на собеседовании работодателю.
Общие идеи
Собеседование на middle-разработчика часто выглядит так же как собеседование junior-а.
Это действительно так. Это связано с тем, что многие тимлиды/тех.директоры не знают, что именно они хотят видеть в middle-разработчике. Поэтому на таких собеседованиях обычно просят «написать декоратор» или «написать сортировку пузырьком на любом языке».
Так же мало кто понимает, чем junior-разработчик отличается от middle-разработчика. Кто-то говорит, что middle – это разработчик с опытом от полутора лет, а кто-то — от трёх. В моём понимании middle-разработчик — это тот разработчик, которому можно смело отдать небольшой проект или какую-либо часть крупного проекта, и чтобы именно он был за неё ответственен. Также важным критерием для middle-разработчика является умение быть наставником для кого-либо или просто умение помогать внедриться новому сотруднику в проект.
Собеседование — это не экзамен, а возможность выявить насколько компания и кандидат подходят друг другу.
Это важное правило часто не понимают сами работодатели. Однажды я был на собеседовании, где меня заставили тянуть билет и отвечать перед собеседующим на листочке. При этом на протяжении всего этого собеседования мы общались десять минут. Такое же поведение часто прослеживается со стороны кандидата. Часто кандидат хочет на всё ответить и ведёт себя как отличница с первой парты. Но тут тоже важно понять, что работодателю не особо интересно насколько хорошо Вы знаете «отличие Python2 от Python3». Гораздо важнее для работодателя понять в целом как ты держишься на собеседовании, как рассуждаешь, как реагируешь на неудачи и т.д.
Middle-разработчиком нельзя стать без опыта.
Конечно, можно, но это повлечёт через какое-то время огромные неприятности как для начальника этого разработчика, так и для проекта. Для слишком одарённых кандидатов без опыта у HR-специалистов есть свой термин – «strong junior-разработчик». Скорее всего таким разработчикам будет предложена неплохая денежная компенсация, но обязанности у них будут как у junior-разработчиков. Возвращаясь к middle-разработчикам хочется отметить, что middle — это тот, кто хоть какое-то время проработал в разработке и понимает из каких процессов она состоит. Также middle умеет работать с различными инструментами(мониторинг, деплой, профилирование, тестирование) с которыми человек без опыта вряд ли сталкивался в учебных целях.
На позицию Middle-разработчика soft skills становятся важным фактором.
Чем выше должность, тем с большим количеством людей приходится взаимодействовать. Поэтому очень часто при приёме на позицию middle-разработчика создаются дополнительные собеседования с HR-специалистом для составления психологического портрета будущего сотрудника. К этому собеседованию надо относиться также серьёзно, как и к техническому. Надо понимать, что Вам дальше работать с этими людьми. И если Вы чувствуете, что Ваши будущие коллеги Вам не очень подходят, то лучше сразу отказаться от дальнейшего сотрудничества.
На позицию middle-разработчика реже дают тестовые задания
.
Это утверждение достаточно субъективное. Лично я действительно столкнулся с таким фактом. Связываю это с тем, что работодателя больше интересует твоё резюме. Если резюме составлено неважно, то скорее всего следует ждать тестового задания.
Вопросы
В данном разделе будет представлен основной список вопросов, который я задаю работодателю на собеседовании. Возможно через какое-то время этот список будет расширяться или сужаться. Нужно отметить, что эти вопросы следует задавать именно на технических собеседованиях и желательно именно тому, с кем Вам потом взаимодействовать.
1. Как дела с тестированием? Какие тесты вы пишете? Какие библиотеки для тестирования вы используете? (фабрики, моки и т.д.)
Тестирование – очень важная часть любой разработки. В моём понимании, тесты должны писать все разработчики хотя бы в каком-то виде. Единственное, кому можно простить отсутствие тестов – это стартапы. В стартапах часто меняется курс движения из-за чего старые проекты обычно бывают никому не нужны. А значит обеспечение качеством таких проектов было впустую потраченным временем. Для всех остальных компаний пощады в этом вопросе быть не должно. Нужно понимать, что внедрение нового сотрудника в проект на первых порах будет приводить к различным ошибкам в коде. И тесты в данном случае является его личной перестраховкой и перестраховкой того, кто будет выливать его решения в production.
Когда работодатель ответит на вторую часть вопроса, Вы сможете понять насколько хорошо команда обеспечивает качеством свой продукт и также возможные обязанности разработчика о которых не было рассказано в вакансии.
Стоит отметить, что на этом вопросе технические специалисты часто начинают теряться. Кто-то иногда говорит, что команда только начала заниматься написанием тестов и еще не знакома со всеми тонкостями этого ремесла. Но иногда я слышал вот такой ответ: «Тестами должны заниматься тестировщики, а разработчик должен творить». Это абсолютно неверно. Разработчик должен писать необходимый минимум тестов, потому что именно он знает, как должен работать функционал, который он сотворил. Никто не говорит о ненужности тестировщиков. Но важно понимать, что разработчики тоже должны нести ответственность за качество своего кода.
2. Что делает разработчик с кодом перед тем, как отправить его в репозиторий?
Под этим вопросом понимается локальная проверка своего кода по различным параметрам. Вот небольшой список того, чем обычно проверяют код перед отправкой в репозиторий:
- Flake8 – анализ кода на соблюдение PEP8,
- Pylint – статический анализ кода,
- Coverage – анализ кода на тестовое покрытие,
- Tox – проверка кода на совместимость с различными версиями отдельных пакетов и с разными версиями Python.
Отсутствие данного кейса в разработке не является критичным. Также во многих компаниях этот кейс используется непосредственно в CI, и разработчик локально у себя ничего не запускает. Даже если это не используется в разработке, то было бы неплохо, чтобы люди, которые Вас собеседуют имели базовые представление об этих инструментах.
3. Есть ли в проектах CI/CD? Есть ли DevOps-инженер?
Этот вопрос не имеет никаких подводных камней и задаю я его чтобы получше понять устройство компании. Если в проектах нет CI/CD и DevOps-инженер тоже отсутствует, то есть вероятность что именно Вы будете этим заниматься. Поэтому этот момент тоже лучше обсудить на собеседовании.
4. Есть ли Code Review? Как оно проходит?
Первую часть вопроса можно оставить без комментариев, потому что все понимают важность этого мероприятия. Но стоит отметить что лично меня интересовало как именно оно проходит. Чаще бывает так, что каждый из команды ревьюит разработчика который сделал Merge Request. Но иногда встречается, что над любым разработчиком есть ментор/наставник и именно он ревьюит разработчика. Первый подход считаю более правильным, так как чем больше людей ревьюит код, тем лучше для проекта и для команды. Здесь сразу затрагиваются такие аспекты, как командное взаимодействие, коллективная ответственность, увеличение bus-фактора.
5. Какую систему контроля версий Вы используете?
На данный момент в России существует немало компаний, которые до сих пор использует hg, svn и прочие древние системы контроля версии. Особенно это относится к компаниям, которые на рынке больше 10 лет. Этот вопрос больше проверяет насколько старая компания восприимчива к новым технологиям. Также стоит отметить, что я недолгий период времени принимал участие в разработке используя hg и особого удовольствия мне это не доставило.
6. Используете ли вы git/hg-flow или какую-либо определенную методологию при работе с git/hg?
Данный вопрос вытекает из предыдущего вопроса о системах контроля версий. Поэтому если команда не использует git/hg, то и задать его нет смысла. Если же компания использует git/hg, то этот вопрос Вам сможет показать насколько хорошо отлажен процесс разработки.
7. Используете ли Вы методологию разработки (scrum, kanban и т.д.)?
В разработке важно придерживаться какого-то определённого подхода(методологии). Самый популярный подход в разработке – итеративный. Такой подход позволяет определить Ваш вклад в проект. В моём понимании, если в команде используется какая-то методология – это однозначно хорошо. Это позволяет Вам определить Вашу эффективность. Также это помогает понимать Вам сроки выделенные на задачи. Это всё равно что у школьников есть 4 четверти в году, где им выставляют отметки, чтобы потом определить итоговую оценку за год.
8. Используются ли системы мониторинга в проектах(Sentry, NewRelic и т.д.)?
Присутствие систем мониторинга в проекте так же важно, как и присутствие тестов. Именно системы мониторинга позволяют объективно оценить работу целой системы основываясь на действиях, которые совершает конечный пользователь. Если систем мониторинга нет, то стоит задуматься о качестве производимого продукта. Это всё равно что повар, который готовит еду, но никогда не у кого не спрашивает вкусная ли она.
9. Используется ли в проекте ELK-технология?
Для меня это тоже является важным показателем. Если ELK отсутствует, то очень трудно определить причину появления сложной ошибки в системе. Данный вопрос не настолько важен, как вопрос №8, но его тоже стоит задать чтобы понять насколько богат опыт у команды в профилировании сложных ошибок.
10. Какие БД используются в проекте? Почему именно такие?
Данный вопрос направлен на то, чтобы оценить компетентность собеседующего. Очень часто при использовании старых БД слышу что-то вроде «так сложилось исторически». Такой ответ считаю неуместным. Технический специалист должен понимать минусы/плюсы используемой им БД. Этот вопрос следует задавать только в том случае, если Вы сами неплохо разбираетесь в различных БД и их отличиях.
11. Какая версия языка Python используется в проектах? Если используется версия Python2.x, то планируется ли переход на Python3.x? И как будете происходить миграция с одной версии на другую?
Этот вопрос, равно как и предыдущей, направлен на оценку компетентности собеседующего, а также на оценку его рассуждения. Надо понимать, что работодатели бывают очень безграмотны и такие вопросы позволяют это выявить уже на стадии собеседования. Прежде чем задавать такого рода вопросы, я Вам настоятельно рекомендую самим углубиться в них.
12. Компания ищет fullstack-разработчика или backend-разработчика?
Этот вопрос я задаю только в том случае, если компанию это сама не уточнила перед собеседованием. Вакансии fullstack-разработчика на рынке труда можно встретить довольно часто. Многие компании считают это выгодным для себя. Мой личный опыт говорит мне что fullstack-разработчиков не бывает, так как frontend и backend стали слишком разными направлениями с того момента как появился Веб. Иными словами, «На двух стульях не усидишь».
В большинстве случаев компанию устраивает, то что ты не знаешь frontend и рассчитывает на то, что ты его подучишь непосредственно в бою. Уточню, что вакансия fullstack-разработчика неприемлема лично для меня. Многие же находят в этом отличную возможность окунуться в богатейший мир frontend-а при это не заплатив ни рубля.
13. Используется ли технология контейнеризации в проектах?
Этот вопрос является дополнением к вопросу №3.
14. Немного поспрашивать собеседующего о том, чем он занимался до этого проекта и давно ли он в проекте.
Этот вопрос очень важен. Чем богаче опыт вашего собеседующего, тем больше это отразится на ваших умениях и навыках через какое-то время. Особенно хорошо задавать такой вопрос в небольшой компании, где медленная текучка кадров.
15. Существует ли в компании годовая/квартальная оценка сотрудников и как она происходит?
Любому сотруднику полезно получать обратную связь от своих коллег. Если в компании существуют для это специальные мероприятия, то это прекрасно. Если — нет, то в этом нет ничего страшного. В любом случае, никто не запрещает запросить обратную связь от коллег в вольной форме.
16. Есть ли у в компании переработки? Если есть, то компенсируются ли они и как часто они происходят?
Мало кому нравится перерабатывать, особенно если ты студент или кормящий отец. Существует огромное количество компаний, которые ставят переработки на первый план. Чтобы понять, что в компании нет переработок или есть но редко, необходимо задавать подобного рода вопросы. Если в компании изредка случаются переработки, то в этом нет ничего критичного. Если переработки участились, то стоит задуматься о целисообразности дальнейшего пребывания в компании.
17. Насколько в компании сильна бюрократия? (Оцените от 1 до 10)
Многие разработчики даже не догадываются о присутствии бюрократии в IT-сфере, но, к сожалению, она есть. Особенно это относится к крупным старым компаниям или к компаниям, которые работают с гос. заказами. Степень бюрократии в компании зависит только от фантазии руководства. Обычно бюрократия заключается в различных формальных заявках, визированиях, доступах, конфликтах интересов между несколькими подразделениями компании и написании скучной сырой документации в Word. Главная проблема такой бюрократии – это очень сильное торможение процесса разработки. То что в нормальной компании делается за один рабочий день, тут на это будут уходить недели. Проще говоря, чем сильнее бюрократия в компании, тем медленнее развитие продукта и Ваше развитие как специалиста.
18. Как обстоят дела с выбиванием ресурсов?
Под ресурсами понимаются новые компьютеры для сотрудников, сервера, домены, лицензии и т.д. Этот вопрос можно также отнести к предыдущему вопросу о бюрократии.
19. Как собеседующий относится к новым внедрениям в проекте?
Данный вопрос позволяет оценить демократичность внутри команды. А также данный вопрос позволит понять, насколько голос обычного разработчика имеет вес для команды и наставника.
20. Является ли компания участником каких-либо IT-конференций и есть ли у компании публикации на IT-темы?
Конференция – это отличная возможность для разработчика и для компании заявить о себе и своих достижениях. Если компания публикуется и является участником конференций, то в какой-то момент Вы тоже сможете пользоваться такой возможностью. Если Вам это не интересно, то и спрашивать об этом нет смысла.
21. Есть ли митапы внутри компании?
Здесь речь пойдет о митапах у разработчиков внутри команды или между командами. Митапы – очень важны. Они позволяют узнать кто и чем именно занимается в данный момент времени. Если у Вас проблемы с публичными выступлениями, то это также поспособствует развитию Ваших soft skills.
22. Есть ли в компании стажёры и развита ли система наставничества?
Стажёры – это потенциальное будущее компании. Если в компании есть стажёры, то возможно Вы сможете быть для них наставником и делиться своим личным опытом. Наставничество – это тоже одно из направлений где Вы сможете развиваться.
Заключение
Всё вышесказанное является моими мыслями, основанными на личном опыте и не является 100-процентно верной информацией. Главная мораль статьи заключается в том, что проверять надо не только кандидата, но и работодателя. Также не стоит нервничать перед собеседованиями или на собеседованиях. Надо понимать что собеседующие такие же люди как и Вы, которые тоже ошибаются или чего-то не знают или не понимают.
Автор: sfilatov96
