Хабрахабр

Вопросы не мальчика, а джуна. 22 вопроса работодателю на собеседовании на позицию «Middle Python-разработчик»

image

Введение

За 2 года мне посчастливилось посетить более сорока собеседований в качестве кандидата на позицию «Middle Python-разработчик». На последних пятнадцати собеседованиях я понял необходимость задавать вопросы работодателю, чтобы в дальнейшем не столкнуться с неожиданностями по работе. Помимо базовых вопросов, которые обычно задают кандидаты работодателю я решил сформировать свои вопросы. Когда я задавал эти вопросы на собеседованиях, я получал самые различные реакции со стороны собеседующих. Кто-то говорил, что я дотошный, кто-то считал эти вопросы слишком банальными, а кто-то даже начинал нервничать(краснеть) и немедленно прерывать собеседование с нелепой отговоркой о том, что у него совещание. В этой статье я хотел бы рассказать об общих идеях посещения таких мероприятий а также привести мои 22 вопроса, которые я задаю на собеседовании работодателю.

Общие идеи

Собеседование на middle-разработчика часто выглядит так же как собеседование junior-а.

Это связано с тем, что многие тимлиды/тех.директоры не знают, что именно они хотят видеть в middle-разработчике. Это действительно так. Кто-то говорит, что middle – это разработчик с опытом от полутора лет, а кто-то — от трёх. Поэтому на таких собеседованиях обычно просят «написать декоратор» или «написать сортировку пузырьком на любом языке».
Так же мало кто понимает, чем junior-разработчик отличается от middle-разработчика. Также важным критерием для middle-разработчика является умение быть наставником для кого-либо или просто умение помогать внедриться новому сотруднику в проект. В моём понимании middle-разработчик — это тот разработчик, которому можно смело отдать небольшой проект или какую-либо часть крупного проекта, и чтобы именно он был за неё ответственен.

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

Однажды я был на собеседовании, где меня заставили тянуть билет и отвечать перед собеседующим на листочке. Это важное правило часто не понимают сами работодатели. Такое же поведение часто прослеживается со стороны кандидата. При этом на протяжении всего этого собеседования мы общались десять минут. Но тут тоже важно понять, что работодателю не особо интересно насколько хорошо Вы знаете «отличие Python2 от Python3». Часто кандидат хочет на всё ответить и ведёт себя как отличница с первой парты. Гораздо важнее для работодателя понять в целом как ты держишься на собеседовании, как рассуждаешь, как реагируешь на неудачи и т.д.

Middle-разработчиком нельзя стать без опыта.

Для слишком одарённых кандидатов без опыта у HR-специалистов есть свой термин – «strong junior-разработчик». Конечно, можно, но это повлечёт через какое-то время огромные неприятности как для начальника этого разработчика, так и для проекта. Возвращаясь к middle-разработчикам хочется отметить, что middle — это тот, кто хоть какое-то время проработал в разработке и понимает из каких процессов она состоит. Скорее всего таким разработчикам будет предложена неплохая денежная компенсация, но обязанности у них будут как у junior-разработчиков. Также middle умеет работать с различными инструментами(мониторинг, деплой, профилирование, тестирование) с которыми человек без опыта вряд ли сталкивался в учебных целях.

На позицию Middle-разработчика soft skills становятся важным фактором.

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

На позицию middle-разработчика реже дают тестовые задания
.

Лично я действительно столкнулся с таким фактом. Это утверждение достаточно субъективное. Если резюме составлено неважно, то скорее всего следует ждать тестового задания. Связываю это с тем, что работодателя больше интересует твоё резюме.

Вопросы

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

Как дела с тестированием? 1. Какие библиотеки для тестирования вы используете? Какие тесты вы пишете? (фабрики, моки и т.д.)

