День добрый. На деле, много из нас страшно ругается на то, как проводят собеседования. И хотелось бы обсудить, а как оно в идеале должно проходить, какие вопросы нужно задавать, и на основании чего определять, подойдет кандидат или нет?
Для начала свой вариант. Предположу, что собеседуется достаточно опытный разработчик. Итак:

Вначале рассказать о проекте, рассказать, чем занимаемся, немного об архитектуре, рассказать о текущих и будущих задачах. Рассказать, кого ищем, зачем ищем, какие позиции рассматриваем, и далее перейти к вопросам.
И самый первый вопрос кандидату:
Предположим вы на моем месте. Какие бы вопросы вы задали мне, как кандидату, чтобы определить мою квалификацию. ИМХО это очень много скажет об уровне кандидата. На часть вопросов предложить кандидату ответить самому, на некоторые вопросы просто спросить, а почему это важно, и какие ваши действия, если кандидат говорит не то, что ожидаете.

Далее, если таких вопросов не было, начать задавать свои вопросы
1) Какие языки программирования, кроме того, что требуется, вы знаете или знали. Почему вы выбрали именно текущий язык? Какие языки можно было бы выбрать для задач нашего проекта (именно для этого рассказывалось вначале о проекте). Какие достоинства, недостатки данного языка.
2) Про какие конкурирующие технологии вы знаете (или имели с ними дело). В чем, на ваш взгляд, достоинства, недостатки определенной технологии, какие потенциальные проблемы можно получить?
3) Ваши сильные и слабые стороны. Какие качества вы хотите развивать? Здесь после ответа попытаться проверить слова кандидата. Если кандидат не указал те сильные стороны, которые вы хотите услышать, попробовать проверить, действительно ли это так, возможно кандидат излишне требователен к себе.
4) Показать кандидату код рабочего проекта. Спросить что он об этом думает об этом коде. Показать индусский код, если ему не понравится, спросить как бы он его переписал. Далее показать свой код или код крутого разработчика. Рассказать о задаче, которую он решал. Спросить, что он думает об этом коде, какие улучшения он может предложить. Дать время ему на рефакторинг. И, в случае, если кандидат код, которым ты гордишься, переписывает гораздо лучше, сходу предлагает новые идеи – тогда брать не раздумывая.
5) Рассказать о текущей задаче в проекте. Попросить кандидата высказать идеи, как бы эти задачи решил он. Сказать свое решение, попробовать с ним поспорить, чье решение лучше.
6) Вопросов может быть достаточно много. Собственно при собеседовании стараться не завалить кандидата, а выявить его сильные стороны. И думать, можно ли это будет применить в текущем проекте, будут ли сильные стороны кандидата полезны, и можно ли будет мириться со слабыми сторонами, то есть впишется ли человек в команду.

Так вот, хотелось бы спросить у общественности, а чем плох тот подход, который я сейчас предложил? Почему никогда, ни на одном собеседовании ни чего подобное не практикуется? Или я неправ, и кто-то подобный подход практикует? Если да, скажите в каких кампаниях?

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

E>День добрый. На деле, много из нас страшно ругается на то, как проводят собеседования. И хотелось бы обсудить, а как оно в идеале должно проходить

Безотносительно остально, полагаю, что секс с HR-кой в туалете, определенно, должен присутсвовать в составе "идеального собеседования"!

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

Хм, не знал что мыщъх писать под раздными никами тут.

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

E>Так вот, хотелось бы спросить у общественности, а чем плох тот подход, который я сейчас предложил? Почему никогда, ни на одном собеседовании ни чего подобное не практикуется?

потому что то что ты написал очень сложно. поставь в свою схему средних собеседующих и собеседуемого — и что —
"картинка оживает" или с трудом?

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

E>Для начала свой вариант. Предположу, что собеседуется достаточно опытный разработчик. Итак:
Это предположение сделано на основании резюме? Или вы знаете про него что то больше. Не всегда резюме соответствует человеку

Интервью ограничено по времени, предположим 1-1.5 часа.

E>Вначале рассказать о проекте, рассказать, чем занимаемся, немного об архитектуре, рассказать о текущих и будущих задачах. Рассказать, кого ищем, зачем ищем, какие позиции рассматриваем, и далее перейти к вопросам.

10-15 минут, ну вполне пойдёт за приветсвие. Правда не всегда можно расказать, про проект. Если контора большая то при собеседовании не известсно в какой отдел человек пойдёт. Но влюбом случае, что то расказать да и нужно.

E>И самый первый вопрос кандидату:
E>Предположим вы на моем месте. Какие бы вопросы вы задали мне, как кандидату, чтобы определить мою квалификацию. ИМХО это очень много скажет об уровне кандидата. На часть вопросов предложить кандидату ответить самому, на некоторые вопросы просто спросить, а почему это важно, и какие ваши действия, если кандидат говорит не то, что ожидаете.

Это покажет умеет ли человек проводить интервью (если у него подобный опыт), но не как не оценит его как программиста, кроме того может поставить в ступор даже хорошого девелопера и будет вам стоять 10 мин. (и того 20)

E>1) Какие языки программирования, кроме того, что требуется, вы знаете или знали. Почему вы выбрали именно текущий язык? Какие языки можно было бы выбрать для задач нашего проекта (именно для этого рассказывалось вначале о проекте). Какие достоинства, недостатки данного языка.

Эрудированость это хорошо особенно если она нужна в проекте, но я бы не задвал этот вопрос в начале. Интервью это стресс и человек устаёт. По этому в начале лучше заставлять его думать. Беседы на общие темы лучше отложить на потом. 10 мин (и того 30)

