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

Есть ещё один тип спецов — кто умеет работать.

Вопрос лишь в том, есть ли среди первых вторые =)

Цыплят я считаю уже 4 года, и вполне успешно

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

S>Цыплят я считаю уже 4 года, и вполне успешно

Поздравляю!

Только тогда к чему этот тред? Почесать ЧСВ?

Активная работа по разработке ПО на заказ у меня идет уже 5-й год, столько же лет моему подходу. Пока полет нормальный.

S>Другими словами: 100 человек получили задание, 99 сделало плохо и обосрало тебя и твой подход, а 1 просто взял и молча сделал хорошо. Да и плевать тогда на мнение этих 99 — оставшийся 1 получает работу, делает ее хорошо, я и он получаем деньги от заказчика и положительный отзыв. У нас в стране так часто: один работает, остальные трендят. Меня в общем-то несильно волнует мнение остальных 99, которые не умеют работать хорошо.
<...>
S>Но все же мне очень интересно обсудить — а на что вы бы смотрели в коде?
<...>
S>Кроме того, при очном собеседовании часто можно попасть в ловушку "мне кажется, что человек умный, потому что он согласен со мной".

Опуская все остальное: когда вы читаете код, с которым "согласны" — вам автоматически кажется, что кандидат умный. Так что вы попадаете ровно в ту же ловушку. Просто с затратами на порядок бОльшими.

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

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

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

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

F>на оформление, простоту, понятность, стандартные подходы.

F>проблема в том, что тестовое могут сделать хорошо, а дальше будут проблемы.

Мне кажется, что это куда менее вероятно, чем обратное. Когда тестовое сделал плохо, а потом в реальной работе все хорошо.

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

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

SD>Опуская все остальное: когда вы читаете код, с которым "согласны" — вам автоматически кажется, что кандидат умный. Так что вы попадаете ровно в ту же ловушку. Просто с затратами на порядок бОльшими.
Код обладает объективными характеристиками — mantainability index, связность классов, количество строк, плотность багов итп.
Кроме того код показывает насколько человек ответственен (если сроки ограничены) и внимателен (если есть нетривиальные требования).


SD>Поймите: в конечном итоге вы всегда выбираете того, кто вам нравится. По какой причине нравится — дело десятое.
Не десятое, а первое, и собственно самое главное. Нравится что и как человек говорит или нравится что и как делает — две огромные разницы.

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

SD>Испытательный срок неспроста существует.
Большинство работодателей его не использует никак.

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

K>Мне кажется, что это куда менее вероятно, чем обратное. Когда тестовое сделал плохо, а потом в реальной работе все хорошо.

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

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

S>Ну все, пора заканчивать, а то целую поэму уже накатал. Как всегда, на правах рекламы — если вас не отпугивает мой подход, то приглашаю к себе разработчиков dotNet. Нам нужны и фултайм в офис (м. 1905 года), так и на удаленку. Проекты — разные, в основном интересные Пишите мне на mailbox at nevlabs dot ru с темой письма "Разработчик на удаленку (код rsdn-dev)". В письме расскажите о себе: из какого вы города, сколько вам лет, кратко-кратко о своем опыте, сколько есть свободного времени на мои проекты. Как я писал выше, я оцениваю кандидатов в первую очередь с позиции тестового задания — поэтому оно обязательно. Жду вас!
Тестовое задание какого рода и какого объема? А то пока что то куча работодателей хочет что то довольно объемное, порядка недели. При этом сама задача фигня, но нужно разбираться в новой технологии, а то и еще в предметной области. И ладно если б у меня самого было желание поиграться с какой технологией. Так ведь экзотическое хотят. Пока отказываюсь выполнять (точнее откладываю), ссылаясь на наличие неплохих офферов без такого геморроя.

Сам тестовое задание давал, удаленное. Время засекал — 1 час. Сам пробовал его сделать, сверхуставший сделал за 30 минут в свое время, параллельно с кандидатом. Самое смешное, что так и не довелось встретить кандидата, который его выполнил хорошо. Максимум удовлетворительно. В основном типичный косяк — любят на ровном месте фабрики фабрик городить. Соответственно не успевают за час. И даже за 4 не успевают с таким переусложнением. Но когда сделают, то имеем на выходе раздутый код с большим количеством классов на ровном месте, кучей копипасты, при этом не расширяемо ни фига. Эталонное решение, которое хотел бы увидеть — 3 класса, в сумме строчек 100, даже ближе к 50-и, никаких наворотов. Про как можно проще говорю сразу, и сразу говорю, что с наворотами фиг успеете и не оценю навороты скорее всего. Куда там. Кстати, брал в принципе людей и с посредственными результатами. Но квалификацию ставил обычно нижний миддл или старший юниор. Если следить — в принципе нормально наботают, а через полгодика вообще нареканий нет почти. Но если блин не следить — потом задолбаешься все рефакторить.

Соответственно тестовое задание простенькое ОЧЕНЬ полезно. Вот только простенькое и быстрое, а не написать блин прототип клона фиг пойми какого сайта за неделю на чем то экзотическом, при этом еще и разобраться самому что сторонний сайт делает, и там еще регаться нужно.

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

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

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

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

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

Хороший пост. Хорош он тем, что описывает реальный практический опыт. Теперь ждем отчета о правильности выбора претендентов.

Теперь немного покритикую подход.

S>Критики данной позиции делятся на 2 части:
S> — те, кто против выполнения каких-либо тестовых заданий вообще;
S> — те, кто против выполнения ТЗ на дому (а на собеседовании — ок).
Я к первым отношусь . И вот почему. Решение "беру/не беру" принимается в первые три секунды после того, как кандидат открыл дверь. Это происходит на уровне подсознания. Дальнейшая беседа это способ либо подтвердить свое решение о приеме, либо поиск причины для отказа. Надо быть очень прокачанным в психологии, чтобы этого избежать и судить беспристрастно. Таким образом, всякие тестовые задания я считаю бессмысленными. Гораздо более продуктивно, опять же с моей точки зрения, разговор с кандидатом о предметной области, об инструментах, предыдущем опыте. Обычно в таких разговорах проскакивают слова маркеры, по которым довольно точно можно определить насколько он в теме. Правда за этим нужно следить и соответственно выстраивать беседу.

Ваш подход это просто своеобразный фильтр, первичный отсев. А дальше работает то, что я описал. То есть, ваш подход помогает сформировать шорт-лист, а не принять на работу.

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

l> P.S. А мне вот интересно, а люди, которые работаю плохо в нашей области — они вобще бывают?

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

Здравствуйте, sanchez911, Вы писали:
s> Критики данной позиции делятся на 2 части:
s> — те, кто против выполнения каких-либо тестовых заданий вообще;
s> — те, кто против выполнения ТЗ на дому (а на собеседовании — ок).
Было бы интересно увидеть статистику тех кто брался вообще за ТЗ: у меня есть такое подозрение, что подавляющее большинство таких кандидатов будет из "глубинки" где рынок труда очень ограничен и/или люди на начальном этапе своей карьеры.

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

DO>Я к первым отношусь . И вот почему. Решение "беру/не беру" принимается в первые три секунды после того, как кандидат открыл дверь. Это происходит на уровне подсознания. Дальнейшая беседа это способ либо подтвердить свое решение о приеме, либо поиск причины для отказа. Надо быть очень прокачанным в психологии, чтобы этого избежать и судить беспристрастно.

Не надо.
Понимание когнитивных искажений не помогает их избежать. Будь ты хоть доктор психологии, ты все равно будешь составлять мнение о человеке в первые 3 секунды, а потом убеждать себя в правильности мнения.
Чтобы избежать когнитивных искажений надо уметь проводить собеседования. В первую очередь надо иметь список вопросов и понимать какие ответы должен давать кандидат. И список этот должен быть на бумаге, а не в голове. Для собеседования нужен "скрипт" примерно как для продажи. Это еще и время значительно экономит.

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

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

Спасибо за честность.
Вы, конечно, вольны поступать как угодно. Возможно, вы круты, даете интересные задачи и много денег и к вам действительно стоит очередь соискателей.
Но, надеюсь что вы понимаете две вещи:

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

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

S> Правильный ответ, до которого нынешняя IT-служба (сторонняя контора) дошла только через 2 месяца жалоб — долгие пинги (а скорость уже установленного соединения — нормальная). Там какой-то странный провайдер, у которого линк идет через Канаду. Отсюда и все проблемы. На этот вопрос большинство кандидатов тоже не смогло ответить. И ведь это люди из шорт-листа, на приличную зарплату!

Я правильно понимаю, что вы хотите от человека, который ни разу не видел и не "щупал" ни ваш продукт, ни оборудование сходу получить ответ, до которого цельная контора доходила 2 месяца?

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

S>Всем привет!

Привет!

S>Итак. Сначала — о поиске разработчиков.

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

То есть когда человек проработал в 10 конторах, сделал 20 проектов на разных технологиях. Когда человек имеет опыт 10-15-20 лет никакие тестовые задания не нужны. Так как и так понятно что нельзя столько лет в профессии и не уметь делать проекты.

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

Вот у меня напротив сидит человек с опытом 20 лет — занимается виртуализацией в ядре, если ему вдруг захочется начать заниматься GUI или фильтрацией сетевого трафика, то через две недели он сможет это делать на высшем уровне.

Ну и если его набирать на работу, то какое тестовое задание ему давать?

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

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

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

Я вот сейчас наблюдаю творчество таких людей отобранных видимо по ТЗ.
Плакать хочется от их решений и подходов. То ли студенты работали, толи барышни.