Не кажется ли вам странным то, что когда вы собираетесь поменять место работы и возникает необходимость пройти интервью, то в первую очередь вы думаете «надо подготовиться к интервью». Прорешать задачи на HackerRank, почитать Crack the coding interview, зазубрить как устроен ArrayList и чем она отличается от LinkedList. Ах да, еще сортировки спросить могут, и явно будет непрофессионально сказать, что quick sort скорее всего будет лучшим выбором.
Но постойте, вы ведь программируете 8 часов в день, решаете интересные и нетривиальные задачи, и на новом месте работы будете делать плюс-минус тоже самое. Но тем не менее, чтобы пройти интервью необходимо как-то дополнительно готовиться, даже не оттачивать ежедневные навыки, а выучить то, что вам не понадобилось ни на текущем месте работы, ни вряд ли понадобиться на следующем. На ваши возражения о том, computer science у нас в крови, и разбуди нас посреди ночи мы обязаны написать с закрытыми глазами на наволочке обход дерева в ширину даже не приходя в сознание, я отвечу, что если я буду устраиваться в цирк, и моим главным трюком будет именно это — то пожалуй да, я согласен. Нужно этот навык проверить.


Но зачем проверять нерелевантные текущей работе навыки? Только потому, что это стало модным? Потому что Google делает так? Или потому, что вашему будущему тимлиду пришлось выучить все методы сортировки перед прохождением собеседования и теперь он считает что «каждый хороший программист обязан знать наизусть реализацию нахождения палиндрома в строке».

Дак вот, вы не Google ©. Что может себе позволить Google, обычные компании не могут. Гугл, проанализировав данные своих работников пришел к выводу, что вот конкретно у него, конкретно его задачами хорошо получается заниматься инженерам с олимпиадным прошлым. Более того, строя процесс отбора, они могут себе позволить заложить риск того, что они могут не нанять нескольких хороших инженеров из-за того, что они не умеют так легко щёлкать математические задачки. Но для них это не беда, желающих работать в Google много, позиция закроется.
Теперь давайте выглянем в окно, и если перед вашим офисом еще инженеры, желающие у вас работать, не разбили палаточный лагерь, а ваши разработчики чаще ищут на stackoverflow какую очередную Спринговую аннотацию нужно поставить, а не тонкости алгоритмов ранжирования, то, по всей видимости, вам пора задуматься над тем стоит ли копировать Google.

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

При чем же здесь ThoughtWorks? Именно здесь я для себя нашел пример образцового собеседования. Кто такие ThoughtWorks? Если кратко, то это High-End консалтинговая компания c офисами по всему мира начиная от Китая, Сингапура и заканчивая Американскими континентами, которая занимается консультированием в сфере разработки порядка 25 лет, имеет свой Science подразделение, возглавляемое Мартином Фаулером. Если вы поищите список из 10 книг, которые must read для Software Engineer, то, пожалуй, 2−3 из них будут написаны ребятами из ThoughtWorks, как например Refactoring By Martin Fowler и Building Microservices: Designing Fine-Grained Systems by Sam Newman или Building Evolutionary Architectures
by Patrick Kua, Rebecca Parsons, Neal Ford.

Бизнес компании строится на оказания достаточно дорогих услуг, но заказчик платит за феноменальное качество, которое складывается из экспертизы, внутренних стандартов и, конечно же, людей. Поэтому здесь жизненно необходимо нанимать правильных людей.
Какие же люди правильные? Конечно же для каждого свои. ThoughtWorks определила что для их бизнес-модели для разработчиков наиболее важными критериями является:

• Способность к парной разработке. Именно способность, а не опыт или умение. Никто не ожидает что придут люди, которые практикуют Pair programming вот уже лет 5. Но быть восприимчивым к чужому мнению, уметь слушать — это необходимый навык.
• Умение писать тесты, а в идеале практиковать TDD
• Понимать SOLID и ООП и уметь применять их.
• Презентовать свое мнение. Консультантом приходится работать с разработчиками заказчика, с другими консультантами, и не так много пользы, если человек умеет что-то делать хорошо, но совершенно неспособен донести это до остальных членов команды.

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

