Pull to refresh

Comments 82

Думаю, что вы очень предвзято относитесь к некоторым пунктам в этом тесте.

Не вижу, на пример, связи между использованием лучших инструментов и тем, что вам вздумается купить за счет фирмы софтину за $1000 и лицензионный виндовс с офисом. Зачем вообще программисту офис на компе?
А для некоторых задач вообще будет лучшим использование линукс.
Все же, работая в команде, вы должны придерживаться правил, которые приняты в команде, а не пороть горячку.

Еще бы в дополнение ко всему перечисленному хотелось бы добавить, что не плохо взглянуть на ТЗ, которое выдается программистам для работы. Думаю, что грамотность ТЗ — это один из важнейших критерием проявления уважения (или не уважения) к программистам.
> Не вижу, на пример, связи между использованием лучших инструментов и тем, что вам вздумается купить за счет фирмы софтину за $1000

Например, я пишу на Java и считаю (небезосновательно) IntelliJ IDEA лучшей IDE для разработки на Java. Штука в том, что лицензия на неё стоит в районе 500$. Отсюда вопрос — есть ли в конторе лицензии, и если нет — купят ли мне её?

> Зачем вообще программисту офис на компе?

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

> А для некоторых задач вообще будет лучшим использование линукс.

Безусловно. Но в повседневной работе я юзаю и винду и юникс (в основном, солярку).

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

Эти правила неплохо бы выяснить для начала! Пост — о том, как это можно сделать.

> грамотность ТЗ — это один из важнейших критерием проявления уважения (или не уважения) к программистам.

Оно не для всех моделей и проектов применимо. Но если есть — я бы взглянул, да. Тот же Джоэл рекомендует не ТЗ, а User Guide в качестве основной спецификации.
Например, я пишу на Java и считаю (небезосновательно) IntelliJ IDEA лучшей IDE для разработки на Java. Штука в том, что лицензия на неё стоит в районе 500$. Отсюда вопрос — есть ли в конторе лицензии, и если нет — купят ли мне её?


Расскажите, пожалуйста, что есть в Ultimate Edition для разработки на Java и при этом в Community Edition нельзя обойтись бесплатными плагинами.
Чистое любопытство. Этот вопрос возник при обсуждении различных IDE среди .NET-программистов и я, как единственный пользовавшийся IDEA (для scala), не смог на него ответить.
Поддержка Web ну и JavaEE вообще :)

нормальная работа с JSON и XML

саппорт, багфиксинг — по моему ощущению, JetBrains охотнее фиксит запросы от платных кастомеров.
>различных IDE среди .NET-программистов
А уже сделали что-то лучше VS? Чистое любопытство.
Я указал контекст обсуждения чтобы уточнить, что велось оно среди людей слабо разбирающихся в вопросе и ни коим образом не подразумевает призыв «зачем платить когда есть бесплатное!».
Например вы пишете плагин для Word на Visual C++, а вам отказываются покупать Visual Assist. Купите за свои деньги?

Безусловно! Добавлю-ка я этот пункт в раздел про контроль версий!
Думаю, описание пункта 1 такой вопрос подразумевает:
есть ли какие-то проверки при коммитах (что проект компилируется, что тесты проходят, что codestyle правильный) и т.п.
Я изначально забыл про Code Review, но уже, конечно, поправил :)
Больше спасибо за статью!
Завтра как раз иду в побеседовать в компанию и попробую пройтись по этим вопросам. Напишу потом насколько успешно вышло и подготовились ли они, так как хабр там люди скорее всего читают.
Более специфические, но важные для меня вопросы:
— используется ли Dependency Injection повсеместно
— утверждены ли стандарты форматирования кода
— является ли стандартом Resharper (или аналогичные инструменты, упрощающие жизнь)

Простите, случайно ответил не туда.
С R# всегда так смешно получается в большинстве компаний куда приходил: многие используют только Ctrl+N и автодополнение более мощное, чем родное предоставляемое IntelliSense.
надо признать, что и Студия не стоит на месте и сделала несколько шагов вперёд по сравнению с тем обморочным состоянием, в котором она была без решарпера году эдак в 2005ом.
Да что там говорить, многие программисты не знают элементарных шорткатов не только в студии, но и в винде. Типа там Win-E, Win-Break, Win-R.

