[Перевод] 12 вопросов, которые стоит задать потенциальным работодателям

mjbfki82gffiufi9saof6ucpv3s.jpeg


Я только что завершил шестинедельный процесс трудоустройства на должность middle-senior разработчика на рынке, где сейчас ведется активная охота за талантами (Амстердам). Иными словами, я побывал на куче собеседований. Чтобы аккуратно разведать, какие компании мне больше всего подходят, я старался задавать побольше вопросов. Тут нужно найти правильный баланс, исходя из своих потребностей и того, кто с вами общается.

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

Стандартная последовательность шагов


По моему опыту, процесс отбора кандидатов обычно разворачивается так:

  1. Телефонный разговор / иногда встреча в офисе. Обычно за этот этап отвечают кадровики. Если же задействован кто-то из разработчиков, то разговор, как правило, получается довольно беглым (не лучшее время, чтобы засыпать их вопросами).
  2. Техническое интервью. Затем следует серия собеседований уже строго с командой разработчиков, которые будут досконально разбирать, что вы умеете, а что нет.
  3. Тестовое задание /«домашняя работа» / совместное написание кода. В моих глазах, компании, которые ввели практику совместного написания кода для кандидатов, сразу зарабатывают много дополнительных очков. Я понимаю, почему многие дают «задание на дом», но в большинстве случаев это пустая трата времени для обеих сторон — выявляются не те навыки, которые реально нужны.
  4. Заключительная встреча, знакомство со всей командой. Если компания маленькая, этот этап иногда заменяется личной беседой с основателем.
  5. Предложение о работе.


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

Вопросы для кадровиков


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

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

Как у вас проходит отбор кандидатов?

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

Расскажите мне в двух словах о команде разработчиков

Сколько в ней человек, какова доля джуниоров и сениоров, как выстраивается внутренняя иерархия (есть ли в компании технический директор или product owner)? На такие вопросы обычно без труда может ответить даже кадровик. Если же нет (такое иногда тоже случается, особенно в крупных корпорациях) — ну ладно.

Прежде чем положить трубку, убедитесь, что понимаете, что вас ждет на следующем этапе.

Вопросы для технического интервью


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

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

Как вы представляете идеального кандидата на эту позицию?

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

Например, в одной компании мне сказали, что им нужен человек, который «будет справляться без особой помощи». Для меня это звоночек. Любому разработчику, приступающему к работе с новой кодовой базой, понадобится помощь, чтобы понять бизнес-логику в ее основе, пусть даже все технологии, на которых она строится, он знает назубок. Если команда негативно относится к идее создания комфортной среды для передачи навыков, я считаю это серьезным минусом.

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

Что самое сложное на этой должности?

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

Кто в компании определяет общее видение?

Здесь я пытаюсь понять, есть ли у компании какие-то долгосрочные планы и, в идеале, поговорить также о целях и направлениях развития. Единственный ответ, который я воспринимаю как тревожный знак — это отсутствие ответа. «Основатель» — вполне нормальный вариант для небольшой команды, а «совет» или «управление» — для компаний покрупнее. Если же все считают себя в какой-то мере причастными к формированию видения и дорожной карты — это высший балл. Непонимающие взгляды говорят о том, что дело плохо — работать желательно с теми, кто хоть примерно представляет себе, куда движется.

Как у вас оценивается успешность деятельности отдела разработки и компании в целом?

Этот вопрос тоже касается рабочего процесса. Я хочу понимать, на основании чего будут судить о моей работе и работе моей команды. Если собеседующий затрудняется с ответом, я захожу с другой стороны и спрашиваю, по каким критериям они оценивают работу как неудовлетворительную. На мой взгляд, если никто не знает, что подразумевается под хорошей работой, но зато все ясно представляют, что значит «завалить задачу» — ничего хорошего ждать не стоит. Как можно успешно выполнять свои обязанности, не зная, что здесь понимают под успешностью?

Что вам больше всего нравится в работе? Что вас сильнее всего раздражает?

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

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

Расскажите, как проводится инспекция кода

Тут ответы по большей части лаконичные — они используют Pull requests, опцию Code Review на GitHub или еще где-то. Попробуйте углубиться в тему и выяснить, какие вносятся комментарии, сколько обычно проходит времени до слияния с основной веткой. Сильно ли они придираются? Или наоборот, пропускают даже серьезные ошибки? Правда ли сотрудники болеют за продукт или просто любят щегольнуть своими знаниями? А как обстоят дела с тестированием? Насколько часто происходят релизы?

Опишите процесс внедрения какой-нибудь новой возможности — как она превращается из абстрактной идеи в пункт бэклога, а затем в код?

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

Этот вопрос перекликается с тем, который касался видения; его можно задавать следом, как логическое продолжение. Допустим, видение у вас есть, а как планируются и реализуются отдельные фичи? Мне кажется, этот вопрос стоит ближе всего к «как здесь вообще работается?», разница лишь в том, что вы это не спрашиваете прямым текстом и, соответственно, не получите в ответ что-нибудь избитое.

Расскажите о какой-нибудь технической проблеме, с которой недавно столкнулись

Если предыдущий вопрос оказался для них слишком сложным, этот будет попроще — я просто прошу привести конкретный пример из последних задач. Команда справлялась с ситуацией совместными силами или решение искал кто-то один? Прибегали ли разработчики к каким-нибудь внешним ресурсам? Или они в итоге оказались от мысли внедрить эту возможность? Опять же, этот вопрос полезен тем, что демонстрирует, как протекает повседневный рабочий процесс.

Бонус: Есть ли какая-то принятая схема для введения новичков в курс дела? Как новые разработчики внедряются в команду?

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

Сюда же, я люблю спрашивать, нанимают ли вообще в команду джуниоров и как с ними работают, но только в тех случаях, если мы предварительно прояснили, что сам я к ним не отношусь. У меня около трех лет опыта за плечами, и мне не хотелось бы оставить ложное впечатление. Более продвинутые разработчики могут задавать подобные вопросы без опасений, что их примут за джуниора — ответы позволяют судить, насколько в компании ценят сотрудников.

Вопросы для заключительной встречи


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

Есть ли какая-то внутренняя политика, которую мне нужно иметь в виду?

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

И последнее


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

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

Удачи вам в поисках!

© Habrahabr.ru