Re[5]: Идеальное собеседование - какое оно? - О работе

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

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

Далее, если таких вопросов не было, начать задавать свои вопросы
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>Более того, если это синьёр, то он должен мочь заменить любого в своей команде. И наче его должность дана за выслугу лет.
А кто говорит о том, что он не умеет разрабатывать софт? Кто говорит что он не может заменить любого в команде? Вполне может оказаться, что может. Человек вполне может эффективно писать код, но не помнить синтаксиса некоторых вещей, так как пишет он в несколько другом стиле. Современное программирование сейчас переходит в функциональный стиль, например, соответственно человек мог привык пользоваться врапперами над циклами, а синтаксис обычных вполне мог забыть, так как не пользовался ими много лет. Как результат, человек много может принести команде, вполне способен решать сложнейшие задачи, но его срезаем на том, что он забыл синтаксис цикла. Как он способен решать задачи то, мы не проверяемс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

E>Вот это уже лучше, это имеет смысл. Одна проблема, учитывая, что после выполнения задания, даже в случае, если результаты не устроили, по хорошему надо хоть несколько строчек соизволить написать, что не устроило, хотя бы вкратце. А то крайне нехорошо, кандидат терял врямя, а результата вообще 0.

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

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

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

Несколько вариантов идеального собеседование

1) Под гипнозом (установим для идеальности, а мы ведь о таком говорим, что человека не будут зомбировать, будут спрашивать только проф. вопросы и т.д и т.п, в общем ничего личного, ничего что может быть использовано против человека или угрожать его здоровью и т.д )

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

2) Второй вариант это — вариант собеседования из кинофильма "код рыба-меч", только без угрозы для жизни.

3) Третий вариант это исповедь — программист должен будет покаяться и рассказать все о всех своих программистких грехах (с прошлой исповеди). Отбор — По степени грешности и тяжести грехов.

4) Собеседование после приема пейета (мескалито) — поможет отобрать достойного архитектора для проекта. Поможет кандидату быстрее выйти на необходимый уровень абстракции для обсуждения проблемы большого кол-во абстрактных слоев.

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

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

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

8) Полный вариант из кинофильма "код рыба-меч" — для программистов в банки.

9) Для программистов указывающих много языков программирования в резюме — собеседование с картами. В колоде обычые карты, но масть каждой карты — название ЯП (Валет С++, Дама PHP), то кол-во мастей может быть больше чем в обычных картах. Кандидату показывают карты рубашкой, от кандидата требуется угадывать масть карты. Если угадывает больше 30% значит подходит.

10) Орел — решка. Просто бросается монетка — вызов судьбы.

11) Русская рулетка между сотрудником компании и кандидатом. Вариант для компаний с hiring freeze

12) Кандидату необходимо удовлетворить нескольких проституток (кол-во зависит от будущей должности). Вариант для мыщьх'а

...

Забыл кофе и wifi, это самое главное.

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

BM>5) Дать кандидату возможность решать абстрактные задачки с реальными предметами. Ну там воду отмерить двумя ведрами, шнуры сжигать и так далее. Поможет какнидату расслабиться, вспомнить детство и берюльки, и в целом испытать много позитива (например выливая ведро воды на пол офиса собеседующей компании в случае неудачной попытки решить задачу по измерению необходимого кол-ва воды)

пробовал — не помогает.

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

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

Я, будучи немного идеалистом, считаю что глупых все-таки сильно больше, чем лжецов

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

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

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

Во вступлении лучше начать с общих вопросов, а не грузить мусором.

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

Для чего это ? Собеседование требует опыта и подготовки, кадндидат вполне может не иметь этого. Т.е.он программист но никогда не проводил собеседований.

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

вообще собеседование начинается задолго до самого собеседования

собеседование начинается с ответа на вопрос — какой работник нужен и нужно взять и составить портрет этого работника

собеседование это не просто оценка уровня, это оценка морально-волевых качеств кандидата

нужно получить ответы на ряд вопросов, кто же такой этот кандидат

исполнитель (ведомый)
лидер (ведущий)
коммандный игрок
одиночка

нужно определить

стимулы для кандидата
отношение к ответсвенности
конфликтность
желание учиться, интерес

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

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

для этого перед собеседованием хорошо бы извлечь максимум информации из резюме

начинать лучше с общих вопросов и перейти на резюме
обязательно спрашивать про предыдущий опыт !

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

И самое главное — интервью это сильный стресс и потому ограничено по времени, общие темы лучше на потом, т.е. короткое введение, не более 10-15 минут, минут 40-45 по технической части и далее общие.

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

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

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

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

13) Терморектальный криптоанализ никто еще не отменял. Кандидат раскажет все что знает и придумает все что не знает.

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

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

E>Почему никогда, ни на одном собеседовании ни чего подобное не практикуется?
Потому что собеседование — это задача на оптимизацию. Минимум времени на оценку кандидатов и максимум валидности этой оценки.
Часто задают вопросы, на которых кандидаты реагируют "во валит, гад". А задают их не для того чтобы завалить, а чтобы точнее обозначить область знаний кандидата. Если уровень интервьюера выше чем у кандидата — то в любом случае найдутся вопросы, на которые кандидат не ответит. Только уровень вопросов будет разный. Hire/no hire зависит не от количества "неответов", а от совпадения области знания кандидата и соответствующей вакансии. Ну, а адекватность и другие личные параметры оценит HR.

Пьеса "Идеальное собеседование"

Действующие лица: Интервьюер(И), Соискатель(С), Секретарь Леночка(Л).

С: Здравствуйте!
И: Здравствуйте!
С: Я Лиходеев Сидор Махмудович, мы договаривались встретиться по поводу открытой в Вашей компании вакансии "Программист микроконтроллеров на базе ARM"
И: Приняты!

Занавес.

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1231>>

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

_>Пьеса "Идеальное собеседование"

_>Действующие лица: Интервьюер(И), Соискатель(С), Секретарь Леночка(Л).

_>С: Здравствуйте!
_>И: Здравствуйте!
_>С: Я Лиходеев Сидор Махмудович, мы договаривались встретиться по поводу открытой в Вашей компании вакансии "Программист микроконтроллеров на базе ARM"
_>И: Приняты!

Хм, а почему Л промолчала всю пьесу. Чем она там занималась, что рот был занят))

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

G>Просто уже после десятого неподошедшего эта часть задвигается в самый конец собеседования.
Что мешает часть этой информации отправить письмом перед собеседованием? Чтобы кандидат не тратил время, если сам видит, что он не подходит. Один раз потратить время на письмо, и копипастом его при приглашении на собеседовании. А то молчат все как партизаны, перечислят требования как к космонавту, а что нужно реально — узнаешь только после того, как на работу выйдешь. Я конечно понимаю что кризис, толпы желающих поработать, некоторые даже вообще без работы сидят, можно творить все что вздумается. Вообще не понимаю, что мешает отправить письмо, ведь все равно придется эту информацию рассказать. А то, "мы крупная стабильная компания, нам нужны разработчики на языке, зарплата высокая" — на такое будут клевать только те, кому нечего терять. Если говорить честно, то возможно у вас получится переманить кого-то на ту же зарплату, а то и меньшую, что люди зарабатывают в других конторах, даже если не подойдет кандидат, он посоветует вакансию другим? Или у всех такое болото, что честно об этом говорить ну никак нельзя?

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