E>2) Про какие конкурирующие технологии вы знаете (или имели с ними дело). В чем, на ваш взгляд, достоинства, недостатки определенной технологии, какие потенциальные проблемы можно получить?

Вопрос прикольный, но не уверен какие это даст сделать выводы. Уж сильно наложит отпечаток умение красиво говорить. 10 мин (и того 40)

E>3) Ваши сильные и слабые стороны. Какие качества вы хотите развивать? Здесь после ответа попытаться проверить слова кандидата. Если кандидат не указал те сильные стороны, которые вы хотите услышать, попробовать проверить, действительно ли это так, возможно кандидат излишне требователен к себе.

Вы интервью проводите один? или перед вами были Эйчары? если да, то они небось уже достали его этими сторонами. (и того 50) Да и так ли вам это важно, что селовек считает полит корректным ответом? Вы психолог? или просто хотите поиграть в игру кто лучше соврёт?

E>4) Показать кандидату код рабочего проекта. Спросить что он об этом думает об этом коде. Показать индусский код, если ему не понравится, спросить как бы он его переписал. Далее показать свой код или код крутого разработчика. Рассказать о задаче, которую он решал. Спросить, что он думает об этом коде, какие улучшения он может предложить. Дать время ему на рефакторинг. И, в случае, если кандидат код, которым ты гордишься, переписывает гораздо лучше, сходу предлагает новые идеи – тогда брать не раздумывая.

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

+ нужен комп (это не проблема, но об этом тоже нужно обзаботится)

30 мин (и того 1 час 20 мин)

E>5) Рассказать о текущей задаче в проекте. Попросить кандидата высказать идеи, как бы эти задачи решил он. Сказать свое решение, попробовать с ним поспорить, чье решение лучше.

Хороший вопрос. Но по времени пора закругляться и ответ может выйти скомканый.

Интервью вообще штука осень субъективное, а ваше мне кажется слишком.
Кроме того когда вы увидите что человек вам не подходит? как вы закончите интервью?

Я проводил интервью следующим образом (интервью для синьёра и джуниора сильно отличается, это пример для мидла-синьёра):
Перед моим интервью с ним уже общались Эйчары и расказали всё о компании и спросили всё про сильные стороны.
Мне не говорят своего мнения (хотя и очень хотят) Эйчары, я беру резюме кладу текстом в низ (я почитаю его потом, пока оно не должно влиять на первое впечатление).

1. Представляюсь, расказываю о то как ведётся разработка, какие есть продукты немного о том что в нутри. Пугаю горой кривого кода (весь этот заученый спич занимает 7 минут)
2. Прошу человека расказать немного о себе о том чем занимался, где работал. Если нужно проверить английский, то прошу расказать на английском (через пару минут, сообщаю что можно перейти на русский) (это занимает порядка 5 минут и даёт возможность оценить как человек вообще говорит пока всё просто и ему расслабится и привыкнуть ко мне.) (и того 12 мин)
3. прошу расказать про неуспешный проект, причины неудачи и что бы вы сделали сейчас. Вопрос интересный, многие говорят что все успешные были (5 мин) (и того 17)
4. говорю что нам очень важно знание С++ и не против ли кандидат начать именно с этого, а потом вернуться к общим вопросам. (насколько я помню никто не отказывался)
4.1 прошу оценить свое знание языка. (вот и тест на самоцоенку)
4.2 выбрать любую тему из языка которую кандидат знает хуже всего и обещаю по ней не задвать вопросы (тут важно маштаб (если человек скажет ADL поиск — это круто, если исключения то так себе)
4.3 задаю быстро по паре вопросов в куждую тему вопосы типа (зачем нужен виртуальный деструктор. можно ли бросать исключения из конструктора/деструктора...)
4.4 несколько вопросов по СТЛ: сем пользовались. оценки сложности по контейнерам.
возможно мы прекратим общение на этом этапе. (это занимает 15 мин. и того 32 мин)
5. прошу написать каую то небольшую задачку (в основном алгоритмика) в это время читаю резюме. Затем обсуждаем код, оценки сложности, граничные случаи. (15 мин и того 47)
6. даю задачку на подумать, это те которые из общей соображалки. (это спорный вопрос, но мне нравится считаю это важным) если не идёт то по прерываю через мин 5. если нормально то в 15 мин вкладываемся.
7. тыкаю в слово из резюме (особенно хорошо если есть то чего не знаю) и прошу расказать как для человека не умеющего программировать. (5 мин)

где то на этом этапе уже есть устойчивое мнение. Но если что то ещё есть:
8. предложите дизайн для ...
9. поговорим про языки, про технологиии вообщем.

Есть ли вопросы? Отвечаю на всё что спросят.
И того те 1.5 часа.

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

IS>потому что то что ты написал очень сложно. поставь в свою схему средних собеседующих и собеседуемого — и что —
IS>"картинка оживает" или с трудом?
Если брать средних собеседующих (то есть тех, кто знает только один язык, знает неплохо, прочитал довольно много книжек именно по этому языку, на все другое смотреть не хочет, считает глупостью — есть только одно правильное решение, а кто с ним не согласен, тот недостойный кандидат. Волей судьбы ему удалось поработать на проектах определенной направленности, и его повысили в результате — у кого опыт был другой, и кто решал задачи по другому — тот недостойный кандидат), то тут да, не оживает. Но может проблема в том, что собеседуют не те люди, а не в самих вопросах? Или те, кто может на основании таких вопросов определить уровень кандидата в принципе не способны занять достаточно высокую должность? ТИХО достаточно просто собеседовать по такой схеме, никаких проблем не вижу.

Относительно средних собеседуемых — я подразумевал, что собеседуются на опытного разработчика, соответственно опытному разработчику вполне комфортно было бы проходить данное собеседование, разве нет? Естественно среднему студенту или джуниору такие вопросы задавать бессмысленно, студентов можно и по старинке. Да и средний собеседуемый не может пройти собеседование, так как на одну вакансию человек 100 претендует, зачем на средних равняться?

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

IS>>потому что то что ты написал очень сложно. поставь в свою схему средних собеседующих и собеседуемого — и что —
IS>>"картинка оживает" или с трудом?
E>Если брать средних собеседующих (то есть тех, кто знает только один язык, знает неплохо, прочитал довольно много книжек именно по этому языку, на все другое смотреть не хочет, считает глупостью — есть только одно правильное решение, а кто с ним не согласен, тот недостойный кандидат. Волей судьбы ему удалось поработать на проектах определенной направленности, и его повысили в результате — у кого опыт был другой, и кто решал задачи по другому — тот недостойный кандидат), то тут да, не оживает. Но может проблема в том, что собеседуют не те люди, а не в самих вопросах? Или те, кто может на основании таких вопросов определить уровень кандидата в принципе не способны занять достаточно высокую должность? ТИХО достаточно просто собеседовать по такой схеме, никаких проблем не вижу.

может быть собеседуют не те люди, но есть ли выбор? нужна система под имеющихся людей.

E>Относительно средних собеседуемых — я подразумевал, что собеседуются на опытного разработчика, соответственно опытному разработчику вполне комфортно было бы проходить данное собеседование, разве нет? Естественно среднему студенту или джуниору такие вопросы задавать бессмысленно, студентов можно и по старинке. Да и средний собеседуемый не может пройти собеседование, так как на одну вакансию человек 100 претендует, зачем на средних равняться?

ага — а где остальные 100 работают — дворниками что ли ? или что среди программистов unemployment rate 99%?

я не говорил о опытности собеседуемых или собеседующих — я говорил о том чтобы система работала хорошо она должна быть нацелена на среднего собеседуемого (т.е. среднего senior dev — если собеседемуй sen dev) и на среднего собеседуюшего (средний TeamLead, HR, Lead Dev — ну кто там еще обычно сидит на собеседованиях).

ну вот первый вопрос твой:

>Какие бы вопросы вы задали мне, как кандидату, чтобы определить мою квалификацию?

ну что на такое можно услышать — или прикол или булшит. зачем это нужно?

>Ваши сильные и слабые стороны. Какие качества вы хотите развивать?

скажут только то что ты хочешь услышать.

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

E>Далее, если таких вопросов не было, начать задавать свои вопросы
E>1) Какие языки программирования, кроме того, что требуется, вы знаете или знали. Почему вы выбрали именно текущий язык? Какие языки можно было бы выбрать для задач нашего проекта (именно для этого рассказывалось вначале о проекте). Какие достоинства, недостатки данного языка.
Если проект уже начат, то это обсуждение бессмысленно. Даже если кандидат великолепно знает Java, а проект уже начат на PHP никто ничего менять не будет (во-первых потому что остальные разработчики на проекте Java не знают, а во вторых потому что на разработку уже потрачены ресурсы).