Я приложил некоторые усилия по внедрению R# в нашей команде, сделал презентацию, показал как всё работает, вбил coding style в настройки и расшарил их, но всё равно люди умудряются игнорировать даже очевидные ворнинги («Possible null reference exception» — вылез баг с ним, открываем код вместе — решарпер подчёркивает. Спрашивается — как такое вышло?).

Некоторые люди просто почему-то не хотят изучить свой инструмент и использовать его на полную.
К сожалению, не все люди, которые работают на должности разработчиков, любят эту профессию и стараются вникать в нее максимально.
боюсь ваше тестирование мало кто пройдёт :) Лично я узнал про DI месяц назад. Сама идея вроде популярна около года (ну ладно, немного больше). А большинство проектов живут уже больше года. Так что вам — в стартап :)
Сама идея вроде популярна около года (ну ладно, немного больше)

Что?
В PHP активно DIC используют больше 2-х лет, первые попытки аж в 2007-ых.
Вообще DIC еще в 90-ых обсуждали.
я тогда джуниором был и не слышал об этом ничего
Принципы SOLID (D это и есть DI) описаны еще в начале 2000. Собственно IoC описан Фаулером в 1988. В 2008 Microsoft выпускает Unity и уже тогда они были не первыми.
Автор книги Dependency Injection in .NET хорошо ответил на вопрос "В чем минусы DI?":

It can be dangerous for your career because it may increase your overall knowledge of good API design. Once you learn how proper loosely coupled code can look like, it may turn out that you will have to decline lots of job offers because you would otherwise have to work with tightly coupled legacy apps. Happens to me a lot :)

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

Я с этим согласен! Потому на собеседованиях буду уточнять. :)
Напишу потом насколько успешно вышло

Будет очень любопытно узнать, что у вас получилось.
Не сошлись на начальном этапе сразу, так что спрашивать было бесполезно
Ну вот, опять неизвестность… :)

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

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

Вдруг проект кажется хорошим, а на самом деле там шлак в обёртке из-под конфеты. Или наоборот, проект поначалу кажется мутным, но по мере раскрытия деталей всё больше и больше хочется в нём работать :)
13. Есть ли у вас печеньки? :)
Если серьёзно, имхо больше от адекватности людей зависит. Так по вопросам особо не угадаешь, понравится ли на предлагаемом месте работы, хотя косвенно судить тоже всегда полезно, особенно если человек выбирает из нескольких предложений.
Печеньки — это вопрос пары тысяч рублей в месяц. Просто русских в силу их ментальности ломает покупать печеньки самим. Хотя как бонус — приятно, не спорю.
Приятно, когда о вас заботятся :)
Это за ними ходить надо, если кончатся…
Спасибо за материал, про тест Джоэла не знал. Интересно, что в какой-то момент при поиске работы и сам составил подобный список, так что сейчас добавил к нему ссылку на эту статью.

Из здешних пунктов у меня были те, с которым на тот момент пришлось столкнуться — насколько интересен проект и про уровень комфорта на рабочем месте. А в моём списке — пара специфических вопросов:

* стабильность работы — не свернётся ли проект через полгода (вопрос, конечно, актуален не для каждого работодателя);

* отсутствие требований к жёсткой посещаемости, ибо была компания, требующая быть в 7 утра как штык;

* возможность подключения и работы из дома.
> ибо была компания, требующая быть в 7 утра как штык;
Девелоперская компания и 7 утра?!
Нет, компания околофинансовая (алгоритмический трейдинг, если не ошибаюсь). И, как рассказал рекрутер, для них очень сложно найти людей. Кто ж в такой фирме захочет работать :) (работать, кстати, нужно было до 5 вечера, т.е. 10 часов в день)
Интересный вопрос — как осуществляется управление проектом. Какие методики, техники, кто начальник, кто руководитель, принимают ли они участие в разработке или они лишь «на бумаге» вами руководят?
В моем случае руководителя нет. Он у меня условный. Т.е. следит за отработанным временем, напоминает про отчеты и т.п. В работе не помогает даже если просишь. Рееедко есть исключения.

От кого получать задачи? От руководителя или заказчика? Как построен принцип распределения задач? Agile, либо каждый раз приоритет может измениться? Есть ли разграничения задач по сотрудникам?

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

