Здравствуйте, Anatolix, Вы писали:
A>Цель для кандидата понятная, задание нужно выполнить, чтобы попасть на собеседование.

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

A>Может я в чем-то ошибся, давно это было. А можно увидеть решение, или где об этом почитать?

в википедии есть страница: http://en.wikipedia.org/wiki/Cycle_detection
применяется для задач типа нахождения периодов генераторов псевдослучайных чисел.
Для кадров потокового видео выглядит довольно бессмысленно.

G>Если не секрет — как ие задания для тимлидов/архитекторов?

Ну, тимлиды/архитекторы — это совершенно другая история.

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

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

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

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

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

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

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

A>>Нет, попросить написать сортировку.
L>На такой вопрос существует только один правильный ответ.
L>"До свидания".

Имело бы смысл, если б работодатель приходил к тебе, а не ты к нему.

Здравствуйте, Кодёнок, Вы писали:

A>>>Нет, попросить написать сортировку.
L>>На такой вопрос существует только один правильный ответ.
L>>"До свидания".
Кё>Имело бы смысл, если б работодатель приходил к тебе, а не ты к нему.

Имеет смысл всегда. Если нет дикого желания работать в конторе по написанию сортировок.

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

N_>Хм.. а наличие нескольких завершонных проектов и высланный пример кода разве не говорит об этом

Реальный пример: написано, 1 год такой-то проект, повышенные требования к надежности, требует очень глубокое знание WinAPI, api hooking, кроссплатформ x86-x64. Выслан пример кода, он хороший. Убеждает? На самом деле: архитектура и рабочие техники уже придуманы главным программером, задачей было лишь дописать фичи, которые тянул на троечку с N-й итерации, не раз скомпрометировав надежность, а код хороший потому что было много ревью.

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

Вы в такой форме решили эту дискуссию вести? Сидит человек, попробовавший принять по короткому собеседованию, и говорит: спросить по STL и попросить написать сортировку недостаточно. Другой говорит, ДА, достаточно. НЕТ, недостаточно. ДА, достаточно. НЕТ, недостаточно. ДА, достаточно. НЕТ, недостаточно. ДА, достаточно. НЕТ, недостаточно. ДА, недостаточно. НЕТ, достаточно.

Задача: за 1-2 встречи сформировать приближенную оценку качеств человека, которая не разойдется с полным представлением о его умениях, которое появится через полгода работы. Решения? Принимать нельзя, во-первых кандидатов шесть, место одно, во-вторых, через полгода проект уже альфу показывать, а не говорить заказчику «с программистом не вышло, бросим кубик еще разок».

Здравствуйте, Кодёнок, Вы писали:

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

A>>>Нет, попросить написать сортировку.
L>>На такой вопрос существует только один правильный ответ.
L>>"До свидания".

Кё>Имело бы смысл, если б работодатель приходил к тебе, а не ты к нему.

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

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

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

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



G>>Лично я получил большое удовольствие даже просто от решения этого задания, при этом потратил на него всего несколько часов.
Dog>А я получил удовольствие проведя эти пару часов не за компьютером

Дык не вопрос — значит конкретно эта работа тебе не нужна

G>> Возвращаясь к вопросу о том, какую информацию можно извлечь о кандидате из такой небольшой проги. К примеру, сразу видны "архитектурные таланты" человека — какие сущности он там завел, как распределил задачи, может даже — не дай конечно бог такого! — подумал о производительности, или о затратах памяти (к примеру, что будет с прогой, если файл размером 10 000 х 10 000 ячеек?) ну и тд и тп.
Dog>О боже, большие файлы. В ТЗ конечно об этом ни слова.

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

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

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

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

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



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

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

G>>В конечно итоге: если вам увиденное творение кандидата понравилось — приглашаете на собеседование (просто посмотреть что за человек, пообщаться приятно о футболе ну и т.п.) и если он адекватен — делаете тут же оффер
Dog>Ну я так и понял, что общаетесь вы только о футболе, а для остального у вас есть тестовое задание

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

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