E>2) Про какие конкурирующие технологии вы знаете (или имели с ними дело). В чем, на ваш взгляд, достоинства, недостатки определенной технологии, какие потенциальные проблемы можно получить?
Аналогично пункту 1, хотя, да здесь есть некоторые возможности.

E>3) Ваши сильные и слабые стороны. Какие качества вы хотите развивать? Здесь после ответа попытаться проверить слова кандидата. Если кандидат не указал те сильные стороны, которые вы хотите услышать, попробовать проверить, действительно ли это так, возможно кандидат излишне требователен к себе.
Хороший вопрос, почему-то очень часто оказывается, что человек ошибается

E>4) Показать кандидату код рабочего проекта. Спросить что он об этом думает об этом коде. Показать индусский код, если ему не понравится, спросить как бы он его переписал. Далее показать свой код или код крутого разработчика. Рассказать о задаче, которую он решал. Спросить, что он думает об этом коде, какие улучшения он может предложить. Дать время ему на рефакторинг. И, в случае, если кандидат код, которым ты гордишься, переписывает гораздо лучше, сходу предлагает новые идеи – тогда брать не раздумывая.
Это достаточно долго, а оценка качества кода вещь очень относительная. Хотя конечно этот вопрос покажет многое, если конечно кандидат вообще с первого взгляда въедет в кусок кода.

E>5) Рассказать о текущей задаче в проекте. Попросить кандидата высказать идеи, как бы эти задачи решил он. Сказать свое решение, попробовать с ним поспорить, чье решение лучше.


E>6) Вопросов может быть достаточно много. Собственно при собеседовании стараться не завалить кандидата, а выявить его сильные стороны. И думать, можно ли это будет применить в текущем проекте, будут ли сильные стороны кандидата полезны, и можно ли будет мириться со слабыми сторонами, то есть впишется ли человек в команду.
Полностью согласен.


E>Так вот, хотелось бы спросить у общественности, а чем плох тот подход, который я сейчас предложил? Почему никогда, ни на одном собеседовании ни чего подобное не практикуется? Или я неправ, и кто-то подобный подход практикует? Если да, скажите в каких кампаниях?
Собственно все очень просто, такое собеседование занимает много времени, а надо ведь узнать уровень знаний кандидата.

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

E>>Для начала свой вариант. Предположу, что собеседуется достаточно опытный разработчик. Итак:
eaa>Это предположение сделано на основании резюме? Или вы знаете про него что то больше. Не всегда резюме соответствует человеку
Есть вакансия, есть требования к вакансии, надо взять именно опытного разработчика. Тек как человек пришел на эту вакансию, считаем что он ей соответствует.