На деле:
дурю голову тим лиду на стороне заказчика «дай таск», получаю иногда ответ «на сегодня все, можешь идти домой», но идти не могу т.к. оплата почасовая.
git — базовое использование. Теги, 1 бранч master. Полное нежелание что-то менять на нашей стороне. Более полугода ушло на то, чтобы хотя бы немного приблизиться к git flow модели.
Тестирование есть. 1 тестировщик на другой фирме. На 80% бесполезный. Тестирование ручное. Документашку тестер читать не может. UML не знает. Увольнять его начальники не хотят. Видимо, дешево обходится. + feedback от пользователей.
Работу сложно назвать командной. Даже когда она таковая, в команде подобрались люди, которые не любят работать командно.
Рабочее место просто жесть. За год несколько переездов между комнатами, разными столами и освещенностью. В итоге сижу сгорбившись т.к. стол низкий. Регулярно пытаюсь на это обратить внимание руководства, но оно регулярно делает вид будто других проблем хватает. Скоро буду совсем злой. Кстати, может посоветуете, как конструктивно по этому поводу говорить?
Комп замечательный.
Ось лицензионная, софт — нет.

Ночных сборок нет, code review нет, спеки нет.

Почитал статью — хоть ты увольняйся :)
Но проект клевый :)
Ага, у меня тоже не все идеально, но очень нравятся задачи которые сейчас решаю и проект.
Хотя мне вмешает ввести тестирование, продвинутое использование СКВ, интеграцию, баг-трекер, только отсутствие достаточного опыта, а скорее всего просто лень и не хочется заниматься такими вещами, потому что пока что итак все довольно эффективно :)
любое исключение лишь подчёркивает правило!
Вы только что ознакомились с сокращенной версией. Вот полная.
Это не сокращённая версия. В посте, на который Вы дали ссылку, я только поверхностно коснулся теста Джоэла, сфокусировавшись больше на кастомных вопросах.
Интересный подход, что-то чувствуется интуитивно, когда спрашиваешь о будущей работе, но многое не знал, спасибо.

Я бы еще добавил адекватность вашего визави. Как правило в качестве тех. спеца выступает непосредственный руководитель или будущий коллега и здесь многое становится понятно: с кем то сходу, налаживается отличный контакт, с кем то не идет. Много зависит от внешнего вида людей и от первых фраз визави, хоть IT и фрики, но все же в спортивном костюме на собеседование это не совсем к месту, я считаю (такое кстати было :). Еще интересный факт, как начинают общение на «вы», на «ты», спрашивают ли можно на «ты». Как правило, тактично начинают с «вы», потом по обоюдному согласию переходим на «ты», все же общаемся в деловой среде и фактические общение с незнакомым человек начинается, но бывали забавные случаи старта на «ты», типа друзья тысячу лет и все такое, но если честно отбивает желание дальше разговаривать такой подход.
Я бы добавил вопрос под номером 0: «Сколько баллов вы набираете по тесту Джоэла?».
Зачастую это позволит сэкономить время.

согласен! сейчас добавлю в пост!
Гарантирую что большинство ответят «А что это?», хотя по пунктам могут и проходить.
ну если визави знают, что это такое — для меня это уже сразу плюс балл :)
По названию могут и не вспомнить, это не однозначный показатель. Зато, если знают, то уж точно маньяки :)
честно говоря, за 2 года работы и 3 проекта нормальных тестировщиков не видел. Ни разу. То ПМ просматривает задание, то никто, то наймут какую-то барышню, которая и комп-то плохо знает. На последней работе такой вариант: тестировщица парт-тайм в другом офисе, тестирование ручное.
Работал с украинцами, датчанами, англичанами.
СВН по мнению автора устарешая система контроля версий? Или просто надо, чтобы собеседующий доказал её пользу?
Лучшие из имеющихся инструментов? Мне никогда не покупали офис, да и PHPStorm тоже.
В общем, все условия вряд ли будут выполнены хоть в одном проекте.
Видел один проект, в котором все условия не выполнялись. До этого я думал что это невозможно.
> СВН по мнению автора устарешая система контроля версий? Или просто надо, чтобы собеседующий доказал её пользу?

SVN — годная система, но не более того. Для небольших проектов — рулит, для больших — имеет много проблем: performance, svnmerge.py, херовый резолвинг конфликтов и пр. Пожалуй, из бесплатных — сложно тягаться с гитом и меркуриалом.
А если почти ничего этого нет, и меня берут именно для того, чтобы это все в компании внедрить?
это — с одной стороны прекрасно, а с другой — может быть нудным геморроем. Ведь если всего этого нет — значит на это есть причины: люди сопротивляются, менеджмент не понимает профита, процессы негибкие, люди забронзовели. Вероятно, как следствие — качество продукта низкое и пр.

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

