_>Это самый тупой вопрос, который можно задать.

Если это был развод на флейм — поздравляю, вам удалось создать один из самых эпичнейших срачей. Тема явно для holy wars.

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

Этот вопрос нужен не для того, чтобы узнать, насколько крут кандидат (это будет выясняться дальше, в технических вопросах). А нужен он для того, чтобы узнать — способен ли кандидат общаться и объяснять, что он сделал. "Секреты" конкурентов никого не интересуют. Почему "секреты" в кавычках? Да потому, что все эти "секреты" вроде кошмарного спагетти-кода или безумных идей менеджерского состава о "мотивации" сотрудников не только ни для кого не являются секретами, но и банально неприменимы к новой компании. Любые "супер-идеи" тоже ерунда — не идеи нужны, а бизнес-планы, чего, разумеется, разрабочтик предоставить не может.

Так вот. Я, на основании рассказанного кандидатом, обычно выбирал один или несколько технических "затравочных" вопросов. Т.е. если кандидат взахлеб рассказывал про мета-программирование и чудеса boost::mpl, технический вопрос обычно касался чего-нибудь вроде реализации тех самых шаблонов и разнице компиляторов. Если были рассказы про супер-чудесную архитектуру, тогда поднимались вопросы наследования-включения-проксирования и связанные с этим особенности.

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

Допускаю существование совершенно другого типа интервью (сам году в 2004 так был "проинтервьюирован" в Акронисе) — когда на входе получаешь 20-страничную распечатку с ужасным кодом на С с классами (право дело, не С++ же это был!) и дополнительными вопросами вида "что из перечисленного не является контейнером STL — queue, vector, list, map, ...". Но, честно сказать, мне претит такой вариант.

Здравствуйте, SkyDance, Вы писали:

_>>Это самый тупой вопрос, который можно задать.

SD>Если это был развод на флейм — поздравляю, вам удалось создать один из самых эпичнейших срачей. Тема явно для holy wars.

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

SD>Интервью должно проходить без разрывов. Плавно. С чего можно начинать интервью, если о кандидате известно только то, что у него в резюме написано? Я всегда начинал с вопроса "что вам больше всего нравилось на любой вашей предыдущей позиции". Там уж как-то само собой выходил вопрос "и что вы на этой позиции смогли сделать", продолжавшийся "а как вы смогли этого добиться" и "вы упомянули проблемы с MSVC6, в чем конкретно они выражались?"

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

И что, что человек что-то делал? Сидел вот какой-то девелопер, насрал написал много кода, делая какой-то модуль, возникали проблемы/непонимание — залез на rsdn, накидали ему решений, воткнул.
Или залез на stackoverflow, нашел там за 2 минуты описание проблем с MSVC6, решил проблему.
Или там дергал серьора, который подкидывал идей.

А потом сидит такой вот девелопер у вас на собеседовании и надувает щеки, какие крутые задачи он делал и какие проблемы решил.

Здравствуйте, michael_isu, Вы писали:

_>Есть некоторый сорт интервьюеров/контор, которые спрашивают вопрос, обозначенный в заголовке. Что вы сделали в таком-то проекте на прошлой работе? А что конкретно вы сделали? А ещё конкретнее?
_>Это самый тупой вопрос, который можно задать.
Ничего тупого
Я и сам ТАКИЕ ВОПРОСЫ задаю

Здравствуйте, RGB_Dart, Вы писали:

RGB>Если человек не способен ответить — чем он занимался, значит он либо ничем не занимался

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

Здравствуйте, Kolobrodin, Вы писали:

K>Здравствуйте, mrTwister, Вы писали:

T>>Мне, честно говоря, нет дела до технолога Кока-колы и инженера BMW.

K>Работодателю кандидата тоже, с какого перепугу кто-то интересуется, как и кто что-то делал в проекте...

А ты работодатель?

Здравствуйте, michael_isu, Вы писали:

_>Вот вы ищете человека на конкретную позицию, который будет работать в определенной среде, с конкретными людьми, с конкретными подчиненными/начальством, делать конкретные задачи. Что мешает предложить ему какие-то кейсы задач из вашей работы?

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

Здравствуйте, michael_isu, Вы писали:

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

Щеки очень быстро сдуваются после дополнительных вопросов.

_> Что мешает предложить ему какие-то кейсы задач из вашей работы?

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

_> Задизайнить какой-то модуль, определить круг проблем и попросить предложить решения и т.д.

