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

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

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

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

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

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

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

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

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

, серия-2

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

.

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

S>See you!

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

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

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

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


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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Не сказал бы. У меня бывало так, что сначала мне человек не нравился, а в ходе беседы я менял мнение на 180 градусов. Или наоборот.

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

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

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

G>>2) Обязательность — отправляешь задание и спрашиваешь когда будет готово, так чтобы точно. Успел в срок — молодец, прислал на пару дней позже — также будет сроки по проекту факапить. Если заранее сообщил что не успевает по объективным причинам — может быть плюсом.
L>
Зря фейспалмичаете. У меня много разногласий с Ганджустасом, но здесь я с ним согласен. Я тоже спрашиваю сроки и про себя отмечаю: будут соблюдены или нет? Нестрашно сказать "я сильно занят, поэтому с запасом назову срок в 3 недели", страшно "сделаю за 5 дней", а прислать через 10. Это просто показывает обязательность человека, умение планировать свое время и давать этому оценку.

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 лет в индустрии коту под хвост, видимо.

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

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

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

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

F>но для избежания этого в процессе работы есть иные средства.
Да? И какие же? Свою голову пришить?

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

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

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

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

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

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

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

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

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

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


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

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

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

F>>но для избежания этого в процессе работы есть иные средства.
S>Да? И какие же? Свою голову пришить?

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

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

S>Зря фейспалмичаете. У меня много разногласий с Ганджустасом, но здесь я с ним согласен. Я тоже спрашиваю сроки и про себя отмечаю: будут соблюдены или нет? Нестрашно сказать "я сильно занят, поэтому с запасом назову срок в 3 недели", страшно "сделаю за 5 дней", а прислать через 10. Это просто показывает обязательность человека, умение планировать свое время и давать этому оценку.



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

Впрочем, если вы красноглазиков нанимаете, то все верно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А откуда известно, что этот метод не отсек тех, кто может работать еще лучше? Я вот уверен в том что узнав про необходимость делать ТЗ top-10% из всех откликнувшихся на вакансию развернулись и ушли.