В моём понимании, тесты должны писать все разработчики хотя бы в каком-то виде. Тестирование – очень важная часть любой разработки. В стартапах часто меняется курс движения из-за чего старые проекты обычно бывают никому не нужны. Единственное, кому можно простить отсутствие тестов – это стартапы. Для всех остальных компаний пощады в этом вопросе быть не должно. А значит обеспечение качеством таких проектов было впустую потраченным временем. И тесты в данном случае является его личной перестраховкой и перестраховкой того, кто будет выливать его решения в production. Нужно понимать, что внедрение нового сотрудника в проект на первых порах будет приводить к различным ошибкам в коде.

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

Кто-то иногда говорит, что команда только начала заниматься написанием тестов и еще не знакома со всеми тонкостями этого ремесла. Стоит отметить, что на этом вопросе технические специалисты часто начинают теряться. Но иногда я слышал вот такой ответ: «Тестами должны заниматься тестировщики, а разработчик должен творить». Это абсолютно неверно.

Никто не говорит о ненужности тестировщиков. Разработчик должен писать необходимый минимум тестов, потому что именно он знает, как должен работать функционал, который он сотворил. Но важно понимать, что разработчики тоже должны нести ответственность за качество своего кода.

Что делает разработчик с кодом перед тем, как отправить его в репозиторий? 2.

Вот небольшой список того, чем обычно проверяют код перед отправкой в репозиторий: Под этим вопросом понимается локальная проверка своего кода по различным параметрам.

  • Flake8 – анализ кода на соблюдение PEP8,
  • Pylint – статический анализ кода,
  • Coverage – анализ кода на тестовое покрытие,
  • Tox – проверка кода на совместимость с различными версиями отдельных пакетов и с разными версиями Python.

Отсутствие данного кейса в разработке не является критичным. Также во многих компаниях этот кейс используется непосредственно в CI, и разработчик локально у себя ничего не запускает. Даже если это не используется в разработке, то было бы неплохо, чтобы люди, которые Вас собеседуют имели базовые представление об этих инструментах.

Есть ли в проектах CI/CD? 3. Есть ли DevOps-инженер?

Если в проектах нет CI/CD и DevOps-инженер тоже отсутствует, то есть вероятность что именно Вы будете этим заниматься. Этот вопрос не имеет никаких подводных камней и задаю я его чтобы получше понять устройство компании. Поэтому этот момент тоже лучше обсудить на собеседовании.

Есть ли Code Review? 4. Как оно проходит?

Но стоит отметить что лично меня интересовало как именно оно проходит. Первую часть вопроса можно оставить без комментариев, потому что все понимают важность этого мероприятия. Но иногда встречается, что над любым разработчиком есть ментор/наставник и именно он ревьюит разработчика. Чаще бывает так, что каждый из команды ревьюит разработчика который сделал Merge Request. Здесь сразу затрагиваются такие аспекты, как командное взаимодействие, коллективная ответственность, увеличение bus-фактора. Первый подход считаю более правильным, так как чем больше людей ревьюит код, тем лучше для проекта и для команды.

Какую систему контроля версий Вы используете? 5.

Особенно это относится к компаниям, которые на рынке больше 10 лет. На данный момент в России существует немало компаний, которые до сих пор использует hg, svn и прочие древние системы контроля версии. Также стоит отметить, что я недолгий период времени принимал участие в разработке используя hg и особого удовольствия мне это не доставило. Этот вопрос больше проверяет насколько старая компания восприимчива к новым технологиям.

Используете ли вы git/hg-flow или какую-либо определенную методологию при работе с git/hg? 6.

Поэтому если команда не использует git/hg, то и задать его нет смысла. Данный вопрос вытекает из предыдущего вопроса о системах контроля версий. Если же компания использует git/hg, то этот вопрос Вам сможет показать насколько хорошо отлажен процесс разработки.

Используете ли Вы методологию разработки (scrum, kanban и т.д.)? 7.

Самый популярный подход в разработке – итеративный. В разработке важно придерживаться какого-то определённого подхода(методологии). В моём понимании, если в команде используется какая-то методология – это однозначно хорошо. Такой подход позволяет определить Ваш вклад в проект. Также это помогает понимать Вам сроки выделенные на задачи. Это позволяет Вам определить Вашу эффективность. Это всё равно что у школьников есть 4 четверти в году, где им выставляют отметки, чтобы потом определить итоговую оценку за год.