В рамках собеседования? Это такой прикол, что ли? Чтобы что-то "задизайнить", сначала надо въехать в предметную область. Потом посмотреть, [del]что было украдено до нас[/del] существующие решения задач такого рода (ибо будем честнЫ — в 99% случаев "новое" решение является велосипедом с колесами сомнительных конфигураций). Не, конечно, если это собеседование в пару-тройку дней длиной — наверное, можно и так, но многие ли согласятся?

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

И что вы из этого узнаете? Ну есть у него ход мыслей. Скажем, отличный от вашего хода. Что теперь? Отказывать кандидату? У него другие предпочтения в дизайне. Он читал другие книжки, и, например, аргументированно не любит "паттерны проектирования". Или, скажем, у него любовь к throw RuntimeException("Meaningful error message"), а вы обожатель throw specifications.
Самое печальное, что человек может складно и красиво говорить, умело оперировать абстракциями, моделировать ситуации, но... когда доходит до реально дела, почему-то, с кодом как-то не складывается (напоминаю, ищем _девелопера_, а не засирателя мозгов).

_>И что, что человек что-то делал?

Дык потому и задают вопрос — что СДЕЛАЛ! Эта единственная буковка "с" меняет всё

_>Или залез на stackoverflow, нашел там за 2 минуты описание проблем с MSVC6, решил проблему.
_>Или там дергал серьора, который подкидывал идей.
_>А потом сидит такой вот девелопер у вас на собеседовании и надувает щеки, какие крутые задачи он делал и какие проблемы решил.

Супер! Отлично! Берем!!!
По крайней мере в Австралии (и в значительной части западного мира) ценится именно умение _сделать_. Т.е. решить проблему. Никого не парит, спросил он у умных дяденек, или почитал rsdn. Или погуглил. Или по-stack-overflow-ил. Важно, что он проблему решил!

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

PS: если сейчас вы затронете "проблему индусокода" (когда задачу решил, но поддерживать решение решительно невозможно) — я сразу скажу: эта проблема никак не устраняется "умелыми абстракциями" и прочим буллщитом. Более того, разгребать сто слоёв "умелых абстракций" в большинстве случаев куда сложнее и дольше, чем копи-паст очередного Кумара.

Здравствуйте, SkyDance, Вы писали:

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

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

_>> Задизайнить какой-то модуль, определить круг проблем и попросить предложить решения и т.д.

SD>В рамках собеседования? Это такой прикол, что ли? Чтобы что-то "задизайнить", сначала надо въехать в предметную область. Потом посмотреть, [del]что было украдено до нас[/del] существующие решения задач такого рода (ибо будем честнЫ — в 99% случаев "новое" решение является велосипедом с колесами сомнительных конфигураций). Не, конечно, если это собеседование в пару-тройку дней длиной — наверное, можно и так, но многие ли согласятся?

Откройте раздел "Архитектура программного обеспечения". Люди как-то задают вопросы, независимо от предметных областей, и ответы получают нередко вполне вменяемые.

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

SD>И что вы из этого узнаете? Ну есть у него ход мыслей. Скажем, отличный от вашего хода. Что теперь? Отказывать кандидату? У него другие предпочтения в дизайне. Он читал другие книжки, и, например, аргументированно не любит "паттерны проектирования". Или, скажем, у него любовь к throw RuntimeException("Meaningful error message"), а вы обожатель throw specifications.

Всегда есть логичные причины использовать ли RuntimeException или "паттерны" или ещё что-то и если людьми руководит здравый смысл, то они придут к общему решению. Я могу поменять взгляд в конкретном случае, или человек. Если же им руководят религиозные взгляды и "лябоффь" к throw Runtime("blablabla"), независимо ни от чего, то пусть идет любить в другое место, где примут его иррациональные порывы. Или вы под него будете подстраиваться?

SD>Самое печальное, что человек может складно и красиво говорить, умело оперировать абстракциями, моделировать ситуации, но... когда доходит до реально дела, почему-то, с кодом как-то не складывается (напоминаю, ищем _девелопера_, а не засирателя мозгов).

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

_>>И что, что человек что-то делал?

SD>Дык потому и задают вопрос — что СДЕЛАЛ! Эта единственная буковка "с" меняет всё

_>>Или залез на stackoverflow, нашел там за 2 минуты описание проблем с MSVC6, решил проблему.
_>>Или там дергал серьора, который подкидывал идей.
_>>А потом сидит такой вот девелопер у вас на собеседовании и надувает щеки, какие крутые задачи он делал и какие проблемы решил.