eaa>10-15 минут, ну вполне пойдёт за приветсвие. Правда не всегда можно расказать, про проект. Если контора большая то при собеседовании не известсно в какой отдел человек пойдёт. Но влюбом случае, что то расказать да и нужно.
Вот это крайне плохо. Раз нельзя рассказать что за проект, то нельзя и определить какие требования предъявлять, непонятно что первостепенно, а что что нет. Соответственно кандидат не факт что захочет работать на этом проекте. И также не факт, что если человек пройдет собеседование, его порекомендуют на определенный проект, то он подойдет к этому проекту. Увы, я хорошо знаю, как составляется описание проекта и требования к нему, часто ничего общего с реальностью нет. Собеседовать должен тот, кто за этот проект отвечает (это архитектор или тех лид, а не тот, кто контролирует выполнение задачь, никогда не видевший кода проекта, или уже давно забывший все это)

eaa>Это покажет умеет ли человек проводить интервью (если у него подобный опыт), но не как не оценит его как программиста, кроме того может поставить в ступор даже хорошого девелопера и будет вам стоять 10 мин. (и того 20)
Поставит в ступор — ничего страшного, пойдем по своим вопросам. Если не поставит в ступор — это даст кандидату возможность указать на свои сильные стороны, даст достаточно много информации о кандидате. Часть из этих 10 минут возможно сэкономится потом, так как на этом этапе возможно кандидат задаст тот же вопрос, что задал бы и ты. Это просто возможность для кандидата хорошо себя показать, очень хорошо бы ему эту возможность предоставить.

eaa>Эрудированость это хорошо особенно если она нужна в проекте, но я бы не задвал этот вопрос в начале. Интервью это стресс и человек устаёт. По этому в начале лучше заставлять его думать. Беседы на общие темы лучше отложить на потом. 10 мин (и того 30)
Не следует ожидать очень длинного монолога. Стараться надо, чтобы кандидат отвечал покороче, задавать некоторые уточныящие вопросы. Это снова даст информацию о кандидате, какие вопросы ему лучше задавать, какие нет. И еще, если человек пришел с утра, то как раз перед напряжением мозгов надо его маленько размять. Если вечером, то он уже уставший в любом случае — может непривычными для него головоломками его стараться не мучить вообще, и постараться, чтобы на собеседовании проверять именно то, что он каждый день использует в работе? Если пытаться проверять квалификацию на похожих задачах, которые требуются каждый день, ответ будет на автомате.

E>>2) Про какие конкурирующие технологии вы знаете (или имели с ними дело). В чем, на ваш взгляд, достоинства, недостатки определенной технологии, какие потенциальные проблемы можно получить?
eaa>Вопрос прикольный, но не уверен какие это даст сделать выводы. Уж сильно наложит отпечаток умение красиво говорить. 10 мин (и того 40)
10 минут как-то многовато, подробно то ответить сходу на вопрос достаточно тяжело. А кратко если ответит (хотя бы перечислит) — покажет эрудированность, большой плюс. Снова как в предыдущем случае — не следует ожидать развернутого подготовленного монолога, хорошо, если это будет диалог.

E>>3) Ваши сильные и слабые стороны. Какие качества вы хотите развивать? Здесь после ответа попытаться проверить слова кандидата. Если кандидат не указал те сильные стороны, которые вы хотите услышать, попробовать проверить, действительно ли это так, возможно кандидат излишне требователен к себе.
eaa>Вы интервью проводите один? или перед вами были Эйчары? если да, то они небось уже достали его этими сторонами. (и того 50) Да и так ли вам это важно, что селовек считает полит корректным ответом? Вы психолог? или просто хотите поиграть в игру кто лучше соврёт?
Неплохо было бы, чтоб ейчары не задавали эти вопросы, именно от ихних вопросов о сильных слабых сторонах эффекта 0. Эйчары пусть о компании рассказывают, о белизне зарплаты, об опционах, корпоративах, аттестациях и т.д. Имеется ввиду технические сильные и слабые стороны. Укажет, что круто знает язык — начинаешь гонять по языку. Укажет, что хорошо архитектурит — даешь задачку на дизайн классов. Говорит, что внимательный — даешь задачку на внимательность. Указал слабые стороны — проверь насколько слабые, тоже дай пример, может не настолько и слабые они окажутся.

eaa>А рефакторинг по маленькому куску кода это уровень среднего девелопера. То есть по нему не увидешь, может ли человек мыслить маштабно (если синьёра ищем).
eaa>+ нужен комп (это не проблема, но об этом тоже нужно обзаботится)
eaa>30 мин (и того 1 час 20 мин)
Да, 30 минут. Но, это можно сделать следующим образом — показать код, сесть с ним вместе, и просить вслух высказывать все, что человек думает. Очень важное качество для разработчика — умение быстро вникать в чужой код. Как я наиболее представляю, на индусский код разработчик скажет, что это типичный индусокод, бегло скажет устно, что он с ним будет делать, и скажет, что придется рефакторить чтобы его понять. Тут его можно прервать и показать ваш эталонный код. Вот тут комментарии будут уже интереснее, и если он еще скажет как его можно отрефакторить, и отрефакторит, то это будет плюсище.

E>>5) Рассказать о текущей задаче в проекте. Попросить кандидата высказать идеи, как бы эти задачи решил он. Сказать свое решение, попробовать с ним поспорить, чье решение лучше.
eaa>Хороший вопрос. Но по времени пора закругляться и ответ может выйти скомканый.
А кто говорит что задавать надо все вопросы? И идти по эталонной тропе? Хорошему кандидату вопрос задать стоит, его свежий взгляд могут помочь проекту, даже если кандидат не совсем подходит. Если видно, что кандидат так себе, можно вопрос не задавать.