Как это часто и бывает 20 минутное собеседование с HR. На нем останавливаться не буду, скажу лишь, что я никогда прежде не встречал HR, который бы мог 15 минут рассказывать о культуре разработки в компании, почему они применяют TDD, почему парное программирование. Обычно на этом вопросе HR’ы сникают и рассказывают, что процесс у них обычный: разработчики разрабатывают, тестировщики тестируют, менеджеры погоняют.

За 1.5 часа до начала собеседования мне прислали задание сделать симулятор Mars Rover.

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

• TDD;
• Умение использовать ООП и писать поддерживаемый код;
• способности к парному программированию

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

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

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

Буквально через несколько часов после собеседования я получил конструктивный фидбек — что понравилось и что нет. В моем случае похвалили за использование Sealed классов как альтернативы объекту\null; за то, что перед написанием кода написал псевдокодом как бы мне хотелось управлять ровером, и таким образом получил набросок классов, по крайней мере тех, которые задействованы в API робота.

За неделю до собеседования меня попросили подготовить презентацию на любую тему, интересную мне. Формат прост и привычен: 15 минут презентация, 15 минут ответы на вопросы.
Я выбрал Clean Architecture by Uncle Bob. И опять меня интервьюировала пара человек. Это был мой первый опыт презентации на английском, и, пожалуй, если бы я был в стрессовой ситуации — я бы не справился. Но опять-таки, у меня ни разу не возникло ощущения что я на собеседовании. Все как обычно — я рассказываю, они внимательно слушают. Даже традиционная сессия вопросов и ответов была не похожа на интервью, было видно что вопросы задают не для того, чтобы «потопить», а те, которые их действительно заинтересовали в моей презентации.

Через пару часов после собеседования получил фидбек — презентация очень полезная и они получили искреннее удовольствие от прослушивания

Предупредив, что это последний этап технических собеседований, меня попросили довести дома код до production-ready состояния, после чего отправить код на ревью и назначить собеседования, на котором требования к задаче поменяются и код потребует модификации. Забегая вперед, могу сказать, что ревью кода проводится вслепую, ревьюверы не знают ни позиции, на которую претендует кандидат, не видят его CV, даже не видят его имени.

Созвон, и опять-таки пара ребят по ту сторону монитора. Все как на первом собеседовании: главное не забывать про TDD, рассказывать, что ты делаешь и зачем. Если вы раньше не практиковали TDD, то я рекомендую немедленно начать это делать, не потому что это необходимо в компаниях, а потому, что это существенно упрощает вашу жизнь, снижает уровень стресса если хотите. Помните, как приходилось судорожно искать дебаггером ошибку, которая воспроизводится только через браузер, а тестами вы ее воспроизвести не можете? Теперь представьте, что вам придется отлавливать такую ошибку во время собеседования — пара-тройка седых волос вам обеспечена. Что же нам обеспечено с TDD? Изменили код и неожиданно для себя поняли, что теперь тесты красные, а в чем ошибка понять с первого раза не удаётся? Окей, говорим интервьюверам «Упс», нажимаем Ctrl-Z и начинаем идти маленькими шагами вперед. И да, умение разрабатывать с использованием TDD, надо в себе вырабатывать, умение идти к цели так, чтобы у вас тесты были перманентно зелеными, а не красными пол дня, потому что «у вас большой рефакторинг». Это точно такой же навык, как умение писать поддерживаемый код, или производительный код.

Итак, насколько хорошо ваш код поддаётся изменениям зависит от того, какой дизайн вы изначально заложили, насколько он прост и от того, насколько хороши ваши тесты.

После собеседования я получил фидбек через несколько часов. На этом этапе я понял, что я практически прошел и осталось совсем немного до «встречи с Фаулером».

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

Если немного погуглить о культуре Thoughtworks, то можно найти статью Мартина Фаулера, в которой описываются 3 Pillars: Sustainable Business, Software Excellence, and Social Justice.

Предположим что Software Excellence у меня уже проверили. Остается показать Sustainable Business и Social Justice.

Притом упор я решил сделать на последнее.

Для начала рассказал почему ThoughtWorks — еще в институте читал блог Мартина Фаулера, отсюда и любовь к Clean code.