SD>Супер! Отлично! Берем!!!
SD>По крайней мере в Австралии (и в значительной части западного мира) ценится именно умение _сделать_. Т.е. решить проблему. Никого не парит, спросил он у умных дяденек, или почитал rsdn. Или погуглил. Или по-stack-overflow-ил. Важно, что он проблему решил!

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

SD>PS: если сейчас вы затронете "проблему индусокода" (когда задачу решил, но поддерживать решение решительно невозможно) — я сразу скажу: эта проблема никак не устраняется "умелыми абстракциями" и прочим буллщитом. Более того, разгребать сто слоёв "умелых абстракций" в большинстве случаев куда сложнее и дольше, чем копи-паст очередного Кумара.

В крайности не стоит впадать, и на небольших конкретных задачах все прекрасно видно, городит ли кандидат 100 абстракций, где они не нужны, и рассуждает ли в стиле фортрана, когда неплохо было бы ввести пару-тройку абстракций.

Здравствуйте, Доктор ТуамОсес, Вы писали:

ДТ>Здравствуйте, michael_isu, Вы писали:

_>>Есть некоторый сорт интервьюеров/контор, которые спрашивают вопрос, обозначенный в заголовке. Что вы сделали в таком-то проекте на прошлой работе? А что конкретно вы сделали? А ещё конкретнее?
_>>Это самый тупой вопрос, который можно задать.
ДТ>Ничего тупого
ДТ>Я и сам ТАКИЕ ВОПРОСЫ задаю

Дохтур, нам вас не хватало. Расскажите о том, как вы ходили на собеседования

_>Что там такого прям специфичного, что нельзя некоторую небольшую часть доступно объяснить?

Что вы будете объяснять-то? Что архитектура немолодого проекта вся на подпорках держится? А вы другие варианты встречали, если проекту много лет уже? И что вы будете обсуждать-то? Поймите правильно: на собеседовании нет цели доказать кандидату, что в нашей компании самый плохой индусокод в мире (даже если это реально так). Более того, для вас это может стать открытием, но — в подавляющем большинстве компаний (в т.ч. и крутейших гуглах, санах-ораклах и прочих, о ужас, эпплах!) реальный продакшн код крайне далек от тех абстракций, которые из самых лучших побуждений предлагают в той же "Архитектуре Программного Обеспечения".

_>Всегда есть логичные причины использовать ли RuntimeException или "паттерны" или ещё что-то и если людьми руководит здравый смысл, то они придут к общему решению. Я могу поменять взгляд в конкретном случае, или человек. Если же им руководят религиозные взгляды и "лябоффь" к throw Runtime("blablabla"), независимо ни от чего, то пусть идет любить в другое место, где примут его иррациональные порывы. Или вы под него будете подстраиваться?

Чудесно! Вот и в рамках ответа на вопрос "а что вы СДЕЛАЛИ" можно поговорить "а почему вы сделали именно так" — и от Runtime vs. compile-time, и много еще о чем. Видите ли, нет смысла обсуждать с кандидатом те вещи, которые они никогда "руками не трогал" — в подавляющем большинстве случаев его голова будет забита какой-нибудь красивой абстрактной теорией или отдельными штуками, в реальной работе не всегда нужными. Другое дело если он действительно что-то сделал, — скорее всего, он помнит, почему он так сделал, и может аргументировать. Всегда легко аргументировать свое уже сделанно решение. А аргументировать абстрактную модель — это больше к ораторскому искусству, чем к разработке софта.

_>А откуда это умение оперировать абстракциями появится-то? с потолка чтоли?

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

_>В крайности не стоит впадать, и на небольших конкретных задачах все прекрасно видно, городит ли кандидат 100 абстракций, где они не нужны, и рассуждает ли в стиле фортрана, когда неплохо было бы ввести пару-тройку абстракций.

Это СУБЪЕКТИВНЫЕ критерии. Вы сколько абстракций введете в "задаче о перевороте строки"?
Видите ли, если вы как интервьюер даете задачу кандидату — он не в курсе тараканов в вашей голове. Может, вы большой фанат тех самых абстрактных слоёв, и ожидаете, что кандидат тоже будет их наворачивать. Или, напротив, вы минималист и любитель agile — писать ровно столько кода, сколько нужно прямо сейчас, и рефакторить его тогда, когда это становится необходимо. Короче говоря, вместо обсуждения полезной конкретики вы можете углубиться в субъективные "нравится/не нравится/а вот Фаулер/а вот Александреску". И получить вместо разработчика — очередного академика, мастера манипуляций абстракциями, с околонулевым КПД для проекта.

