Здравствуйте, michael_isu, Вы писали:
_>Есть некоторый сорт интервьюеров/контор, которые спрашивают вопрос, обозначенный в заголовке. Что вы сделали в таком-то проекте на прошлой работе?
Очень хороший вопрос. Думаю, что задеть он может только того, кто ничего не делал на прошлой работе. Лично я с удовольствием рассказываю, что сделал, что удалось хорошо, а что хотел бы улучшить и почему.
Есть некоторый сорт интервьюеров/контор, которые спрашивают вопрос, обозначенный в заголовке. Что вы сделали в таком-то проекте на прошлой работе? А что конкретно вы сделали? А ещё конкретнее?
Это самый тупой вопрос, который можно задать. Он говорит о том, что интервьюер слабо владеет предметом, о котором идет речь, совершенно не умеет оценивать технический уровень кандидата, и показывает полную невежественность интервьюера.
С опытом у человека меняется уровень осознания того, чем он профессионально занимается.
Если ты только джуниор, то ты ещё нихрена не понимаешь, что такое хорошо, а что такое плохо. в голове куча разрозненных книжных знаний и незакрытых гештальтов.
В какой-то момент начинают вырисовываться какие-то представления о дизайне отдельных модулей и небольших приложений, хотя ещё много кривых убеждений касаемо того, как это нужно правильно делать. Тогда человека можно назвать условно обычным средним девелопером.
С течением времени и набитых шишек убеждения и знания начинают выкристаллизовываться, и дизайн отдельных частей приложений делается уже весьма качественно, гибко и т.д. Вырос сеньор.
Потом наступает ясное понимание, что такое хорошо, и что такое плохо. Человек может создавать и продумывать архитектуру больших приложений и делать это хорошо. Архитектор.
И задача интервьюера — выяснить, на каком уровне сознания находится человек. Что он уже понял в законах разработки софта, в его жизненном цикле и вообще в жизни в целом Поэтому вопросы "а что вы сделали там такого-эдакого" нужно просто убрать. После этого больше не остается вопросов кроме как по фичам языка-фреймворка? Значит не нужно собеседовать людей.
Подобными вопросами можно выяснить только то, насколько хорошо человек умеет говорить, а не оценить сложность сделанных задач (и как следствие потом сделать вывод, что такие же задачи человек сможет решать на новом месте). А потом сыплются вопросы сюда же — ой, а почему я облажался с кандидатом, ведь я развесил уши он красиво рассказывал и хорошо себя показал, а реально ничего делать не умеет.
Может интервьюеру стоит сначала дорасти до сеньора хотя бы?
_>Это самый тупой вопрос, который можно задать. Он говорит о том, что интервьюер слабо владеет предметом, о котором идет речь, совершенно не умеет оценивать технический уровень кандидата, и показывает полную невежественность интервьюера.
Это самый конкретный вопрос. Если человек не в состоянии рассказать, что именно он делал на прошлой работе, то значит он там ничего не делал. Лучше такие вопросы, чем вопросы о крышках канализационных люков.
Здравствуйте, michael_isu, Вы писали:
_>Есть некоторый сорт интервьюеров/контор, которые спрашивают вопрос, обозначенный в заголовке. Что вы сделали в таком-то проекте на прошлой работе? А что конкретно вы сделали? А ещё конкретнее? _>Это самый тупой вопрос, который можно задать.
Нет, это самый важный вопрос. Нормальному работодателю интересно на что вы способны, а не сколько книжек вы прочитали и сколько умных слов впихнули в свое резюме.
Здравствуйте, Kolobrodin, Вы писали:
K>Ок, вопрос: что делали вы? K>Ответ: делал котлету. K>Вопрос: а конкретнее?
ну вот примерный разговор из моего опыта
— что вы делали ?
— я сделал такую-то систему/модуль
— а по конкретнее ?
— а конкретно этот модуль на основе информации из субд формирует то-то и отдает тому то, использовались такие-то технологии и т.д.
дальше идет предметный разговор из которого понятно что человек из себя представляет, это как раз и есть хорошее собеседование
Разговор в стиле "зачем нужно такое-то ключевое слово ?" или "можно ли в конструкторе сделать то-то ?" не говорит о том что человек может реально делать. Матчасть конечно тоже важна, но в без реального опыта ни о чем не говорит.
Здравствуйте, michael_isu, Вы писали:
_>Может интервьюеру стоит сначала дорасти до сеньора хотя бы?
Сеньоры в каждой конторе тоже разные. Сеньор из одной компании может легко оказаться на уровне джуниора из другой компании. И наоборот. И даже системы аттестации не помогают.
Вообще, этот вопрос идет из собеседований на манегеров из управления или продаж, когда желают от манегера услышать что-то типа "я повысил продажи компании на 50%", "после моих предложений снизились издержки на 30%" и тд. Сначала это начали копировать эйчары и агенты, набирающие людей в IT-индустрии, потом, глядя на них, стали и интервьюеры по технической части практиковать. Смысла особого не вижу в этом, так как подвиги на одном месте работы могут оказаться не к месту на другом, особенно, когда это касается переходов из мелкой компании в крупную и наоборот. Выполнять обязанности это не мешает. Да и вообщем-то часто это мимо кассы, так как задающие этот вопрос не понимают, что хотят услышать и какие выводы делать по разным ответам, кроме как покивать.
Про конкретность: в мелких конторах на человеке может висеть много задач, он и архитектором будет, и кодером. В больших конторах человек может сидеть и ждать когда ему свалится тикет на задачу. На выполнение обязанностей на новом месте работы никак не влияет то, что делал человек на старом месте и почему. Кроме того, интервьюер часто не знаком с продуктом, который выпускает компания кандидата, поэтому если человек назовет какую-то функцию из продукта — ему это ни о чем не скажет.
Для аналогии: какой смысл спрашивать столяра, повара, сантехника, медика, учителя, преподавателя вуза, таскателя чугуния, чистильщика сортиров — чего сделал он на предыдущем месте работы? Выполнял свои обязанности, прописанные в документах. Делал работу. А выдавать идеи на гора да подвиги устраивать в случае чужой халатности — это не по закону.. =) ну по крайней мере для простых работяг=) манегеров пинайте сколько хотите))
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, ishare, Вы писали:
I>Здравствуйте, Kolobrodin, Вы писали:
K>>Ведущий программист так сказал делать. Архитектор спроектировал. В ТЗ было так прописано. Сроки сжатые. Надо было сделать заплатку. Нельзя использовать что-то известное и готовое из какого-то фреймворка. Написали простенький велосипед. I>я бы по такому ответу сделал вывод, что либо человек "стоял рядом" или просто врет, либо, скажем так, может только тупо кодить.
Так перед человеком стояли задачи — тупо кодить. Вот он и решил сменить место работы.
I>Не надо считать других глупее себя, в беседе всегда можно понять в чем человек "шарит" и что он реально делал, а в чем — нет.
А после того, как выяснили, что же человек делал на прошлой работе, и как эти знания бесполезны, теперь лучше перейти к той части собеседования, где выясняются его навыки и уровень знаний и знакомство с технологиями (то есть насколько он шарит), и насколько он подходит для решения задач, стоящих в другой компании. И это можно делать без того, чтобы узнавать, что же человек делал конкретно на прошлом месте работы. Честное пионерское, можно!)))
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, bkat, Вы писали:
B>Если ты, делая эти презентации говорил, что слоистая архитектура и т.п. — твоя заслуга, то ты просто врал. B>Будучи юниором ты фиксил баги, пытался понять как работает готовая система и перекладывал это в диаграмки. B>Именно это и надо было отвечать на вопрос "что вы конкретно сделали".
Во-первых, мне врали 80% работодателей касаемо каких-то условий предстоящей работы. Есть аргументы? Врут все и везде, приукрашивают, преподносят, продают себя и т.д.
Во-вторых, причем тут вообще я? Тебе будет легче от осознания того, что я не тот, кого ты ожидал увидеть у себя в команде, потому что сказал "не именно то"? Я уйду, другое место найду, а деньги твоей конторы выкинуты на ветер, сроки ещё больше жмут и уже пахнет жареным.
Вопрос в методах оценки людей, чтобы застраховаться от рассказчиков, которые красиво говорят, но ничего не делают, а не в моей личности, у меня все более чем в порядке.
Здравствуйте, Vzhyk, Вы писали:
V>Ну зачем так жестко? Лучше спросить: "А что делает этот модуль?" "А V>зачем он нужен был?" "А как вы его реализовывали?" "А почему вы V>использовали это и это, а не что-то другое?" ...
Ну я несколько утрирую конечно. Я хотел показать, как при таком подходе собеседование превращается из "типа экзамена" в разговор, по которому можно понять что человек из себя представляет.
25.08.2011 15:43, Kolobrodin пишет:
> Решений много, люди умеют перестраиваться с разных способов работы. > Вопрос тогда сводится к тому, что вы ищете человека, который не смог бы > перестроиться по ваши порядки, а уже работает так, как принято в компании.
Фактически так и есть. Перестроится он или нет — это неизвестно. А вот
то, что он уже сделал известно.
Здравствуйте, SkyDance, Вы писали:
_>>Это самый тупой вопрос, который можно задать.
SD>Если это был развод на флейм — поздравляю, вам удалось создать один из самых эпичнейших срачей. Тема явно для holy wars.
Мне было интересно послушать таких людей, как Kolobrodin, т.к. у него схожие размышления.
SD>Интервью должно проходить без разрывов. Плавно. С чего можно начинать интервью, если о кандидате известно только то, что у него в резюме написано? Я всегда начинал с вопроса "что вам больше всего нравилось на любой вашей предыдущей позиции". Там уж как-то само собой выходил вопрос "и что вы на этой позиции смогли сделать", продолжавшийся "а как вы смогли этого добиться" и "вы упомянули проблемы с MSVC6, в чем конкретно они выражались?"
Вот вы ищете человека на конкретную позицию, который будет работать в определенной среде, с конкретными людьми, с конкретными подчиненными/начальством, делать конкретные задачи. Что мешает предложить ему какие-то кейсы задач из вашей работы? Задизайнить какой-то модуль, определить круг проблем и попросить предложить решения и т.д. Чтобы выяснить насколько человек умеет оперировать абстракциями, моделировать ситуации, каким образом идет ход его мыслей.
И что, что человек что-то делал? Сидел вот какой-то девелопер, насрал написал много кода, делая какой-то модуль, возникали проблемы/непонимание — залез на rsdn, накидали ему решений, воткнул.
Или залез на stackoverflow, нашел там за 2 минуты описание проблем с MSVC6, решил проблему.
Или там дергал серьора, который подкидывал идей.
А потом сидит такой вот девелопер у вас на собеседовании и надувает щеки, какие крутые задачи он делал и какие проблемы решил.
Здравствуйте, 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 абстракций, где они не нужны, и рассуждает ли в стиле фортрана, когда неплохо было бы ввести пару-тройку абстракций.
Поддержу комментаторов выше — это самый главный и правильный вопрос.
Если человек не способен ответить — чем он занимался, значит он либо ничем не занимался, либо так и не понял — чем же он занимался, либо не умеет доносить свою мысль до собеседников.
Хорошими ответами на подобный вопрос являются: "спроектировал систему бронирования авиаперелетов", "разработал дизайн такого-то сайта", "улучшил производительность legacy-системы в полтора раза за счет изменения запросов к БД" ...
Здравствуйте, michael_isu, Вы писали:
_>Если ты только джуниор, то ты ещё нихрена не понимаешь, что такое хорошо, а что такое плохо. в голове куча разрозненных книжных знаний и незакрытых гештальтов.
Ну так сам же видишь — что у джуниора в голове каша, поэтому чётко рассказать о том, что он делал не получится, даже если действительно чем-то полезным занимался. Сеньёр будет видеть систему уже на уровень выше.
То есть получается, что из ответов можно легко понять какого уровня профессионализм человека. Плюс развернутый рассказ о своей работе поможет человеку расслабиться, потом будет легче отвечать на всякие глупые и не глупые вопросы о синтаксисе языка или используемых паттернах.
Здравствуйте, Kolobrodin, Вы писали:
K>Для аналогии: какой смысл спрашивать столяра, повара, сантехника, медика, учителя, преподавателя вуза, таскателя чугуния, чистильщика сортиров — чего сделал он на предыдущем месте работы? Выполнял свои обязанности, прописанные в документах. Делал работу.
Я тебе там почву для размышлений. Тех кто занимается преподаванием спрашивают и ответы бывают примерно такие: "Из 10 моих учеников 8 поступило в МГУ", "Из моих моих студентов 10 уже защищают кандидатскую". Столяров спрашивают, делал он ящики для яблок или кресла из красного дерева. У повара интересуются варил он макароны или готовил лобстеров. И так далее
25.08.2011 8:49, michael_isu пишет:
> Есть некоторый сорт интервьюеров/контор, которые спрашивают вопрос, > обозначенный в заголовке. Что вы сделали в таком-то проекте на прошлой > работе? А что конкретно вы сделали? А ещё конкретнее?
Так что Вы конкретно сделали? Расскажите. Али все больше по митингам, по
митингам. Ну так с таким опытом Вам в думу надо, а не к нам.
> > Наболело.
Лечиться, Вам, батенька надо.
Здравствуйте, michael_isu, Вы писали:
_>Во-первых, мне врали 80% работодателей касаемо каких-то условий предстоящей работы. Есть аргументы? Врут все и везде, приукрашивают, преподносят, продают себя и т.д.
Ну наврал ты и что ? Если не подходишь, то испытательный срок не пройдешь и все, для того он и существует.
25.08.2011 12:30, ishare пишет:
> — что вы делали ? > — я сделал такую-то систему/модуль > — а по конкретнее ?
Ну зачем так жестко? Лучше спросить: "А что делает этот модуль?" "А
зачем он нужен был?" "А как вы его реализовывали?" "А почему вы
использовали это и это, а не что-то другое?" ...
> — а конкретно этот модуль на основе информации из субд формирует то-то и > отдает тому то, использовались такие-то технологии и т.д. > > дальше идет предметный разговор из которого понятно что человек из себя > представляет, это как раз и есть *хорошее собеседование*
Причем еще и учитывается, как человек рассказывает, как он может
представить свою работу, как он формулирует свои мысли и т.д.
25.08.2011 12:42, Kolobrodin пишет:
> > В резюме человек указывает, какие технологии он использовал. Почему > сразу не начать предметный разговор по нужной тематике? Но не совпадение > решаемыех задач на прошлой работе с теми, которые придется решать на > новом месте работы не говорит о том, что человек не сможет их решать.
Обычно исходят из того, что если человек уже сделал вот эту конкретную
вещь неким инструментом, то подобные вещи подобным инструментом он
делать сможет. А вот знание тобой всего моря инструментов и неумение
пользоваться ими неинтересно большинству работодателей.
> Расписывать на бумажке-доске-словами архитектуру конкретного проекта и > конкретных решений — есть разглашение какой-то там тайны. С какой стати, > кандидат должен рассказывать об этом? А по технологиям разговаривать — > пожалуйста, сколько душе угодно. Другое дело, если интервьюер не умеет > завязать разговор.... и ему требуется, чтобы кандидат начал говорить, > чтобы начать цепляться...
Да потому что неинтересно, сколько разных видов топоров ты знаешь.
Интересно, умеешь ли ты применять хоть один из них.
25.08.2011 15:00, Kolobrodin пишет:
> V>Вот только делать работу можно по-разному. Чтобы убедиться в этом, тебе > V>достаточно сесть на табуретку, сделанную плохо. > > Так делал ж. Это ж важно. Но что табуретки делал, выяснили.
Вопрос как ты их делал.
> > V>Извини, но это твоя буйная фантазия. И разбираться в твоих фантазиях я > V>не намерен — это к психологам. > > Толсто.
Ты возможно не поверишь, но я не троллил пока в этой теме.
25.08.2011 19:02, Madruel пишет:
> Интересно, а как следует отвечать на этот вопрос, если работал в команде > со 100% совместным использованием кода? То есть, вчера работал над одним > модулем, сегодня переключился на совершенно иную задачу, а над вчерашним > модулем работает уже другой человек. При такой организации процесса > можно сказать, что сделала команда, но вопрос о том, что сделал > конкретный человек бессмыслен.
При такой организации процесса работающего продукта на выходе не будет
никогда.
Здравствуйте, michael_isu, Вы писали:
_>А вот вопросы по результатам работы можно и задать. Например — есть задача скачать 100 млн. html-страниц из интернета и их каким-то образом обработать. Как это быстрее всего сделать, в какой части тут нужны потоки, а в какой не нужны, как это хранить и т.д. Вот это нормальный вопрос, из которого можно развить интересный разговор.
По результатам какой работы?
Если проект с тобой вместе делали 10 человек (если ты его делал 1 то не может быть вопросов что делал конкретно ты). И вот лично ты в том прокете исключительно проектировал БД и оптимизировал запросы к ней с учетом аххрененного количества параллельных запросов по таблицам нихреновых размеров (интервьювер же не знает как там у вас было все организовано, а — сюрприз — в разных компаниях разработка по-разному организована). И вдруг тебе бац — и предлагают сделать эффектный парсинг 100 млн страниц. Ну и остается рассказывать на РСДН каие все интервьюверы тупые, не смогли телепатически угадать правильный вопрос по проведенной работе, а почему-то стали спрашивать про проведенную работу..
Здравствуйте, michael_isu, Вы писали:
_>Вот вы ищете человека на конкретную позицию, который будет работать в определенной среде, с конкретными людьми, с конкретными подчиненными/начальством, делать конкретные задачи. Что мешает предложить ему какие-то кейсы задач из вашей работы?
Для того, чтобы у соискателя был шанс ответить что-то адекватное, ему надо сначала погружаться в проект месяц-другой.
25.08.2011 19:47, Madruel пишет:
> Наоборот, все делалось в срок, потому что не возникает ситуаций, когда > пялишься в код с мыслью "WTF?!?", а писавший этот код человек недоступен. > Любой член команды может сказать, зачем здесь вот эта строчка, что > позволяет с легкостью перераспределять разработчиков между задачами в > соответствии с их важностью и срочностью (это также может происходить > автоматически, без вмешательства руководства).
Учитывая ограниченность памяти обычного человека легко можно прийти к
выводу, что или проект у вас очень маленький (тогда всю эту толпу можно
разогнать и оставить одного человека, не будет потерь времени на
коммуникации) или у вас собрались одни гении (но и в этом случае они
дублируют работу друг друга, соответственно всех, кроме самого
гениального можно тоже уволить).
Здравствуйте, Kolobrodin, Вы писали:
K>Чтобы оценить адекватность аргументации, интервьюер должен быть погружен в контекст задач, которые решал кандидат...
Для того, чтобы оценить адекватность аргументации достаточно услышать аргументацию.
On 25.08.2011 9:49, michael_isu wrote:
> Есть некоторый сорт интервьюеров/контор, которые спрашивают вопрос, обозначенный > в заголовке. Что вы сделали в таком-то проекте на прошлой работе? А что > конкретно вы сделали? А ещё конкретнее? > Это самый тупой вопрос, который можно задать. Он говорит о том, что интервьюер > слабо владеет предметом, о котором идет речь, совершенно не умеет оценивать > технический уровень кандидата, и показывает полную невежественность интервьюера.
> Может интервьюеру стоит сначала дорасти до сеньора хотя бы? > > Наболело.
Может иногда лучше не искать двойной смысл в вопросах, а просто на него ответить
? Человек хочет узнать, какова была твоя роль в тех проектах,
в которых ты участвовал. Что в этом плохого ?
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, michael_isu, Вы писали:
_>>Если ты только джуниор, то ты ещё нихрена не понимаешь, что такое хорошо, а что такое плохо. в голове куча разрозненных книжных знаний и незакрытых гештальтов.
A>Ну так сам же видишь — что у джуниора в голове каша, поэтому чётко рассказать о том, что он делал не получится, даже если действительно чем-то полезным занимался. Сеньёр будет видеть систему уже на уровень выше.
Откуда такое предположение, что умение презентовать себя зависит от технических навыков? Я например будучи джуниором, участвовал в проекте автоматизации судов, и хотя моя роль в разработке была минимальна — багфиксинг, тестирование, почти ничего нового не сделал, но зато дербанил сеньоров на тему как и чего реализовано, и потом так красиво и складно рассказывал на собеседованиях (слоистая архитектура, workflow, паттерны всякие втыкал к месту, и много других умных слов, что услышал когда-то, а фичи языка в доступной книжке прочитал), что сомнений в квалификации мало у кого возникали и офферы падали как из рога изобилия и на позиции выше. По ходу пьесы народ понимал, что меня ещё надо учить многому, и я сам уже потом догонял то, что сказал, но уже поздно пить боржоми.
A>То есть получается, что из ответов можно легко понять какого уровня профессионализм человека. Плюс развернутый рассказ о своей работе поможет человеку расслабиться, потом будет легче отвечать на всякие глупые и не глупые вопросы о синтаксисе языка или используемых паттернах.
Я допустим о своих проектах рассказывал уже раз 8. И мне совершенно не интересно и не хочется снова делать "развернутый рассказ". Скучно просто.
Здравствуйте, michael_isu, Вы писали:
_>Есть некоторый сорт интервьюеров/контор, которые спрашивают вопрос, обозначенный в заголовке. Что вы сделали в таком-то проекте на прошлой работе? А что конкретно вы сделали? А ещё конкретнее? _>Это самый тупой вопрос, который можно задать. Он говорит о том, что интервьюер слабо владеет предметом, о котором идет речь, совершенно не умеет оценивать технический уровень кандидата, и показывает полную невежественность интервьюера.
Вопрос нормальный... Если вам его задают часто на собеседовании, то это значит, что вы слишком туманно отвечаете на первичный вопрос: "Что сделали в таком-то проекте". А туман с точки зрения работодателя может обозначать или попытку уйти от конкретного ответа (потому как ничего особо не было сделано), либо неспособность описать словами, что было сделано (если что-то действительно было сделано). Копнув чуть глубже вопросом "что конкретно", работодатель в первом случае видит, что человек приукрасил свой вклад, а во втором случае оценивает, может ли претендент пояснить результаты своей работы. Бывает и так, что соискателя, неспособного лаконично пояснить свои результаты всё-таки берут, если из его попыток объяснить очевидно, что да — он это делал и сделал, и может решать такие-то задачи, хотя объясняет всё с трудом. А бывает, что не берут... Способность объяснять важна, если взаимодействие в команде построено на принципе свободного обмена устной информацией по проекту, не ведётся подробной письменной документации, и скорость разработчика Васи на ближайший день может зависеть от того, объяснил ли (смог ли объяснить) ему другой разработчик Петя, который давно в теме, чего да как, как можно сделать, и где слабые места.
_>И задача интервьюера — выяснить, на каком уровне сознания находится человек. Что он уже понял в законах разработки софта, в его жизненном цикле и вообще в жизни в целом
Выяснением таких вещей занимаются обычно кадровики на самом первом интервью с претендентом на вакансию. Чтобы решить, допускать ли претендента на следующее интервью, где будут задавать более конкретные вопросы, или решить, что не стоит отнимать у других людей время...
_>Может интервьюеру стоит сначала дорасти до сеньора хотя бы?
Только с достопочтенными донами разговаривать изволите?
Здравствуйте, michael_isu, Вы писали:
_>Откуда такое предположение, что умение презентовать себя зависит от технических навыков? Я например будучи джуниором, участвовал в проекте автоматизации судов, и хотя моя роль в разработке была минимальна — багфиксинг, тестирование, почти ничего нового не сделал, но зато дербанил сеньоров на тему как и чего реализовано, и потом так красиво и складно рассказывал на собеседованиях (слоистая архитектура, workflow, паттерны всякие втыкал к месту, и много других умных слов, что услышал когда-то, а фичи языка в доступной книжке прочитал), что сомнений в квалификации мало у кого возникали и офферы падали как из рога изобилия и на позиции выше.
Если ты, делая эти презентации говорил, что слоистая архитектура и т.п. — твоя заслуга, то ты просто врал.
Будучи юниором ты фиксил баги, пытался понять как работает готовая система и перекладывал это в диаграмки.
Именно это и надо было отвечать на вопрос "что вы конкретно сделали".
Здравствуйте, michael_isu, Вы писали:
_>Во-первых, мне врали 80% работодателей касаемо каких-то условий предстоящей работы. Есть аргументы? Врут все и везде, приукрашивают, преподносят, продают себя и т.д.
Еще спросят про книжки, которые вы читали. А как начнешь растекаться словом... как они будут кивать с пониманием.. а устроишься на работу — так ткнут в код, который совсем не по книжкам написан...
Когда пытаются узнать, что может человек принести в работу, код, команду, неплохо бы, чтобы адекватно еще оценивали, а что может команда предложить человеку...
Знаю один случай, когда другу прислали отказ со словами "вам у нас будет скучно".. Зато честно.
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, Ytz, Вы писали:
Ytz>Здравствуйте, Kolobrodin, Вы писали:
Ytz>Я тебе там почву для размышлений. Тех кто занимается преподаванием спрашивают и ответы бывают примерно такие: "Из 10 моих учеников 8 поступило в МГУ", "Из моих моих студентов 10 уже защищают кандидатскую". Столяров спрашивают, делал он ящики для яблок или кресла из красного дерева. У повара интересуются варил он макароны или готовил лобстеров. И так далее
У поваров есть диапазон блюд, которые наиболее распространены. Достаточно спросить — вы умеете готовить это и то. Но не будут выяснять — а скажите, а что вы готовили, а конкретнее, а еще конкретнее — о, а вы тут изюминку на вершину торта положили... Проще спросить по списку. Так ведь? Ну, и про наличие санитарной книжки не мешало бы спросить.
Столяра не спросят про ящики для яблок, а плотника про кресла.
Если указан краснодеревщик, то это значит, что человек знаком с тем, как ведут себя ценные породы древесины при разных условиях в течении эксплуатации.
У учителя труда/пения/физкультуры/географии/биологии и тд тоже спросят сколько его учеников поступило в МГУ? У учеников не один наставник, поэтому спрашивать про это бессмысленно — так ведь? =)
Неоконченная мысль всегда казалась Шри Япутре слишком
25.08.2011 9:30, RGB_Dart пишет:
> Хорошими ответами на подобный вопрос являются: "спроектировал систему > бронирования авиаперелетов", "разработал дизайн такого-то сайта", > "улучшил производительность legacy-системы в полтора раза за счет > изменения запросов к БД" ...
И дальше последует еще вопросы: "Так что именно вы сделали?" "Расскажите
дизайн этой системы бронирования ..." "Вот вам ручка, бумажка, доска"
Здравствуйте, michael_isu, Вы писали:
_>Здравствуйте, bkat, Вы писали:
B>>Если ты, делая эти презентации говорил, что слоистая архитектура и т.п. — твоя заслуга, то ты просто врал. B>>Будучи юниором ты фиксил баги, пытался понять как работает готовая система и перекладывал это в диаграмки. B>>Именно это и надо было отвечать на вопрос "что вы конкретно сделали".
_>Во-первых, мне врали 80% работодателей касаемо каких-то условий предстоящей работы. Есть аргументы? Врут все и везде, приукрашивают, преподносят, продают себя и т.д.
Вранье других не оправдывает собственное вранье.
Когда все подряд врут, то естественно всем в итоге фигово и возникают проблемы о которых ты пишешь.
В ситуации когда никто никому не доверяет вообще ничего толком добиться невозможно.
Но поверь мне, не везде так.
_>Во-вторых, причем тут вообще я? Тебе будет легче от осознания того, что я не тот, кого ты ожидал увидеть у себя в команде, потому что сказал "не именно то"? Я уйду, другое место найду, а деньги твоей конторы выкинуты на ветер, сроки ещё больше жмут и уже пахнет жареным.
Ты тут не причем. Ты рассказал о своей ситуации, ее я и прокомменировал.
В той ситуации и вообще в любой другой можно отверить на вопрос "что вы конкретно сделали?".
Более того, правдивые ответы не уменьшают шансов на получение нормальной работы.
А приукрашивание — это на самом деле упор на сильные черты и с откровенным враньем ничего общего не имеет.
_>Вопрос в методах оценки людей, чтобы застраховаться от рассказчиков, которые красиво говорят, но ничего не делают, а не в моей личности, у меня все более чем в порядке.
100% гарантий нету, но общие работающие подходы известны.
Например:
— тестовые задания
— испытательный срок
— звонки на предыдущую работу и рекомендации коллег
— анализ резюме. Если к примеру человек часто меняет работу, то это повод задуматься.
Возможно все нормально, но прямо спросить не мешает.
— Задать на собеседовании вопрос "что вы конкретно сделали" и сравнить и резюме
Если для тебя известные подходы не работают, то ты просто не тот, кто может решать подобные проблемы.
Это не означает, что никто другой с ними не справляется.
25.08.2011 11:22, Kolobrodin пишет:
> Для аналогии: какой смысл спрашивать столяра, повара, сантехника, > медика, учителя, преподавателя вуза, таскателя чугуния, чистильщика > сортиров — чего сделал он на предыдущем месте работы? Выполнял свои > обязанности, прописанные в документах. Делал работу.
Вот только делать работу можно по-разному. Чтобы убедиться в этом, тебе
достаточно сесть на табуретку, сделанную плохо.
Здравствуйте, Kolobrodin, Вы писали:
K>У поваров есть диапазон блюд, которые наиболее распространены. Достаточно спросить — вы умеете готовить это и то. Но не будут выяснять — а скажите, а что вы готовили, а конкретнее, а еще конкретнее — о, а вы тут изюминку на вершину торта положили...
Будут спрашивать. Вот есть к примеру котлета и доложу я тебе большая разница между котлетой в привокзальной забегаловке и хорошем ресторане. Это не очевидно? Сравнить тебе не с чем?
K>Если указан краснодеревщик, то это значит, что человек знаком с тем, как ведут себя ценные породы древесины при разных условиях в течении эксплуатации.
Опять ты не прав. У разных мастеров разное качество. У меня брат занимается дорогими лестницами из хорошего дерева, так вот у него есть ряд секретов из-за которых его лестницы не начинают со временем скрипеть, в отличии от конкурентов.
K>У учителя труда/пения/физкультуры/географии/биологии и тд тоже спросят сколько его учеников поступило в МГУ? У учеников не один наставник, поэтому спрашивать про это бессмысленно — так ведь? =)
Если для поступления нужно сдавать труд/пение/физкультуру/географию/биологию, то конечно спросят. Ты сам найди людей которые детей отправляли к репетитору и поинтересуйся спрашивают это или нет.
Здравствуйте, Vzhyk, Вы писали:
V>25.08.2011 11:22, Kolobrodin пишет:
>> Для аналогии: какой смысл спрашивать столяра, повара, сантехника, >> медика, учителя, преподавателя вуза, таскателя чугуния, чистильщика >> сортиров — чего сделал он на предыдущем месте работы? Выполнял свои >> обязанности, прописанные в документах. Делал работу. V>Вот только делать работу можно по-разному. Чтобы убедиться в этом, тебе V>достаточно сесть на табуретку, сделанную плохо.
А это уже не узнать при помощи вопросов, которые озвучил топикстартер.
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, Ytz, Вы писали:
Ytz>Здравствуйте, Kolobrodin, Вы писали:
K>>У поваров есть диапазон блюд, которые наиболее распространены. Достаточно спросить — вы умеете готовить это и то. Но не будут выяснять — а скажите, а что вы готовили, а конкретнее, а еще конкретнее — о, а вы тут изюминку на вершину торта положили...
Ytz>Будут спрашивать. Вот есть к примеру котлета и доложу я тебе большая разница между котлетой в привокзальной забегаловке и хорошем ресторане. Это не очевидно? Сравнить тебе не с чем?
Ок, вопрос: что делали вы?
Ответ: делал котлету.
Вопрос: а конкретнее?
Что должен нормальный человек ответить на такой вопрос?
Вопрос о том, стоит ли брать повара из забегаловки в дорогой ресторан, решается с помощью других вопросов, а не тех, о которых мы говорим.
K>>Если указан краснодеревщик, то это значит, что человек знаком с тем, как ведут себя ценные породы древесины при разных условиях в течении эксплуатации.
Ytz>Опять ты не прав. У разных мастеров разное качество. У меня брат занимается дорогими лестницами из хорошего дерева, так вот у него есть ряд секретов из-за которых его лестницы не начинают со временем скрипеть, в отличии от конкурентов.
Вопрос брату: что делали вы?
Ответ: делал лестницу из красного дерева.
Вопрос: а конкретнее?
Брат расскажет секреты?
Вопрос другому человеку из конкурирующей организации: что делали вы?
Ответ: делал лестницу из красного дерева.
Вопрос: а конкретнее?
Кого взять?
K>>У учителя труда/пения/физкультуры/географии/биологии и тд тоже спросят сколько его учеников поступило в МГУ? У учеников не один наставник, поэтому спрашивать про это бессмысленно — так ведь? =)
Ytz>Если для поступления нужно сдавать труд/пение/физкультуру/географию/биологию, то конечно спросят. Ты сам найди людей которые детей отправляли к репетитору и поинтересуйся спрашивают это или нет.
И много человек из класса идет на какой-то один конкретный факультет МГУ? Это ни о чем. Знает ли преподаватель, куда после окончания школы ушел выпускник? Уехал в Москву, навсегда. А кем и куда там... да фиг его знает..
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, ishare, Вы писали:
I>Здравствуйте, Kolobrodin, Вы писали:
K>>Ок, вопрос: что делали вы? K>>Ответ: делал котлету. K>>Вопрос: а конкретнее?
I>ну вот примерный разговор из моего опыта
I>- что вы делали ? I>- я сделал такую-то систему/модуль I>- а по конкретнее ? I>- а конкретно этот модуль на основе информации из субд формирует то-то и отдает тому то, использовались такие-то технологии и т.д.
I>дальше идет предметный разговор из которого понятно что человек из себя представляет, это как раз и есть хорошее собеседование
I>Разговор в стиле "зачем нужно такое-то ключевое слово ?" или "можно ли в конструкторе сделать то-то ?" не говорит о том что человек может реально делать. Матчасть конечно тоже важна, но в без реального опыта ни о чем не говорит.
В резюме человек указывает, какие технологии он использовал. Почему сразу не начать предметный разговор по нужной тематике? Но не совпадение решаемыех задач на прошлой работе с теми, которые придется решать на новом месте работы не говорит о том, что человек не сможет их решать. Расписывать на бумажке-доске-словами архитектуру конкретного проекта и конкретных решений — есть разглашение какой-то там тайны. С какой стати, кандидат должен рассказывать об этом? А по технологиям разговаривать — пожалуйста, сколько душе угодно. Другое дело, если интервьюер не умеет завязать разговор.... и ему требуется, чтобы кандидат начал говорить, чтобы начать цепляться...
Неоконченная мысль всегда казалась Шри Япутре слишком
25.08.2011 11:58, Kolobrodin пишет:
> > А это уже не узнать при помощи вопросов, которые озвучил топикстартер.
Да ну. Именно при помощи таких вопросов все и узнается. Очень хорошо
видно, когда человек делал сам и что именно он делал и когда рядом стоял.
V>Вот только делать работу можно по-разному. Чтобы убедиться в этом, тебе V>достаточно сесть на табуретку, сделанную плохо.
V>25.08.2011 11:58, Kolobrodin пишет:
>> >> А это уже не узнать при помощи вопросов, которые озвучил топикстартер. V>Да ну. Именно при помощи таких вопросов все и узнается. Очень хорошо V>видно, когда человек делал сам и что именно он делал и когда рядом стоял.
Так мы про то, стоял ли человек рядом или про то, плохо или хорошо он работал?
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, Kolobrodin, Вы писали:
K>В резюме человек указывает, какие технологии он использовал. Почему сразу не начать предметный разговор по нужной тематике? Но не совпадение решаемыех задач на прошлой работе с теми, которые придется решать на новом месте работы не говорит о том, что человек не сможет их решать. Расписывать на бумажке-доске-словами архитектуру конкретного проекта и конкретных решений — есть разглашение какой-то там тайны. С какой стати, кандидат должен рассказывать об этом? А по технологиям разговаривать — пожалуйста, сколько душе угодно. Другое дело, если интервьюер не умеет завязать разговор.... и ему требуется, чтобы кандидат начал говорить, чтобы начать цепляться...
Вот именно, что по другому разговор завязывать подавляющее большинство интервьюеров не умеет. И минусики ставят потом, уже 14 штук накидали
Например я делал проект автоматизированного продвижения сайтов статьями, аналог sape.ru. Многими местами серое продвижение, но ничего криминального. Но при желании придраться можно. Зачем я об этом буду кому-то рассказывать? Я просто не хочу этого делать. И что, меня из-за этого на работу нельзя брать? смех и грех.
А вот вопросы по результатам работы можно и задать. Например — есть задача скачать 100 млн. html-страниц из интернета и их каким-то образом обработать. Как это быстрее всего сделать, в какой части тут нужны потоки, а в какой не нужны, как это хранить и т.д. Вот это нормальный вопрос, из которого можно развить интересный разговор.
Или например прочекать 100 тыс. сайтов на индексацию в гугле и яндексе, притом что автоматический чек поисковики запрещают, и надо все делать через антикапчу. Сделать так, чтобы можно было безболезненно добавлять другие поисковики и подключать другие сервисы антикапчи, или же несколько аккаунтов с одного сервиса и с каждым при этом работать через прокси-сервера, списки которых тоже поставляют разные источники, причем некоторые из них особо быстрые, но имеют ограничение на кол-во подключений, что надо контролировать.
Просто вот задачи, которую можно обсудить и понять, на каком уровне человек умеет решать задачи. Джуниор ли он, сеньор ли или ещё кто. И другие варианты кейсов придумать. А от простого бла-бла-бла — толку не будет.
25.08.2011 13:01, Kolobrodin пишет:
> > Так мы про то, стоял ли человек рядом или про то, плохо или хорошо он > работал?
А что есть разница между "рядом стоял" и "плохо работал"?
Мне, например, ни тот ни другой и даром не нать.
Здравствуйте, michael_isu, Вы писали:
_>Например я делал проект автоматизированного продвижения сайтов статьями, аналог sape.ru. Многими местами серое продвижение, но ничего криминального. Но при желании придраться можно. Зачем я об этом буду кому-то рассказывать? Я просто не хочу этого делать. И что, меня из-за этого на работу нельзя брать? смех и грех.
Ну я, например, как то собеседовал человека, который делал порносайт, и его потом взял. А если ты не хочешь или не можешь ничего о себе рассказывать, то это сугубо твои проблемы.
Здравствуйте, Kolobrodin, Вы писали:
K>Так мы про то, стоял ли человек рядом или про то, плохо или хорошо он работал?
Если человек просто стоял рядом, то в такой беседе как раз это и выяснится, т.к. если ты задачу на самом деле не решал, то ты не сможешь ответить на вопросы типа "а как вы решили эту проблему ?" или "почему применили то, а не это ?"
Здравствуйте, Vzhyk, Вы писали:
>> >> Так мы про то, стоял ли человек рядом или про то, плохо или хорошо он >> работал? V>А что есть разница между "рядом стоял" и "плохо работал"? V>Мне, например, ни тот ни другой и даром не нать.
Есть разница. Есть люди, которые активно учавствовали в проекте, могут рассказать о проекте и архитектуре (с нарушением тайны), но внутри был код, который потом пришлось выкинуть.
V>Обычно исходят из того, что если человек уже сделал вот эту конкретную V>вещь неким инструментом, то подобные вещи подобным инструментом он V>делать сможет. А вот знание тобой всего моря инструментов и неумение V>пользоваться ими неинтересно большинству работодателей.
V>Да потому что неинтересно, сколько разных видов топоров ты знаешь. V>Интересно, умеешь ли ты применять хоть один из них.
Человек сделал табуретку (то есть вот эту конкретную вещь). Топором (неким инструментом). Рядом не стоял. Умеет применять хоть один топор. Сможет еще раз повторить.
НО:
V>Вот только делать работу можно по-разному. Чтобы убедиться в этом, тебе V>достаточно сесть на табуретку, сделанную плохо.
И выкинуть все табуретки, который этот горе-мастер сделал....
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, ishare, Вы писали:
I>Здравствуйте, Kolobrodin, Вы писали:
K>>Так мы про то, стоял ли человек рядом или про то, плохо или хорошо он работал? I>Если человек просто стоял рядом, то в такой беседе как раз это и выяснится, т.к. если ты задачу на самом деле не решал, то ты не сможешь ответить на вопросы типа "а как вы решили эту проблему ?" или "почему применили то, а не это ?"
Ведущий программист так сказал делать. Архитектор спроектировал. В ТЗ было так прописано. Сроки сжатые. Надо было сделать заплатку. Нельзя использовать что-то известное и готовое из какого-то фреймворка. Написали простенький велосипед.
Это не говорит о том, что человек знает и умеет. Это говорит лишь о том, как они работали на прошлом/текущем месте работы и на это причин может быть тысяча и одна лишь — компетентность и опыт человека.
Неоконченная мысль всегда казалась Шри Япутре слишком
25.08.2011 13:52, Kolobrodin пишет:
> V>А что есть разница между "рядом стоял" и "плохо работал"? > V>Мне, например, ни тот ни другой и даром не нать. > > Есть разница. Есть люди, которые активно учавствовали в проекте, могут > рассказать о проекте и архитектуре (с нарушением тайны), но внутри был > код, который потом пришлось выкинуть.
К чему ты это написал, если вопрос только о том хорошо или плохо работал?
> > > Человек сделал табуретку (то есть вот эту конкретную вещь). Топором > (неким инструментом). Рядом не стоял. Умеет применять хоть один топор. > Сможет еще раз повторить. > > НО: > > И выкинуть все табуретки, который этот горе-мастер сделал....
Вот это и позволит узнать беседа с тобой, какие же все-таки табуретки ты
делал?
25.08.2011 13:59, Kolobrodin пишет:
> > Ведущий программист так сказал делать. Архитектор спроектировал. В ТЗ > было так прописано. Сроки сжатые. Надо было сделать заплатку. Нельзя > использовать что-то известное и готовое из какого-то фреймворка. > Написали простенький велосипед.
Ну вот. Теперь расскажите нам про вами написанный велосипед. Какие вы
видите плюсы и минусы этого велосипеда?
Ну и еще, ваша оценка данного решения? было ли по вашему мнению другое
решение? И т.д.
Ну и такой маленький нюансик, вы уже выложили — вы достаточно
исполнительны (хотя несколько уточняющих вопросов я бы еще задал). Есть
море людей, которые будут делать по своему и не слушать начальников, с
такими много головной боли.
Здравствуйте, Vzhyk, Вы писали:
V>25.08.2011 13:52, Kolobrodin пишет:
>> V>А что есть разница между "рядом стоял" и "плохо работал"? >> V>Мне, например, ни тот ни другой и даром не нать. >> >> Есть разница. Есть люди, которые активно учавствовали в проекте, могут >> рассказать о проекте и архитектуре (с нарушением тайны), но внутри был >> код, который потом пришлось выкинуть. V>К чему ты это написал, если вопрос только о том хорошо или плохо работал?
Вопрос о том, что факт участия человека в проекте не дает достаточных и необходимых аргументов, чтобы сделать выводы о его профпригодности и способности делать качественный продукт.
V>Вот это и позволит узнать беседа с тобой, какие же все-таки табуретки ты V>делал?
— Здравствуйте, я по объявлению о вакансии мастера по табуреткам. Я мастер по табуреткам.
— Здравствуйте, а что вы делали на прошлой работе?
— Делал табуретки.
— А конкретнее?
— Табуретки из дерева.
— А еще конкретнее?
— Омуменные табуретки, должен вам сказать, делал.
— А еще сможете делать?
— Конечно смогу.
— Вы нам подходите.
А табуретки потом выкинуть придется все равно...
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, Vzhyk, Вы писали:
V>25.08.2011 13:59, Kolobrodin пишет:
>> >> Ведущий программист так сказал делать. Архитектор спроектировал. В ТЗ >> было так прописано. Сроки сжатые. Надо было сделать заплатку. Нельзя >> использовать что-то известное и готовое из какого-то фреймворка. >> Написали простенький велосипед.
V>Ну вот. Теперь расскажите нам про вами написанный велосипед.
С какой стати? Следующие вопросы на этом заканчиваются, хотя должны закончится еще на том, что разглашать детали проекта нельзя.
V> Какие вы видите плюсы и минусы этого велосипеда? V>Ну и еще, ваша оценка данного решения? было ли по вашему мнению другое V>решение? И т.д.
Вопрос кандидата может быть такой:
А расскажите, какие технологии применяете вы? Какие уникальные решения были сделаны в ходе проекта? Какие плюсы и минусы? Как вы относитесь к каким-то решениям своего руководства? Это запатентованные решения? Как обходите проблемы? Ни один интервьюер на это не ответит. Зачем требовать то, что не можешь сделать сам?
V>Ну и такой маленький нюансик, вы уже выложили — вы достаточно V>исполнительны (хотя несколько уточняющих вопросов я бы еще задал). Есть V>море людей, которые будут делать по своему и не слушать начальников, с V>такими много головной боли.
После озвученных проблем перед высшим руководством, ведущий был уволен, архитектор смещен, тем, кто подписывал ТЗ дали по шее.
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, Kolobrodin, Вы писали:
K>Ведущий программист так сказал делать. Архитектор спроектировал. В ТЗ было так прописано. Сроки сжатые. Надо было сделать заплатку. Нельзя использовать что-то известное и готовое из какого-то фреймворка. Написали простенький велосипед.
я бы по такому ответу сделал вывод, что либо человек "стоял рядом" или просто врет, либо, скажем так, может только тупо кодить. Не надо считать других глупее себя, в беседе всегда можно понять в чем человек "шарит" и что он реально делал, а в чем — нет.
Здравствуйте, Vzhyk, Вы писали:
V>Ну вот. Теперь расскажите нам про вами написанный велосипед. Какие вы V>видите плюсы и минусы этого велосипеда? V>Ну и еще, ваша оценка данного решения? было ли по вашему мнению другое V>решение? И т.д.
Как-то собеседовался в контору терралинк. Чувак очень настойчиво задавал вопрос "а конкретно?". Чуть ли не через один вопрос, и потом сокрушался, что я отвечаю абстрактно.
Когда попросил потом рассказать конкретно о задачах, которые предстоит решить в ближайшем будущем человеку — просто замялся и ничего не ответил конкретного вообще. Ну типа там у нас одна большая система документооборота для большого заказчика на основе какой-то нашего решения, в рамках тех. заданий будут ставиться задачи и бла-бла, о задачах так и не раскололся. Но как любил вопрос "а конкретно?!"
25.08.2011 14:09, Kolobrodin пишет:
> > Вопрос о том, что факт участия человека в проекте не дает достаточных и > необходимых аргументов, чтобы сделать выводы о его профпригодности и > способности делать качественный продукт.
Тебе это мы и пытаемся объяснить. Не важен факт твоего участия, важно,
что именно ты сам делал.
> > V>Вот это и позволит узнать беседа с тобой, какие же все-таки табуретки ты > V>делал? > > — Здравствуйте, я по объявлению о вакансии мастера по табуреткам. Я > мастер по табуреткам. > — Здравствуйте, а что вы делали на прошлой работе? > — Делал табуретки. > — А конкретнее? > — Табуретки из дерева. > — А еще конкретнее? > — Омуменные табуретки, должен вам сказать, делал. > — А еще сможете делать? > — Конечно смогу. > — Вы нам подходите.
Извини, но это твоя буйная фантазия. И разбираться в твоих фантазиях я
не намерен — это к психологам.
Здравствуйте, Kolobrodin, Вы писали:
K>Здравствуйте, ishare, Вы писали:
I>>Здравствуйте, Kolobrodin, Вы писали:
K>>>Ведущий программист так сказал делать. Архитектор спроектировал. В ТЗ было так прописано. Сроки сжатые. Надо было сделать заплатку. Нельзя использовать что-то известное и готовое из какого-то фреймворка. Написали простенький велосипед. I>>я бы по такому ответу сделал вывод, что либо человек "стоял рядом" или просто врет, либо, скажем так, может только тупо кодить.
K>Так перед человеком стояли задачи — тупо кодить. Вот он и решил сменить место работы.
Ну вот он и есть тупой кодер, для того чтобы это выяснить и задавался вопрос.
K>А после того, как выяснили, что же человек делал на прошлой работе, и как эти знания бесполезны, теперь лучше перейти к той части собеседования, где выясняются его навыки и уровень знаний и знакомство с технологиями (то есть насколько он шарит), и насколько он подходит для решения задач, стоящих в другой компании. И это можно делать без того, чтобы узнавать, что же человек делал конкретно на прошлом месте работы. Честное пионерское, можно!)))
Ты правда не понимаешь разницы между книжными знаниями и реальным опытом ?
25.08.2011 14:16, Kolobrodin пишет:
> > V>Ну вот. Теперь расскажите нам про вами написанный велосипед. > С какой стати? Следующие вопросы на этом заканчиваются, хотя должны > закончится еще на том, что разглашать детали проекта нельзя.
Во-первых, это даже не смешно про неразглашение в случае твоего велосипеда.
В данном абзаце слишком много моментов ты озвучил, чтобы тебя не брать,
вне зависимости от твоей квалификации.
> > V> Какие вы видите плюсы и минусы этого велосипеда? > V>Ну и еще, ваша оценка данного решения? было ли по вашему мнению другое > V>решение? И т.д. > > Вопрос кандидата может быть такой: > А расскажите, какие технологии применяете вы?
Вот на этот без проблем.
> Какие уникальные решения > были сделаны в ходе проекта? Какие плюсы и минусы? Как вы относитесь к > каким-то решениям своего руководства? Это запатентованные решения? Как > обходите проблемы? Ни один интервьюер на это не ответит. Зачем требовать > то, что не можешь сделать сам?
Что даст тебе ответ на эти вопросы?
> > V>Ну и такой маленький нюансик, вы уже выложили — вы достаточно > V>исполнительны (хотя несколько уточняющих вопросов я бы еще задал). Есть > V>море людей, которые будут делать по своему и не слушать начальников, с > V>такими много головной боли. > > После озвученных проблем перед высшим руководством, ведущий был уволен, > архитектор смещен, тем, кто подписывал ТЗ дали по шее.
И что?
V>Тебе это мы и пытаемся объяснить. Не важен факт твоего участия, важно, V>что именно ты сам делал.
V>Да ну. Именно при помощи таких вопросов все и узнается. Очень хорошо V>видно, когда человек делал сам и что именно он делал и когда рядом стоял.
И что видно то? Что табуретки человек делал? Так у него в резюме написано, что делал.
Ну, делал человек табуретки. Именно сам, и именно табуретки.
А как же:
V>Вот только делать работу можно по-разному. Чтобы убедиться в этом, тебе V>достаточно сесть на табуретку, сделанную плохо.
Так делал ж. Это ж важно. Но что табуретки делал, выяснили.
V>Извини, но это твоя буйная фантазия. И разбираться в твоих фантазиях я V>не намерен — это к психологам.
Толсто.
Неоконченная мысль всегда казалась Шри Япутре слишком
25.08.2011 14:41, Kolobrodin пишет:
> > Так перед человеком стояли задачи — тупо кодить. Вот он и решил сменить > место работы.
Не бывает таких задач.
> > А после того, как выяснили, что же человек делал на прошлой работе, и > как эти знания бесполезны, теперь лучше перейти к той части > собеседования, где выясняются его навыки и уровень знаний и знакомство с > технологиями (то есть насколько он шарит), и насколько он подходит для > решения задач, стоящих в другой компании. И это можно делать без того, > чтобы узнавать, что же человек делал конкретно на прошлом месте работы.
Он не подходит, потому как уже есть уверенность, что до сих пор он
ничего не делал (вне зависимости от его знаний и времени пребывания на
конторах).
Здравствуйте, ishare, Вы писали:
K>>Так перед человеком стояли задачи — тупо кодить. Вот он и решил сменить место работы.
I>Ну вот он и есть тупой кодер, для того чтобы это выяснить и задавался вопрос.
Совершенно неправильный вывод.
Может он умеет новые парадигмы программирования и алгоритмы придумывать... и вообще — эксперт по языку... Есть тут такие личности. Полет мысли еще тот, а вот к тупым кодерам себя не относит, хотя на прошлом месте работы выполнял рутинные действия, не требующий особой мозговой деятельности.
I>Ты правда не понимаешь разницы между книжными знаниями и реальным опытом ?
Понимаю. И что?
То, что человек решал какие-то задачи, в рамках какого-то проекта, каким-то способом еще не означает, что он их решил правильно или неправильно, и не означает, что он сможет решать новые поставленные перед ним задачи правильно или неправильно. Трактовка решения зависит от опыта интервьюера и принятых в компании практиках. Для кого-то какое-то решение покажется чрезмерно медленным, для кого-то сложным, кто-то решает все волевым решением запретить юзеру что-то делать во время выполнения какой-то функции, так как проблемы с многопоточным приложением. Это не значит, что решение, которое принималось в другой компании неправильное, и что в других условиях в новой компании человек примет такое же решение.
В большинстве случаев вопрос, который озвучивался в начале топика ведет лишь тому, что интервьюер по прошлому опыту человека сделает неправильные выводы о его способностях в будущем решать задачи таким образом, как принято в компании.
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, Vzhyk, Вы писали:
V>25.08.2011 14:41, Kolobrodin пишет:
>> >> Так перед человеком стояли задачи — тупо кодить. Вот он и решил сменить >> место работы. V>Не бывает таких задач.
Бывают.
Вообще, мы тут в тупик зашли в споре. Наверное, надо прекращать уже. Каждый со своей точкой зрения. К согласию не пришли. Наверное, этот вопрос относится к той же теме, что и полезность тестовых заданий. =)
Неоконченная мысль всегда казалась Шри Япутре слишком
25.08.2011 15:31, Kolobrodin пишет:
> > Может он умеет новые парадигмы программирования и алгоритмы > придумывать... и вообще — эксперт по языку... Есть тут такие личности. > Полет мысли еще тот, а вот к тупым кодерам себя не относит, хотя на > прошлом месте работы выполнял рутинные действия, не требующий особой > мозговой деятельности.
Это ты Доктора помянул или про себя рассказываешь?
> > В большинстве случаев вопрос, который озвучивался в начале топика ведет > лишь тому, что интервьюер по прошлому опыту человека сделает > неправильные выводы о его способностях в будущем решать задачи таким > образом, как принято в компании.
Именно правильные. Пусть ты хоть сам Энштейн, но мы не разрабатываем
теорию относительности, мы решаем более простые и скромные задачи,
которые нужны людям сейчас. И нам нужно их решать качественно и в срок и
так, как принято у нас в компании. Вот это мы и пытаемся у тебя
выяснить, подходишь ли ты нам.
Здравствуйте, Kolobrodin, Вы писали:
K>Здравствуйте, ishare, Вы писали:
K>>>Так перед человеком стояли задачи — тупо кодить. Вот он и решил сменить место работы.
I>>Ну вот он и есть тупой кодер, для того чтобы это выяснить и задавался вопрос.
K>Совершенно неправильный вывод.
Нет, правильный. Просто он тебе не нравится.
K>Может он умеет новые парадигмы программирования и алгоритмы придумывать... и вообще — эксперт по языку...
Ага. Он все умеет, только опыта такого у него нет
I>>Ты правда не понимаешь разницы между книжными знаниями и реальным опытом ?
K>Понимаю. И что?
K>В большинстве случаев вопрос, который озвучивался в начале топика ведет лишь тому, что интервьюер по прошлому опыту человека сделает неправильные выводы о его способностях в будущем решать задачи таким образом, как принято в компании.
Никто не может сделать вывод о том на что человек способен по интервью. Это невозможно. Но на основании разговора о прошлом опыте понятно, что он уже делал и, соответственно, делать может точно. Анекдот про "виртуально" и "реально" знаешь ?
Здравствуйте, Kolobrodin, Вы писали:
K>Вообще, мы тут в тупик зашли в споре. Наверное, надо прекращать уже. Каждый со своей точкой зрения. К согласию не пришли. Наверное, этот вопрос относится к той же теме, что и полезность тестовых заданий. =)
Ты вообще людей собеседовал ? На работу принимал ?
Здравствуйте, Vzhyk, Вы писали:
V>25.08.2011 15:31, Kolobrodin пишет:
>> >> Может он умеет новые парадигмы программирования и алгоритмы >> придумывать... и вообще — эксперт по языку... Есть тут такие личности. >> Полет мысли еще тот, а вот к тупым кодерам себя не относит, хотя на >> прошлом месте работы выполнял рутинные действия, не требующий особой >> мозговой деятельности. V>Это ты Доктора помянул или про себя рассказываешь?
дохтура... он по графику видно сегодня чугуний ворочает... не слышно его, а то прибежал бы уже...
V>Именно правильные. Пусть ты хоть сам Энштейн, но мы не разрабатываем V>теорию относительности, мы решаем более простые и скромные задачи, V>которые нужны людям сейчас. И нам нужно их решать качественно и в срок и V>так, как принято у нас в компании. Вот это мы и пытаемся у тебя V>выяснить, подходишь ли ты нам.
Решений много, люди умеют перестраиваться с разных способов работы. Вопрос тогда сводится к тому, что вы ищете человека, который не смог бы перестроиться по ваши порядки, а уже работает так, как принято в компании.
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, ishare, Вы писали:
K>>Совершенно неправильный вывод. I>Нет, правильный. Просто он тебе не нравится.
Просто был опыт работы с одним типом... ведущим и тимлидом... к нему применялись методы, которые вы описываете и он удачно прошел собеседование. И также накосячил. Только поняли это также не после испытательного срока, а спустя год...
K>>Может он умеет новые парадигмы программирования и алгоритмы придумывать... и вообще — эксперт по языку... I>Ага. Он все умеет, только опыта такого у него нет
я на собеседование его пригласил бы ради интереса)))
I>Никто не может сделать вывод о том на что человек способен по интервью. Это невозможно. Но на основании разговора о прошлом опыте понятно, что он уже делал и, соответственно, делать может точно. Анекдот про "виртуально" и "реально" знаешь ?
Жги.
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, Kolobrodin, Вы писали:
K>Здравствуйте, ishare, Вы писали:
I>>Ты вообще людей собеседовал ? На работу принимал ?
K>Да, собеседовал, а на работу принимает отдел кадров.
Просто какой то однобокий взгляд на проблему у тебя.
Вовочка подходит к папе:
— Папа, а что такое “ВИРТУАЛЬНО“ и “РЕАЛЬНО“?
— Так, ну вот смотри! — И отец обращается к 15-тилетней дочке:
— Света, ты бы за 2000 баксов дала Эдику, сыну моего друга?
— Конечно, дала бы!
— Хорошо. — И обращаясь к жене: — Эй, Маня, ты бы моему корешу за 2000 баксов дала бы?
— Легко! Только бабки давай!!
— Хорошо. — И к тестю: — Эй, Михал Петрович, ты бы Борису Моисееву за 2000 бакинских дал бы?
— Ясный перец! Только бабки вперёд!!
— Ну вот, Вовочка: ВИРТУАЛЬНО у нас 6000 баксов, а РЕАЛЬНО — две шлюхи и один старый педераст!..
Здравствуйте, Vzhyk, Вы писали:
V>25.08.2011 9:30, RGB_Dart пишет:
>> Хорошими ответами на подобный вопрос являются: "спроектировал систему >> бронирования авиаперелетов", "разработал дизайн такого-то сайта", >> "улучшил производительность legacy-системы в полтора раза за счет >> изменения запросов к БД" ... V>И дальше последует еще вопросы: "Так что именно вы сделали?" "Расскажите V>дизайн этой системы бронирования ..." "Вот вам ручка, бумажка, доска"
Так ведь это же прекрасно! Можно рассказать про дизайн системы, почему сделали так или иначе, какие были проблемы, как решались. Можно рассказать, что спустя полгода пришлось там-то и там-то сильно переделывать, а вот этот вот кусок оказался супер-гибким и легко подстраивался под меняющиеся требования. Рассказать про архитектурные подходы, посудачить о кривых фреймворках, в которых пришлось дыры латать костылями...
Это всяко интересней, чем обсуждать чему равно i++ + ++i.
И то, с каким "огоньком" кандидат рассказывает о том, чем он занимался, можно понять — насколько его вообще привлекает то, что он делал на прошлом месте .
25.08.2011 17:02, RGB_Dart пишет:
> > Так ведь это же прекрасно! Можно рассказать про дизайн системы, почему > сделали так или иначе, какие были проблемы, как решались. Можно > рассказать, что спустя полгода пришлось там-то и там-то сильно > переделывать, а вот этот вот кусок оказался супер-гибким и легко > подстраивался под меняющиеся требования. Рассказать про архитектурные > подходы, посудачить о кривых фреймворках, в которых пришлось дыры латать > костылями... > Это всяко интересней, чем обсуждать чему равно i++ + ++i. > И то, с каким "огоньком" кандидат рассказывает о том, чем он занимался, > можно понять — насколько его вообще привлекает то, что он делал на > прошлом месте .
Именно. Вот посему мне и непонятно, что не нравиться Колобродину и ТС в
данном подходе.
Здравствуйте, Vzhyk, Вы писали:
V>25.08.2011 17:02, RGB_Dart пишет:
>> >> Так ведь это же прекрасно! Можно рассказать про дизайн системы, почему >> сделали так или иначе, какие были проблемы, как решались. Можно >> рассказать, что спустя полгода пришлось там-то и там-то сильно >> переделывать, а вот этот вот кусок оказался супер-гибким и легко >> подстраивался под меняющиеся требования. Рассказать про архитектурные >> подходы, посудачить о кривых фреймворках, в которых пришлось дыры латать >> костылями... >> Это всяко интересней, чем обсуждать чему равно i++ + ++i. >> И то, с каким "огоньком" кандидат рассказывает о том, чем он занимался, >> можно понять — насколько его вообще привлекает то, что он делал на >> прошлом месте . V>Именно. Вот посему мне и непонятно, что не нравиться Колобродину и ТС в V>данном подходе.
=) Рассказ левому человек про дизайн системы и описание решений в другой компании.
Неоконченная мысль всегда казалась Шри Япутре слишком
25.08.2011 17:27, Kolobrodin пишет:
> > =) Рассказ левому человек про дизайн системы и описание решений в другой > компании.
Ну скажи интервьюеру, что если я тебе расскажу, то мне придется тебя
застрелить.
Как человек, который говорил no hire всегда, когда кандидан не мог внятно объяснить что именно он сделал, отвечу:
* Непонятен смысл брать человека, который не показал что умеет делать delivery, если можно взять того кто это умеет. Не просто работать над фичей/модулем X, а _сделать_ фичу/модуль X. Обычно это означает что реализована не только какая-нибудь (может быть отвороченная) логика, которой было интересно заниматься, но и пофикшены куча мелких багов и сделаны вещи, которыми, может быть, было не очень интересно заниматься. Поверьте, есть очень умные и много знающие программисты с нулевым выхлопом, которым слишком интересно _решать_ задачу, нежели _решить_ ее.
* Без понимания того что человек _сделал_ непонятно что он делал вообще: объем реализованной им функциональности, решенные им проблемы и timeframe.
* Я понимаю что не всем компаниям это нужно. Например если хорошо поставлен майкроменеджмент, спецификации очень формальны и штаты раздуты (что IMHO часто идет рука об руку), то компания обычно имеет ресурсы на то чтобы заставлять народ делать delivery нужного качества в нужном темпе. Еще в компании могут быть совсем research-like long shot проекты с первыми майлстоунами через год, которые запускаюся, на них тратятся ресурсы, потом эти проекты умирают.
Здравствуйте, RGB_Dart, Вы писали:
RGB>Поддержу комментаторов выше — это самый главный и правильный вопрос. RGB>Если человек не способен ответить — чем он занимался, значит он либо ничем не занимался, либо так и не понял — чем же он занимался, либо не умеет доносить свою мысль до собеседников. RGB>Хорошими ответами на подобный вопрос являются: "спроектировал систему бронирования авиаперелетов", "разработал дизайн такого-то сайта", "улучшил производительность legacy-системы в полтора раза за счет изменения запросов к БД" ...
Интересно, а как следует отвечать на этот вопрос, если работал в команде со 100% совместным использованием кода? То есть, вчера работал над одним модулем, сегодня переключился на совершенно иную задачу, а над вчерашним модулем работает уже другой человек. При такой организации процесса можно сказать, что сделала команда, но вопрос о том, что сделал конкретный человек бессмыслен.
Здравствуйте, Madruel, Вы писали:
M>Интересно, а как следует отвечать на этот вопрос, если работал в команде со 100% совместным использованием кода? То есть, вчера работал над одним модулем, сегодня переключился на совершенно иную задачу, а над вчерашним модулем работает уже другой человек. При такой организации процесса можно сказать, что сделала команда, но вопрос о том, что сделал конкретный человек бессмыслен.
Ну так и рассказать, в чем проблемы?
Дальше скорее всего будут уточняющие вопросы.
Этот вопрос главным образом служит базой для других вопросов.
Здравствуйте, Vzhyk, Вы писали:
V>25.08.2011 19:02, Madruel пишет:
V>При такой организации процесса работающего продукта на выходе не будет V>никогда.
Наоборот, все делалось в срок, потому что не возникает ситуаций, когда пялишься в код с мыслью "WTF?!?", а писавший этот код человек недоступен.
Любой член команды может сказать, зачем здесь вот эта строчка, что позволяет с легкостью перераспределять разработчиков между задачами в соответствии с их важностью и срочностью (это также может происходить автоматически, без вмешательства руководства).
Разумеется, это работает только при условии постоянного эффективного обмена информацией внутри команды (что вряд ли реализуемо для больших команд).
Здравствуйте, Kolobrodin, Вы писали:
I>>Разговор в стиле "зачем нужно такое-то ключевое слово ?" или "можно ли в конструкторе сделать то-то ?" не говорит о том что человек может реально делать. Матчасть конечно тоже важна, но в без реального опыта ни о чем не говорит.
K>В резюме человек указывает, какие технологии он использовал. Почему сразу не начать предметный разговор по нужной тематике?
Для плодотворного разговора о технологиях требуется контекст, на роль которого отлично подходит описание предыдущих проектов. На примере их можно обсудить, почему использовались именно эти технологие, а не другие, что было сделано правильно, а что нет, с какими трудностями столкнулся, какие могли быть альтернативные решения и т.д.
После такого разговора хорошо видно, что из себя представляет соискатель. Толи он просто нахватался базвордов из википедии, толи он действительно понимает то, о чем написал в резюме. Становится понятно, врал ли соискатель в резюме, или нет.
Здравствуйте, Kolobrodin, Вы писали:
K>Вопрос кандидата может быть такой: K>А расскажите, какие технологии применяете вы? Какие уникальные решения были сделаны в ходе проекта? Какие плюсы и минусы? Как вы относитесь к каким-то решениям своего руководства? Это запатентованные решения? Как обходите проблемы? Ни один интервьюер на это не ответит.
Здравствуйте, ishare, Вы писали:
I>Просто какой то однобокий взгляд на проблему у тебя.
У меня мало требований, но это достаточно высокие требования. Впрочем, речь тут не обо мне.
Здравствуйте, RGB_Dart, Вы писали:
RGB>Так ведь это же прекрасно! Можно рассказать про дизайн системы, почему сделали так или иначе, какие были проблемы, как решались. Можно рассказать, что спустя полгода пришлось там-то и там-то сильно переделывать, а вот этот вот кусок оказался супер-гибким и легко подстраивался под меняющиеся требования. Рассказать про архитектурные подходы, посудачить о кривых фреймворках, в которых пришлось дыры латать костылями... RGB>Это всяко интересней, чем обсуждать чему равно i++ + ++i.
Когда вижу в коде, как ведущий (даже уже не старший) программист с "огоньком" в глазах пишет:
int arr[20];
// double y, z прилетают издалека и их разница может быть отрицательной ))
size_t x = y - z;
if (x < 0) x = 0;
return arr[x];
Или когда другой ведущий программист запрещает использовать stl в коде, утверждая, что в данной реализации он крайне нестабилен, но при этом сам втихомолку делает поиск по std::map обращаясь к элементам через оператор [].... А его подчиненным приходится писать собственные списки с элементами void*, потому что шаблоны ведущий тоже запретил...
то я начинаю думаю, что обсудить i++ + ++i гораздо правильнее, чем начинать с технологий... до них, вероятнее всего, и не дойдет.... Но именно эти ведущие будут в своих компаниях проводить собеседования.
RGB>И то, с каким "огоньком" кандидат рассказывает о том, чем он занимался, можно понять — насколько его вообще привлекает то, что он делал на прошлом месте .
От того, что человеку привлекательно то, что он делал на прошлом месте ни холодно ни жарко, особенно, если он решил сменить это место Или вы только про вчерашних студентов?
Здравствуйте, Vzhyk, Вы писали:
V>Ну скажи интервьюеру, что если я тебе расскажу, то мне придется тебя застрелить.
Я, пожалуй, воздержусь от вашего совета, тем более я его не спрашивал... Это если я правильно понял, кто кому и что должен сказать....
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, mrTwister, Вы писали:
T>Для плодотворного разговора о технологиях требуется контекст, на роль которого отлично подходит описание предыдущих проектов. На примере их можно обсудить, почему использовались именно эти технологие, а не другие, что было сделано правильно, а что нет, с какими трудностями столкнулся, какие могли быть альтернативные решения и т.д. T>После такого разговора хорошо видно, что из себя представляет соискатель. Толи он просто нахватался базвордов из википедии, толи он действительно понимает то, о чем написал в резюме. Становится понятно, врал ли соискатель в резюме, или нет.
Если технолог Кока-колы придет на собеседование в Пепси-колу, то будет ли он рассказывать, какие проблемы были у Кока-колы и как он их решил?
Или инженер BMW на собеседование в Mersedes.
Неоконченная мысль всегда казалась Шри Япутре слишком
Здравствуйте, Kolobrodin, Вы писали:
K>Если технолог Кока-колы придет на собеседование в Пепси-колу, то будет ли он рассказывать, какие проблемы были у Кока-колы и как он их решил? K>Или инженер BMW на собеседование в Mersedes.
Мне, честно говоря, нет дела до технолога Кока-колы и инженера BMW.
K>* Я понимаю что не всем компаниям это нужно. Например если хорошо поставлен майкроменеджмент, спецификации очень формальны и штаты раздуты (что IMHO часто идет рука об руку), то компания обычно имеет ресурсы на то чтобы заставлять народ делать delivery нужного качества в нужном темпе.
майкроменеджмент говоришь?
Ты наверное свой инглиш импрувиш?
P.S. Кстати, а как правильно писать, инглишь или инглиш?
Если это был развод на флейм — поздравляю, вам удалось создать один из самых эпичнейших срачей. Тема явно для holy wars.
Но если вы это серьезно, то... вы заблуждаетесь. Если человек может рассказать сначала в общих чертах, затем с упором вот на те и эти детали — и может сделать это так, что даже непосвященному интервьюеру будет достаточно — значит, проблем с коммуникациями не возникнет.
Этот вопрос нужен не для того, чтобы узнать, насколько крут кандидат (это будет выясняться дальше, в технических вопросах). А нужен он для того, чтобы узнать — способен ли кандидат общаться и объяснять, что он сделал. "Секреты" конкурентов никого не интересуют. Почему "секреты" в кавычках? Да потому, что все эти "секреты" вроде кошмарного спагетти-кода или безумных идей менеджерского состава о "мотивации" сотрудников не только ни для кого не являются секретами, но и банально неприменимы к новой компании. Любые "супер-идеи" тоже ерунда — не идеи нужны, а бизнес-планы, чего, разумеется, разрабочтик предоставить не может.
Так вот. Я, на основании рассказанного кандидатом, обычно выбирал один или несколько технических "затравочных" вопросов. Т.е. если кандидат взахлеб рассказывал про мета-программирование и чудеса boost::mpl, технический вопрос обычно касался чего-нибудь вроде реализации тех самых шаблонов и разнице компиляторов. Если были рассказы про супер-чудесную архитектуру, тогда поднимались вопросы наследования-включения-проксирования и связанные с этим особенности.
Интервью должно проходить без разрывов. Плавно. С чего можно начинать интервью, если о кандидате известно только то, что у него в резюме написано? Я всегда начинал с вопроса "что вам больше всего нравилось на любой вашей предыдущей позиции". Там уж как-то само собой выходил вопрос "и что вы на этой позиции смогли сделать", продолжавшийся "а как вы смогли этого добиться" и "вы упомянули проблемы с MSVC6, в чем конкретно они выражались?"
Допускаю существование совершенно другого типа интервью (сам году в 2004 так был "проинтервьюирован" в Акронисе) — когда на входе получаешь 20-страничную распечатку с ужасным кодом на С с классами (право дело, не С++ же это был!) и дополнительными вопросами вида "что из перечисленного не является контейнером STL — queue, vector, list, map, ...". Но, честно сказать, мне претит такой вариант.
Здравствуйте, michael_isu, Вы писали:
_>Есть некоторый сорт интервьюеров/контор, которые спрашивают вопрос, обозначенный в заголовке. Что вы сделали в таком-то проекте на прошлой работе? А что конкретно вы сделали? А ещё конкретнее? _>Это самый тупой вопрос, который можно задать.
Ничего тупого
Я и сам ТАКИЕ ВОПРОСЫ задаю
Здравствуйте, RGB_Dart, Вы писали:
RGB>Если человек не способен ответить — чем он занимался, значит он либо ничем не занимался
Ну блин, сказал как отрезал. Все такие телепаты и провидцы, нафига вообще интервью? Может просто по фотке определять способности и будющий успех в компании.
Здравствуйте, Kolobrodin, Вы писали:
K>Здравствуйте, mrTwister, Вы писали:
T>>Мне, честно говоря, нет дела до технолога Кока-колы и инженера BMW.
K>Работодателю кандидата тоже, с какого перепугу кто-то интересуется, как и кто что-то делал в проекте...
Здравствуйте, michael_isu, Вы писали:
_>А потом сидит такой вот девелопер у вас на собеседовании и надувает щеки, какие крутые задачи он делал и какие проблемы решил.
Щеки очень быстро сдуваются после дополнительных вопросов.
_> Что мешает предложить ему какие-то кейсы задач из вашей работы?
Как правило, специфичность решаемых задач. Ну и иногда большая кодовая база со всяким индусо-легаси.
_> Задизайнить какой-то модуль, определить круг проблем и попросить предложить решения и т.д.
В рамках собеседования? Это такой прикол, что ли? Чтобы что-то "задизайнить", сначала надо въехать в предметную область. Потом посмотреть, [del]что было украдено до нас[/del] существующие решения задач такого рода (ибо будем честнЫ — в 99% случаев "новое" решение является велосипедом с колесами сомнительных конфигураций). Не, конечно, если это собеседование в пару-тройку дней длиной — наверное, можно и так, но многие ли согласятся?
_> Чтобы выяснить насколько человек умеет оперировать абстракциями, моделировать ситуации, каким образом идет ход его мыслей.
И что вы из этого узнаете? Ну есть у него ход мыслей. Скажем, отличный от вашего хода. Что теперь? Отказывать кандидату? У него другие предпочтения в дизайне. Он читал другие книжки, и, например, аргументированно не любит "паттерны проектирования". Или, скажем, у него любовь к throw RuntimeException("Meaningful error message"), а вы обожатель throw specifications.
Самое печальное, что человек может складно и красиво говорить, умело оперировать абстракциями, моделировать ситуации, но... когда доходит до реально дела, почему-то, с кодом как-то не складывается (напоминаю, ищем _девелопера_, а не засирателя мозгов).
_>И что, что человек что-то делал?
Дык потому и задают вопрос — что СДЕЛАЛ! Эта единственная буковка "с" меняет всё
_>Или залез на stackoverflow, нашел там за 2 минуты описание проблем с MSVC6, решил проблему. _>Или там дергал серьора, который подкидывал идей. _>А потом сидит такой вот девелопер у вас на собеседовании и надувает щеки, какие крутые задачи он делал и какие проблемы решил.
Супер! Отлично! Берем!!!
По крайней мере в Австралии (и в значительной части западного мира) ценится именно умение _сделать_. Т.е. решить проблему. Никого не парит, спросил он у умных дяденек, или почитал rsdn. Или погуглил. Или по-stack-overflow-ил. Важно, что он проблему решил!
Некоторые разработчики, почему-то, вместо решения задач предпочитают заниматься фаллометрией — кто больше умных книжек прочитал, кто знает больше багов в реализации gcc 4.0.x, кто умнее оперирует абстракциями. Но это нафиг не нужно ни тимлидам, ни работодателям — никому.
PS: если сейчас вы затронете "проблему индусокода" (когда задачу решил, но поддерживать решение решительно невозможно) — я сразу скажу: эта проблема никак не устраняется "умелыми абстракциями" и прочим буллщитом. Более того, разгребать сто слоёв "умелых абстракций" в большинстве случаев куда сложнее и дольше, чем копи-паст очередного Кумара.
Здравствуйте, Доктор ТуамОсес, Вы писали:
ДТ>Здравствуйте, michael_isu, Вы писали:
_>>Есть некоторый сорт интервьюеров/контор, которые спрашивают вопрос, обозначенный в заголовке. Что вы сделали в таком-то проекте на прошлой работе? А что конкретно вы сделали? А ещё конкретнее? _>>Это самый тупой вопрос, который можно задать. ДТ>Ничего тупого ДТ>Я и сам ТАКИЕ ВОПРОСЫ задаю
Дохтур, нам вас не хватало. Расскажите о том, как вы ходили на собеседования
Неоконченная мысль всегда казалась Шри Япутре слишком
_>Что там такого прям специфичного, что нельзя некоторую небольшую часть доступно объяснить?
Что вы будете объяснять-то? Что архитектура немолодого проекта вся на подпорках держится? А вы другие варианты встречали, если проекту много лет уже? И что вы будете обсуждать-то? Поймите правильно: на собеседовании нет цели доказать кандидату, что в нашей компании самый плохой индусокод в мире (даже если это реально так). Более того, для вас это может стать открытием, но — в подавляющем большинстве компаний (в т.ч. и крутейших гуглах, санах-ораклах и прочих, о ужас, эпплах!) реальный продакшн код крайне далек от тех абстракций, которые из самых лучших побуждений предлагают в той же "Архитектуре Программного Обеспечения".
_>Всегда есть логичные причины использовать ли RuntimeException или "паттерны" или ещё что-то и если людьми руководит здравый смысл, то они придут к общему решению. Я могу поменять взгляд в конкретном случае, или человек. Если же им руководят религиозные взгляды и "лябоффь" к throw Runtime("blablabla"), независимо ни от чего, то пусть идет любить в другое место, где примут его иррациональные порывы. Или вы под него будете подстраиваться?
Чудесно! Вот и в рамках ответа на вопрос "а что вы СДЕЛАЛИ" можно поговорить "а почему вы сделали именно так" — и от Runtime vs. compile-time, и много еще о чем. Видите ли, нет смысла обсуждать с кандидатом те вещи, которые они никогда "руками не трогал" — в подавляющем большинстве случаев его голова будет забита какой-нибудь красивой абстрактной теорией или отдельными штуками, в реальной работе не всегда нужными. Другое дело если он действительно что-то сделал, — скорее всего, он помнит, почему он так сделал, и может аргументировать. Всегда легко аргументировать свое уже сделанно решение. А аргументировать абстрактную модель — это больше к ораторскому искусству, чем к разработке софта.
_>А откуда это умение оперировать абстракциями появится-то? с потолка чтоли?
Как откуда? Из книжек, форумов, дебатов и прочих подобных источников. Что, кстати, тоже отличный индикатор. Если человек не может рассказать, что он _сделал_, но при этом чудесно оперирует абстрациями — значит, вместо работы он упражнялся в оперировании абстракциями. Если нам нужен оператор абстракциями, наверное, это хороший кандидат. Но это хлебные должности, на них "люди с улицы" не приходят никогда. Я же собеседовал разработчиков. Которые должны уметь сделать, а не поговорить про абстракции.
_>В крайности не стоит впадать, и на небольших конкретных задачах все прекрасно видно, городит ли кандидат 100 абстракций, где они не нужны, и рассуждает ли в стиле фортрана, когда неплохо было бы ввести пару-тройку абстракций.
Это СУБЪЕКТИВНЫЕ критерии. Вы сколько абстракций введете в "задаче о перевороте строки"?
Видите ли, если вы как интервьюер даете задачу кандидату — он не в курсе тараканов в вашей голове. Может, вы большой фанат тех самых абстрактных слоёв, и ожидаете, что кандидат тоже будет их наворачивать. Или, напротив, вы минималист и любитель agile — писать ровно столько кода, сколько нужно прямо сейчас, и рефакторить его тогда, когда это становится необходимо. Короче говоря, вместо обсуждения полезной конкретики вы можете углубиться в субъективные "нравится/не нравится/а вот Фаулер/а вот Александреску". И получить вместо разработчика — очередного академика, мастера манипуляций абстракциями, с околонулевым КПД для проекта.
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 абстракций, где они не нужны, и > рассуждает ли в стиле фортрана, когда неплохо было бы ввести пару-тройку > абстракций.
Ну, и не говори, например "переворот строки".
Специфичностью его прошлой работы не получится захлебнуться? И кодовой базой индусо-легаси сверху 
в большинстве случаев куда сложнее и дольше, чем копи-паст очередного Кумара.
я на собеседование его пригласил бы ради интереса)))
