Нужны толковые программисты в San Francisco Bay Area (.NET)

[Мальчик-Одуванчик]

Если один девелопер не может на пальцах рассказать другому девелоперу, чем он занимался - в 99% нахер он не сдался, такой девелопер. Вы же не доктора наук по ядерной физике интервьюируете...

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

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

А если выясняется что соискатель неизмеримо круче чем то что вам надо?

[fruit6]

А если выясняется что соискатель неизмеримо круче чем то что вам надо?

никто, будуче на зарплате, в здравом рассудке не наймет умнее себя.
в специализированной литературе описано более ста лет назад как.

"расскажите про свои слабые стороны, что делали, как боролись" -- loaded question из области риторики (по сообщениям википедии)

[Boriskin]

А если выясняется что соискатель неизмеримо круче чем то что вам надо?

Overqualified -> thank you, but no, thank you. Так же как нанимать лауреата нобеля на должность лаборанта, приятно, но очень ненадолго. "Это же элементарно, Ватсон!"

[valchkou]

А если выясняется что соискатель неизмеримо круче чем то что вам надо?

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

это 2 разные весчи:
круче то что нам надо, совсем не означает что он умнее меня.
если первое еще может как то произойти по недоразумению,
то вероятность второго, у приветовца, стремится к нулю.

[Мальчик-Одуванчик]

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

[Berlaga]

Если один девелопер не может на пальцах рассказать другому девелоперу, чем он занимался - в 99% нахер он не сдался, такой девелопер. Вы же не доктора наук по ядерной физике интервьюируете...

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

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

Я не очень предствавляю как можно ковыряться, если сам не имеешь экспертных знаний в той же узкой области. Расскажет кандидат о проблемах с оптимизацией сетевого траффика для случая проигрывания видео в системе удаленного доступа (реальный случай). Идею-то я пойму, но чтоб копаться в деталях - увольте!

[Boriskin]

Я не очень предствавляю как можно ковыряться, если сам не имеешь экспертных знаний в той же узкой области. Расскажет кандидат о проблемах с оптимизацией сетевого траффика для случая проигрывания видео в системе удаленного доступа (реальный случай). Идею-то я пойму, но чтоб копаться в деталях - увольте!

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

[Berlaga]

Я не очень предствавляю как можно ковыряться, если сам не имеешь экспертных знаний в той же узкой области. Расскажет кандидат о проблемах с оптимизацией сетевого траффика для случая проигрывания видео в системе удаленного доступа (реальный случай). Идею-то я пойму, но чтоб копаться в деталях - увольте!

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

То есть, довериться ощущениям и догадкам? Нет, мы не будем полагаться на чувства!

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

[Boriskin]

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

[Мальчик-Одуванчик]

Иной раз и хорошая книжка с прорешанными задачками будет получше скромного опыта.

[Berlaga]

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

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

[Berlaga]

Иной раз и хорошая книжка с прорешанными задачками будет получше скромного опыта.

Йеп.

[Мальчик-Одуванчик]

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

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

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

[Berlaga]

Не только STL, а и C++ в целом - просто кладезь "задачек".

Но я все же больше люблю что-нибудь без привязки к ЯП, тем более что С++/STL считаю усложненными, в общем-то, неоправданно. Но это уже оффтоп.

[Boriskin]

Ну все, запинали, но мы не сдаемся, в ответ мы спрашиваем кандидата "А в чем, по вашему, сермяжная правда использования статической виртуальной функции класса в С++?" и получаем удовольствие от любого ответа.