25.08.2011 19:47, Madruel пишет:

> Наоборот, все делалось в срок, потому что не возникает ситуаций, когда
> пялишься в код с мыслью "WTF?!?", а писавший этот код человек недоступен.
> Любой член команды может сказать, зачем здесь вот эта строчка, что
> позволяет с легкостью перераспределять разработчиков между задачами в
> соответствии с их важностью и срочностью (это также может происходить
> автоматически, без вмешательства руководства).
Учитывая ограниченность памяти обычного человека легко можно прийти к
выводу, что или проект у вас очень маленький (тогда всю эту толпу можно
разогнать и оставить одного человека, не будет потерь времени на
коммуникации) или у вас собрались одни гении (но и в этом случае они
дублируют работу друг друга, соответственно всех, кроме самого
гениального можно тоже уволить).

25.08.2011 21:40, Kolobrodin пишет:

>
> Или когда другой ведущий программист запрещает использовать stl в коде,
> утверждая, что в данной реализации он крайне нестабилен, но при этом сам
> втихомолку делает поиск по std::map обращаясь к элементам через оператор
> [].... А его подчиненным приходится писать собственные списки с
> элементами void*, потому что шаблоны ведущий тоже запретил...
В жутких местах ты работал...

Здравствуйте, Vzhyk, Вы писали:

V>25.08.2011 21:40, Kolobrodin пишет:

>>
>> Или когда другой ведущий программист запрещает использовать stl в коде,
>> утверждая, что в данной реализации он крайне нестабилен, но при этом сам
>> втихомолку делает поиск по std::map обращаясь к элементам через оператор
>> [].... А его подчиненным приходится писать собственные списки с
>> элементами void*, потому что шаблоны ведущий тоже запретил...
V>В жутких местах ты работал...

Угу.
Чугуний спокойнее таскать..

Здравствуйте, michael_isu, Вы писали:

_>Вы объяснить не можете в рамках собеседования, а кандидат должен уметь чтоли все конкретно и подробно рассказать о проектах, а ещё потом и на более конкретные вопросы ответить, да ещё и о нюансах рассказать и о разных решениях, которые были приняты, какие удачные, какие нет и почему?

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

Здравствуйте, mrTwister, Вы писали:

T>Здравствуйте, michael_isu, Вы писали:

_>>Вы объяснить не можете в рамках собеседования, а кандидат должен уметь чтоли все конкретно и подробно рассказать о проектах, а ещё потом и на более конкретные вопросы ответить, да ещё и о нюансах рассказать и о разных решениях, которые были приняты, какие удачные, какие нет и почему?

T>Совершенно верно. Для того, чтобы предложить хорошее решение, требуется быть погруженным в контекст. А для того, чтобы оценить адекватность аргументации этого не требуется.

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

Здравствуйте, Kolobrodin, Вы писали:

K>Здравствуйте, mrTwister, Вы писали:

T>>Здравствуйте, michael_isu, Вы писали:

_>>>Вы объяснить не можете в рамках собеседования, а кандидат должен уметь чтоли все конкретно и подробно рассказать о проектах, а ещё потом и на более конкретные вопросы ответить, да ещё и о нюансах рассказать и о разных решениях, которые были приняты, какие удачные, какие нет и почему?

T>>Совершенно верно. Для того, чтобы предложить хорошее решение, требуется быть погруженным в контекст. А для того, чтобы оценить адекватность аргументации этого не требуется.

K>Чтобы оценить адекватность аргументации, интервьюер должен быть погружен в контекст задач, которые решал кандидат...
Если я спрошу человека как вы решали такую-то проблему то он может ответить:
1. проблемы нет, т.к. ....
2. решали так то и так то
3. эээ, ммм, ну там это, ...

в третьем случае мне понятно, что он вообще не в теме

26.08.2011 8:21, michael_isu пишет:

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

Здравствуйте, Kolobrodin, Вы писали:

K>Чтобы оценить адекватность аргументации, интервьюер должен быть погружен в контекст задач, которые решал кандидат...

Для того, чтобы оценить адекватность аргументации достаточно услышать аргументацию.