eaa>Интервью вообще штука осень субъективное, а ваше мне кажется слишком.
Оно и должно быть субъективным, зависить от специфики проекта. Но оно должно давать кандидату шанс показать себя с хорошей стороны. И если есть стороны, в которых кандидат лучше проверяющего, то человека надо брать несмотря на недостатки — выгодно будет всем. Слабые стороны кандидат подтянет от остальных достаточно быстро, а сильнам научит других — выиграют все.

eaa>Кроме того когда вы увидите что человек вам не подходит? как вы закончите интервью?
Как только смогу убедиться, что дальше продолжать не имеет смысла. Например на сплошное копипасте кандидат говорит, что он всегда имеенно так пишет, код оптимален и в улучшениях не нуждается, указал в качестве своих сильных сторон знания языка но не знает даже синтаксиса шаблонов, не может даже прочитать написанное. При этом ни кругозора, ничего. Тут лучше не мучить себя и кандидата, сказав, что тут вы нам не подойдете, для нас знание языка критично, увы, вы не показали себя в этом хорошо. Всяко лучше, чем промучить человека, пообещав непременно огласить результат, и естественно не сдержав обещаний.

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

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

E>>2) Про какие конкурирующие технологии вы знаете (или имели с ними дело). В чем, на ваш взгляд, достоинства, недостатки определенной технологии, какие потенциальные проблемы можно получить?
Х>Аналогично пункту 1, хотя, да здесь есть некоторые возможности.
Аналогично пункту 1.

Х>Это достаточно долго, а оценка качества кода вещь очень относительная. Хотя конечно этот вопрос покажет многое, если конечно кандидат вообще с первого взгляда въедет в кусок кода.
Покажет самое основное качество — скорость вникания в чужой код.

Х>Собственно все очень просто, такое собеседование занимает много времени, а надо ведь узнать уровень знаний кандидата.
А почему уровень умений кандидата узнавать не надо? Почему оцениваем на основе знания теории? Самый вычокий уровень знаний будет у вчера прочитавшего книжку.

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

S>Безотносительно остально, полагаю, что секс с HR-кой в туалете, определенно, должен присутсвовать в составе "идеального собеседования"! :)

Во первых, хрю обязательно должна быть красивой и не просто красивой, а во вкусе претендента
Во вторых, ну и странные — же у тебя фантазии "в туалете" :))) А на столе слабо?
В третьих, почему именно с ашеркой, вдруг претендент — женщина ;)
В четвёртых, что это одна девушка, я меньше чем две за раз не потребляю :)) p.s. Бутылки в том числе ;)

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

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

E>>>Для начала свой вариант. Предположу, что собеседуется достаточно опытный разработчик. Итак:
eaa>>Это предположение сделано на основании резюме? Или вы знаете про него что то больше. Не всегда резюме соответствует человеку
E>Есть вакансия, есть требования к вакансии, надо взять именно опытного разработчика. Тек как человек пришел на эту вакансию, считаем что он ей соответствует.

Это в теории, к сожалению это далеко не так. И по этому, это нужно проверить в первую очередь. Как фраза от человека у которого завялено 10 лет С++: "Я не помню синтаксис" (речь шла не про специализацию шаблона или что то ещё, а что то типа цикла)? И такое случается. По этому если человек ниже какой то планки, это нужно определить как можно раньше.

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

eaa>>10-15 минут, ну вполне пойдёт за приветсвие. Правда не всегда можно расказать, про проект. Если контора большая то при собеседовании не известсно в какой отдел человек пойдёт. Но влюбом случае, что то расказать да и нужно.
E>Вот это крайне плохо. Раз нельзя рассказать что за проект, то нельзя и определить какие требования предъявлять, непонятно что первостепенно, а что что нет.

Я работал в продуктовой компании, там нет зоопарка. Во всех продуктах один набор технологий + общие либы. Есть разные отклонения, но они не существенны. Кроме того цель именно этой части интервью, это определить именно технический уровень кандидата. Затратив минимум времени и не оставив не приятного впечатления у кандидата (типа устроили экзамен)

E>Увы, я хорошо знаю, как составляется описание проекта и требования к нему, часто ничего общего с реальностью нет. Собеседовать должен тот, кто за этот проект отвечает (это архитектор или тех лид, а не тот, кто контролирует выполнение задачь, никогда не видевший кода проекта, или уже давно забывший все это)

Вы говорите про аутсорс, у нас было иначе

eaa>>Это покажет умеет ли человек проводить интервью (если у него подобный опыт), но не как не оценит его как программиста, кроме того может поставить в ступор даже хорошого девелопера и будет вам стоять 10 мин. (и того 20)
E>Поставит в ступор — ничего страшного, пойдем по своим вопросам. Если не поставит в ступор — это даст кандидату возможность указать на свои сильные стороны, даст достаточно много информации о кандидате. Часть из этих 10 минут возможно сэкономится потом, так как на этом этапе возможно кандидат задаст тот же вопрос, что задал бы и ты. Это просто возможность для кандидата хорошо себя показать, очень хорошо бы ему эту возможность предоставить.

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



