Здравствуйте, 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, а в россии исследуют то, сколько багов и фич помнит человек.

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

S>Нужно посадить человека за компьютер и заставить написать 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...) и рандомно выбрать язык и алгоритм, и предложить кандидату реализовать этот алгоритм на этом языке. Дать книгу и транслятор. То пожалуй подобное интервью будет весьма показательным, но, боюсь, много людей вы так не наберёте.

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

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

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? С какого перепоя?