G>>Просто уже после десятого неподошедшего эта часть задвигается в самый конец собеседования.
E>Что мешает часть этой информации отправить письмом перед собеседованием?

Я разве сказал, что ничего говорить кандидату не нужно?

... << RSDN@Home 1.2.0 alpha 4 rev. 1231>>

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

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

Практически никто не сможет ответить на этот вопрос адекватно. Вот ты например на форуме выясняешь какие вопросы стоит задавать, а какие нет. А на лету, в стрессовой ситуации?

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

Разве что про достоинства и недостатки стоит спросить.

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

И какие выводы ты собираешься делать из ответов на этот вопрос?

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

ок. имеет смысл.

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

Бессмысленно. За 10 секунд адекватно оценить код незнакомого проекта нереально, а уж тем более отрефакторить.

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

То есть другими словами "дать кандидату порешать какие-то задачи"

Вопрос какие.

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1231>>

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

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

_>>Пьеса "Идеальное собеседование"

_>>Действующие лица: Интервьюер(И), Соискатель(С), Секретарь Леночка(Л).

_>>С: Здравствуйте!
_>>И: Здравствуйте!
_>>С: Я Лиходеев Сидор Махмудович, мы договаривались встретиться по поводу открытой в Вашей компании вакансии "Программист микроконтроллеров на базе ARM"
_>>И: Приняты!

N_>Хм, а почему Л промолчала всю пьесу. Чем она там занималась, что рот был занят))

Блин, не вычитал...
Это выдержка из пьески для корпоративной пьянки.
Леночка там приносила Хеннеси, лимончики, а потом принимала живейшее участие и в самом процессе интервьюирования

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

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

G>Ну знач прикатываешь ты в контору, только шаг в дверь, а там — цыгане поют и танцуют, медведь чарку водки подносит, отовсюду "К нам приехал, к нам приехал..." Ты значится чарку хлопнул, ну и сразу тебя за стол, во главу, на почетное место, там вся контора ужо сидит, ну и начинаете квасить, жрать и плясать — а там блатная всякая выпивка, мясо, цельные поросята, цыгане по ходу дела не унимаются, бабы полуголые все норовят с тобой потанцевать. Ну и само собой дирехтур ентой конторы типа как рядом шмыгнет, скажет мол тебе — иван иваныч, милейший, благословите, мы тут люди бедные 15К зелени в месяц — больше предложить не можем — вобщем чем бог послал, подмахните трудовой договор (само собой 35 рабочих дней отпуска, квартальные бонусы и служебная хонда аккорд тайп-р — можно без водилы). Ну ты значится подмахиваешь, дирик испаряется, и бухалово продолжается еще дня три, потом неделька отдыха — за счет "принимающей" конторы где-нить в Мармарисе. Ну а потом конечно и работать начать не грех

Да банально уж слишком

. Я только из отпуска, из родных краев, мне эта водка и пьянки с директорами прямо в офисе уже вот где сидят, сколько можно!

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

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

G>Ё-мое, ну как это какое оно в идеале?
G>Ну знач прикатываешь ты в контору, только шаг в дверь, а там — цыгане поют и танцуют, медведь чарку водки подносит, отовсюду "К нам приехал, к нам приехал..." Ты значится чарку хлопнул, ну и сразу тебя за стол, во главу, на почетное место, там вся контора ужо сидит, ну и начинаете квасить, жрать и плясать — а там блатная всякая выпивка,
G>..........................................................................................................................
G>бухалово продолжается еще дня три, потом неделька отдыха — за счет "принимающей" конторы где-нить в Мармарисе. Ну а потом конечно и работать начать не грех

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

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

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

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

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

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

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

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

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

Это все не мои мысли. В книжке одной вычитал. А теперь мои.
В профессии архитектора, руководителя разработчиков лучше подходят статики. Им легче представить конечную цель. Для движения же к этой цели, т.е. на позицию собственно разработчиков лучше подходят динамики, они знают, как достичь эту цель наилучшим образом.
Опять-таки образ мышления задает интересы: статику не интересно движение к цели, динамику — сама цель.
На мой взгляд, формула Спольски "Уметь решать проблемы" довольно близка к "умный динамический логик".

Теперь перейдем к вопросам elmal'a(на мой взгляд отличным). Разобьем их на 2 части, руководствуясь исключительно соображениями, являются ли эти вопросы оценкой способностям к динамической или к статической логике?

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

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

Отсюда видно, что elmal скорее динамик

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

Удивил?

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

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

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

А если с начальником HR-отдела, опытным кадровиком партийной закалки Васлием Ивановичем Пафнтуиевым?

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

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

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

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

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

E>3) Ваши сильные и слабые стороны. Какие качества вы хотите развивать?
Это еще мне зачем на интервью? Пусть какие хочет, такие и развивает. А сильные и слабые стороны я и сам увижу, в процессе.

E>4) Показать кандидату код рабочего проекта.
И нарушить NDA?

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

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

E>6) Вопросов может быть достаточно много. Собственно при собеседовании стараться не завалить кандидата, а выявить его сильные стороны.
См. выше о целях собеседования.

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

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

V>По определению плохой вопрос. Предполагается, что квалификация кандидата ниже, чем моя — иначе это он бы меня к себе в команду набирал, а не я его к себе.
К сожалению подход распространенный, но часто это утверждение не соответствует действительности.

E>>1) Почему вы выбрали именно текущий язык? Какие языки можно было бы выбрать для задач нашего проекта (именно для этого рассказывалось вначале о проекте). Какие достоинства, недостатки данного языка.
V>Бессмысленный вопрос. Это в RSDN холиварить уместно. А в реальных проектах выбор языка определяется, как правило, отнюдь не только его достоинствами или недостатками.
Как я понял, ищете исполнителя, кругозор не приветствуется. И упаси боже наличие инициативы — нужен исполнитель. Микроменеджмент практикуется, насколько я понимаю?

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

E>>3) Ваши сильные и слабые стороны. Какие качества вы хотите развивать?
V>Это еще мне зачем на интервью? Пусть какие хочет, такие и развивает. А сильные и слабые стороны я и сам увижу, в процессе.
А затем. Если человек старается развивать технические стороны например, старается выполнять свою работу лучше за счет умения программировать, а у вас ценится не это, а умение писать документацию, умение запомнить наизусть спеку. В этом случае сразу кандидата об этом предупредить.

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

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

