Тест Джоэла как инструмент собеседуемого

Наверняка, многие хабровачане знакомы с тестом Джоэла ^[1] (перевод ^[2]). Если в двух словах, Джоэл Спольски ^[3] предлагает на основе выбранных им критериев оценить любому инженеру, насколько хороша его команда.

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

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

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

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

1. Пользуетесь ли вы системой контроля версий?

Сейчас VCS — это правило, поэтому ответа «нет» Вы, скорее всего, не услышите. Поэтому следует спросить, какой системой контроля версий пользуются Ваши визави? Если выяснится, что это какая-нибудь старая и медленная система — вероятно, процессы в проекте (или во всей компании) идут медленно или народ не понимает преимуществ современных систем по сравнению со старыми. Имеет смысл спросить, есть ли в ближайших планах Git или Mercurial, и если есть — поинтересоваться, что мешало перейти на него раньше, какие бенефиты планируют получить при переходе.
Ещё имеет смысл спрашивать, как построена работа с репозиториями — в каких ветках происходит разработка, в какие моменты и по каким правилам делаются мёрджи, насколько стабилен trunc, есть ли какие-то проверки при коммитах (что проект компилируется, что тесты проходят, что codestyle правильный) и т.п.

2. Можете ли вы собрать продукт за один шаг?

Могут ли Ваши визави выполнить сборку/деплой/чоувастам своего продукта (или чо у вас там) за один шаг? За два шага? Иными словами, автоматизирована ли сборка. Если нет — имеет смысл спросить, почему она не автоматизирована. Что мешает её автоматизировать и тем самым сэкономить людские ресурсы (и нервы)? На этом этапе может выясниться много интересного про проект.

3. Выполняете ли вы ежедневные билды?

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

4. Используете ли вы базу данных ошибок?

Опять-таки, сейчас багтрекерами пользуются все. Поэтому интересно вот что: какой багтреккер используется? Какие процессы построены вокруг него? Кто, как и кому перекидывает тикеты? Это удобно? Что вас не нравится в текущем багтрекере или в процессах вокруг него? Какая деятельность регистрируется в трекере (баги, фичи, бэкпорты, регулярные таски), а какая — нет.

5. Исправляете ли вы ошибки перед написанием нового кода?

Исправляют ли Ваши визави имеющиеся ошибки прежде, чем писать новый код? Не все? Почему? Какие исправляют, а какие нет? Кто решает, исправлять ли данную ошибку или забить? Если в проекте много открытых багов (пусть даже только P4 и P5) — это верный признак не очень высокого качества продукта и недостатка ресурсов, разработчиков. Это может грозить авралами, оверхедами и потрёпанными нервами.

Ну или просто всем всё пох на проекте и люди элементарно забивают. Вы хотите работать в таком проекте?

6. Есть ли у вас актуальный план работ?

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

7. Есть ли у вас спецификация?

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

8. Предоставлены ли вашим программистам спокойные условия для работы?

Созданы спокойные условия для работы инженеров? Сколько человек ещё человек сидит в комнате, где будете сидеть Вы? Разговаривают ли люди у себя рабочем месте по мобильникам? Едят ли прямо перед компом? Есть ли какие-то правила насчёт того, как должно выглядеть рабоччее место?

Не знаю, как вам, а мне всё это действительно очень важно. Я привык работать в покойной обстановке.

9. Используете ли вы для работы лучшие из имеющихся инструментов?

Дают ли инженерам для работы современные компы или заставляют пользоваться устарелым шлаком? Будет ли у Вас свобода в выборе ОС, IDE, тексового редактора, антивируса и т.д.? Всё ли ПО в конторе (проекте) — лицензионное? Винда? Ворд? Если Вам для работы понадобится софтина за 100 долларов — Вам купят на неё лицензию? А за $500? А за $1000?

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

10. Есть ли у вас тестеры?

Если нет — то надо бежать бегом, если это не Гугл. Сколько тестировщиков в проекте? Каково количественное отношение тестировщиков и разработчиков? Чем занимаются тестировщики — ручным тестированием или автоматическим? Пишут ли разработчики какие-нибудь тесты (юнит, регрессия). Тестировщики — члены команды или принадлежат соседнему подразделению? Второй случай означает невидимый барьер внутри команды, поэтому имеет смысл спросить, как в этом случае выстроено взаимодейтвие между тестировщиками и программистами.

11. Пишут ли кандидаты на работу код во время собеседования?

Думаю, ответ на этот вопрос вы и так узнаете)) Но тема — важная. Представьте, что Вас не попросили написать код на интервью. Значит, скорее всего, Ваших будущих коллег — тоже не просиили. Значит, есть ненулевая вероятность, что они пишут код не очень хорошо. А может, они знают это и боятся облажаться перед Вами? В общем, если не просят писать код — имеет смысл насторожиться.

12. Проводите ли вы коридорное тестирование удобства использования программ?

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

Как-то так.

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

А что бы спросили Вы?

Автор: 23derevo

Источник ^[4]