Нашел давеча на RSDN. Феерично. Позволю себе скопипастить полностью, дабы иметь перед глазами:
Есть некоторый сорт интервьюеров/контор, которые спрашивают вопрос, обозначенный в заголовке. Что вы сделали в таком-то проекте на прошлой работе? А что конкретно вы сделали? А ещё конкретнее?
Это самый тупой вопрос, который можно задать. Он говорит о том, что интервьюер слабо владеет предметом, о котором идет речь, совершенно не умеет оценивать технический уровень кандидата, и показывает полную невежественность интервьюера.С опытом у человека меняется уровень осознания того, чем он профессионально занимается.
Если ты только джуниор, то ты ещё нихрена не понимаешь, что такое хорошо, а что такое плохо. в голове куча разрозненных книжных знаний и незакрытых гештальтов.
В какой-то момент начинают вырисовываться какие-то представления о дизайне отдельных модулей и небольших приложений, хотя ещё много кривых убеждений касаемо того, как это нужно правильно делать. Тогда человека можно назвать условно обычным средним девелопером.
С течением времени и набитых шишек убеждения и знания начинают выкристаллизовываться, и дизайн отдельных частей приложений делается уже весьма качественно, гибко и т.д. Вырос сеньор.
Потом наступает ясное понимание, что такое хорошо, и что такое плохо. Человек может создавать и продумывать архитектуру больших приложений и делать это хорошо. Архитектор.
И задача интервьюера — выяснить, на каком уровне сознания находится человек. Что он уже понял в законах разработки софта, в его жизненном цикле и вообще в жизни в целом Поэтому вопросы "а что вы сделали там такого-эдакого" нужно просто убрать. После этого больше не остается вопросов кроме как по фичам языка-фреймворка? Значит не нужно собеседовать людей.
Подобными вопросами можно выяснить только то, насколько хорошо человек умеет говорить, а не оценить сложность сделанных задач (и как следствие потом сделать вывод, что такие же задачи человек сможет решать на новом месте). А потом сыплются вопросы сюда же — ой, а почему я облажался с кандидатом, ведь я развесил уши он красиво рассказывал и хорошо себя показал, а реально ничего делать не умеет.Может интервьюеру стоит сначала дорасти до сеньора хотя бы?
Наболело.
Собственно, все написано настолько впечатляюще, что и комментировать особой необходимости нет. Добавлю лишь пару ремарок.
Во-первых, сам автор соль мощного опуса, michael_isu, объявился на RSDN-е в 2008 и активно рассказывал там о своем профессиональном пути – как собрался в Москву, как перебрался и пр. Так вот, у человека опыта профессионального всего-то три года. Я помню каким знающим и высокопрофессиональным я считал себя в том же возрасте. И помню, как смутные сомнения в собственной исключительности у меня стали закрадываться где-то на восьмом году профессиональной деятельности. А нормальным человеком я стал, наверное, лет через 10-12 работы программистом. И это только если я себе не льщу. Так вот, по моему мнению, большинству “молодых специалистов” лучше вообще молчать в тряпочку и ума-разума набираться. Иногда лучше жевать, чем говорить ©
Во-вторых, вопрос этот у меня является вторым по значимости при собеседовании кандидата. Если он не может ответить, то сразу идет лесом. Значит не разработчик перед тобой, а профессиональный пинатель (от “Чем занимаешься? – Хуи пинаю!”). Первым же по значимости на собеседовании у меня является вопрос “А какой своей разработкой вы больше всего гордитесь?” Очень многое можно узнать о человеке, наблюдая за тем, как меняется выражение его глаз, когда он отвечает на него. Точнее, когда у него есть что ответить.
8 комментариев:
Я с ним, в основном, согласен.
Очень понравилось:
"То, что человек решал какие-то задачи, в рамках какого-то проекта, каким-то способом еще не означает, что он их решил правильно или неправильно, и не означает, что он сможет решать новые поставленные перед ним задачи правильно или неправильно. Трактовка решения зависит от опыта интервьюера и принятых в компании практиках. Для кого-то какое-то решение покажется чрезмерно медленным, для кого-то сложным, кто-то решает все волевым решением запретить юзеру что-то делать во время выполнения какой-то функции, так как проблемы с многопоточным приложением. Это не значит, что решение, которое принималось в другой компании неправильное, и что в других условиях в новой компании человек примет такое же решение.
В большинстве случаев вопрос, который озвучивался в начале топика ведет лишь тому, что интервьюер по прошлому опыту человека сделает неправильные выводы о его способностях в будущем решать задачи таким образом, как принято в компании.
"
ИМХО: Любые попытки разбить программистов на градации сенйор-мидл-джуниор идиотичны. В большинстве ситуаций опыт добавляет процентов 30 к ценности программиста, так что ценность балбесов с 10-летним опытом максимум такая же как толкового студента.
Ну и насчёт того что человек который не может рассказать о том чем занимался в проекте как минимум не слишком адекватен я целиком и полностью согласен.
@serger: мне нужно некоторое время, чтобы ответить вам обстоятельно.
@Left:
+1 на счет идиотичности.
Помнится, мне на пальцах объясняли, что в советских КБ означали звания:
программист -- может программировать;
ведущий программист -- может программировать самостоятельно;
главный программист -- можно дать под его начало несколько ведущих программистов.
И никаких других тогда делений (джуниор, сеньер, чиф, архитектор, чиф архитектор, тех лид и пр.) не было. Да и на фиг не нужны были.
@serger:
>В большинстве случаев вопрос, который озвучивался в начале топика ведет лишь тому, что интервьюер по прошлому опыту человека сделает неправильные выводы о его способностях в будущем решать задачи таким образом, как принято в компании.
Начнем с того, что michael_isu в силу своего возраста вряд ли имеет достаточный опыт проведения собеседований в качестве интервьюера чтобы говорить о том, что в большинстве случаев интервьюеры хотят таким вопросом узнать. Поэтому этот абзац 100% попадает под категорию "Отучаемся говорить за всех".
>То, что человек решал какие-то задачи, в рамках какого-то проекта, каким-то способом еще не означает, что он их решил правильно или неправильно, и не означает, что он сможет решать новые поставленные перед ним задачи правильно или неправильно.
Во-первых, вопрос предназначен не для выявления уровня способностей, а для того, чтобы выяснить, какой уровень ответственности возлагался на человека раньше. Т.е. решал ли он действительно хоть что-нибудь. Т.е. считали ли его достаточно ответственным и толковым, чтобы поручить что-либо важное. Или же он только воплощал чужие решения в коде.
Во-вторых, по характеру поручаемых человеку задач можно сделать приблизительные представления о том, к чему он склонен. Например, есть люди, которые и обожают, и способны быстро осваивать новое. Таким поручают освоить инструмент X и помочь научить других. Садить такого человека на сопровождение старого, но важного продукта не имеет смысла. С другой стороны, если есть аккуратный и скрупулезный человек, которы отлично фиксит баги в больших чужих системах, то вовсе не факт, что он сможет столь же успешно писать новый код с использованием самых новых технологий.
В-третьих. Нельзя решать правильно или неправильно. Неправильное решение -- это не решение. Поэтому если человек действительно что-то решал и его решения пошли в готовый продукт, значит этот специалист действительно имеет некоторую ценность. А размер и характер решаемых задач может подсказать величину этой ценности.
> Нельзя решать правильно или неправильно. Неправильное решение -- это не решение.
Имхо, я думаю по-другому.
Считаю, что решение может работать с разной эффективностью ( [0..100%), грубо). Соответственно чтобы её оценить надо приводить несколько решений и комплексно их оценивать. От сюда и куча срача в инете, какая технология правильнее, какая лучше. В разных условиях используют разные решения, и не факт что лучшие...
зы. Возможно всё зависит ещё и от сферы, в которых мы вертимся.
@serger:
Я полностью согласен с тем, что вы говорите. Но дело в том, что это не есть "правильно/неправильно".
Например, есть задача -- обеспечить одновременную работу до 1000 параллельных клиентов. Если она решена, т.е. 1000 клиентов обслуживаются, значит решение было найдено правильно. Неправильное решение -- это когда 1000 не обслуживается.
Правильные (т.е. работающие) решения уже могут оцениваться по целому ряду факторов -- стоимости, сложности, ресурсоемкости, простоте расширения и/или сопровождения и т.д. Причем оценки эти могут сильно меняться со временем.
Но, на мой взгляд, краеугольный камень такой: программа либо работает (значит решение было найдено правильно на данный момент), либо не работает -- значит решение неправильное. И сравнивать правильное решение с неправильным по тем же самым факторам (см. выше) просто не имеет смысла.
Ещё потроллю:
http://tonsky.livejournal.com/241148.html
Отправить комментарий