Всем привет!

Предыдущие серии: серия-1

Автор: sanchez911
Дата: 17.09.15

, серия-2

Автор: sanchez911
Дата: 15.10.15

.

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

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

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

Критики данной позиции делятся на 2 части:
— те, кто против выполнения каких-либо тестовых заданий вообще;
— те, кто против выполнения ТЗ на дому (а на собеседовании — ок).

Наиболее часто встречается мнение, что тестовое задание — это зверство по отношению к кандидату, что это говорит непрофессионализме работодателя, и много-много других мнений, сходящихся в том, что ТЗ — это плохо и "я бы ни за что не пошел туда, где дают тестовое задание". Мол, вот пусть кандидаты показывают свой код из реальных проектов; код говорит о многом, по коду можно понять, что за человек. И я возьму на себя смелость возразить.

Нет, друзья, нихрена код не показывает. Код позволяет увидеть стиль программирования, но не личные качества. Я много раз встречал примеры аккуратно, хорошо оформленного кода, который работал неправильно. Причины могли быть разные: либо ошибка на системном уровне, либо более мелкие ошибки из-за невнимательности (а это важно!). Вникать же в представленный код настолько глубоко, чтобы находить подобные ошибки — у меня просто банально нет на это времени. Как вы думаете, если на объявление на каком-нибудь hh.ru приходит более 100 откликов за неделю, реально ли подробно и детально изучить код каждого из них? Неважно, кому это делать: мне, или тимлиду — времени уйдет очень много, и реальная работа на это время встанет. И еще раз хочу напомнить: красиво оформленный код нередко работает плохо!

У тестового задания есть очень хороший плюс. Это задание, выданное разным кандидатам, позволяет _сравнить_ их между собой. Для начала можно даже несильно вникать в код. Достаточно просто прогнать различные тестовые ситуации. На них можно отсеить 80-90% человек. И если кто-то из них начнет доказывать, что это я сам осел, что не оценил такую хорошую программу, то на это можно смело забить: у тебя есть 10%, которые выполнили задание хорошо, а значит задание адекватно, и твои тесты — тоже.

Если же мне дают посмотреть код, то сравнивать людей между собой гораздо сложнее. Допустим, один показал код простой задачи (и он сделан хорошо), другой — код сложной задачи — и он сделан средне. Как понять, хорошо ли покажет себя программист 1 на сложной задаче? А может программист 2 хорошо себя покажет на более простых задачах и не стоит его сразу отфутболивать? Другими словами, если давать одинаковое тестовое задание всем программистам, то на выходе я получаю нормированный результат, а если сравнивать их продакшн-код — то нет, и у меня понятия нет, как его нормировать.

Еще один пример удобства сравнения людей по ТЗ. Когда я разработчику говорю в отказе, потому что в таком-то случае программа повела себя неправильно, мне порой отвечают — да, но это же тестовое задание. Но у меня есть люди, которые и в тестовом задании эту ситуацию обрабатывают правильно. Если один поленился, а другой нет, разве это не помогает сделать выбор? Да и откуда мне знать, человек действительно знал, но не сделал из-за объема, или не догадался протестировать одну из возможных ситуаций? А это ведь важно в работе.

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

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

Но все же мне очень интересно обсудить — а на что вы бы смотрели в коде?

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

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

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

Кстати, еще ремарка. У успешных и известных компаний подход аналогичен. Скажем, тестовые задания на дом есть у яндекса, есть у студии Лебедева. И нельзя сказать, что они очень маленькие (хотя зависит от должности). Можно возразить, что я — не студия Лебедева, но значит ли это, что нельзя брать пример с лучших компаний? А может быть они не просто так стали лучшими?

С разработчиками разобрались, идем дальше. Ранее я рассказывал, что ввязался в один совместный проект по разработке и продаже ПО для медицинской сферы (организовали с заказчиком ранее разработанной программы совместное предприятие).

Так вот, там нужно было взять несколько человек непрограммистской направленности, а именно: руководителя IT-службы, руководителя отдела обучения, менеджера сопровождения. Руководитель IT должен сформировать свой отдел, т.е. набрать сисадминов, и обеспечивать нормальное функционирование инфраструктуры у наших клиентов (клиник). Отдел обучения должен обучать юзеров нашей программе. Менеджер сопровождения — ну что-то типа личного менеджера у каждого клиента, хорошо знает нашу программу, помогает им в сложных вопросах, передает нам их хотелки.

В общем, разместили вакансии на хедхантере. На IT-директора пришло 300 откликов, на остальные должности — около 50. Я решил для начала дать людям тоже простенькую "домашку".

Для IT руководителя задал 3 вопроса: как бы вы объяснили девушке-гуманитарию три вещи: ARP, облако (чем отличается от сервера-кластера), отличия винды от линукса. Смысл именно таких вопросов в следующем. Во-первых, по характеру объяснения будет понятно, понимает ли человек реально термин, который он разъясняет. Например, далеко не все правильно понимали ARP. Во-вторых, по тому, насколько человек внятно умеет объяснять, насколько он сможет "транслировать" пояснение для гуманитария, можно судить, насколько он адекватен в целом. Например, многие, кто знал суть ARP, пытались его объяснить техническими терминами, что было бы непонятно стороннему человеку. Ну ведь написано же в задании: девушка-гуманитарий!

Руководитель обучения получил 1 вопрос — просьбу объяснить врачу "что такое компилятор". Опять же, доступную аналогию проводили немногие, на четверку считался ответ "это переводчик с языка человека на язык компьютера". На четверку, потому что в общем-то суть правильна, но ответ похож на отмазку. Что значит "язык компьютера"? Мне больше нравится, когда человек проводит понятную для слушателя аналогию. Например, кто-то объяснял на примере расшифровки медицинского рецепта пациенту.

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

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

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

Ну, про катастрофы вообще никто правильно не ответил. Некоторые вообще отвечали что-то в духе "безопасность надо мерить количеством происшествий, где меньше там и лучше". Впрочем, заставлял задуматься мой вопрос "за месяц 100 самолетов перевезло 10000 человек, 2 разбилось; за тот же месяц 2 автомобиля перевезло 4 человека, 1 разбился — значит автомобиль безопасней?". Ну и все в таком духе. Кстати, была у меня в кандидатах на обучателя одна девушка, которая пишет диссертацию с активным использованием аппарата матстатистики, и она тоже бредово ответила.

А вот с яндекс-картами интересней. Технари отвечали хуже, чем гуманитарии — те чаще догадывались до правильного ответа.

Еще, что меня поразило — это крайне низкий уровень технических знаний у IT-директоров. Почти никто не знал отличия BIOS от UEFI, никто не знал что такое GPT-диск, на вопрос "чем fat32 отличается от ntfs" наиболее распространенный ответ — "у ntfs размер раздела может быть больше", как реально работает маска подсети почти никто не знает, ну а wildcard-маска — это вопрос-fatality У меня была еще задачка из недавней реальной практики. У нас толстый клиент, который коннектится к WCF. Несколько клиник в Москве. Сервер в Москве. Клиники коннектятся к серверу через инет. В одной из клиник жалуются на медленную работу программы, в остальных все нормально. Все условия идентичны: одно железо, одни компы, один набор прикладного софта. Скорость инета в "медленной" клинике — даже больше, чем в других — скачивали большой файл с сервера и замеряли время. В чем может быть причина? Правильный ответ, до которого нынешняя IT-служба (сторонняя контора) дошла только через 2 месяца жалоб — долгие пинги (а скорость уже установленного соединения — нормальная). Там какой-то странный провайдер, у которого линк идет через Канаду. Отсюда и все проблемы. На этот вопрос большинство кандидатов тоже не смогло ответить. И ведь это люди из шорт-листа, на приличную зарплату!

Когда я осмелился дать им обратную связь — мол, господа, ну нельзя же так, — стал получать ответы "а я же руководитель, я буду руководить, а разбираться в этом должны мои сисадмины!". На что я сразу задавал следующий тестовый вопрос: вам нужно набрать себе в штат 2 сисадмина. Разместили вакансию, пришло 500 откликов. Как вы будете выбирать? Первое, что отвечали — по резюме. Ну ок, говорю я, выбрали 100, с идеальными резюме. Дальше? Дальше ответы варьировались (но мало какие мне понравились). Наконец, дошли до истины: как вы будете собеседовать людей себе в подчинение, если сами не разбираетесь ни в чем? Все это я спрашивал со свойственной мне прямотой и заработал некоторые обиды на себя)))) В общем, печально.