G>>Хочешь сменить работу, получить больше денег, новую должность — будь добр, попотей. Не хочешь потеть — сиди где сидишь. А совкое мышление — это как раз попытка и рыбку съесть, и на кое-что не сесть

A>Это смотря как потеть. Как выше упоминалось задания могут быть очень объемными. Лучше потеть без заданий это более эфективно с точки зрения соискателя. Единственное если нет совсем выбора, тогда можно пытаться.
A>Если объем большой и сроки как правило ограничены — это бесполезно (надо еще есть, спать и т д)

Полностью с тобой солидарен — каждый для себя сам решает что для него объемное задание, что нет, стоит ли потеть или не стоит лишний раз напрягаться.

A>>>У вас в конторе тестеры есть, тогда почему вы решили что разработчик сам способен качественно протестировать, также как и команда тестеров.

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

A>Да, код обычно проверяется разаработчиком, причем тщательно. Но чтобы очень тщательно нужно много времени, котрого в данной ситуации просто нет (если конечно человек не работает а ищет работу).

Итить-колотить... ДА НЕ НУЖНО очень тщательно, понимаешь, НЕ НУЖНО. Мне вот лично было бы достаточно увидеть общую картину, увидеть ее "здравость", тенденции и тд и тп. Между черным и белым есть миллион градаций серого, и именно такие градации меня (ну и нормальных людей) и интересуют. САМО СОБОЙ, если чел начнет трахать тебе мозг типа "Почему у вас тут такие отступы, а тут вот такие — в нашей компании это совершенно недопустимо!" то тут можно сразу слать всех на...(ну ты понял) — такая контора вряд ли нужна нормальному человеку.

A>Это smoke test, дальше может быть напр. unit test. Затем тестеры тестируют это может быть product test. Команда тестеров найдет кучу багов как бы тщательно не тестировал разработчик, следует также учитывать ограниченость во времени.

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

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

A>Он высморит весьма поверхностно. Так и проводите только интервью без заданий, высматривайте кандидатов.

Ну вот в нашей конторе мы так и проводим (я к примеру) Но была бы возможность — я бы давал и тестовое задание. Я просто реально отдаю себе отчет в том, что 2-хчасовая беседа далеко не всегда может представить кандидата в верном свете. Может, к примеру, оказаться так, что мы его недооценим — ну вот не умеет человек подать свои достижения в правильном свете. Или наоборот — вам попался умелец пускать пыль, "sales" (и такое бывало). А весна (то есть небольшое, но грамотно составленное тестовое задание) покажет, кто где сра.. какал

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

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

A>Речь выше шла о том что кандадату интересен проект в конк компании. Но это может несовпадать с мнением кандидата и все.

Не понял — что с чем не может совпадать

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

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

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

G>>Хорошо налажен процесс только на конвеере генри форда. А в нашей отрасли специфика такова, что каждый человек таки очень ценен (при всех там процессах, ISO, CMMI и других страшных словах). Хотя бы просто потому, что есть проекты, въехать в которые занимает месяцев 6. И если человек уже въехал в прожект и работает на нем нормально, его потеря обернется: а) поиском нового кандидата б) скорее всего — срывом сроков, урезанием скоупа, недовольными клиентами, потерей денег для конторы в) риском того, что нанятый чел таки не въедет в прожект — то есть опять а) и б).

A>Процесс нуже везде.

А кто ж спорит

A>Разработка ПО такая же индустрия как и все остальное.

Небо голубое... трава зеленая...

A>Есл у вас принято делать на коленках — это ваши проблемы, которые и происходят из за этого. Те риски которые вы описали предсказуемы и ими легко управлять. ISO, CMMI это не страшные вещи а вполне работающие стандарты, правила и принципы. Все зависимости от ISO, CMMI описанные проблемы имеют регуларную основу. Попытайтесь управлять их появлением и снижением риска их появления

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

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

N_>Здравствуйте, eshe_odin_programmer, Вы писали:
__>>Вот мнение моего коллеги "с той стороны баррикады".
__>>http://eao197.blogspot.com/2010/05/work.html


N_>Бред написан.
N_>Разбор его тезисов:

N_>

N_>умеет ли человек программировать;

N_>Хм.. а наличие нескольких завершонных проектов и высланный пример кода разве не говорит об этом

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

N_>

N_>есть ли у человека устоявшийся подход к разработки программ (в простейшем случае – придерживается ли он какой-то нотации);

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

Но при этом аааабсолютно нифига не понятно, что именно этот код делает, и делает ли вообще — может это какой-то мертвый бренч, который еще 10 лет назад был вырезан из кода ifdef-ом, но по старой памяти все еще живет в сорцах.

N_>

N_>умеет ли человек тестировать программы;

N_>Эээ.. а типа тут ктото в тестеры нанимается чтоль?

Ну да — не читатели, писатели ведь

N_>

N_>умеет ли человек вникать в поставленную перед ним задачу;

N_>для этого достаточно дать задачку обьемом в 10 минут, а не несколько дней.

Ну на несколько дней это конечно перебор, а вот часиков на 6-8 из рассчета по 2 часа в день в течении недели — не повредит.


N_>

N_>умеет ли человек критически относиться к написанному им коду;

N_>Это как интерестно

Хороший вопрос кстати — я тоже не понял этой мысли
N_>

N_>размер достойной оплаты человека на время испытательного срока.

N_>Тока на основе тестового задания

N_>-------------
N_>Вобщем ахинею написал твой знакомый.

Да не, нормально написал. Чуток сумбурно, но вцелом нормально.

Здравствуйте, Glоbus, Вы писали:
A>>И потом. если локомотив уйдет у вас что все остановиться? Когда было мнго работы, года два назад примерно, такие локомотивы уходили пачками и контора не всегла могла им предложить повышение. Если вы руководитель ваша задача добиться результата независимо от того кто ушел или пришел.

G>"Вы обязаны добится бла бла бла" — это все прописные истины типа трава зеленая, небо голубое. Да, добится полной независимости от каждого конкретного человека — это прекрасная идея, я бы сам такого хотел (и на этой почве уже не первый год ломаю копья в битве с заказчиками, начальством и всеми по кругу). Но к сожалению за всю свою жизнь я видел только одну контору где это работало в практически идеальном варианте. Но там к каждому человеку и относились именно как к винтику: один выкинули — вставили другой, колесики крутятся дальше. А если я буду относиться к каждому человеку (ну и кандидату соотвественно) как к винтику, мне пофиг на его свободное время (тем более если он уменя еще не работает): если работа нужна — напишет мне задание в виде компилятора С++ за неделю, не нужна — найдем более сговорчивый винтик Так что тут везде свои подводные камни

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

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

Ответ — PR. В прессе обилие восторженных статей про Яндекс написанных прикормленными журналистами. И печенешки у них бесплатные, и теннисный стол есть, и работа круче которой нет на свете. То же самое, еще в большей степени относится к Google.

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

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

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

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

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

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

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

N_>>Высланный пример кода подойдет здесь гораздо лучше — потому что он может быть напорядок обьемней тестового задания.
G>Но при этом аааабсолютно нифига не понятно, что именно этот код делает, и делает ли вообще — может это какой-то мертвый бренч, который еще 10 лет назад был вырезан из кода ifdef-ом, но по старой памяти все еще живет в сорцах.

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

N_>>

N_>>умеет ли человек критически относиться к написанному им коду;

N_>>Это как интерестно
G>Хороший вопрос кстати — я тоже не понял этой мысли

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

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

N_>Насамом деле такой процесс вполне реально построить — ничего космического в этом нет.