В общем, если у Вас карт-бланш — то флаг Вам в руки. Но боюсь, что Вы столкнётесь с неким сопротивлением, и преодолевать его будет, скорее всего, непросто.

Главное — чтобы было интересно!
1. Если Вы никогда не настраивали процесс разработки в (именно) команде «с нуля», то лучше попрактиковаться. Иначе возникнет ситуация:
— Здесь написано, что надо работать так — давайте все вместе настроимся и начнем работать так!
— Угу…
— Почему мы до сих пор так не работаем?
— Угу… эээ… угу
— Вы будете так работать?
— Угу
— Loop until @#$%!

2. Если процесс разработки не налажен, а ребята уже «во всю» работают над проектом, то будет полнейший ахтунг, ибо продукт будет первичен.

3. Если Вы еще и на роль PM идете + внедрять систему разработки, то ахтунг удваивается троекратно.

4. Если в процессе стабилизации разработки реально(!) заинтересован какой-либо высокий манагер компании, то может и получится.

Лично мое мнение — это мегагеморроидальная задача в существующих проектах/командах, на неё я бы подписался только за очень большие деньги, т.к. реально знаю что это (кто мне вернет нервы? :) ).
1. Хм. Задумался на первом же (нулевом по нумерации) вопросе.
Честно скажу, первый раз слышу про этот тест. Что, по вашему мнению, это значит?
Не считаю, что это хоть какой-то показатель, т.к. по остальным указанным пунктам может быть всё в порядке.

2. Почему вы считаете, что git и mercurial абсолютно лучше, скажем, svn?
Уверен, что многие с вами не согласятся, но не потому, что являются последователями черепашки, а просто потому, что в некоторых аспектах svn намного удобнее и лучше справляется с определёнными обязанностями. Поэтому опять же, считаю, что слишком предвзято относитесь к СКВ.
1. расширяйте кругозор, читайте хорошие статьи на Хабре! Ну и блог Джоэла, естественно!

2. Я в посте нигде не пишу про SVN. Потому что слишком многие на нём сидят и сразу начнут обижаться, прямо как Вы :) Судя по всему Git быстрее, чем Subversion, лучше справляется с мёрджами (svnmerge.py для нормального слияния веток — это вообще жесть) и конфликтами, умеет работать с локальным репозиторием. Ну и до версии 1.7 было много бесячего мусора в репозитории, который мешал, например, grep'у.
Приведите, пожалуйста, аргументы — чем лучше SVN?
Приведите, пожалуйста, аргументы — чем лучше SVN?
При работе с центральным репозиторием в команде, лично мне удобнее работать с SVN. Потому что нет этого двух-фазного комита — сначала в локальный репо, потом пуш в центральный.

В-нулевых, это частый сценарий, что комит+пуш может выполняться атомарно.

Во-первых, сейчас нет тулов, которые наглядно показывают незапушенные чейнджи (как в случае с dirty working copy в SVN), то получается что есть большой шанс, большой человеческий фактор, что пуш будет забыт. Ну и вообще, это надо самому ходить и проверять — есть ли че запушить. (Если вы мне хотите рассказать, что «забывать» это не удел хороших программистов, то это не о «забывчивости», а об удобстве. Такие же проблемы решают пункты 2,3,4,10 Теста Джоэла — там тоже можно все руками делать)

Ну, а в-третьих, с мерджем у меня больших проблем не возникало. Я и cherry-picking делаю, и сливаю между ветками. Проблема возникает тогда, когда объем комитов большой. Но в моем случае мне это не нравится по причине, что слишком много человек владеют одним кодом и решают в нем разные задачи.
> Во-первых, сейчас нет тулов, которые наглядно показывают незапушенные чейнджи (как в случае с dirty working copy в SVN), то получается что есть большой шанс, большой человеческий фактор, что пуш будет забыт.

Тулов море — во-первых, все IDE под Java, например, по дефолту это делают. IDE сама за вас всё проверяет и подсказывает, что есть незапушенные changeset'ы.

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

В третьих, часть процесса. Тестировщики или роботы или кто-то ещё у вас не проверяют результат? Пример: разработчик отмечает в JIRA, что фикс интегрирован, но забывает сделать пушю Тестировщик видит изменение в статусе бага и проверяет фикс. Пуша нет, поэтому от выставляет в JIRA «fix failed». Вот Вам и вариант детектора.