E>>>3) Ваши сильные и слабые стороны. Какие качества вы хотите развивать? Здесь после ответа попытаться проверить слова кандидата. Если кандидат не указал те сильные стороны, которые вы хотите услышать, попробовать проверить, действительно ли это так, возможно кандидат излишне требователен к себе.
eaa>>Вы интервью проводите один? или перед вами были Эйчары? если да, то они небось уже достали его этими сторонами. (и того 50) Да и так ли вам это важно, что селовек считает полит корректным ответом? Вы психолог? или просто хотите поиграть в игру кто лучше соврёт?
E>Неплохо было бы, чтоб ейчары не задавали эти вопросы, именно от ихних вопросов о сильных слабых сторонах эффекта 0. Эйчары пусть о компании рассказывают, о белизне зарплаты, об опционах, корпоративах, аттестациях и т.д. Имеется ввиду технические сильные и слабые стороны. Укажет, что круто знает язык — начинаешь гонять по языку. Укажет, что хорошо архитектурит — даешь задачку на дизайн классов. Говорит, что внимательный — даешь задачку на внимательность. Указал слабые стороны — проверь насколько слабые, тоже дай пример, может не настолько и слабые они окажутся.

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

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

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

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

eaa>>30 мин (и того 1 час 20 мин)
E>Да, 30 минут. Но, это можно сделать следующим образом — показать код, сесть с ним вместе, и просить вслух высказывать все, что человек думает. Очень важное качество для разработчика — умение быстро вникать в чужой код. Как я наиболее представляю, на индусский код разработчик скажет, что это типичный индусокод, бегло скажет устно, что он с ним будет делать, и скажет, что придется рефакторить чтобы его понять. Тут его можно прервать и показать ваш эталонный код. Вот тут комментарии будут уже интереснее, и если он еще скажет как его можно отрефакторить, и отрефакторит, то это будет плюсище.

(Я перенёс этот абзац из конца)
eaa>>Кроме того когда вы увидите что человек вам не подходит? как вы закончите интервью?
E>Как только смогу убедиться, что дальше продолжать не имеет смысла. Например на сплошное копипасте кандидат говорит, что он всегда имеенно так пишет, код оптимален и в улучшениях не нуждается, указал в качестве своих сильных сторон знания языка но не знает даже синтаксиса шаблонов, не может даже прочитать написанное. При этом ни кругозора, ничего. Тут лучше не мучить себя и кандидата, сказав, что тут вы нам не подойдете, для нас знание языка критично, увы, вы не показали себя в этом хорошо. Всяко лучше, чем промучить человека, пообещав непременно огласить результат, и естественно не сдержав обещаний.

Да, но вы обнаружили это потратив час времени, а могли это сделать в течении первых 15 минут.

eaa>>Интервью вообще штука осень субъективное, а ваше мне кажется слишком.
E>Оно и должно быть субъективным, зависить от специфики проекта. Но оно должно давать кандидату шанс показать себя с хорошей стороны. И если есть стороны, в которых кандидат лучше проверяющего, то человека надо брать несмотря на недостатки — выгодно будет всем. Слабые стороны кандидат подтянет от остальных достаточно быстро, а сильнам научит других — выиграют все.

Проблема в том, что такое интервью весьма субъективно не к спецификам проекта, а к умению себя держать, умению говорить и поднести себя.
А потом вы этого человека завтавите не говорить, а код писать. Если бы вы собирали команду консалтеров, то наверное это был бы эталон правельного интервью, но вы ведь девелоперов ищите...

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

eaa>Это в теории, к сожалению это далеко не так. И по этому, это нужно проверить в первую очередь. Как фраза от человека у которого завялено 10 лет С++: "Я не помню синтаксис" (речь шла не про специализацию шаблона или что то ещё, а что то типа цикла)? И такое случается. По этому если человек ниже какой то планки, это нужно определить как можно раньше.
Именно опытные разработчики часто некоторый синтаксис забывают. Например оператор goto забывают, забывают что такое метка. Забывают синтаксис массивов, так как пользуются давно векторами, забывают про оператор delete, так как пользуются смартпоинтерами. Что-то забывают, что-то приобретают. А тут на незнании синтаксиса цикла бракуем человека?

eaa>Показать кем? Есть два синьор девелопера, один любит проводить интервью и делает это частенько, другой сторониться этого впринципе. Так вот контраст будет настолько большой, что вы не сможете их сравнить. Только и всего. А если вопрос не влияет на результат собеседования зачем его задавать? Это вещь сродни внешнего вида и тд. То есть производит впечатление на интервьюера, но не относится к професлиональным навыкам.
На практике, увы, в любом случае тот, кто больше ходит по собеседованиям, тот и выиграет. Так как его в ступор не вгонят всякие простенькие задачки, которые он решал в последний раз в институте, а также всякие задачки на синтаксис.

eaa>Ну почему все мнят себя психологами? Ну ладно девчёнки из Эйчар они книгу про это прочитали, но вы то зачем? Ну скажет он вам что он честный и пунктуальный (честность вроде всегда хорошо, а пунктуальность вроде плюс) и пожертвует к примеру трудолюбием (ну нельзя же быть во всём идеальным, как я, вроде сейчас не смертельный грех) и что это даст? И будет стоять на этом до конца, ну не хочет он вам душу раскрывать, да и не обязан.
Беспокоимся о том, что кандидата слишком долго будем мучить, но совершенно не беспокоимся, что его еще до этого HR мучит всякими анкетками с тестами вида "расставьте приоритеты"?

eaa>Я несколько раз на такое натыкался, спрашивают знаешь это? отвечаю не знаю. начинают по нему гонять. часто, встаю ухожу, вне зависмости от того знаею ответы или нет. Это очень не красиво смотриться со стороны кандидата.
Лично я про слабые места говорю сразу, про это я в свое время книжку читал, на практике никогда не применял, можете поспрашивать, вдруг чего и вспомню, вы уж извините если буду отвечать своими словами, а не по эталонному. Если критично это на вашем проекте, обязуюсь книжку перечитать перед работой . Наверно зря так делаю, лучше молчать.

eaa>Да, но вы обнаружили это потратив час времени, а могли это сделать в течении первых 15 минут.
На основании вопросов типа — что такое некластерный индекс ? Не ответил — до свидания?