Проекты тоже можно преподнести с разных ракурсов. Разрабатывал и для медицины ПО, которое, упрощало жизнь пациентам, и даже по слухам спасло одну жизнь. Разрабатывал и ПО для банков, тоже своего рода упрощение жизни гражданам. Особенно если этим банком пользуется процентов 70% населения страны. Речь не про Сбербанк и даже не про Россию.

Хотите узнать обо мне? Окей. Мое хобби — фотография, так или иначе держу фотоаппарат в руках лет 10, есть фотографии, которые не очень стыдно показать. Так же, одно время, я помогал приюту для кошек: фотографировал кошек, которым нужен постоянный дом. А с хорошими фотографиями пристроить кошку гораздо легче. Наверное, отснял с сотню кошек ????

В конечном итоге, 80% презентации у меня было заполнено кошками.

Сразу же после презентации мне написал HR что он еще не знает результатов собеседования, но уже весь офис впечатлен кошками.

В конечном итоге я дождался фидбека — я всех удовлетворил как личность.

Но HR при финальном разговоре тактично рассказал, что Social Justice это очень хорошо и нужно, но не все проекты такие. И спросил не пугает ли это меня. В общем, переборщил я немного с Social Justice, бывает ????

Как итог, я уже несколько месяцев работаю в Сингапуре в Thoughtworks, вижу, что и здесь многие компании перенимают «лучшие практики собеседования» из Google, используя листочки и Whiteboard для коддинга, при том, что знаний дальше Spring’а, Symfony, RubyOnRails (нужное подчеркнуть) в работе не требуется. Инженеры берут недельный отпуск перед собеседованием чтобы «подготовиться».

В Thoughtworks же, помимо адекватных требований к кандидату во главу угла ставятся такие принципы:
Joy of Interviewing. При том для обоих сторон. Действительно, если вы хотите получить лучшие кадры (а кто не хочет?), то собеседование — это не рынок, где выбирают рабов, а смотрины, где и работодатель, и кандидат оценивают друг друга. И если у кандидата с компанией ассоциируются приятные эмоции — вполне вероятно, что он выберет именно эту компанию

Multiple interviewers to mitigate bias. В Thoughtworks парное программирование — стандарт де-факто. И если эту практику можно применить в других сферах, TW старается это делать. На каждом этапе собеседование проводят 2 человека. Таким образом, каждого человека оценивает минимум 8 человек, и TW старается подбирать интервьюверов с разным бекраундом, разных направлений (не только технарей) и пола.

В конечном итоге решение о приеме на работу будет принято на основании мнения как минимум 8 человек, и ни у кого нет права решающего голоса.

Attribute-based hiring Вместо того, чтобы принимать решение на основании «нравится\не нравится» кандидата, для каждой роли и для каждого этапа разработана форма, включающая оцениваемые атрибуты. При этом при оценки очень советуют оценивать не опыт в определенном навыке, а способность применять его. Таким образом, если у кандидата не было возможно применять какие-либо скилы, как TDD, но тем не менее он его старается применять, слушает советы по правильному использованию — у него есть все шансы пройти интервью.

Education Certificates not required TW не требует от кандидата обязательных сертификатов или образования в Computer Science. Оцениваются только умения.

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

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

Если вы хотите присоединиться к ThoughtWorks, открытые вакансии можно посмотреть здесь
Так же предлагаю обратить внимание на интересные вакансии:
Lead Software Engineer: Германия, Лондон, Мадрид, Сингапур
Senior Software Engineer: Сидней, Германия, Манчестер, Бангкок
Software Engineer: Сидней, Барселона, Милан
Senior Data Engineer: Милан
Quality Analyst: Германия Китай
Infrastacture: Германия, Лондон, Чили
(Хочу честно предупредить, что ссылка реферальная, если вы пройдете в TW, то я получу приятный бонус). Выбирайте офис по душе, не обязательно ограничиваться только Европой, в конце концов, каждые 2 года TW будет счастлив перевезти вас в другую страну, т.к. это часть политики ThoughtWorks, таким образом культура распространяется и усредняется.

Не стесняйтесь задавать вопросы в комментариях или просить меня порекомендовать вас.
Если тема показалась интересной, я напишу про то, как работается в ThoughtWorks и как живётся в Сингапуре.

[Репост моей статьи с хабра]