А что, кто-то где-то писал что это НЕреально?

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

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

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

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

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


E>>>Тестовое задание — идеальный вариант собеседования.

G>>+1000

A>Ничего идеального в этом мире нет.

Nobody is perfect, but I'm pretty fuckin' close

E>>>Особенно если оно оплачивается

G>>А вот этого я вообще не понимаю А почему только тестовое задание? А может и собеседование оплатим? Ну типа ж чел пришел с нами посидеть, потрещать?

A>Здесь имеются ввиду тестовые задания до собеседования на которые необходимо потратить 8 часов и более. Рабочий день программиста стоит скажем 100$. Т.е. работодатель как бы говорит. Отдай нам свои 100 баксов, а мы подумаем, пригласить тебя или нет. Понятно, что у безработных это не 100$, а 0$. Но ведь большинство именно работают.

Хм... работодатель же не требует делать это задание в рабочее время — так что свои 100 баков никто не теряет. Можно конечно сказать "а вот если бы я эти 8 часов своего рабочего времени потратил на ... то это были бы 100 у.е., а так я трачу на неоплачиваемое задание... т.е. 100 у.е. как бы теряются" — вопросов нет если человек уж так себя ценит, то наверное всем будет лучше если он действительно вместо тестового задания будет ничего не делать и как бы не потеряет эти 100 условных баксов Я тут уже писал, и напишу еще раз — все зависит от мотивации каждого отдельного кандидата: не нравится процедура найма в конторе Х — его туда никто силком не тянет

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

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

N_>>>Высланный пример кода подойдет здесь гораздо лучше — потому что он может быть напорядок обьемней тестового задания.
G>>Но при этом аааабсолютно нифига не понятно, что именно этот код делает, и делает ли вообще — может это какой-то мертвый бренч, который еще 10 лет назад был вырезан из кода ifdef-ом, но по старой памяти все еще живет в сорцах.

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

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

N_>>>

N_>>>умеет ли человек критически относиться к написанному им коду;

N_>>>Это как интерестно
G>>Хороший вопрос кстати — я тоже не понял этой мысли

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

Эт оно конечно да

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

G>В случае объемных заданий человек может попросить знакомого гуру выполнить задание за него.
G>Что проверяется такими заданиями

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

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

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

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

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

Ха, и это тоже бывает правдой.
У меня идея создать топик как раз из-за компании, которая нарыла на HH мое резюме годичной давности и стала вести беседы о трудоустройстве.
Интересно, почему они меня откопали? Ведь если резюме не обновлялось год, слишком мала вероятность, что человек реально активно ищет работу.

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

Так в чем же дело?
А в том, что после первого собеседования огорошили тестовым заданием часов так на 16. И моя мотивация продолжать общаться резко упала.

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

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

A>>Здесь имеются ввиду тестовые задания до собеседования на которые необходимо потратить 8 часов и более. Рабочий день программиста стоит скажем 100$. Т.е. работодатель как бы говорит. Отдай нам свои 100 баксов, а мы подумаем, пригласить тебя или нет. Понятно, что у безработных это не 100$, а 0$. Но ведь большинство именно работают.

G>Хм... работодатель же не требует делать это задание в рабочее время — так что свои 100 баков никто не теряет. Можно конечно сказать "а вот если бы я эти 8 часов своего рабочего времени потратил на ... то это были бы 100 у.е., а так я трачу на неоплачиваемое задание... т.е. 100 у.е. как бы теряются" — вопросов нет если человек уж так себя ценит, то наверное всем будет лучше если он действительно вместо тестового задания будет ничего не делать и как бы не потеряет эти 100 условных баксов Я тут уже писал, и напишу еще раз — все зависит от мотивации каждого отдельного кандидата: не нравится процедура найма в конторе Х — его туда никто силком не тянет

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

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

Это мое мнение как разработчика о мотивации.