В итоге из 25 прособеседованных человек мне понравился один IT-директор, 3 руководителя обучения и 2 менеджера. Пригласил их на еще одно собеседование — со вторым учредителем (он более бизнесовый, чем технарский, поэтому взгляд со стороны очень полезен). И в общем-то по результатам я мысленно похвалил себя за правильный выбор: IT-директор понравился, руководители обучения понравились все (пришлось выбирать), и только менеджеры оба не понравились — их не взяли. А так моя методика оказалась пока что успешной Посмотрим, как эти люди будут вести себя в работе, но пока мне их деятельность нравится.

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

See you!

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

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

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

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

T>где-то на половине прочтённого, мне показалось что автор занимается самоудовлетворением
так и есть, ну и ещё в каждом абзаце — вы все дураки, а я дартаньян, и мне покласть с прибором на чужое мнение))


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

Раньше давал тестовые задания, потом отказался.

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

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

K>Автор всего-лишь говорит, что его задача — найти работников, а не получить одобрение от неудачливых кандидатов. Вполне адекватная точка зрения. Пока ему удается находить подходящих людей.

Нет, автор говорит что ему покласть на мнение 99 людей, потому что они не прошли его тесты, простая мысль что это не люди отстой, а его тесты, в его светлую голову не вмещается, потому что, о боже, человек который прошёл его тест — оказался хорошим работником. То что он отсеял быть может на порядок лучших работников, ему тоже в голову не приходит. Ведь он думает так — похож на меня, значит хороший. Это конечно распространённое ошибочное мнение, но всё таки оно ошибочное. Про остальные опусы автора а-ля "код нихрена не показывает" и то что автор в коде видит только его "аккуратность", это вообще пять, похоже автор дальше джуна в разработке не продвинулся. В общем там сплошной фейспалм, если честно всё лень комментировать. Но в целом забавно, как человек абсолютно не воспринимает критику и отвергает здравый смысл, но полон самоуверенности, wishful thinking и поклонения культа карго.

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

Да миллион раз уже обсуждали.

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

Такой подход к собеседованию может быть оправдан в трёх случаях:
1. Вы работодатель с мировым именем, и к вам выстроилась очередь желающих работать именно у вас.
2. На рынке острый дефицит рабочих мест.
3. Для выполнения вашей работы нет нужды в программистах хорошего уровня, достаточно средних джуниоров.

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

S>>>У тестового задания есть очень хороший плюс. Это задание, выданное разным кандидатам, позволяет _сравнить_ их между собой.
L>>Говорят, из заведомо ложного предположения вытекает все, что угодно.
L>>Тут именно такой случай.

S>Ммм, а как вы опровергнете тезис о том, что ТЗ позволяет сравнивать людей между собой?

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

P.S. Поиск неисправности в сети доставил

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

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

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

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

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

Привет!

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

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

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

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

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

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

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

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

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

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

S>See you!

Удачи!

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

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

T>>где-то на половине прочтённого, мне показалось что автор занимается самоудовлетворением
A>так и есть, ну и ещё в каждом абзаце — вы все дураки, а я дартаньян, и мне покласть с прибором на чужое мнение))

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

> Работнику достаточно подать в суд и

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

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


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

"хоть ссы в глаза, всё божья роса"

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

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

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

Говорят, из заведомо ложного предположения вытекает все, что угодно.
Тут именно такой случай.

S>Руководитель обучения получил 1 вопрос — просьбу объяснить врачу "что такое компилятор".
Сдается мне, чтобы объяснить что-то сложное человеку, нужно знать о нем немного больше. Или хотя бы иметь живую обратную связь.
Может быть, этому врачу не требуется расшифровывать чужие каракули т.к. работает только через ПК, или вообще никогда в жизни рецептов не выписывал тк он — патологоанатом. А вот аптекарю такое объяснение было в самый раз.


S>А вот с яндекс-картами интересней. Технари отвечали хуже, чем гуманитарии — те чаще догадывались до правильного ответа.


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


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

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

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

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

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

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

Начало: «Приходит на работу всякое быдло, которое денег хочет, а глубокими знаниями не обладает. Тесты помогают их отсеивать, зачем мне балласт? Тесты объективны, а без них можно ошибиться и взять быдло.» Нуок, допустим.

...

Конец: «Приходите на меня работать!»

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

«У нас бесплатная кормежка в ресторанах, крутые корпоративы, офис в минуте от метро, парковку оплачивает работодатель, поэтому есть ради чего попотеть, пытаясь попасть к нам на работу. Кроме того, мы через 2 года выйдем на IPO, дадим вам опционы, которые сделают вас миллионером, и вам самим же в первую очередь выгодно, чтобы шлак отсеивался. А если вдобавок к прочему вы тщеславный ублюдок, то наша компания называется Студия-Лаборатория ВМикроАртСофте и у вас будет крутая визиточка». Удивите меня: напишите, что хоть одно письмо с кодом «rsdn-dev» получили.

G>1. Вы и вправду считаете что ИТ-директор должен обладать равными или большими знаниями в каждой из областей, что и узкие специалисты в его компании.
Неужели знание отличий NTFS от FAT32 это нечто особенное? Ну пусть он не знает про размеры кластеров и про ограничение на их кол-во, но ведь можно уж хотя бы знать, что в ntfs есть нативное шифрование/сжатие, просто банально потому что в свойствах папки есть такая галочка? Или _хотя_бы_ сказать, что UEFI отличается от биоса наличием графики и поддержкой мыши? Не пинайте, я знаю, что там еще миллион отличий, но видимо, если человек не знает даже этой банальности, то скорее всего он никогда не заходил в меню уефи, или думал что это меню ОС? Мое мнение — что это базовые понятия, я не спрашивал тонкости вроде "в чем отличие MBR от загрузочной записи на GPT-диске". Хотя я вот сам не админ, и не ИТ-директор, а человек, ставший во многом манагером, но почему я эти вещи знаю? На должности ИТ-директора, я считаю, должен быть гик, а гики всегда интересуются техническими вещами.

G>3. Каким вы сами считаете правильным ответом на вопрос "— в какой размерности правильно считать безопасность транспорта? Кол-во погибших на....?" Я, надеюсь, ответ не "Кол-во погибших на количество перевезенных километров, (этакое трупы на километр)"
Ну да, кол-во погибших на перевезенных человекокилометров. А как правильно на ваш взгляд?

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

G>>1. Вы и вправду считаете что ИТ-директор должен обладать равными или большими знаниями в каждой из областей, что и узкие специалисты в его компании.
S>Неужели знание отличий NTFS от FAT32 это нечто особенное? Ну пусть он не знает про размеры кластеров и про ограничение на их кол-во, но ведь можно уж хотя бы знать, что в ntfs есть нативное шифрование/сжатие, просто банально потому что в свойствах папки есть такая галочка? Или _хотя_бы_ сказать, что UEFI отличается от биоса наличием графики и поддержкой мыши?

Вот это как раз правильный ответ для IT-директора! А всяких лузеров которые будут говорить о журналируемости, правах доступа, размерах кластеров, и уж тем паче B+ деревьях надо гнать сразу.

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

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

K>>Автор всего-лишь говорит, что его задача — найти работников, а не получить одобрение от неудачливых кандидатов. Вполне адекватная точка зрения. Пока ему удается находить подходящих людей.

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

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

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

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

A>В общем там сплошной фейспалм

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

Практика — критерий истины.

S>Итак. Сначала — о поиске разработчиков.
S>Я практикую тестовое задание на дом.
S>Критики данной позиции делятся на 2 части:
S> — те, кто против выполнения каких-либо тестовых заданий вообще;
S> — те, кто против выполнения ТЗ на дому (а на собеседовании — ок).
Есть 3-я — это я...
Вот если б я к вам надумал идти, и получил ТЗ для разработки, то ПЕРВОЕ, что я сделал бы — раздербанил бы ваше ТЗ на предмет неточных и неполных данных.
Явно уточнений там потребовалось бы +100500 штук.
Второе — непременно попросил бы уточнить цель написания — какую прогу надо писать:
— самую короткую?
— самую быструю?
— самую простую и понятную?
— самую экономную по памяти?
— самую сопровождаемую (рефакторинг легко делать) ?
— самую...

И еще в копилку наблюдений при общении с программистами.
Претенденты, у которых плохо "подвешен язык" — интроверты.
Как правило, это — хорошие программисты.

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

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

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

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

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

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

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