eaa>А потом вы этого человека завтавите не говорить, а код писать. Если бы вы собирали команду консалтеров, то наверное это был бы эталон правельного интервью, но вы ведь девелоперов ищите...
С кодом есть большая проблема. Простой код мало что выявит, на более сложный нужно время, не каждый будет неделю или день тратить на тестовое задание. Как компромисс эту проблему можно решить так, как я указывал, на рабочем примере попробовать определить что написано, отрефакторить, предложить лучшее решение. Но ни разу не встречал, код просят написать тривиальнейший, при этом основное — не забыть проверки условий в начале проверить. Проверяете код — делайте на более-менее реальном примере, а не на перемножении или транспонировании матриц.

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

E>Именно опытные разработчики часто некоторый синтаксис забывают. Например оператор goto забывают, забывают что такое метка. Забывают синтаксис массивов, так как пользуются давно векторами, забывают про оператор delete, так как пользуются смартпоинтерами. Что-то забывают, что-то приобретают. А тут на незнании синтаксиса цикла бракуем человека?

Вы уверенны, что это всё ещё разработчик? Может его нужно как то иначе назвать? Консультант? Специалист по прохождению интервью?
Как по мне, то разработчик должен в первую очередь уметь разрабатывать софт. ТОЧКА! всё остальное вторично.
Более того, если это синьёр, то он должен мочь заменить любого в своей команде. И наче его должность дана за выслугу лет.

Что касается синтаксиса, пускай он что то не помнит, мне струдом верится, что человек так легко забудет то с чем имел дело каждый день в течении 10 лет, но пускай.
Но есть задачка синтетическая, игрушечная, но задачка по программированию. И девлопер её должен решить. Не помнишь синтаксиса фор, делай вайлом, делай гото, делай рекурсией, задай конкретный вопрос в конце концов. Но должен написать. Потом будем спорить, будем оценивать. Но девелопер который не может (не умеет) писать код мне не нужен. И никакие смарт поинтеры не могут служить оправданием.

Я не просил его выписать грамматику этой конструкции, но в целом — да. Не может написать цикл, бракуем. У него возможно богатый внутренний мир, он генерит превосходные идеи, но он не девелопер. Всегда есть минимальный уровень ниже которого не ответ на любой вопрос — не годен. Просто, что то делается сознательно, что то нет. Пришёл к вам человек и не может сказать ни как его зовут ни чего он пришёл, будите продолжать интервью, что бы узнать как у него с познаниями в архитектуре? Сомневаюсь.

Задача интервью, не проверить ВСЕХ кандидатов, а набрать нужное количество людей нужного уровня.
Я исхожу из тезиса, что лучше не взять хорошего, чем взять плохого. + я ценю свое время и время кандидата, по этому я не провожу препорацию всех его знаний.
Я с этого начинал. Так сказать пытал человека до конца, на случай а вдруг там внутри, есть знания которых я так не вижу. А потом перестал.

Ведь с точки зрения компании цель этого всего исключительно набор людей. Даже мнение кандидатов вторично (просто оно сильно влияет на набор в будущем вот с ним и носятся). и не важно скольких отфильтровывают, пока желающих достаточно, что бы закрывать позиции.


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

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

E>Беспокоимся о том, что кандидата слишком долго будем мучить, но совершенно не беспокоимся, что его еще до этого HR мучит всякими анкетками с тестами вида "расставьте приоритеты"?

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

eaa>>Я несколько раз на такое натыкался, спрашивают знаешь это? отвечаю не знаю. начинают по нему гонять. часто, встаю ухожу, вне зависмости от того знаею ответы или нет. Это очень не красиво смотриться со стороны кандидата.
E>Лично я про слабые места говорю сразу, про это я в свое время книжку читал, на практике никогда не применял, можете поспрашивать, вдруг чего и вспомню, вы уж извините если буду отвечать своими словами, а не по эталонному. Если критично это на вашем проекте, обязуюсь книжку перечитать перед работой . Наверно зря так делаю, лучше молчать.

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


eaa>>Да, но вы обнаружили это потратив час времени, а могли это сделать в течении первых 15 минут.
E>На основании вопросов типа — что такое некластерный индекс ? Не ответил — до свидания?

Если берёте человека который будет заниматься оптимизации базы то да. А если будет делать интерфейс то пожалуй нет.

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

eaa>Вы уверенны, что это всё ещё разработчик? Может его нужно как то иначе назвать? Консультант? Специалист по прохождению интервью?
eaa>Как по мне, то разработчик должен в первую очередь уметь разрабатывать софт. ТОЧКА! всё остальное вторично.
eaa>Более того, если это синьёр, то он должен мочь заменить любого в своей команде. И наче его должность дана за выслугу лет.
А кто говорит о том, что он не умеет разрабатывать софт? Кто говорит что он не может заменить любого в команде? Вполне может оказаться, что может. Человек вполне может эффективно писать код, но не помнить синтаксиса некоторых вещей, так как пишет он в несколько другом стиле. Современное программирование сейчас переходит в функциональный стиль, например, соответственно человек мог привык пользоваться врапперами над циклами, а синтаксис обычных вполне мог забыть, так как не пользовался ими много лет. Как результат, человек много может принести команде, вполне способен решать сложнейшие задачи, но его срезаем на том, что он забыл синтаксис цикла. Как он способен решать задачи то, мы не проверяемс.

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

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

E>День добрый. На деле, много из нас страшно ругается на то, как проводят собеседования. И хотелось бы обсудить, а как оно в идеале должно проходить, какие вопросы нужно задавать, и на основании чего определять, подойдет кандидат или нет?
E>Для начала свой вариант. Предположу, что собеседуется достаточно опытный разработчик. Итак:

Я довольно часто провожу собеседования. И как раз для позиций senior developer. Продуктовая компания.
Часть про рассказать про позицию, чем заниматся, какие технологии, возможные задачи — да, это часть любого собеседования.
Затем говорю с кандидатом про его опыт работы, чем он до этого ззанимался.
Потом перехожу к части по технологии — вопросы на знание технологии. Обычно это разговор примерно на 1 час, без компьютера и примеров кода.
Чаще всего (примерно в 90-95% случаях) довольно быстро выясняется что хотя у кандидата в резюме написано что он все отлично знает, и он говорит что у него куча опыта работы, но на самом деле у него довольно поверхностное представление о технологиях, и на он тянет в лучшем случае на обычного разработчика (а чаще всего на juniora).
В случае если кандидат хорошо все знает — с трудом укладываюсь в полтора часа. Время нужно для хорошей проверки знаний. Время на показ кода и т.п. — просто нет да и я считаю это ненужным.
Что касается чтения книг и т.п. перед собеседованиями. Не помогает, потому что за пару дней на хорошем уровне все не выучишь.
У меня получается что даю положительную рекомендацию по итогам интервью примерно для 1 из 20 интервьюируемых. Да, это отнимает немало времени, на зато у меня команда одна из лучших в компании и все до одного отличные профессионалы. — Подход показывает хорошие результаты.

Фишка отбора (в частности интервью) в том чтобы отсеить заведомо неподходящих кандидатов на как можно более ранней стадии. Соответственно, длинные разговоры "о высоком", исходя из того что собеседуется квалифицированный сотрудник (интересно, откуда берется такое странное предположение?) — ресурсы на ветер.

Я, лично, понимаю что трачу много времени на интервью, но примерно выглядит так (после HR):
* короткий рассказ о компании и о том чем занимаемся, кого и зачем ищем (полезно создавать бренд на рынке труда, смысл пихать это в начало интервью в том, что потом времени на это может не оказатсья в случае если человек не подходит
* несколько заданий на кодирование/дизайн, для чего кандидат остается один, соответственно, время не тратится
* проверка задания, которая естественным образом переходит в разговор о техноголических вещах, если видно что человек не подходит, интервью заканчивается
* разговор о прошедших проектах, разговор о нашей компании etc, Q&A
* тестовое задание на дом


Кстати, вот идеальный процесс отбора с "другой" стороны:

* задание на дом, если результат не впечатляет, дальше не продолжаем
* рассказ про компанию
* обсуждение задания, вопросы типа почему сделали так или иначе, как это работает внутри, технологии etc
* разговор о проектах etc, разговор о том чем предстоит заниматься, о компании, Q&A

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

eaa>>Вы уверенны, что это всё ещё разработчик? Может его нужно как то иначе назвать? Консультант? Специалист по прохождению интервью?
eaa>>Как по мне, то разработчик должен в первую очередь уметь разрабатывать софт. ТОЧКА! всё остальное вторично.
eaa>>Более того, если это синьёр, то он должен мочь заменить любого в своей команде. И наче его должность дана за выслугу лет.
E>А кто говорит о том, что он не умеет разрабатывать софт? Кто говорит что он не может заменить любого в команде? Вполне может оказаться, что может. Человек вполне может эффективно писать код, но не помнить синтаксиса некоторых вещей, так как пишет он в несколько другом стиле. Современное программирование сейчас переходит в функциональный стиль, например, соответственно человек мог привык пользоваться врапперами над циклами, а синтаксис обычных вполне мог забыть, так как не пользовался ими много лет. Как результат, человек много может принести команде, вполне способен решать сложнейшие задачи, но его срезаем на том, что он забыл синтаксис цикла. Как он способен решать задачи то, мы не проверяемс.

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

Если человек не знает синтаксиса языка, а уже несколько лет пишен на какой то надстройке. То нужно чествно говорить, пишу на надстройке сам язык трогал давно. А то так у меня может оказаться 10 лет опыта ассемблера, ведь С++ по сути надстройка над ним

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

Кроме того как я писал раньше, я когда то был очень любопытный и проводя интервью пытался сделать полную трепанацию знаний. Не знаем, что такое вертуальный деструктор, пробуем касты, не слышали про касты, а как с шаблонами, ладно не знаем С++ может хоть с алгоритмами хорошо. И по моей статистике не стоит оно этого. Если человек написал, что у него хороший С++, а это оказалось не так, нет смысла копать глубже.

У меня были интервью, где человек говорил. Я на самом деле давно на С++ не програмировал и его забыл. Да не вопрос, можем встретится через неделю, через две. Так вот повторно возвращаются еденицы, и как правило их таки берут. Но большенство не возвращаются, так как можно пройти другое интервью.

Так что если есть такой синьёр который не умеет писать циклы, а всё остальное супер, то он один из 1000 и не стоит тратить время. на то что бы такой эксземпляр распознать.


Задача интервьёра не найти лучшего програмиста, а найти человека на вакансию за разумное время.

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

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

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

+100 !

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

K>Кстати, вот идеальный процесс отбора с "другой" стороны:

K>* задание на дом, если результат не впечатляет, дальше не продолжаем
K>* рассказ про компанию
K>* обсуждение задания, вопросы типа почему сделали так или иначе, как это работает внутри, технологии etc
K>* разговор о проектах etc, разговор о том чем предстоит заниматься, о компании, Q&A
Вот это уже лучше, это имеет смысл. Одна проблема, учитывая, что после выполнения задания, даже в случае, если результаты не устроили, по хорошему надо хоть несколько строчек соизволить написать, что не устроило, хотя бы вкратце. А то крайне нехорошо, кандидат терял врямя, а результата вообще 0.