V>Малореально. Как правило, если проект достаточно специфический, то погрузить кандидата в проект настолько, чтобы он смог предлагать решения, за 20 минут невозможно.
Ну не знаю, у меня получается высказывать предложения еще на этапе рассказа о проекте. Причем сходу получается давать альтернативные решения (задаю вопрос — а почему сделали не так). Собеседущие начинают нервничать, не привыкли к такой наглости

.

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

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

Нужно посадить человека за компьютер и заставить написать qsort на любом языке. Если он сделает это быстро и профессионально, то он может быстро освоить любую технологию (XML, SQL, C#, java, C++ и пр.). Если нет -- то будет писать pure quality code, делать ошибки, ронять тесты и пр. К сожалению, такие собеседования проводятся только в лучших фирмах типа Microsoft, а в россии исследуют то, сколько багов и фич помнит человек.

? Ну допустим перед собеседованием я прочитал еще раз про это, потренировался на время писать, и сходу напишу эталонную реализацию. 15 лет назад я бы написал сходу и профессионально, щас быстро не напишу, и реализация будет точно не эталонной. Последний раз сортировку реализовывал 5 лет назад, и это был пузырек, quick sort не разу не реализовывал, последний раз готовился к таким вопросом на первом курсе, реализовывать не пришлось, реализовывал что-то другое. Итого, раньше я был гораздо круче чем сейчас, чтоль? А именно тогда я писал pure quality code и делал ошибки, щас как-то наоборот все. И ладно, раз проверяем знания алгоритмов, а востребованы ли они будут, эти знания? Что-то мне подсказывает что нет. Может был бы и готов это все вспомнить, но как-то вообще в практической работе никогда не требовалось.

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

V>Я провел немало собеседований. Идеальное собеседование позволяет в кратчайшие сроки найти кандидата, удовлетворящего требованиям. Заметьте, не наилучшего кандидата, потому что поиск наилучшего кандидата по определению занимает бесконечное время.

+1

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

Почему вопрос плохой я писал раньше.
Но подход, что все кандидаты ниже меня уровнем — это путь к деградации. И подход а чё это вы такие бедные если такие умные, скорее попытка обидеть человека.
Далеко не все программисты мечтают быть начальниками. У программиста любого уровня бывают моменты когда он ищет работу (Если исходить из того, что если у меня есть СЕЙЧАС работа, то все кто её ищут — более слабые. То в следующий раз когда будешь тскать работу вспомни, что есть джуниоры которые СЕЙЧАС работают). Так что иногда на собеседования приходят люди очень сильные, и задача интервьера его опознать. Кроме того становясь начальником, ты начинаешь терять скилы девелопера (хотя обычно люди это не замечают), по этому подход: "что квалификация кандидата, ниже чем моя" быстро закроет путь к хорошим девелоперам. А самое интересное, что квалификация это не скаляр, а вектор, так что сравнивать его можно только исходя из субьективной оценки важности. А зачем набирать людей с сильными сторонами в том же что и у себя?

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

Не согласен. Вопрос имеет смысл, и покажет и уровень кандидата и убщую эрудированость. Просто он отберает кучу времени. И можно случайно уйти в спор на долго. Таой вопрос можно бросить в конце интервью, когда всё что нужно уже спросил.

E>>4) Показать кандидату код рабочего проекта.
V>И нарушить NDA?

Ну можно и кандидата попросить подписать NDA, так что это не проблема. Хотя тут на форуме, как то настороженно к этому относятся.

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