Можно автоматически делать — указывать при закрытии бага номер changeset'а. JIRA, интегрированная с репозиторием, проверяет, что такой changeset есть в репозитории. Если нет — сообщает разработчику и не даёт закрыть баг.

В общем, способов море.

Про мёрдж — отдельная песня. SVN-овский не блещет. А в меркуриале, например, можно любой внешний тул подключить, если дефолтный не устраивает. Например, для мёрджа html и xml нужно применять специальные тулы. SVN в этом месте часто лажает, проверено. Потому что он чисто текст мёрджит. И пофиг, какой.
Тулов море — во-первых, все IDE под Java, например, по дефолту это делают. IDE сама за вас всё проверяет и подсказывает, что есть незапушенные changeset'ы.

Я пользуюсь IDEA, в 10 был грустный клиент гитовый. Сейчас стало лучше, но все равно это не соответствует прекрасному.

Если я правильно пользуюсь, там ставится тэг. Его можно увидеть только во вкладке log. Ни в changes ни в коде (dirty файлы там помечаются отличным цветом) dirty local repo никак не маркируется.

Короче, там есть всякие хаки, типа экстеншенов, dropdown-кнопок, по которой нужно попасть чтобы выбрать commit&push, алиасы комманд, скрипты, тестеры… Все это заплатки. Тул должен браться и работать, а там предлагают «паровоз и доработать напильником» уютно, под себя.

Это очень по-гиковски. Это мило, где-то прикольно, и даже умно. И скорее всего, лет через n — мы увидим понятный тул для гита.

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

Когда-то давно, все понимали почему не CVS, а SVN. Сейчас это смхивает на hype, и SVN по-большому счету никто не мешает сосуществовать с GITом в мире разработки. Правда GIT часто лепят не туда, тыкая, что вообще панацея для всего.

Опять же про мердж. Если объем комитов большой, тут что git, что svn — попаболь еще та. Проблему в этом случае я описывал в коменте выше.

Остальные косяки с мерджем возникают тогда, когда не настроены code-style. В IDEA не очень хороший форматтер и рулы для формата XML-like синтаксиса. А также народ забывает настраивать импорты, например, одинаково для всех участников. И т.п.

Мердж окошко SVNа в IDEA вполне справляется со своими задачами при отсуствии факторов выше.
Плюсую и соглашаюсь! Вы очень классно написали, правда.

Но, к сожалению, как аргумент в пользу SVN, я эти мысли принять не могу. Прослеживается мысль «в IDEA поддержка SVN лучше, чем поддержка Git». Это скорее мысли о том, что хорошо бы не стесняться файлить баги на IDEA :)

Ну и кстати, поддержка Меркуриала в Идее мне нравится!
Современная поддержка git в idea вполне неплоха. В idea 10, 10.5, 11 и 12 EAP.

Хотя лично я отдаю предпочтение консоли при работе и с git, и с hg, и с svn. И стараюсь на работе (используем git) прививать привычку использовать git в консоли + qgit/gitg/gitk для самоконтроля.

Незакомиченные файлы, лишние игноры и прочие признаки халатного отношения к VCS встречаются независимо от конкретной VCS/DVCS.
Согласен с вами. DCVS не панацея — когда много коммитов и много человек работает над одной частью, то что гит что свн — всё равно мержить ручками придётся и конфликтов не избежать.
если куча людей работают над одной частью — имхо это признак организационных проблем в проекте.
Всегда ведь есть файл констант, файл проекта и т.п., которые затрагивают практически все.
делите на куски, стройте дерево
Вы ошибаетесь, что я обижаюсь (:
В работе пользуюсь git'ом, но, тем не менее, не игнорирую некоторые достоинства SVN.

Полагаю, стоит отметить, что услышав в ответ ту или иную СКВ, не помешает осведомиться, почему именно эту систему выбрали. Если аргументы будут в духе «так исторически сложилось», «другого не пробовали», то это скажет больше о компании, чем сама СКВ.
абсолютно согласен с Вами!
Отвечу как представитель организации, в которой недавно перешли с svn на git, а конкретно — на Github
1. Гораздо удобнее стала работа с ветками. Так как все ветки физически хранятся на локальном компьютере, switch очень быстрый.
В svn для работы параллельно с несколькими ветками нужно разворачивать каждую в отдельной папке — это долго и неудобно.

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

3. В github встроена довольно удобный (хотя и не идеальный) инструмент, позволяющий ревьюить пул-реквесты. Благодаря этому мы довольно быстро внедрили ревью в наш процесс. Непросмотренный код теперь вообще не попадает в репозиторий — это радость.

4. Будущее за git — все пацаны уже переходят. Надо идти в ногу со временем. :)

Кстати, черепашка под git тоже есть.
10. Есть ли у вас тестеры?

Если нет — то надо бежать бегом, если это не Гугл.
____________
А что, в Гугле нет тестеров?
Судя по тому, что в андройде пропустили декабрь — да :)
На хабре был пост про многоуровневый процесс тестирования в Google. Видимо, не панацея. Либо не во всех проектах применяют.
в некоторых проектах. Там вообще местами демократично довольно, насколько я знаю. Но это не важно. Важно то, что если Вы делаете офигенную вещь, и она получается очень качественной — то мне совершенно пофиг, есть ли у вас отдельные тестеры, или процесс проверки устроен как-то нетрадиционно для индустрии :)
Если в проекте много открытых багов (пусть даже только P4 и P5) — это верный признак не очень высокого качества продукта и недостатка ресурсов, разработчиков. Это может грозить авралами, оверхедами и потрёпанными нервами.

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

Вот заглянул сейчас в багзиллу mozilla.org. Только в одном компоненте Core/JavaScript Engine 3170 открытых багов (из них 3 блокера и несколько сотен критичных). Ужасный, абсолютно негодный проект, где всё просто рассыпается в руках, а разработчики не спят ночами?
Я написал «это может грозить XXX», а не «в таких проектах обязательно XXX»
Я кроме технических моментов (правда, не столько детально) еще задаю два вопроса:
1) Что вам больше всего нравится в работе в этой компании?
2) Что вам больше всего не нравится в работе в этой компании?

Много интересного для размышлений можно почерпнуть из ответов. На втором вопросе, например, многие просто виснут — плохой знак.
Белусловно! Только задавать эти вопросы нужно в проивоположном порядке — чтобы у собеседников остался положительный фон после разговора с Вами.
Стереотип :). Тут как раз порядок нужный: про хорошее все взахлеб, а потом бамс. Вот тут и видно, как дела в компании, как человек относится и т.д. Ну и, конечно, это не последний мой вопрос, после него еще задаю другие вопросы.
Я спросил бы обязательно, как устроено тестирование в компании.
В том смысле, пишутся ли автоматические тесты, и кто их пишет.

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

Первым и основным вопросом руководителю проекта, я бы задал вопрос:
«Какую методологию управления проектами Вы используете?»
Отсутствие ответа на этот вопрос нам какбэ намекнет…

Еще вопрос, на который желательно получить ответ от PM:
«Существует ли в Вашем проекте архитектор?»
Ответ в стиле «у нас каждый участник архитектор своего участка» подскажет нам, что
а) проект не имеет «стержня»
б) в ответе явная тавтология…

Следующий вопрос подскажет нам, как быстро мы поймем, что ребята всей командой делают:
«У вас есть техническая и пользовательская документация, кто пишет?» — Документация должна быть. Должна Быть.
Если документация есть, то нужно попросить с ней ознакомится ;)

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

Я, по своей натуре, очень щепетильно отношусь к юзабилити решений, посему задал бы вопрос:
«Проводите ли Вы юзабилити-тесты Вашего продукта?».
На утвердительный ответ — попросите показать Вам пару форм/дизайнов/ещечего одного и того-же проекта и найдите 5 отличий:)

Что я хотел сказать коментом помимо примеров вопросов — не верьте ответам! При любой возможности — просите подтверждение слов, иначе, в первый рабочий день, велика вероятность столкнуться с «когнитивным диссонансом» :)
Я вот не соглашусь ни с одним из пунктов!

Какую методологию управления проектами Вы используете?
Scrum? До свидания и удачи!

Существует ли в Вашем проекте архитектор?
Да? До свидания и удачи!

У вас есть техническая и пользовательская документация, кто пишет?» — Документация должна быть. Должна Быть
Голословное, вредное и абсолютно ни на чём не основанное утверждение. Проектов бывает миллион. Документация нужна там, где будет кто-то, кто будет её читать. Кому из пользователей сайта Аэрофлота нужна документация к нему? Спецификация как документация — должна быть. Чтобы заказчик мог сверить желаемое с действительным. Но вот User Guide — нет!

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

Соглашусь лишь с последним Ваши утверждением:
не верьте ответам!
Люди врут.

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

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

Sign up to leave a comment.