S> — те, кто против выполнения каких-либо тестовых заданий вообще;
S> — те, кто против выполнения ТЗ на дому (а на собеседовании — ок).
Против первого и второго.
ТЗ на дому обычно у всех объемное, мне в одной конторе однажды заявили что, цитирую "задание совсем небольшое, примерно на 6-8 часов, можно один выходной выделить и все сделать". После этого товарищи незамедлительно пошли лесом. Работодателю следует задаться вопросом — срхена ли кто-то в здравом уме и памяти должен тратить 8 часов своего личного времени на тз в компанию, в которую еще могут и не взять, и за которые не заплатят ни копейки. Если это не убеждает, возможно убедит следующее — самый обычный программист в поисках работы обычно находится в процессе общения с множеством компаний одновременно, чаще всего при этом он продолжает работать на текущем месте работы. Если одна из этих компаний пошлет его делать объемное ТЗ, очень вероятно, что выбор будет сделать в пользу тех кто не пошлет. В общем, ТЗ это чаще всего непрофессионализм работодателя. Я один раз делал ТЗ, в поиск яндекса. Но там ТЗ во первых — достаточно интересное (нужно было написать свой поиск и добиться определенной релевантности), во вторых, его можно было сделать довольно быстро, по крайней мере если ты знаком с основами IR.

S>Нет, друзья, нихрена код не показывает. Код позволяет увидеть стиль программирования, но не личные качества. Я много раз встречал примеры аккуратно, хорошо оформленного кода, который работал неправильно. Причины могли быть разные: либо ошибка на системном уровне, либо более мелкие ошибки из-за невнимательности (а это важно!). Вникать же в представленный код настолько глубоко, чтобы находить подобные ошибки — у меня просто банально нет на это времени. Как вы думаете, если на объявление на каком-нибудь hh.ru приходит более 100 откликов за неделю, реально ли подробно и детально изучить код каждого из них? Неважно, кому это делать: мне, или тимлиду — времени уйдет очень много, и реальная работа на это время встанет. И еще раз хочу напомнить: красиво оформленный код нередко работает плохо!

Можно почитать код и понять, хороший это код или нет. Не обязательно читать код полностью для этого, просто взять и поревьюить его 30-40 минут. Часто достаточно 5-10 минут для того, чтобы сформулировать какие-нибудь претензии/вопросы по коду, по которым уже можно будет дальше разговаривать и обсуждать. Все любят потрепаться, мало кто может взять и сделать, так ты тут писал? Вот это как раз тот случай — нужно взять и вникнуть. Не получится добиться результата не вникая. Даже если все сделают ТЗ, толку от этого не будет, если ты будешь изучать ТЗ поверхностно.

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

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

S>Кстати, еще ремарка. У успешных и известных компаний подход аналогичен. Скажем, тестовые задания на дом есть у яндекса, есть у студии Лебедева. И нельзя сказать, что они очень маленькие (хотя зависит от должности). Можно возразить, что я — не студия Лебедева, но значит ли это, что нельзя брать пример с лучших компаний? А может быть они не просто так стали лучшими?

Не знаю как у Лебедева, но у Яндекса ТЗ — это просто способ отсеять совсем уж дебилов. У них очень большой поток кандидатов. ТЗ очень простое (можно на сайте у них посмотреть), ТЗ посложнее у них есть не во всех командах (насколько я знаю). Основное у них — собеседование в офисе.


S>Так вот, там нужно было взять несколько человек непрограммистской направленности, а именно: руководителя IT-службы, руководителя отдела обучения, менеджера сопровождения. Руководитель IT должен сформировать свой отдел, т.е. набрать сисадминов, и обеспечивать нормальное функционирование инфраструктуры у наших клиентов (клиник). Отдел обучения должен обучать юзеров нашей программе. Менеджер сопровождения — ну что-то типа личного менеджера у каждого клиента, хорошо знает нашу программу, помогает им в сложных вопросах, передает нам их хотелки.


S>Еще, что меня поразило — это крайне низкий уровень технических знаний у IT-директоров. Почти никто не знал отличия BIOS от UEFI, никто не знал что такое GPT-диск, на вопрос "чем fat32 отличается от ntfs" наиболее распространенный ответ — "у ntfs размер раздела может быть больше", как реально работает маска подсети почти никто не знает, ну а wildcard-маска — это вопрос-fatality

Зачем это все знать управленцу? Я вот, например, не знаю без гугла чем BIOS отличается от UEFI и что такое GPT. 10 лет в индустрии коту под хвост, видимо.

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

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

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

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

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

L>P.S. Нормальным инженерам, кроме всего прочего, платят в том числе и за то, чтобы выявлять бессмысленные и невозможные пункты Т.З., разбираться в том, откуда оно вообще взялось и предлагаеть решение.
Нормальный инженер перевернет строку на собеседовании и забудет об этом.
А ненормальный начнет нервничать, переживать, волноваться, много говорить, жаловаться что тестовое задание дурацкое. Но так и не перевернет строку и на работу взят не будет.

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

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

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

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

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

L>>Стесняюсь спросить, а у тебя дети есть?

AR>Нет. И хомяка тоже нет, который сдохнуть может. Да, а каким образом дети с тебя ответственность за свои обещания снимают?

Ха-ха-ха.
Очень просто снимают.
Нужно с важностью в голосе сказать: У МЕНЯ ЖЕ РЕБЕНОК!
И ответственность как рукой сняло.
А если кто-то посмел не понять, почему это ему всё можно с ребенком — то тот товарищ сволочь последняя, бессердечная к тому же.

В точку!

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

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

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

А в чем успех то?

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

G>Тестовое здание показывает другие вещи:
G>1) Знание нужных фреймворков. Например в команде используется boost, а человек его не знает. В смысле слышал, но не использовал. На собеседовании можно отвертеться от вопроса про знание буста, а в тестовом задании никак не отвертишься.

А ты сам-то буст знаешь?
Не знает — так узнает. Этих фреймворков как собак нерезаных, все их знать жизни не хватит

G>2) Обязательность — отправляешь задание и спрашиваешь когда будет готово, так чтобы точно. Успел в срок — молодец, прислал на пару дней позже — также будет сроки по проекту факапить. Если заранее сообщил что не успевает по объективным причинам — может быть плюсом.

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

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

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

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

Абсолютно согласен, запросто можно заменить.

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

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

K>В плане трудоемкости ТЗ бывают забавные случаи. Мы однажды давали кандидатам довольно простое ТЗ — сделать приложение, которое подключается к БД, выводит список таблиц и при выборе таблицы позволяет просматривать и редактировать данные. Без каких-то изысков или подводных камней, просто лишь бы запускалось и работало. Короче, если есть опыт работы в этой области, то с современными средствами разработки такое ТЗ делается на коленке за обеденный перерыв.

Я не понял, вы просили разработать ТЗ или приложение?

Сначала — какая БД? Нужно ли обрабатывать ошибки соединения? Автоматическое восстановление соединения нужно? Поддержка транзакционности, возможность отката?
Затем — интерфейс за 15 минут не делается. Говно можно сделать за 15 минут, а нормальный интрфейс — нет.

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

K>1) Далеко не все кандидаты, претендующие на должность связанную с очень плотной работой с БД, могут такое приложение написать. Многие присылали полную хрень.
K>2) Некоторым не понравилось, что мы хотим, чтоб они потратили свои выходные на такую бесплатную работу.

Совершенно справедливо не понравилось.

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

G>>Мне даже резюме смотреть неинтересно, там чаще всего никаких полезных сведений нет.
S>+100. У большинства кандидатов резюме вылизаны так, что и придраться не к чему (ну, кроме частой смены работы). Да и как понять, врет человек в резюме или нет? Только собеседовать (а это опять же время).
Скорее наоборот. Среднее резюме выглядит как "работал работу за деньги" и указание кучи трехбуквенных аббревиатур.

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

K>>В плане трудоемкости ТЗ бывают забавные случаи. Мы однажды давали кандидатам довольно простое ТЗ — сделать приложение, которое подключается к БД, выводит список таблиц и при выборе таблицы позволяет просматривать и редактировать данные. Без каких-то изысков или подводных камней, просто лишь бы запускалось и работало. Короче, если есть опыт работы в этой области, то с современными средствами разработки такое ТЗ делается на коленке за обеденный перерыв.

EL>Ну то есть формошлепством оно решается за обеденный перерыв.

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

EL>Я вот знаю как минимум двух хороших специалистов по реляционным СУБД, которые это задание не сделали бы даже за полные рабочий день. Они не знакомы с формошлепством, зато могут работать как DBA и имеют хороший за плечами сложные проекты, в которых эти самые реляционные СУБД использовались нетривиальным образом.

Ну если был бы нужен DBA, то наверно бы искали по-другому. Но нужны были, которые будут писать клиентские приложения для БД. И такое тестовое задание как простой примитивный фильтр. Если человек его сделал, то стоит с ним познакомиться поближе и поговорить о более сложных вещах. Ну а если не сделал, то лучше не тратить ни его, ни наше время.

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

K>Причем в результате в выигрыше обе стороны. И "на порядок лучшие работники" найдут себе более подходящую им вакансию и автор нашел тех, кто ему подошел. А квалификация должна быть достаточной. Истории с наймом overqualified-специалиста часто заканчиваются грустно.

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

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

S>Поверьте, я знаю отличия нтфс от фат32, иначе не стал бы спрашивать людей то, в чем плаваю сам

Верю-верю, расслабься.

S>Про кластеры это был лишь пример.

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

MTD>>У меня в далеком 1995 году на 486 машине был биос с графикой и поддержкой мышки, разумеется ни каким UEFI тогда и не пахло.
S>Это все же исключение.

Вообще-то это не нонейм биос, а ами:



Чего-то не знать не стыдно, а вот думать, что знаешь все — глупо.

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

S>>С яндексом — просто на догадливость (правильный ответ — пешеходы никогда не превышают определенной скорости, дан самим яндексом).

MTD>Ответ красивый, но не правильный (видимо поэтому так мил гуманитариям). Что если пешеход поймал такси? Задать минимальный порог? А если это целый автобус с пешеходами? А еще и такси с автобусов стало в пробке? А если автомобилист вышел и пошел пешком? И т.д. и т.п.

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

Кстати, летом на своем примере наблюдал случай "автомобилист вышел и пошел пешком" за грибами. Результат — пробка на дороге, где машины проезжают раз в 10 мин.

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

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

S>Предыдущие серии: серия-1

Автор: sanchez911
Дата: 17.09.15

, серия-2

Автор: sanchez911
Дата: 15.10.15

.

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

S>See you!

Вижу, что, в основном, здесь критические отзывы на ваши подходы к найму.

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

С точки зрения кандидата тоже не все однозначно плохо.

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


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

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

Кому как, а я для себя в этом вижу пользу.


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


На этом положительная часть закончилась, позвольте и немного покритиковать.

На мой взгляд, в описанном вами,
единственная ложка дегтя — вопросы про АРП /компилятор/определение водитель или пешеход по GPS

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

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

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

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

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

Про вопрос о компиляторе.
Мне не понятно, почему ответ вида: "компилятор — это переводчик" считается только
правильным, но только на четверочку. Ведь есть еще такое слово "транслятор", а оно дословно именно то
и обозначает.

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

Получается, что компилятор, как концепция, сложнее
для понимания врачом чем понимание обычным человеком работы врача ?
Ну сами то подумайте ! Да даже рецепты простые люди разобрать не могут !
Какие уж там концепции !!!

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

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

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

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

Иными словами, скорость может быть одним из критериев, но никак не единственным верным и правильным.


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

Всего доброго.

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

K>Я никогда не сомневался, что на форуме есть много людей, которые прожили мою жизнь и знакомы с моим личным опытом намного лучше меня.

Извини, но мы с этим "опытом" знакомы непонаслышке.

L>>Я понимаю, что могу разрушить веру во всемогущего деда мороза, но заинтересованность человека в работе всегда подкрепляется денежной компенсацией. Никакой другой "заинтересованности" в работе в очередной "ведущей компании" быть не может.
K>Я понимаю, что ЧСВ чесать очень приятно. Тут вопрос что важнее — почесать ЧСВ или получить интересную работу.

Интересная работа, дружный коллектив. У меня дежа вю

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

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

L>>Вот так вы сами отсеиваете самых адекватных сотрудников

K>Вот Яндекс например даже форму на сайте с тестовым заданием сделал, чтоб заведомо неподходящих людей отсеивать. Но те наверно как раз и считают себя наиболее адекватными сотрудниками. Это безусловно.

О, Яндекс. Это не они недавно обосрались по-крупном, да и не один раз?

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

S> Или _хотя_бы_ сказать, что UEFI отличается от биоса наличием графики и поддержкой мыши?

Нет, этим не отличается.

K>Распространенное ошибочное мнение — это то, что кому-то якобы нужны "на порядок лучшие работники". Автор подбирает сотрудников согласно собственным субъективным фильтрам и это нормально.
Ну, фильтр конечно действительно субъективный, но 100% людей, которые со мной работают, являются разработчиками более высокого уровня, чем я. У меня нет комплексов по этому поводу, так и должно быть.

K>Практика — критерий истины.
Именно! Спасибо В каком-то бандитском фильме был хороший диалог между двумя ментами:
— Ну Петр Петрович, операция была спланирована тщательно, все продумали...
— А он ушел. Качество операции, Иван Иваныч, определяется ее результатом. Упустили! И это все значит.

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


даже для уборщиц разброс в уровне работодателей (зарплата, работа в бизнес-центре класса А, доплата за лояльность и конфиденциальность и т.п.) может быть в разы.
У программистов разброс много выше.

Быстро найти можно кучу посредственных предложений с посредственными зарплатами и задачами.

LVV>>И собственный овер20летний опыт — на студентах.
N>При всем уважении к Вашим заслугам, но я сам был таким студентом и для этого существовали объективные предпосылки: студенты слушают лекции, записывают в тетрадь, дома пишут код и сидят в Интернете, а голосовое общение сводится к минимуму. А в работе, если не удаленщик, приходится общаться с живыми людьми горазда чаще.
N>Лично я уже научился в тесном кругу вполне сносно поддерживать разговор.
1. Я сам интроверт. Поэтому интровертов просто вижу.
2. Нифига студенты не пишут (наши, по крайней мере), а смотрят и слушают.
А потом делают лабы, для чего читают книжки, ищут инфу в инете, задают вопросы.
3. Мы со студентами общаемся ежедневно. И особенно заставляем их тренироваться для защиты курсовых, которые у нас КАЖДЫЙ семестр...
(смотри мой пост про курсовые в нашем универе — в форуме Образование и наука).
Вот на прошлой неделе несколько человек делали доклад-презентацию по текущему состоянию курсовой.
Так что голосового общения у нас — просто ДОФИГА.
И сразу видно студентов, которые предпочитают код написать, а не рассказать...
Многолетние наблюдения показывают, что такие студенты — хорошие программисты.
Вместо чесания языком они больше думают и пишут.

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

LVV>Вот если б я к вам надумал идти, и получил ТЗ для разработки, то ПЕРВОЕ, что я сделал бы — раздербанил бы ваше ТЗ на предмет неточных и неполных данных.
LVV>Явно уточнений там потребовалось бы +100500 штук.
LVV>Второе — непременно попросил бы уточнить цель написания — какую прогу надо писать:
LVV>- самую короткую?
LVV>- самую быструю?
LVV>- самую простую и понятную?
LVV>- самую экономную по памяти?
LVV>- самую сопровождаемую (рефакторинг легко делать) ?
LVV>- самую...
LVV>

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

+100. В задании я пишу, что все, о чем не сказано — на ваше усмотрение. Насколько хорошо делать? Так, чтобы вам самим нравился результат.

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

E>Сам тестовое задание давал, удаленное. Время засекал — 1 час. Сам пробовал его сделать, сверхуставший сделал за 30 минут в свое время, параллельно с кандидатом. Самое смешное, что так и не довелось встретить кандидата, который его выполнил хорошо. Максимум удовлетворительно.

а чего удивительного? сам придумал, сам сделал быстро.

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

E>Даже не я придумывал. Я тут помнится с RSDN взял одно задание да и все, когда один кандидат жаловался что его запороли. Мне показалось неплохим. Ну и соответственно его чуток еще упростил. Типа в той конторе на бумажке заставляли делать за 15 минут, я же час и чем угодно пользоваться. Соответственно первый раз я сам честно параллельно с кандидатом его делал .

Ой, неужели список развернуть?

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

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

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

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

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

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

S>Это не так. У нас в мире полно людей, которые и к старости не умнеют. Опыт выполнения проектов не говорит почти ни о чем.

Так кого вы ищите?

Вы ищите УМНЫХ?
Или Вы ищите опытных, способных сделать задачу?

Я реально знаю 100 миллионов очень-очень умных людей которые, закончили ВУЗы по IТ тематике но не смогли проработать в программистах и пяти лет.

Так что ум это способность от рождения. А для успешной работы программистом надо :
-Усидчивость
-Аккуратность
-Умение и желание учится всю жизнь.
-Мотивация быть программистом.

И только на 80 месте ум.

Так как ум это врожденное то нельзя поумнеть — можно только поглупеть. Самый умный мозг у ребенка 6-8 месяцев. А далее только ум снимается.

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

AR>>Ну ок, пусть тестовое задание будет. Как насчет оплатить его выполнение?
S>Никак. Задачка абстрактная, в реальности не используется. Опять же, в вакансии сказано про обязательность ТЗ, не нравится — не откликайся, и делов-то.

Это работает только в случае, когда область деятельности не узкоспециализированная.
Представь, что тебе нужен специалист по computer vision. А ты ему высылаешь задание по подсчету гномиков. И он тебя справедливо посылает.
Вопрос — кто из вас двоих лоханулся?

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

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

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

L>
L>Кое-кто, сам того не подозревая, в данном случае требовали наличия телепатических способностей от кандидата.
L>В сетях возможны 100500 причин, которые могут привести к описанному эффекту.

Я не знаю как звучал вопрос автора. Но такие вопросы полезны, чтобы посмотреть на ход мышления кандидата. Понятно, что не зная всех деталей, он не сможет угадать. Но он может поразмышлять об этом вслух. Позадавать вопросы, рассказать что бы он сделал для диагностики проблемы. Может быть рассказать какие-то случаи из личного опыта. То есть показать бы те самые problem solving skills.

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

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


K>> L>Вот так вы сами отсеиваете самых адекватных сотрудников

K>> Вот Яндекс например даже форму на сайте с тестовым заданием сделал, чтоб заведомо неподходящих людей отсеивать. Но те наверно как раз и считают себя наиболее адекватными сотрудниками. Это безусловно.
D>Это просто умора сравнить твое задание в компанию "очередной мегаинтегратор херачим формочки на дельфи" и компанию с каким-никаким именем и доестаточно нетривиальными продуктами.

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

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

L>>>>Хинт — у людей есть личная жизнь. Которая плохо поддается планированию. Если вообще поддается.
AR>>>Это сказки. Поддается. И очень хорошо.
L>>Стесняюсь спросить, а у тебя дети есть?
AR>Нет. И хомяка тоже нет, который сдохнуть может. Да, а каким образом дети с тебя ответственность за свои обещания снимают?

Мне больше нечего сказать. Удачи в поиске адекватных сотрудников.

Здравствуйте, LaptevVV, Вы писали:
LVV>Есть 3-я — это я...
LVV>Вот если б я к вам надумал идти, и получил ТЗ для разработки, то ПЕРВОЕ, что я сделал бы — раздербанил бы ваше ТЗ на предмет неточных и неполных данных.
LVV>Явно уточнений там потребовалось бы +100500 штук.
LVV>Второе — непременно попросил бы уточнить цель написания — какую прогу надо писать
Я тоже практикую тестовые задания (как правило, на новую для кандидата технологию, чтобы продемонстрировал способность к обучению и сам пользу с этого поимел) — такое поведение однозначно расцениваю как большой плюс кандидату. Хотя обычно даю кандидатам отдельную задачку на коммуникации, чтобы понять насколько кандидат командный игрок.

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

G>Вообще хотите узнать интересную тенденцию — посмотрите компании, которым доставалась награда HR-бренд года. А потом посмотрите на ЗП в этой компании — почти всегда ЗП будут ниже рынка. Для крупных компаний это очень оправдано. Экономия 10% на ЗП выливается в огромную прибыль.

А можешь чуть подробней рассказать про награду HR-бренд года? Она чистой воды купленная (т.е. компания платит порталу HH, чтоб тот её лучшей признал), или частично купленная, частично за заслуги? За какие заслуги? Или может полностью за заслуги и даже без откатов? (ну мало ли)
Я как-то на нее особо внимания не обращал, ну награда, и награда; я на другое смотрел.

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

BZ>>я готов выполнить ТЗ яндекса

F>а чем они заслужили такое снисхождение?
F>или тут можно подставить любую крупную известную контору?

вместо Я можно подставить любого среднестатистического программиста, а вместо Яндекса — любую контору, обеспечившую себе достаточный пиар, от fog creek до теслы. смысл моего спича был именно в том, что таких контор по определению немного и остальным нет смысла пытаться им подражать. при этом та конкретная контора, в которой раньше работал Kerk, вполне может входить в эту десятку, просто надо понимать, что здесь логика обратна его рассуждениям — не "контора наняла крутых спецов благодаря придирчивой системе отбора", а "контора может позволить себе придирчивый отбор, поскольку в ней работают звёзды"

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

S>ИТ-директора, я считаю, должен быть гик, а гики всегда интересуются техническими вещами.

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

S>Ну да, кол-во погибших на перевезенных человекокилометров. А как правильно на ваш взгляд?

Это ответ, во-первых, очень банален и не показывает никакого системного мышления, а во вторых, может быть не верен. Рассмотрите ситуацию:
Построили 11 звездолетов с 1 местом для космонавта. Первый долетел до Марса и успешно вернулся обратно. Остальные 10 взорвались на старте. В итоге 1 труп на 10 млн. человекокилометров.
С другой стороны есть тысяча автомобилей, которые проехали по 100 км, а 1001-й выехал на встречку. Итого 1 труп на 100 тыс. человекокилометров.

Вопрос: на чем вы поедите если будет выбор?

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

S>Неужели знание отличий NTFS от FAT32 это нечто особенное?
Нет. Но ИТ-директору не нужное. Я знаю хороших директоров ИТ и многие из них не знают/давно забыли все эти отличия.
Зато знают как набрать хороший персонал, делегировать полномочия, руководить нижестоящими руководителями, умеют работать с бюджетом,
отстаивать свою точку зрения, принимать ответственность за свои решения и контролировать ход всех подотчетных проектов.

S>то скорее всего он никогда не заходил в меню уефи, или думал что это меню ОС?
Я вот заходил в меню и того и другого и что-то вот в жизни бы не подумал назвать такие отличия или какие-либо отличия вообще.
Для меня это всё остается общим названием БИОС, например.

S>Хотя я вот сам не админ, и не ИТ-директор, а человек, ставший во многом манагером, но почему я эти вещи знаю?
Понятие не имею, почему ты эти вещи знаешь. Знаю только точно, что ИТ-директору эти знания не обязательны. И даже
директора, выросшие из сисадминов, очень часто всё это забывают, если они, конечно, директора, а не руководители
отделов из 3-х человек, включая самого себя.

S>На должности ИТ-директора, я считаю, должен быть гик, а гики всегда интересуются техническими вещами.
1. Не должен быть. Твое "считаю" ошибочно настолько, что может работать в отрицательную сторону. Среди хороших ИТ-директоров
гиков вообще мало, ИМХО. Это удел рядового персонала.
2. Судя по твоим вопросам, тебе нужен не ИТ-директор, а кто-то близкий к тим-лиду сисадминов или девопсов с доп. функциями.

Всё высказанное — ИМХО, основанное на личном опыте и дружбе, родстве, приятельстве, совместной работе с разными руководителями из
IT-сферы.

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

S>Ну пусть он не знает про размеры кластеров и про ограничение на их кол-во

Это по твоему и есть отличия? Как-то ожидал большего.

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

Из галочки это вообще никак не следует.

S>Или _хотя_бы_ сказать, что UEFI отличается от биоса наличием графики и поддержкой мыши?



У меня в далеком 1995 году на 486 машине был биос с графикой и поддержкой мышки, разумеется ни каким UEFI тогда и не пахло.

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

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

T>Не тогда надо вас уволить и нанять на ваше место этого программиста, потому как решает такие вещи именно ведущий программист, и именно поэтому на этом месте не сидит очередная Светочка-менеджер, со скиллом аккуратность и обязательность. А связаны или не связаны эти вопросы, так сразу и не скажешь, возможно следовало уточнить и вы узнали-бы нечто новое.

Я тебе больше скажу — тот "генератор вопросов" был ведущий программист. Вот сейчас рядом со мной сидит просто программист, как это не парадоксально — но он даже без высшего образования и с опытом работы — 6 мес до нас и 4 мес у нас. Получилось так, что его первый день работы попал в мое отсутствие. Постановка задачи была посредством СМС, по приезду домой задача была выполнена без каких либо вопросов. Вот он инженер, а не просиживатель штанов. И не важно какой у него опыт и образование, главное он инженер в голове.

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

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

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

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

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

Требуете ответственность, возьмите сначала на себя ответственность — оплатите время, затраченное на выполнение задания.

AR>P.S. Пост твой сверху на тему детей почему-то не открывается. Что с ним не так?

Наверное, кто-то чего-то кому-то наобещал и не выполнил

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

L>>Совершенно верно. Диагностика, особенно диагностика неочевидных неисправностей, стоит денег.
AR>Есть у меня админ знакомый (простите, Systems Engineer). Так он даже не услышав проблемы, говорит 40 баксов в час. Потому что ему не интересно админить. Ему интересно сидеть в маленьком городе рядом с мамой толстой жопой на стуле и всем рассказывать, что его время стоит аж 40 баксов в час.

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

AR>Согласен, что проблема может оказаться непредвиденно сложной. А может быть и простой, например пинг большой. И что, я должен платить 4*80=320 баксов просто за то, чтобы абстрактное Его Величество приехало, набрало ping google.com, потом еще поигралось минут 5 с tracert и уехало с вердиктом "разбирайтесь с провайдером, у него пинг плохой до внешнего мира"?

Да, бывает.

"Удар кувалдой — 5 долларов.
Знание, куда ударить кувалдой — 300 долларов".

Поговорку "Скупой платит дважды" напомнить?

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

AR> L>Совершенно верно. Диагностика, особенно диагностика неочевидных неисправностей, стоит денег.

AR> Согласен, что проблема может оказаться непредвиденно сложной. А может быть и простой, например пинг большой. И что, я должен платить 4*80=320 баксов просто за то, чтобы абстрактное Его Величество приехало, набрало ping google.com, потом еще поигралось минут 5 с tracert и уехало с вердиктом "разбирайтесь с провайдером, у него пинг плохой до внешнего мира"?

Вот у топикстартера некая компания с пингом разбиралась 2 месяца и вряд ли там обошлось 4*80

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

AR> И что, я должен платить 4*80=320 баксов просто за то, чтобы абстрактное Его Величество приехало, набрало ping google.com, потом еще поигралось минут 5 с tracert и уехало с вердиктом "разбирайтесь с провайдером, у него пинг плохой до внешнего мира"?

Да. Если ты сам не умеешь набрать ping google.com и пять минут поиграться с tracert'ом, тебе придется заплатить 320 баксов тому, кто это умеет. Ну или оставаться с проблемой один на один. Это тоже возможный выбор.

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

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

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

g> BZ>Здравствуйте, Sharov, Вы писали:

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

g> BZ>а соискателю каким макаром?

g> Собеседование это — полчаса в одну сторону ехать, полчаса в другую, час там торчать. Выпадает два часа. Тем более обычно по собеседованиям ездят по вечерам, в час пик, что неприятно вдвойне.

g> Любому программисту будет комфортнее потратить два часа на кодинг, чем на проезды.

Вот только в 99.9% случаев выполненное тестовое задание не избавит от необходимости очного собеседования. Так что тестовое задание помогает соискателю в том плане что позволяет избежать нонейм компашек с манией величия.

G>>Построили 11 звездолетов с 1 местом для космонавта. Первый долетел до Марса и успешно вернулся обратно. Остальные 10 взорвались на старте. В итоге 1 труп на 10 млн. человекокилометров.
G>>С другой стороны есть тысяча автомобилей, которые проехали по 100 км, а 1001-й выехал на встречку. Итого 1 труп на 100 тыс. человекокилометров.
S>Если говорить строго статистически, то да, звездолет безопасней. Но в общем-то если бы человек мыслил и дискутировал таким бы образом, он бы сразу стал первым кандидатом на работу. Там такого и в помине не было.

Не, сравнение статистики в данном примере — это сравнение теплого с мягким и в принципе некорректно.

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

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

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

LVV>С вами, как с работодателем — все ясно.
LVV>Я выше не написал НИ ОДНОГО ВОПРОСА — ибо не было конкретного ТЗ.
LVV>Вы приняли варианты целей за кучу несвязанных вопросов.
LVV>Дальше я читать не буду...
LVV>

Я понял, знаки вопросов у вас означают совсем иное и это были не вопросы:

LVV>- самую короткую?
LVV>- самую быструю?
LVV>- самую простую и понятную?
LVV>- самую экономную по памяти?
LVV>- самую сопровождаемую (рефакторинг легко делать) ?

С вами все понятно и дальше читать не буду.

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

S>Всем привет!
S>Предыдущие серии: серия-1

Автор: sanchez911
Дата: 17.09.15

, серия-2

Автор: sanchez911
Дата: 15.10.15

.
S>много букв
S>See you!

Работаю в американских рогах-и-копытах, активно используется подход тестовое задание + беседа с менеджером. Пару раз в итоге нанимали таких людей, которым явно кто-то задание сделал, а язык у них хорошо подвешен — объяснить смогли что и как, а работать потом нормально — увы, нет. Так что вопрос "как правильно собеседовать" до сих пор открытый

S>>И как же они будут отбирать сисадминов, если не могут проверить их техническую компетенцию, потому что сами некомпетентны?
_AB>
То-то и оно. Личные контакты, кстати, тоже совершенно не являются гарантией, а скорее приводят к кумовству, поэтому когда человек хочет привести кого-то своего, я крайне настораживаюсь и сразу говорю, что готов его прособеседовать, но только на общих основаниях. Если там, конечно, не звезда какая-нибудь.

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

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

S>На что возражать-то? На то, что единственный способ поиска подопечных, который вы предложили — по знакомству?
По рекомендациям своих связей или лично знакомым я писал, добавив слово "например".

S>Знакомый автоматически означает "хороший"?
Я бы посоветовал владельцу бизнеса научиться читать. Полезно при оценке контрактов, например...

S>А если нет знакомых, и компетенций нет, то как искать людей себе в отдел?
Если нет знакомых, которые могут порекомендовать тебе хорошего спеца, или помочь провести собеседование,
то какой ты нафиг ИТ-директор вообще?

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

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

M>>Так что не понимаю, кто из наемных работников станет подавать в суд на работодателя.
G>Работник начнет всем подряд рассказывать что он судился с работодателем?

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

А расскажет всё работодатель, у HR cарафанное радио — основной хлеб.
Вот вы лично взяли бы на работу человека, о котором рекрутер так неуверенно "он вот судиться любит, из-за него на деньги попасть можно, вот в фирме Х и Y уже потерпели..." ну и, конечно, если вы обратитесь за отзывом на предыдущее место работы, то он будет понятно какой?
Я про найм не завсегдатаев форума, тут у нас каждый первый — специалист с мировым именем, премию Тьринга некуда ставить(юрист по совместительству), а про "обычную" жизнь.

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

L>>Нормальный инженер резюме на вакансию переворачивателя строк даже засылать не будет.
AR>Ок, как проверить способность кандидата писать код, а не красиво говорить?
AR>Одно условие — без тестового задания — тема как раз про это, допустим, что его нет.

Ты всерьез думаешь, что человек, отработавший программистом лет 5-10 и не слинявший из отрасли в манагеры по продажам, не умеет писать код?
Нет, всякое бывает, но такого я еще не видел.

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

L>>Не "не смогли", а "не захотели". Почувствуй разницу и вспомни анекдот про консерваторию.
AR>Не не. Не смогли. Краснели, потели, волновались, много говорили, а работающий код написать так и не смогли.

Ты себе льстишь.
Именно "не захотели". Потому что последний раз, когда кто-либо из них писал некрасивый неулучшаемый алгоритм с O(N), был лет 20-30 назад, в школе. С тех пор желание заниматься ерундой иссякло.
Невозможно оставаться в этой области 10-20 лет и не уметь простейший код.
Вот уметь не писать код дурацкий — умение и правда редкое, но ты ж не это спрашиваешь.

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

K>В этой сфере правильно все то, что работает
вот это логика. браво! т.е. когда бизнес крякнет, или перестанет развиваться — тогда и думать, да? А до тех пор чтобы не делал — всё правильно.