S>Нужно посадить человека за компьютер и заставить написать qsort на любом языке. Если он сделает это быстро и профессионально, то он может быстро освоить любую технологию (XML, SQL, C#, java, C++ и пр.). Если нет -- то будет писать pure quality code, делать ошибки, ронять тесты и пр. К сожалению, такие собеседования проводятся только в лучших фирмах типа Microsoft, а в россии исследуют то, сколько багов и фич помнит человек.

Я знаю несколько ХОРОШИХ алгоритмистов которые шишут прикольные спагетти. Но qsort напишут.

Боюсь, что на подобном интервью больший отрыв получат, те кто недавно нашёл qsort.

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

Хотя если развивать мысль, то можно взять десяток разных алгоритмов и десяток экзотичиских языков (Pure,Brain Fuck,Self...) и рандомно выбрать язык и алгоритм, и предложить кандидату реализовать этот алгоритм на этом языке. Дать книгу и транслятор. То пожалуй подобное интервью будет весьма показательным, но, боюсь, много людей вы так не наберёте.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

E>Это шутка такая чтоль

?
Нет.
E>Ну допустим перед собеседованием я прочитал еще раз про это, потренировался на время писать, и сходу напишу эталонную реализацию. 15 лет назад я бы написал сходу и профессионально, щас быстро не напишу, и реализация будет точно не эталонной. Последний раз сортировку реализовывал 5 лет назад, и это был пузырек, quick sort не разу не реализовывал, последний раз готовился к таким вопросом на первом курсе, реализовывать не пришлось, реализовывал что-то другое. Итого, раньше я был гораздо круче чем сейчас, чтоль? А именно тогда я писал pure quality code и делал ошибки, щас как-то наоборот все. И ладно, раз проверяем знания алгоритмов, а востребованы ли они будут, эти знания? Что-то мне подсказывает что нет. Может был бы и готов это все вспомнить, но как-то вообще в практической работе никогда не требовалось.

По тому, как человек программирует, сразу виден его профессиональный уровень. Можно заставить его писать сервлеты, или ещё что-то связанное со спецификой, но если он не знает основ теории алгоритмов, то это уже сомнительный уровень. Есть много других задач, квиксорт не обязательно писать, можно попросить сделать HashSet или std::map. Не важно. Важно, что если такие базовые знания отсутствуют, сложную систему человек отладить не сможет.

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

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

S>>Нужно посадить человека за компьютер и заставить написать qsort на любом языке. Если он сделает это быстро и профессионально, то он может быстро освоить любую технологию (XML, SQL, C#, java, C++ и пр.). Если нет -- то будет писать pure quality code, делать ошибки, ронять тесты и пр.
T>Ты видимо хотел написать poor, но в агонии гнева на отсутствие qsort вопросов на собеседовании написал pure? Если нет, то перевод будет как раз хорошим: чистый качественный код.

Ага, ашипка.

eaa>Я знаю несколько ХОРОШИХ алгоритмистов которые шишут прикольные спагетти. Но qsort напишут.

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

eaa>Боюсь, что на подобном интервью больший отрыв получат, те кто недавно нашёл qsort.
Это вообще-то базовое знание, вроде хэша, кэша или crc. Можно, конечно, сказать, что с приходом Java мы вышли на новый уровень, где этого всего можно не знать, но закон дырявых абстракций неумолим. Это знать нужно.

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

Микрософту это удаётся. Неужели все кандидаты будут приходить с флэшкой и приносить одинаковые исходники? У вас в запасе заданий целая библиотека CRT!

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

S>По тому, как человек программирует, сразу виден его профессиональный уровень. Можно заставить его писать сервлеты, или ещё что-то связанное со спецификой, но если он не знает основ теории алгоритмов, то это уже сомнительный уровень. Есть много других задач, квиксорт не обязательно писать, можно попросить сделать HashSet или std::map. Не важно. Важно, что если такие базовые знания отсутствуют, сложную систему человек отладить не сможет.
По коду — я только всеми руками за, мое тоже глубокое убеждение, что на собеседовании обязательно надо давать писать код, и именно на основании этого определять годность. Одно но, вопрос какой именно код? На практике, увы, библиотечные функции пишешь крайне редко, надо быть крайне удачливым, чтобы тебе повезло поучавствовать в таком проекте. Алгоритмы тоже если и используются, то тривиальнейшие. Соответственно преимущество будет у студента, который только что сдал зачет, ну или у преподавателя таких студентов, круче него вообще только скалы будут. А практики программирования ни у одного, ни у другого нет. На практике же пишутся чаще всего ну совсем не сортировки. Я потому и говорю, что неплохо бы давать задачи из того, что возможно требуется в текущем проекте (части задачи, попросить набросать идею как будешь делать и т.д). Мое глубокое убеждение, что проверять надо именно то, что потребуется в работе — пишешь низкоуровневые высокооптимизированные библиотеки, попроси написать что-то из этого. Надо реализовывать запутанную логику — попроси набросать иерархию классов и черновой вариант того, как это все будет работать.

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

S>Нужно посадить человека за компьютер и заставить написать qsort на любом языке.

А strcpy написать не нужно?

А если серьезно, то очень огорчает, что так часто возникают предложения реализовать какой-нибудь алгоритм.
Было бы круто, чтобы вместо сферических алгоритмов в вакууме, реализованных надцать лет назад на всех языках, давались бы задачки, хоть как-то приближенные к производству.
Ну, допустим, в резюме есть буковки ASP.NET, ADO... И что, будем заставлять qsort реализовывать? Не лучше ли дать ему комп со студией, сиквелом с тестовой базой (ну пусть AdventureWorks) и пусть создаст страничку и покажет на ней табличку продуктов.

Здравствуйте, elmal,

E>День добрый. На деле, много из нас страшно ругается на то, как проводят собеседования. И хотелось бы обсудить, а как оно в идеале должно проходить, какие вопросы нужно задавать, и на основании чего определять, подойдет кандидат или нет?
--
Мой вариант проведения интервью, который сдожился примерно за 10 лет их проведения (программирование и/или электроника):

1. Обязательно рассказать о компании, ее успешных проектах, текуших задачах. В конце этого вырисовывается требования к кандидату (кого мы ищем).
2. Сразу же предложить интервьюируемому задать вопросы по этой части, выслушать их и ответить на все.
3. Предложить рассказать ему о себе. Когда он начнет говорить о своих прошлых проектах, активно побеседовать с ним, задавая вопросы и обсуждая его ответы (типа почему сделали так, а не иначе; в чем выигрыш и т.п.). Здесь уже становится примерно ясно, с кем имеем дело.
4. Предложить ему одну единственную задачу, которая имеет несколько решений, каждое из которых более лучшее или корректнее, чем предыдущее. За эти 10 лет я придумал одну такую задачу по программированию (С/С++) и пару задач по электронике, которые сам в свое время решил.
Если кандидат не выдает никакого решения, помочь ему получить самое простое и затем задавая вопросы, помочь ему получить более сложное.
Если выдается какое-то решение, раскритиковать его и попросить получить следующее.
5. Завершить интервью. Если человек мне понравился, то это явно ему сообшается. Если нет, то прощаемся нейтрально.

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

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

E>Так вот, хотелось бы спросить у общественности, а чем плох тот подход, который я сейчас предложил? Почему никогда, ни на одном собеседовании ни чего подобное не практикуется? Или я неправ, и кто-то подобный подход практикует? Если да, скажите в каких кампаниях?
--
На мой взляд, вопросы пп. 1, 2, 3 и 5 особо задавать и не стоит, это в основном "говорильня". Работа с существующим кодом (п.4) не всегда может быть организована из-за формальных ограничений (NDA), здесь, на мой взляд, лучше работать с кодом интервьюируемого.

С уважением,
Геннадий Майко.

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

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

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

eaa>Ну можно и кандидата попросить подписать NDA, так что это не проблема. Хотя тут на форуме, как то настороженно к этому относятся.
Кандидата? Подписать NDA? С какого перепоя?

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

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

eaa>>Не согласен. Вопрос имеет смысл, и покажет и уровень кандидата и убщую эрудированость. Просто он отберает кучу времени. И можно случайно уйти в спор на долго.
V>Именно. И главное, он совершенно бессмысленный. Опять же проект уже есть и развивается, и явно никто не станет его переписывать на другом языке потому, что кандидат на интревью рассказал о паре прекрасных фич другого языка.
Небольшой пример — проект на Java 1.4. Там нет слова enum, и народ в лучшем случае константы выносит. Приходит кандидат, знающий C++. Пишет код, видит, что нужна конструкция enum, и эмулирует ее на Java, теми средствами, которые есть в языке (то есть создаст класс). Проект на Си, кандидат знает объектно ориентированный подход — объектно ориентированный подход он сможет применять и на Си. Тоже самое с функциональным подходом. Проект на VB допустим — если кандидат знает C++, то он вполне сможет грамотно организовать обработку ошибок, и выглядеть это будет очень похоже на исключения. Неужели так мало народа знает, что языки программирования используют для решения задачь, а не пишут на языках? Что язык это только инструмент, а не то, чему надо поклоняться.

E>Ну ну. Когда тебя собеседует начальник, понятия не имеющий ни о процессах, о непрерывной интеграции, даже о системах контроля версий, и проработавший в конторе 3 года, до этого не программирующий вообще — я менее квалифицированный?
В таком месте, под руководством такого начальника, делать нечего.

E>Небольшой пример — проект на Java 1.4. Там нет слова enum, и народ в лучшем случае константы выносит. Приходит кандидат, знающий C++. Пишет код, видит, что нужна конструкция enum, и эмулирует ее на Java, теми средствами, которые есть в языке (то есть создаст класс).
Искусственный пример, очень искусственный. Не говоря уже о том, что я не вижу преимуществ класса перед константой.

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

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

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

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

eaa>>Я знаю несколько ХОРОШИХ алгоритмистов которые шишут прикольные спагетти. Но qsort напишут.

S>Да, есть такие. По тому, как будет реализован qsort, сразу можно будет понять какой код будет на выходе у такого человека.

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

eaa>>Боюсь, что на подобном интервью больший отрыв получат, те кто недавно нашёл qsort.
S>Это вообще-то базовое знание, вроде хэша, кэша или crc. Можно, конечно, сказать, что с приходом Java мы вышли на новый уровень, где этого всего можно не знать, но закон дырявых абстракций неумолим. Это знать нужно.
Причём тут ява? как давно вам приходилось реализовывать qsort? Тот кто делал это недавно имеет явное приемущество, то что любой программист должен уметь написать какую то сортировку — согласен, но это не основание для найма. А тем более красота одной функции.

eaa>>А кроме того такое интервью плохо маштабируется, уже после десятка интервью, все кандидаты будут давать одинаковое отличное решение.
S>Микрософту это удаётся.

Если набирать студентов без опыта (а микрософт, в основном так и набирает), то это не плохой способ сравнивать студентов. Но не все компании настолько богаты, что бы растить всех со студентов.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Так вы его по предметной области собеседовать собрались?

eaa>>Далеко не все программисты мечтают быть начальниками. У программиста любого уровня бывают моменты когда он ищет работу.
V>Конечно. Но тут есть еще вот какой момент. Техническое собеседование в большинстве своем проводят "играющие тренеры", то есть люди, которые реально пишут код, совмещая это с руководством. Это все если речь идет о наборе программиста.

Вот и я о том же. Что этот "играющий тренер" плавно начинает терять квалификацию "игрока", по крайней мере перестаёт расти. И сам этого не замечает. А потом ущербные менеджеры вырастают, которые пытаются научить программистов программировать. Если вы уж ступили на тропу менеджмента, и стали хотя бы тимлидиром, то это есть начало вашей деградации как программиста. И главное осознать, то что программист пришедший к вам на собеседование, может программировать лучше вас.

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

eaa>>Ну можно и кандидата попросить подписать NDA, так что это не проблема. Хотя тут на форуме, как то настороженно к этому относятся.
V>Кандидата? Подписать NDA? С какого перепоя?
А к вас с этим проблемы? боитесь не сдержаться?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>По тому, как человек программирует, сразу виден его профессиональный уровень. Можно заставить его писать сервлеты, или ещё что-то связанное со спецификой, но если он не знает основ теории алгоритмов, то это уже сомнительный уровень. Есть много других задач, квиксорт не обязательно писать, можно попросить сделать HashSet или std::map. Не важно. Важно, что если такие базовые знания отсутствуют, сложную систему человек отладить не сможет.

Алгоритмы, это одна из специализаций. Естесвенно любой программист должен представлять себе, про что эта область, как и любая другая. То есть знать и оценки сложности std::map и что такое хеш функция и хеш таблица. Но при этом он может быть не в состоянии написать слёту хорошую хеш функцию или RB-дерево. Да, он может разобраться и написать. И основы теории алгоритмов это именно представление, о том какие есть структуры данных, какие есть базовые алгоритмы на них, как считается оценка сложности. А умение написать qsort — требует конкретные знания. Точно так же как основа теория баз данных, это понятие кортежа и отношения, что есть таблица, индекс и понятие нормализации. А вот синтаксис SQL — это конкретные знания.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

Нужен работающий вариант. Видел "проектировщиков", которые знают все паттерны, используют их и проваливают сроки. Работающую программу можно сделать на компьютере за пару часов. Пусть она будет небольшая. Но спрашивать на собесе "знаете ли вы особенности hibernate 2.1?" — глупость. Это значит что контора нацелена на текучку.

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

Вообще-то, в 99.9% случаев разработчики более квалифицированы, чем их непосредственные начальники. Это следует из определения: начальник вынужден заниматься не столько разработкой, сколько всякой волокитой по отчетам, планам и т.п..

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

E>Небольшой пример — проект на Java 1.4. Там нет слова enum, и народ в лучшем случае константы выносит. Приходит кандидат, знающий C++. Пишет код, видит, что нужна конструкция enum, и эмулирует ее на Java, теми средствами, которые есть в языке (то есть создаст класс).

На очередном code review кандидату дают по сусалам за инициативу. Enum есть в 1.5 на который проект рано или поздно все равно перейдет. Так что время лучше было потратить на подготовку к переходу, а не изобретение велосипедов.

E>Проект на Си, кандидат знает объектно ориентированный подход — объектно ориентированный подход он сможет применять и на Си.

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

E>Тоже самое с функциональным подходом. Проект на VB допустим — если кандидат знает C++, то он вполне сможет грамотно организовать обработку ошибок, и выглядеть это будет очень похоже на исключения.

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

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

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

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

M>На очередном code review кандидату дают по сусалам за инициативу. Enum есть в 1.5 на который проект рано или поздно все равно перейдет. Так что время лучше было потратить на подготовку к переходу, а не изобретение велосипедов.
Это и есть подготовка к переходу. И это не велосипед, а достаточно распространенный подход, я его, например, у Макконела прочитал (хотя, Макконел как-то непопулярен среди народа смотрю, читало его от силы 1%, наверно потому что там не было названия конкретного ЯП). Ну и квалификация ревьюера, который по рукам бьет за типобезоавсный код, оставляет сомнения — явно человек не на своем месте сидит.

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

M>И получить нечитаемый простыми VB программистами код. Потому, что исключения должны поддерживаться языком иначе сработает закон дырявых абстракций.
А они и поддерживаются языком, кстати, хоть и синтаксис довольно уродский. Вот только надежно писать мало кто может, и тем более не задумываются о читаемости. И как это нечитаемый? Обычные же будут в спагетти стиле писать, если разбираются в спагетти с методами па 10 000 строк, то разберутся и в методе на 10 строк.

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

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>5. Завершить интервью. Если человек мне понравился, то это явно ему сообшается. Если нет, то прощаемся нейтрально.

Интересно, откуда взялась эта "традиция". Почему о негативном результате никогда не говорят прямо?

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

T>Здравствуйте, Геннадий Майко, Вы писали:

ГМ>>5. Завершить интервью. Если человек мне понравился, то это явно ему сообшается. Если нет, то прощаемся нейтрально.

T>Интересно, откуда взялась эта "традиция". Почему о негативном результате никогда не говорят прямо?

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

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

G>Ну а зачем обижать человека? Мало кто в стрессовой ситуации способен адекватно воспринять негативную информацию. А потом на форуме раздаются вопли "контора ХХХ — сволочи, был у них на интервью, отказали прямо в лицо"

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

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

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

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

G>>Ну а зачем обижать человека? Мало кто в стрессовой ситуации способен адекватно воспринять негативную информацию. А потом на форуме раздаются вопли "контора ХХХ — сволочи, был у них на интервью, отказали прямо в лицо"

T>А какой смысл, если все равно большинство знает "мы вам потом сообщим == отказ"?
Дык вот смысл как раз и заключается в том, чтобы донести до человека информацию позволив ему сохранить лицо.

T>Ведь не сообщают и потом тоже. Иногда так и хочется среагировать неадекватно. Например — дать в зубы человеку, который с улыбкой и глядя тебе в глаза врет

Ну, я бы больше опасался за зубы интервьювера, если бы он в глаза говорил "ваш уровень C++/C#/... слишком слаб. Вы нам не подходите".
Хотя в этом случае зубы еще могут уцелеть. А вот в случае отказа из-за человеческого фактора "вы слишком заносчиво и неадекватно вели себя на собеседовании. Нам такие не нужны" — неоднозначно придется ставить протезы.

T>И таких воплей на форуме я никогда не видел. По моему, большинству просто не хватает духу сказать правду. Как в анекдоте про щенка, которого очень жалели и отрезали хвост по частям.

Наоборот, сделали щенку анестезирующий укол перед операцией.

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

G>Дык вот смысл как раз и заключается в том, чтобы донести до человека информацию позволив ему сохранить лицо.

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

Нежелание сказать человеку, что он не подходит — это просто малодушие.

G>Ну, я бы больше опасался за зубы интервьювера, если бы он в глаза говорил "ваш уровень C++/C#/... слишком слаб. Вы нам не подходите".

А я был бы рад услышать это прямо. Особенно с уточнением, что конкретно плохо в моих знаниях.
Это я странный или весь мир сошел с ума?

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

T>А я был бы рад услышать это прямо. Особенно с уточнением, что конкретно плохо в моих знаниях.
T>Это я странный или весь мир сошел с ума?

Это очень здорово получить такой ответ от проводящих интервью. Только вот не все кандидаты адекватно на такой ответ реагируют.

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

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

T>>А я был бы рад услышать это прямо. Особенно с уточнением, что конкретно плохо в моих знаниях.
T>>Это я странный или весь мир сошел с ума?

S>Это очень здорово получить такой ответ от проводящих интервью. Только вот не все кандидаты адекватно на такой ответ реагируют.

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

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

G>Я бы тоже не отказался послушать конструктивную критику.
G>Но, во-первых, у интервьювера может просто не быть ни времени ни желания устраивать консультации каждого неподошедшего.
G>Во-вторых, даже если интервьювер соизволит проехаться по моим знаниям танком, я, хоть и останусь благодарным на рациональном уровне, но буду ощущать неприятный осадок от того что меня попустили на эмоциональном уровне.
G>И вот скажите, а нафига оно надо интервьюверу?

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

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

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

G>А если серьезно, то очень огорчает, что так часто возникают предложения реализовать какой-нибудь алгоритм.
G>Было бы круто, чтобы вместо сферических алгоритмов в вакууме, реализованных надцать лет назад на всех языках, давались бы задачки, хоть как-то приближенные к производству.
G>Ну, допустим, в резюме есть буковки ASP.NET, ADO... И что, будем заставлять qsort реализовывать? Не лучше ли дать ему комп со студией, сиквелом с тестовой базой (ну пусть AdventureWorks) и пусть создаст страничку и покажет на ней табличку продуктов.

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

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

Потому что теория алгоритмов — основа информатики.

Не знаю как там в default city, а у нас в регионах собеседования проводить не умеют и поэтому половина разработчиков не знает простейших вещей и тянет вниз остальных (отжирая часть ЗП), тратя их время на исправление за ними плохого кода. При мне взяли на работу программиста, который не мог написать даже пузырёк, зато знает всякие ADO, XML, Struts, синглтоны, XP и пр. базворды

В отрасли сейчас много лишних людей, т.к. сужается рынок. Но разгильдяя нельзя уволить просто так, поскольку он написал кучу барахла и лишь он может всё это сопровождать. Как говорил Билл Гейтц: "на работу нужно брать только отличников (то есть тех кто помнит с вуза теорию алгоритмов). Если возьмёшь четвёрошников, то они наберут троешников и пиши пропало". Не вникая в монопольный аспект деятельности его конторы, хотел бы заметить, что у них лучшие кадры, лучшие продукты и прибыли в мире по интегральным показателям. Когда берут в MS, просят написать ...strcpy или memmove и отправить им по email, недавно один уматывал в MS, всё рассказал.

Не знаю как остальные, мы изучали и имплементировали qsort ещё в школе.

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

S>Потому что теория алгоритмов — основа информатики.

А математика — основа точных наук. А философия — основа всех наук.

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

С развитеем отрасли, увеличивается объём информации. И если те кто стоят у истоков знают про отраль всё, то со временем знать всё просто физичиски не возможно. Появляются специализации — забываются основы. Уже сейчас всё яснее разрыв между программистом на С++ и оракл ДБА. И если сейчас ещё реально прыгать между языками и направлениями, то лет через 10, разница будет така я же как сейчас между инженером-акустиком и инженером-строителем.

S>Не знаю как там в default city,

Не знаю я там не работаю, те с кем я там пиво пил, простейшие вещи знают

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

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

S>При мне взяли на работу программиста, который не мог написать даже пузырёк, зато знает всякие ADO, XML, Struts, синглтоны, XP и пр. базворды

Ответьте, только честно, в его работе что он будет делать чаще писать свои сортировки или использовать АДО? Если раз в году он не справится с задачей по тому что нужно написать что то алгоритмичиски сложнее чем просто соединение вкучу компонент. То это не повод его не нанимать, ведь всё остальное время он приносит пользу.

S>В отрасли сейчас много лишних людей, т.к. сужается рынок.

Отрасль популярна — много случайных людей. Хотите область без случайных людей выбирайте что то маргинальное. С другой стороны останетесь заниматься алгоритмами лет через 10 окажетесь в маргинальной области сами собой. Просто таки произойдёт разделение и вы останетись с не модной специализаций программист-алгоритмист, а большенство уйдут в модные программист-на-...

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

Большенство проектов барахло. Кроме того, мы практичиски не создаём продукты. Большенство это аутсорс софт под конкретного заказчика и пр. Зрелость индустрии во много и определяется отношением количества звёзд к количеству "средних" специалистов. Индустрия программирования — повзраслела. Хотите быть среди лучших — уходите из программирование в что то сверх новое.

S>Как говорил Билл Гейтц: "на работу нужно брать только отличников (то есть тех кто помнит с вуза теорию алгоритмов). Если возьмёшь четвёрошников, то они наберут троешников и пиши пропало".

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

Что касается "(то есть тех кто помнит с вуза теорию алгоритмов)", то Микрософт богатая контора и может себе позволить воспитывать кадры, и вообще они стояли у истоков индустрии, так что у них немного всё иначе.

S>Не знаю как остальные, мы изучали и имплементировали qsort ещё в школе.

Я в школе алфавит учил, но если меня спросить какая буква 12 по счёту, то не уверен в адекватности моего ответа.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

S>>Потому что теория алгоритмов — основа информатики.

eaa>А математика — основа точных наук. А философия — основа всех наук.

eaa>Так может быть поговорим про метод Ньютона или о филосифии Канта (хм на до же, хоть кого то впомнил)? Я боюсь, что после таких вопросов на собеседовании, тут на форуме будут долго обсуждать неадыкватность того кто проводил собеседования. А каких то 100 лет назад инженер не разбирающейся в математике был не возможен. А ещё раньше любой ученый — филосов. Сейчас как дань уважения филосовию "учат" в институте и сдают для получения кандминимума.

Из уважения философию учат только невежды.

eaa>С развитеем отрасли, увеличивается объём информации. И если те кто стоят у истоков знают про отраль всё, то со временем знать всё просто физичиски не возможно. Появляются специализации — забываются основы. Уже сейчас всё яснее разрыв между программистом на С++ и оракл ДБА. И если сейчас ещё реально прыгать между языками и направлениями, то лет через 10, разница будет така я же как сейчас между инженером-акустиком и инженером-строителем.

S>>При мне взяли на работу программиста, который не мог написать даже пузырёк, зато знает всякие ADO, XML, Struts, синглтоны, XP и пр. базворды

eaa>Ответьте, только честно, в его работе что он будет делать чаще писать свои сортировки или использовать АДО? Если раз в году он не справится с задачей по тому что нужно написать что то алгоритмичиски сложнее чем просто соединение вкучу компонент. То это не повод его не нанимать, ведь всё остальное время он приносит пользу.

Он занимался разгребанием С++ гавнокода. Безуспешно.

S>>В отрасли сейчас много лишних людей, т.к. сужается рынок.

eaa>Хотите область без случайных людей выбирайте что то маргинальное.
Только после вас.

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

eaa>Большенство проектов барахло. Кроме того, мы практичиски не создаём продукты. Большенство это аутсорс софт под конкретного заказчика и пр. Зрелость индустрии во много и определяется отношением количества звёзд к количеству "средних" специалистов. Индустрия программирования — повзраслела. Хотите быть среди лучших — уходите из программирование в что то сверх новое.

А я и так среди лучших. В своей деревне.

S>>Как говорил Билл Гейтц: "на работу нужно брать только отличников (то есть тех кто помнит с вуза теорию алгоритмов). Если возьмёшь четвёрошников, то они наберут троешников и пиши пропало".

eaa>Да подобные тянутся к подобным. Если я выбираю из двух людей равнах по полезных для проекта скилзам — я выберу того кто лучше разбирается в алгоритмах, кто то другой того кто лучше шарит в базах. И что? Просто у каждого свои приоритеты.
eaa>Что касается "(то есть тех кто помнит с вуза теорию алгоритмов)", то Микрософт богатая контора и может себе позволить воспитывать кадры, и вообще они стояли у истоков индустрии, так что у них немного всё иначе.
Это каждый себе может позволить.

S>>Не знаю как остальные, мы изучали и имплементировали qsort ещё в школе.
eaa>Я в школе алфавит учил, но если меня спросить какая буква 12 по счёту, то не уверен в адекватности моего ответа.
Это заметно по вашей орфографии.

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

S>>>Потому что теория алгоритмов — основа информатики.

eaa>>А математика — основа точных наук. А философия — основа всех наук.

eaa>>Так может быть поговорим про метод Ньютона или о филосифии Канта (хм на до же, хоть кого то впомнил)? Я боюсь, что после таких вопросов на собеседовании, тут на форуме будут долго обсуждать неадыкватность того кто проводил собеседования. А каких то 100 лет назад инженер не разбирающейся в математике был не возможен. А ещё раньше любой ученый — филосов. Сейчас как дань уважения филосовию "учат" в институте и сдают для получения кандминимума.

S>Из уважения философию учат только невежды.

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

S>>>При мне взяли на работу программиста, который не мог написать даже пузырёк, зато знает всякие ADO, XML, Struts, синглтоны, XP и пр. базворды

eaa>>Ответьте, только честно, в его работе что он будет делать чаще писать свои сортировки или использовать АДО? Если раз в году он не справится с задачей по тому что нужно написать что то алгоритмичиски сложнее чем просто соединение вкучу компонент. То это не повод его не нанимать, ведь всё остальное время он приносит пользу.

S>Он занимался разгребанием С++ гавнокода. Безуспешно.

В как же "лучшие" наплодили то это говнокод? И помогли бы ему при этом сортировки?
Каждая компания получает тех сотрудников которых заслужила.

S>>>В отрасли сейчас много лишних людей, т.к. сужается рынок.

eaa>>Хотите область без случайных людей выбирайте что то маргинальное.
S>Только после вас.

Я уже там, я занимаюсь специфичной алгоритмикой. И стараюсь не знаниматься мейнстреймом.
Ктса, для сильно "грамотных", маргинальный — не значит отснойный, а просто не мейнстрейм.

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

eaa>>Большенство проектов барахло. Кроме того, мы практичиски не создаём продукты. Большенство это аутсорс софт под конкретного заказчика и пр. Зрелость индустрии во много и определяется отношением количества звёзд к количеству "средних" специалистов. Индустрия программирования — повзраслела. Хотите быть среди лучших — уходите из программирование в что то сверх новое.

S>А я и так среди лучших. В своей деревне.

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

S>>>Как говорил Билл Гейтц: "на работу нужно брать только отличников (то есть тех кто помнит с вуза теорию алгоритмов). Если возьмёшь четвёрошников, то они наберут троешников и пиши пропало".

eaa>>Да подобные тянутся к подобным. Если я выбираю из двух людей равнах по полезных для проекта скилзам — я выберу того кто лучше разбирается в алгоритмах, кто то другой того кто лучше шарит в базах. И что? Просто у каждого свои приоритеты.
eaa>>Что касается "(то есть тех кто помнит с вуза теорию алгоритмов)", то Микрософт богатая контора и может себе позволить воспитывать кадры, и вообще они стояли у истоков индустрии, так что у них немного всё иначе.
S>Это каждый себе может позволить.
Так мисье программист или бизнесмен?

S>Это заметно по вашей орфографии.
Я так понимаю, это самый веский аргумент.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

S>>Из уважения философию учат только невежды.

eaa>Остальные учат по тому что в программе есть. Ктса два семестра по паре в неделю — это знакомство, а не изучение для столь обширной науки.
eaa>И всё так вы съехали, почему бы не начинать собеседование с философии раз это основа основ?
Философия — не наука. Основа науки — не философии, а научный метод.

S>>Он занимался разгребанием С++ гавнокода. Безуспешно.

eaa>В как же "лучшие" наплодили то это говнокод? И помогли бы ему при этом сортировки?
Вот история программного продукта:
1. создание хорошего продукта выдающимися программистами третьих стран, съём большой части сегмента рынка у MS.
2. передача продукта америкацам, которые понаделали фич и внесли много ошибок, сделав код трудносопровождаемым, но всё ещё можно было спасти.
3. Убиение последней надежды данным кадром, который усугублял баги, а не исправлял их. Задачи были алгоритмические и более сложные чем qsort.
4. Закрытие проекта как нерентабельного.

eaa>Каждая компания получает тех сотрудников которых заслужила.
У кого заслужила?

S>>>>В отрасли сейчас много лишних людей, т.к. сужается рынок.

eaa>>>Хотите область без случайных людей выбирайте что то маргинальное.
S>>Только после вас.

eaa>Я уже там, я занимаюсь специфичной алгоритмикой. И стараюсь не знаниматься мейнстреймом.
eaa>Ктса, для сильно "грамотных", маргинальный — не значит отснойный, а просто не мейнстрейм.

В курсе.

eaa>>>Хотите быть среди лучших — уходите из программирование в что то сверх новое.
Только после вас.

S>>А я и так среди лучших. В своей деревне.

eaa>Каждый человек "лучший" — просто нужно линейку правильную выбрать.
eaa>А откуда же у лучших стоны про разгильдяев, сужение рынка? Или "лучших" "средние" щимят? Может "лучшие" неудачно линейку всё же взяли?
От того, что ложки дёгтя достаточно для порчи бочки мёда.

eaa>Так мисье программист или бизнесмен?
Гейтс — бизнесмен.

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

S>>>Из уважения философию учат только невежды.

eaa>>Остальные учат по тому что в программе есть. Ктса два семестра по паре в неделю — это знакомство, а не изучение для столь обширной науки.
eaa>>И всё так вы съехали, почему бы не начинать собеседование с философии раз это основа основ?
S>Философия — не наука. Основа науки — не философии, а научный метод.

Пифагор — метематик
Фалес — метематик
Декарт — метематик, физик
Галилео — физик

И список можно продолжать. Так почему они все были философами?

А является ли философия наукой или нет можно спорить долго.

S>>>Он занимался разгребанием С++ гавнокода. Безуспешно.

eaa>>В как же "лучшие" наплодили то это говнокод? И помогли бы ему при этом сортировки?
S>Вот история программного продукта:
S>1. создание хорошего продукта выдающимися программистами третьих стран, съём большой части сегмента рынка у MS.
S>2. передача продукта америкацам, которые понаделали фич и внесли много ошибок, сделав код трудносопровождаемым, но всё ещё можно было спасти.
S>3. Убиение последней надежды данным кадром, который усугублял баги, а не исправлял их. Задачи были алгоритмические и более сложные чем qsort.
S>4. Закрытие проекта как нерентабельного.

Ну просто детектив.
Одно не понятно как один человек смог угробить такой чудесный продукт?

S>>>>>В отрасли сейчас много лишних людей, т.к. сужается рынок.

eaa>>>>Хотите область без случайных людей выбирайте что то маргинальное.
S>>>Только после вас.

eaa>>Я уже там, я занимаюсь специфичной алгоритмикой. И стараюсь не знаниматься мейнстреймом.
eaa>>Ктса, для сильно "грамотных", маргинальный — не значит отснойный, а просто не мейнстрейм.

S>В курсе.

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

S>>>А я и так среди лучших. В своей деревне.

eaa>>Каждый человек "лучший" — просто нужно линейку правильную выбрать.
eaa>>А откуда же у лучших стоны про разгильдяев, сужение рынка? Или "лучших" "средние" щимят? Может "лучшие" неудачно линейку всё же взяли?
S>От того, что ложки дёгтя достаточно для порчи бочки мёда.

Так зачем лезть с ними в одну бочку?

eaa>>Так мисье программист или бизнесмен?
S>Гейтс — бизнесмен.

Так любая контора? Или есть контора которая показала, что это работает?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

eaa>И список можно продолжать. Так почему они все были философами?
Потому что

eaa>А является ли философия наукой или нет можно спорить долго.

S>>>>Он занимался разгребанием С++ гавнокода. Безуспешно.

eaa>>>В как же "лучшие" наплодили то это говнокод? И помогли бы ему при этом сортировки?
S>>Вот история программного продукта:
S>>1. создание хорошего продукта выдающимися программистами третьих стран, съём большой части сегмента рынка у MS.
S>>2. передача продукта америкацам, которые понаделали фич и внесли много ошибок, сделав код трудносопровождаемым, но всё ещё можно было спасти.
S>>3. Убиение последней надежды данным кадром, который усугублял баги, а не исправлял их. Задачи были алгоритмические и более сложные чем qsort.
S>>4. Закрытие проекта как нерентабельного.

eaa>Ну просто детектив.
eaa>Одно не понятно как один человек смог угробить такой чудесный продукт?
А что тут непонятного? Есть центральный цикл вёрстки, очень ответственное место. И в него вносятся фичи, к которым привыкают пользователи. Вместе с фичами появляются баги.
С помощью goto, глобальных переменных и пр. Он его похоронил, а мог бы и вылечить.

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

Мои мотивы не имеют отношения к дискуссии.

eaa>>>Каждый человек "лучший" — просто нужно линейку правильную выбрать.
eaa>>>А откуда же у лучших стоны про разгильдяев, сужение рынка? Или "лучших" "средние" щимят? Может "лучшие" неудачно линейку всё же взяли?
S>>От того, что ложки дёгтя достаточно для порчи бочки мёда.

eaa>Так зачем лезть с ними в одну бочку?

В деревне бочек немного. Я нахожусь в лучшей.

eaa>>>Так мисье программист или бизнесмен?
S>>Гейтс — бизнесмен.

eaa>Так любая контора? Или есть контора которая показала, что это работает?
Что "любая контора". Что "это"?

	От:	elmal
	Дата:	15.08.09 07:40
	Оценка:

	От:	Sashaka
	Дата:	15.08.09 08:24
	Оценка:	1 (1) +3 -3

	От:	Nik_1
	Дата:	15.08.09 09:01
	Оценка:

	От:	Igor Sukhov
	Дата:	15.08.09 09:07
	Оценка:	1 (1)

	От:	eaa
	Дата:	15.08.09 09:27
	Оценка:	30 (5) +2 -1

От:	kosmik	http://www.linkedin.com/in/kosmik
Дата:	15.08.09 16:54
Оценка:

	От:	BishopMorton
	Дата:	16.08.09 00:15
	Оценка:	23 (3)

От:	x64	http://x64blog.name
Дата:	16.08.09 01:11
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	16.08.09 20:17
Оценка:	9 (1) +1

От:	DmitriN	http://nesteruk.wordpress.com
Дата:	17.08.09 05:29
Оценка:

От:	Gradient	http://www.x-trips.com/
Дата:	17.08.09 07:59
Оценка:

От:	alex_mah	www.elsy.ru
Дата:	17.08.09 11:43
Оценка:	+1

	От:	Геннадий Майко
	Дата:	21.08.09 13:30
	Оценка:	10 (3) +1

От:	Pzz	https://github.com/alexpevzner
Дата:	21.10.09 22:14
Оценка: