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

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

Ну тогда мы возвращаемся к исходному вопросу — как правильно определить на интервью, подходит человек или нет?

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

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

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

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

J>Ну тогда мы возвращаемся к исходному вопросу — как правильно определить на интервью, подходит человек или нет?
Попробуем. Если не ошибаюсь, было только одно интервью?

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

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

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

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

A>Да ладно, я такие копипасты индусские встречал, эти чудаки даже не удосуживались вычистить ненужный функционал в несколько сотен строк. И еще орали на code review — не называй наш код копипастой.
Сталкивался с такими персонажами.
Скопипастили свою же огромную функцию строк на тысяч 4-5 (файлы меньше чем в 10 тыс строк у них встречались редко)
В начале функции if с телом, составляющим где то процентов 80 от функции, который в новом месте был не нужен вовсе.
Но вместо того чтоб удалить его идус просто дописал перед if кучу присваиваний, которые обеспечивали что условие в if (тоже кстати длинное) всегда будет false.

05.11.2010 7:21, justinian пишет:

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

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

V>05.11.2010 7:21, justinian пишет:

>> Я с этим согласен. Вопрос — как конкретно вы на интервью распознаете
>> людей способных решать проблемы?
V>Единственный способ выяснить, как человек решал проблемы на прошлых работах.

Как вы себе это представляете?

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

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

Кроме всяких шуток, "не помню" — это не дежурная отмазка. Во всяком случае, как уже в ветке писали, в состоянии стресса (лично для меня интервью — всегда неслабый стресс) человек может вести себя не так, как в рабочей обстановке. Пару дней назад проходил интервью, так что по свежим впечатлениям... Один из интервьюеров задал дежурный вопрос про виртуальный деструктор (изыгранный баян), а потом минут N-дцать долбил, как заведенный (может, для него это тоже был стресс?) "вы вот все хорошо рассказываете, но я не вижу деталей и из вашего рассказа не улавливаю — какова была ваша роль? выберите проект, которым гордитесь, и нарисуйте для него диаграмму классов, или опишите алгоритм, который использовали". Ну что я, держу в голове то, что делал полгода-год назад? Дальше анекдот: начинаю кое-как рисовать диаграмму классов для кода, который незадолго до того писал. Примитив полный: 1 базовый класс, 2 производных класса, 2 вирт. метода. Интервьюер спрашивает "а почему тут нельзя просто написать две отдельные функции, а не городить ООП и полиморфизм"? Даже вот такой простой, как амеба, код работает не в сферическом вакууме(ТМ), значит, надо еще рассказать, где это применяется, и главное — зачем. Начинаю ему объяснять, товарищ снова недоволен: "не будем углубляться в детали", и тут я уже срываюсь слегка и заявляю "ну вы же сами просили детали!" Смотрю краем глаза, второй интервьюер тихо сползает со стула

Выводы? Да опять же, никаких.

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

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

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

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

Что касается, поговорить неформально с бывшими коллегами это в моей текущей ситуации вобще не применимо.

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

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

UA>>>>>В репозитарии не должно быть не компилябельного кода.
U_E>>>>и дело разработчика поправить этот момент, разве нет
CC>>>Речь о разработчике которого недавно взяли.

AV>>Несколько месяцев назад — это недавно?
CC>Мне SCSI PR вынесло моск.
CC>Невнимательно прочитал топикстартера.

Я так и подумал.

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

K>Хотя опять же — тут всё зависит от постановки задачи. Если задача была поставлена так: "Вот тут возьми код, и поправь в нём то-то и тот-то" — то ожидать вопросов на тему того, что оно не билдится, вполне нормально.

Не совсем согласен. Логично было бы если бы вопрос звучал примерно так: "утилитка не билдится, потому что пути неверные". И далее или вопрос "сейчас вот такие вот пути. Их использовать?" или хотя бы "какие пути сейчас используются". Хотя если утилитка использует что-то что использовалось на проекте, где человек был занят, то второй вариант тоже достаточно подозрителен

05.11.2010 11:26, justinian пишет:
> V>Единственный способ выяснить, как человек решал проблемы на прошлых
> работах.
>
> Как вы себе это представляете?
Честно, я уже устал повторять одно и тоже.
1. Представьте, что перед вами не робот, не компьютер, а живой человек.
2. Попросите человека рассказать о своем прошлом опыте.
3. Слушайте человека и задавайте уточняющие вопросы по необходимости.
4. Поговорите на темы, с которыми будет связана его дальнейшая работа
(вот здесь и пригодятся бумажка с ручкой).
5. Выясните, что человеку интересно делать и как ему нравиться работать.
6. На основе предыдущих пунктов принимайте решение подходит ли вам этот
человек или нет.

05.11.2010 11:40, justinian пишет:

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

>
> Кроме того, для меня ситуация усугубляется тем, что наша контора
> аутсорсинговая. Заказчик платит за головы, заполнение вакансий является
> делом срочным, причем кандидат при необходимости еще и должен суметь
> пройти интервью у заказчика.
Т.е. ты сам не знаешь чем будет заниматься нанимаемый человек?
Т.е. ты взял специалиста в С++, а задачи ему даются по С# или наоборот?
Я правильно понял?
Тогда вариант у тебя только один — брать студентов (они специалисты во
всем и ни в чем), набор через экзамен, чтобы хоть что-то умели и
увольнять чуть что.
Итого, дешево, быстро и некачественно — но, именно это вами надо.

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

V>05.11.2010 7:21, justinian пишет:

>> Я с этим согласен. Вопрос — как конкретно вы на интервью распознаете
>> людей способных решать проблемы?
V>Единственный способ выяснить, как человек решал проблемы на прошлых работах.

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

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

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


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


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

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

J>>даем прямо на интервью написать на ручкой на бумаге

D>Один из самых раздражающих приемов интервьюеров. Мой совет — дайте ноут пусть хоть с голым нотепадом.

Кстати, да. Писать что-то ручкой само по себе неудобно(отвыкаешь полностью от этого навыка за годы неиспользования), а уж код и подавно(IDE нынче умные, и огромную черновую работу по написанию кода делают сами, и руками это возпроизводить — )

Здравствуйте, Stanislav V. Zudin, Вы писали:


D>>Один из самых раздражающих приемов интервьюеров. Мой совет — дайте ноут пусть хоть с голым нотепадом.

SVZ>Хум, как говорится, хау.
SVZ>Мне, например, с бумагой и ручкой лучше думается.


А я уже забыл, когда последний раз писал что-либо длиннее номера телефона.

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


CC>Скопипастили свою же огромную функцию строк на тысяч 4-5 (файлы меньше чем в 10 тыс строк у них встречались редко)
CC>В начале функции if с телом, составляющим где то процентов 80 от функции, который в новом месте был не нужен вовсе.
CC>Но вместо того чтоб удалить его идус просто дописал перед if кучу присваиваний, которые обеспечивали что условие в if (тоже кстати длинное) всегда будет false.

Жестко.

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

J>Ну тогда мы возвращаемся к исходному вопросу — как правильно определить на интервью, подходит человек или нет?

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

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

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

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

J>Советы в принципе правильные. К сожалению, человек может очень убедительно рассказать как он решал задачи на предыдущей работе, а потом окажется, что работать он не хочет.

Почему не хочет? Какая проблема на интервью выделить круг задач, которые интересны соискателю? Хотя бы потому, о каких проектах он рассказывал более увлеченно

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

J>Выводы? да собственно никаких

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