Разумеется. Но я о задании и объеме предупреждаю честно заранее. Кто не хочет — просто не откликается.

A>они не прошли его тесты, простая мысль что это не люди отстой, а его тесты
Вы немного путаете, "мне наплевать на мнение человека Х по вопросу Y" и "человек Х — отстой" — немного разные вещи, не находите? Покажите мне, где я назвал этих людей дураками и отстоем.

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

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

A> а-ля "код нихрена не показывает" и то что автор в коде видит только его "аккуратность", это вообще пять, похоже автор дальше джуна в разработке не продвинулся
Ну, а все же, расскажите, как бы вы смотрели код? На что смотрели бы? Как оценивали бы?

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

S>>У тестового задания есть очень хороший плюс. Это задание, выданное разным кандидатам, позволяет _сравнить_ их между собой.
L>Говорят, из заведомо ложного предположения вытекает все, что угодно.
L>Тут именно такой случай.

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

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

LVV>>И еще в копилку наблюдений при общении с программистами.
LVV>>Претенденты, у которых плохо "подвешен язык" — интроверты.
N>Не нужно так обощать, Эллочка-людоедка ни разу не интроверт
N>И обратное тоже неверно: умение красиво и уверенно говорить — всего лишь навык.
Ну, на собеседование к топикстартеру попадают не Эллочки-людоедочки, а вполне себе конкретные ребята, справившиеся с тестовым заданием.
Речь именно о них.

И собственный овер20летний опыт — на студентах.

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

S>>А вот с яндекс-картами интересней. Технари отвечали хуже, чем гуманитарии — те чаще догадывались до правильного ответа.
N>Как Вы думаете, этот ответ дан разработчиком писавшим ту часть кода?
Ответ дан одним из разработчиков я-карт. Я не знаю, он ли писал эту часть кода, но очевидно, что он знал, о чем говорил.

S>>Правильный ответ, до которого нынешняя IT-служба (сторонняя контора) дошла только через 2 месяца жалоб — долгие пинги
N>Просто поразительно! Не процессор перегружен, не памяти мало(и свопит на диск), не фильмы качаются юзером, а пинг! И вам понадобилось целых два месяца чтобы это понять. Вам(!), потому что это ваш софт. А Вы требуете, чтобы человек из "шорт-листа" об этом сходу догадался.
Вы внимательно читали? Написал же: _сторонняя_ контора! Мы не админим им сеть (а теперь будем админить, для этого и создаем собственную службу).

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

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

K>>В этой сфере правильно все то, что работает
A>вот это логика. браво! т.е. когда бизнес крякнет, или перестанет развиваться — тогда и думать, да?

Да. Те, кто понимает это, нанимают.

LVV>>Вот если б я к вам надумал идти, и получил ТЗ для разработки, то ПЕРВОЕ, что я сделал бы — раздербанил бы ваше ТЗ на предмет неточных и неполных данных.
LVV>>Явно уточнений там потребовалось бы +100500 штук.
LVV>>Второе — непременно попросил бы уточнить цель написания — какую прогу надо писать:
LVV>>- самую короткую?
LVV>>- самую быструю?
LVV>>- самую простую и понятную?
LVV>>- самую экономную по памяти?
LVV>>- самую сопровождаемую (рефакторинг легко делать) ?
LVV>>- самую...
D>Был у меня опыт (печальный) работы с программистом, который именно так и поступал, каждый раз давая ему задачу он генерил кучу вопросов, несвязанных. Вот просто смотрит тебе в лицо и говорит: а зачем, а почему, а как это так. Он даже сам не понимает что спрашивает, но продолжает это делать. Если ты позиционируешь себя как инженера-программиста, то эти вопросы ты должен решить сам, принять нужное решение и сказать почему именно так. Такие вопросы свойственно задавать кодеру, а не инженеру. И если бы мне попался опять такой же кандидат, то больше таких ошибок я не совершу — сразу распрощаюсь.
1 ваша ошибка: предположение о том, что будет куча несвязанных вопросов...
2 ошибка: предположение о том, что я не понимаю, что спрашиваю.
И кстати, ответы нанимателя на них много чего мне о нанимателе скажут — и я всерьез подумаю, устроит ли меня такой работодатель.
Не только наниматель проверяет претендента, но и претендент тестирует нанимателя — это справедливо.

3 ошибка: не обратили внимание на ФОРМУЛИРОВКИ ЦЕЛЕЙ.
Еще в 1971 году Вайнберг: http://dic.academic.ru/dic.nsf/ruwiki/1479920 писал вот в этой книге:
The Psychology of Computer Programming. Silver Anniversary Edition (1998)
что программы у программистов получаются сильно разными в зависимости от цели, которую перед ним поставили.
И в данном случае — это важно.
Ибо предпочтения нанимателя весьма существенным образом сказываются на судьбе претендента.

S>>>А вот с яндекс-картами интересней. Технари отвечали хуже, чем гуманитарии — те чаще догадывались до правильного ответа.
N>>Как Вы думаете, этот ответ дан разработчиком писавшим ту часть кода?
S>Ответ дан одним из разработчиков я-карт. Я не знаю, он ли писал эту часть кода, но очевидно, что он знал, о чем говорил.

Если Вы разработчик, то должны понимать, что одним IF там не обойдешься, а сказано сотрудником яндекса это было для того, чтобы что-то ответить на бессмысленный вопрос, а не развивать эту тему дальше и не вникать в детали алгоритма.
Я понимаю, это же сказал авторитет — сотрудник Яндекса!


S>>>Правильный ответ, до которого нынешняя IT-служба (сторонняя контора) дошла только через 2 месяца жалоб — долгие пинги
N>>Просто поразительно! Не процессор перегружен, не памяти мало(и свопит на диск), не фильмы качаются юзером, а пинг! И вам понадобилось целых два месяца чтобы это понять. Вам(!), потому что это ваш софт. А Вы требуете, чтобы человек из "шорт-листа" об этом сходу догадался.
S>Вы внимательно читали? Написал же: _сторонняя_ контора! Мы не админим им сеть (а теперь будем админить, для этого и создаем собственную службу).

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

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

N>Лично я уже научился в тесном кругу вполне сносно поддерживать разговор.

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

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

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

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

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

S>Я практикую тестовое задание на дом.

ответь (заодно и себе) на один вопрос — а чем ваша контора лучше тех, которые не практикуют Это? зарплатой, условиями, оплатой этого ТЗ?

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

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

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

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

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

Может ничем и не лучше (по крайней мере, оправдываться тут я не буду). Но ведь отклик на вакансию и выполнение ТЗ — дело добровольное, не так ли?

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

F>проблема в том, что тестовое могут сделать хорошо, а дальше будут проблемы.
Да, такое может быть, но у меня в общем-то это редкость, и возникает в основном с теми, кто выполнил "почти отлично", кто без приставки "почти" — вообще ни разу никаких проблем не было.

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

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

Цыплят, как говорится, по осени считают
ИМХО можно давать ТЗ, можно просто монетку кидать — результат будет примерно тот же.

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

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

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

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

Поздравляю!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

G>В противовес этому многие разработчики (и я в том числе) по умолчанию придерживаются неких этических норм. Например, при найме не устраивать "аукцион" среди работодателей. При увольнении не уходить в ответственный для проекта момент. Уходя — честно передать знания. По мере возможности осуществлять "поддержку" по телефону некоторое время после ухода.
Я надеюсь, выделенное за 60€/hr? Иначе тебя просто поимели =)

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

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

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

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

не брать его. он не знает деталей реализации %feature_name%

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

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

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

K>Привет!

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

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

K>То есть когда человек проработал в 10 конторах, сделал 20 проектов на разных технологиях. Когда человек имеет опыт 10-15-20 лет никакие тестовые задания не нужны. Так как и так понятно что нельзя столько лет в профессии и не уметь делать проекты.
Тестовое здание показывает другие вещи:
1) Знание нужных фреймворков. Например в команде используется boost, а человек его не знает. В смысле слышал, но не использовал. На собеседовании можно отвертеться от вопроса про знание буста, а в тестовом задании никак не отвертишься.
2) Обязательность — отправляешь задание и спрашиваешь когда будет готово, так чтобы точно. Успел в срок — молодец, прислал на пару дней позже — также будет сроки по проекту факапить. Если заранее сообщил что не успевает по объективным причинам — может быть плюсом.
3) Внимательность — если задание нетривиально, то можно проверить точность выполнения требований, обработку крайних случаев итд.

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

Кстати на "архитектуру" смотреть в ТЗ не имеет никакого смысла, особенно если требований к ней нету. Хотя большинство парится на тему сколько классов написать и какие паттерны применить.


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

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

F>а чего удивительного? сам придумал, сам сделал быстро.
Даже не я придумывал. Я тут помнится с RSDN взял одно задание да и все, когда один кандидат жаловался что его запороли. Мне показалось неплохим. Ну и соответственно его чуток еще упростил. Типа в той конторе на бумажке заставляли делать за 15 минут, я же час и чем угодно пользоваться. Соответственно первый раз я сам честно параллельно с кандидатом его делал .

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

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

G>>Тестовое здание показывает другие вещи:
G>>1) Знание нужных фреймворков. Например в команде используется boost, а человек его не знает. В смысле слышал, но не использовал. На собеседовании можно отвертеться от вопроса про знание буста, а в тестовом задании никак не отвертишься.

L>А ты сам-то буст знаешь?
Я не знаю, мне не надо. Но если для собеседования — легко расскажу так, что все подумают что знаю.

L>Не знает — так узнает. Этих фреймворков как собак нерезаных, все их знать жизни не хватит
Ну так работодателю не нужно много, нужен один-два конкретных. Узнает в процессе выполнения задания — молодец.

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


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

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

Если человек проработал 20 лет, и в "требованиях" в вакансии написано "знание буст", а у него его нет — ТО ОН НЕ БУДЕТ высылать резюме на эту вакансию. Так как проблемы найти работу НЕТ. Есть проблема лени — "оказаться в такой компании и начать учить буст".
Поэтому пункт 1 — не подходит для выбора тестового задания.

2 и 3 — вообще не оцениваются через ТЗ. Их не возможно оценить через ТЗ.

K>>Ну и если его набирать на работу, то какое тестовое задание ему давать?
G>Видишь проблема в чем. Ты не говоришь чего ты хочешь от этого человека. Может даже не знаешь. Если бы ты знал, что тебе нужно от человека, то проблем с тестовым заданием не было бы вообще.

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

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

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

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

K>Вот на мой взгляд, это яркий пример того как отсутствие опыта, заменяется "рассуждениями". Нет только ради бога без обид, так как опыт приобретется, если бы мне кто-то сказал что у меня нет какого-то опыта и я его заменяю рассуждениями, то я бы не обиделся — ну а чем еще его заменять.
Конечно у меня мало опыта, я порядка 200 собеседований провел и дважды собирал команду разработки с нуля


K>Если человек проработал 20 лет, и в "требованиях" в вакансии написано "знание буст", а у него его нет — ТО ОН НЕ БУДЕТ высылать резюме на эту вакансию. Так как проблемы найти работу НЕТ. Есть проблема лени — "оказаться в такой компании и начать учить буст".
Да конечно.
Процитирую товарища landerhigh

Не знает — так узнает. Этих фреймворков как собак нерезаных, все их знать жизни не хватит

Руководствуясь такой логикой будет много кандидатов, не знающих буст.


K>2 и 3 — вообще не оцениваются через ТЗ. Их не возможно оценить через ТЗ.
Еще как оцениваются. Я только так людей и набираю последнее время. Мне даже резюме смотреть неинтересно, там чаще всего никаких полезных сведений нет.


K>>>Ну и если его набирать на работу, то какое тестовое задание ему давать?
G>>Видишь проблема в чем. Ты не говоришь чего ты хочешь от этого человека. Может даже не знаешь. Если бы ты знал, что тебе нужно от человека, то проблем с тестовым заданием не было бы вообще.

K>Я уже сказал — что уверен что он подойдет для любого говна которое есть, проблема в том — захочет ли он в нем копаться.
Тогда почему вопрос в ТЗ? Этот человек overqualified для тебя, тестовое задание тут не при чем.

Задание заданию рознь. Или речь идет о каких-то моих работах?

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

L>>А ты сам-то буст знаешь?
G>Я не знаю, мне не надо. Но если для собеседования — легко расскажу так, что все подумают что знаю.

Ну расскажи мне об предназначении boost::context и его устройстве, никуда не подглядывая.

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

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

L>>>А ты сам-то буст знаешь?
G>>Я не знаю, мне не надо. Но если для собеседования — легко расскажу так, что все подумают что знаю.

L>Ну расскажи мне об предназначении boost::context и его устройстве, никуда не подглядывая.

Зачем мне тебе чего-то рассказывать?

Насколько помню context это что-то о кооперативной многозадачности.

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

G>Конечно у меня мало опыта, я порядка 200 собеседований провел и дважды собирал команду разработки с нуля

Ты пытаешься "рассуждать" о тех людях которые провели 500 собеседований и 10 раз собирали команду с нуля.
Ты не можешь смоделировать для своих рассуждений людей с 10-20 лет опыта. Но в экстраполируешь себя на них и думаешь что они такие-же как ты.

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

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


K>>Если человек проработал 20 лет, и в "требованиях" в вакансии написано "знание буст", а у него его нет — ТО ОН НЕ БУДЕТ высылать резюме на эту вакансию. Так как проблемы найти работу НЕТ. Есть проблема лени — "оказаться в такой компании и начать учить буст".
G>Да конечно.

Что да конечно?
Я серьезно — к этому длинному опыту люди:
во-первых давно научились дурить таких как ты, как на собеседовании так и на ТЗ.
2. Проблемы найти работу нет.
3. Главным останавливающим моментом является лишь "лень". Ну не хотят они учить буст, если их и так неплохо кормят.

G>Руководствуясь такой логикой будет много кандидатов, не знающих буст.

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


K>>2 и 3 — вообще не оцениваются через ТЗ. Их не возможно оценить через ТЗ.
G>Еще как оцениваются. Я только так людей и набираю последнее время. Мне даже резюме смотреть неинтересно, там чаще всего никаких полезных сведений нет.

Да тебе все что угодно сделают на ТЗ если решили тебя "надуть".
И идеально код напишут, и в срок, и предупредят и уточнят по ТЗ.
Но это ни о чем не скажет, кроме того что люди "не бараны".
А ты же отбираешь, не "не баранов"?


K>>>>Ну и если его набирать на работу, то какое тестовое задание ему давать?
G>>>Видишь проблема в чем. Ты не говоришь чего ты хочешь от этого человека. Может даже не знаешь. Если бы ты знал, что тебе нужно от человека, то проблем с тестовым заданием не было бы вообще.

K>>Я уже сказал — что уверен что он подойдет для любого говна которое есть, проблема в том — захочет ли он в нем копаться.
G>Тогда почему вопрос в ТЗ? Этот человек overqualified для тебя, тестовое задание тут не при чем.

Да просто ТЗ надо для других. А этих надо отбирать по другому.
)

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

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

от размеров команды это не зависит.
но для избежания этого в процессе работы есть иные средства.

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

S>Никто как правило не горит желанием устроиться строго в определённую нонейм контору. Резюме рассылаются пачками, за день можно побывать на трёх собеседованиях. Поэтому наличие домашнего тестового задания на дом сразу отсеивает по-настоящему хороших спецов — они найдут работу ещё до того, как за это задание сядут.
Факт. Если работодатель предлагает мне сделать тестовое задание дома — идет сразу лесом. С какой радости я буду тратить своё личное время (а это часто не один час) на какой-то код одному из работодателей, которых на рынке десятки, а то и сотни. И да, большинство из них тестового задания не просят. Кроме того, на такую позицию клюнут те, кому уж очень нужна или работа вообще или работа за предлагаемую зарплату. Другими словами получается негативный отбор самим фактом наличия тестового задания.

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

Ну ок, пусть тестовое задание будет. Как насчет оплатить его выполнение?

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

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

G>>>Я не знаю, мне не надо. Но если для собеседования — легко расскажу так, что все подумают что знаю.
L>>Ну расскажи мне об предназначении boost::context и его устройстве, никуда не подглядывая.
G>Зачем мне тебе чего-то рассказывать?
G>Насколько помню context это что-то о кооперативной многозадачности.

По этим двум предложениям — No Hire.
По крайней мере в описанной тобой команде

1) Знание нужных фреймворков. Например в команде используется boost, а человек его не знает. В смысле слышал, но не использовал. На собеседовании можно отвертеться от вопроса про знание буста, а в тестовом задании никак не отвертишься.

Если собеседование провожу я, то одно только знание выражения "кооперативная многозадачность" — это уже почти Hire