Используются ли системы мониторинга в проектах(Sentry, NewRelic и т.д.)? 8.

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

Используется ли в проекте система для хранения логов и работы с ними(ELK-технология и прочее)? 9.

Если ELK отсутствует, то очень трудно определить причину появления сложной ошибки в системе. Для меня это тоже является важным показателем. Данный вопрос не настолько важен, как вопрос №8, но его тоже стоит задать чтобы понять насколько богат опыт у команды в профилировании сложных ошибок.

Какие БД используются в проекте? 10. Почему именно такие?

Очень часто при использовании старых БД слышу что-то вроде «так сложилось исторически». Данный вопрос направлен на то, чтобы оценить компетентность собеседующего. Технический специалист должен понимать минусы/плюсы используемой им БД. Такой ответ считаю неуместным. Этот вопрос следует задавать только в том случае, если Вы сами неплохо разбираетесь в различных БД и их отличиях.

Какая версия языка Python используется в проектах? 11. И как будете происходить миграция с одной версии на другую? Если используется версия Python2.x, то планируется ли переход на Python3.x?

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

Компания ищет fullstack-разработчика или backend-разработчика? 12.

Вакансии fullstack-разработчика на рынке труда можно встретить довольно часто. Этот вопрос я задаю только в том случае, если компанию это сама не уточнила перед собеседованием. Мой личный опыт говорит мне что fullstack-разработчиков не бывает, так как frontend и backend стали слишком разными направлениями с того момента как появился Веб. Многие компании считают это выгодным для себя. Иными словами, «На двух стульях не усидишь».

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

Используется ли технология контейнеризации в проектах? 13.

Этот вопрос является дополнением к вопросу №3.

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

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

Существует ли в компании годовая/квартальная оценка сотрудников и как она происходит? 15.

Если в компании существуют для это специальные мероприятия, то это прекрасно. Любому сотруднику полезно получать обратную связь от своих коллег. В любом случае, никто не запрещает запросить обратную связь от коллег в вольной форме. Если — нет, то в этом нет ничего страшного.

Есть ли у в компании переработки? 16. Если есть, то компенсируются ли они и как часто они происходят?

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

Насколько в компании сильна бюрократия? 17. Особенно это относится к крупным старым компаниям или к компаниям, которые работают с гос. (Оцените от 1 до 10)
Многие разработчики даже не догадываются о присутствии бюрократии в IT-сфере, но, к сожалению, она есть. Степень бюрократии в компании зависит только от фантазии руководства. заказами. Главная проблема такой бюрократии – это очень сильное торможение процесса разработки. Обычно бюрократия заключается в различных формальных заявках, визированиях, доступах, конфликтах интересов между несколькими подразделениями компании и написании скучной сырой документации в Word. Проще говоря, чем сильнее бюрократия в компании, тем медленнее развитие продукта и Ваше развитие как специалиста. То что в нормальной компании делается за один рабочий день, тут на это будут уходить недели.

Как обстоят дела с выбиванием ресурсов? 18.

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

Как собеседующий относится к новым внедрениям в проекте? 19.

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

Является ли компания участником каких-либо IT-конференций и есть ли у компании публикации на IT-темы? 20.

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

Есть ли митапы внутри компании? 21.

Митапы – очень важны. Здесь речь пойдет о митапах у разработчиков внутри команды или между командами. Если у Вас проблемы с публичными выступлениями, то это также поспособствует развитию Ваших soft skills. Они позволяют узнать кто и чем именно занимается в данный момент времени.

Есть ли в компании стажёры и развита ли система наставничества? 22.

Если в компании есть стажёры, то возможно Вы сможете быть для них наставником и делиться своим личным опытом. Стажёры – это потенциальное будущее компании. Наставничество – это тоже одно из направлений где Вы сможете развиваться.

Заключение

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть