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

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

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

D>PS. Правда там 10 лет опыта в резюме фигурировало, так что мог себе позволить

Хе-хе, судя по ответам дающих задания, чем больше опыта — тем больше должно быть задание

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

Кё>Здравствуйте, jeeist, Вы писали:
J>>Проблема в том, что программист работал один, делал все сам, начиная на пустом месте, от начала до конца, занимаясь всем, с различной степенью успеха.
J>>Ясно, что в Вашей компании работают по-другому и программисту придется кардинально изменить стиль работы, при этом получая помощь от коллег, которая не была доступна раньше.

Кё>Не вижу тут проблемы. Если ты опасаешься, что работа в команде будет непривычна, то зря, если не клинический аутист, то это наоборот проще и веселее.

Если я правильно понимаю, тестовое задание приходится
выполнять уже в команде, в условиях, "приближенных к"?

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

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

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

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

V>>Только не просто один кандидат, а один подходящий кандидат. А вот с этим сложнее.

PD>Сорри, но не смог удержаться, чтобы не процитировать Паркинсона.

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

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

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

G>>Многие компании в процессе трудоустройства дают тестовое задание

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

J>А здесь — один раз высосал из пальца тестовое задание, которое не имеет никакого практического смысла, и дальше только галочки в Excel-е ставишь — выполнил/невыполнил.

Не могу согласиться со сказанным. Если интервьювер ленив, то ему тестовое задание не поможет — хотя бы просто потому, что он поленится прошерстить код, посмотреть как там и что, какие подходы использовались, как человек пишет, ну и все в таком духе. Я сам был на многих собеседованиях, и с той и с другой стороны. И мне лично кажется, что тестовое задание — вещь хорошая (хотя я лично и не применяю). Само собой, давать задание на неделю работы — форменный фашизм. Однако, хорошо состалвенное задание займет ну максимум часов 6-8 выполнения (скажем по 2 часика после работы) и скажет о кандидате ну оооочень много — во всякмо сулчае, всего этого на собеседовании не вытянешь.

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

J>Вместо "программист" следует читать
J>"человек, пытающийся стать программистом"

J>Если программист переходит из одной компании
J>в другую и нет сомнений в его адекватности,
J>то скорее всего тест такого рода не нужен.

Ага, и собеседование тоже ненужно Сразу наливаешь ему 7К зелени — и вперед, пусть идет к станку — лазить по ютубу

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

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

Не понимаю, в чем проблема Берем в качестве примера тестовое задание из одной конторы, в которую я ломился лет пять назад: простая реализация электронных таблиц. На входе: текстовый файл (Н строк на М столбцов, столбцы разделены табами/запятыми/... ), в каждой ячейке — простое выражение (к примеру A2 + 4*(16-D5)). Задача: написать консольную прогу, которая засасывает этот файл, считает значения в ячейках, на выход выдает другой файл такого же с готовым результатом по каждой ячейке. Дополнительные требования: прога должна адекватно сигнализировать об ошибках в выражениях, циклических ссылках ну и т.п (скажем, выдавая просто сообщение на экран — мол в ячейке такой-то неверное выражение ну и т.п.). Можно еще чего-то придумать, но думаю этого вобщем достаточно.
Лично я получил большое удовольствие даже просто от решения этого задания, при этом потратил на него всего несколько часов. Возвращаясь к вопросу о том, какую информацию можно извлечь о кандидате из такой небольшой проги. К примеру, сразу видны "архитектурные таланты" человека — какие сущности он там завел, как распределил задачи, может даже — не дай конечно бог такого! — подумал о производительности, или о затратах памяти (к примеру, что будет с прогой, если файл размером 10 000 х 10 000 ячеек?) ну и тд и тп. Далее, можно составить представление о стиле кодирования — выдержан ли единый стиль (пофиг какой), есть ли хоть минимальные комментарии, обрабатываются ли ошибки, исключения ну и т.п. Кроме того, сразу отпадает вопрос об алгоритмических способностях — скажем, если сумел залезть в инет, нарыть там требуемую инфу или алгоритм, разобраться и заимплементить то, что было нарыто — честь ему и хвала. Кроме всего прочего, еще хдоп.плюсом будет считаться, если кандидат начнет спрашивать типа "а как поступить в такой-то ситуации? а что если...? если вы выступаете в роли заказчика — то как будет вам удобнее" — из этих копеечных вопросов видно, что человек задание прочитал внимательно, осмыслил, переварил, выявил у нас же самих в задании какие-то косяки и грамотно попытался разрулить ситуаху. Другими словами, можно заведомо внеся неясность, прошерстить умение человека работать с требованиями. А то бывает — приходит какой-то сенйор архитектор, пальцы веером, типа "я из наса, шатлы запускал", а потом оказывается что он по уровню — просто студос (и то еще не лучший).
В конечно итоге: если вам увиденное творение кандидата понравилось — приглашаете на собеседование (просто посмотреть что за человек, пообщаться приятно о футболе ну и т.п.) и если он адекватен — делаете тут же оффер

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

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

J>>Вместо "программист" следует читать
J>>"человек, пытающийся стать программистом"

J>>Если программист переходит из одной компании
J>>в другую и нет сомнений в его адекватности,
J>>то скорее всего тест такого рода не нужен.

G>Ага, и собеседование тоже ненужно Сразу наливаешь ему 7К зелени — и вперед, пусть идет к станку — лазить по ютубу

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

Только скорее всего речь идет о 2 заданиях — до
собеседования и после (или во время), опять же
см. ниже.

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


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

+1000


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

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

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

Поддерживаю

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

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


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

G>+1000

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

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

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

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

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


Кё>>Если есть свои проекты, или заметное участие в open-source (целые модули), то они прокатывают, так что обязательно стоит указывать. Цель не задание, а оценка, дайте надежный способ оценки, и готово.

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

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

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

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

A>Затем,
A>Если будете искать полгода, то где гарантия что сотрудника все будет устраивать и он не уйдет через день. Затем искать опять полгода.

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

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

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

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

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

Здравствуйте, Тролль зеленый и толстый, Вы писали:

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

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

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

G>Ага, и собеседование тоже ненужно :)) Сразу наливаешь ему 7К зелени — и вперед, пусть идет к станку — лазить по ютубу :))

Это что за бредовые мячты: пара штук, вот о чем речь, а уж понтов-то!

Кстати, забавно. На Привете очередной русскоязычный гоблин жалуется: 200 кандидатов пришло — некого брать! все с 10ю годами опыта — и все НИКУДЫШНЫЕ. Все тупее интервьюера, вот ведь беда какая!

ну где ему ровню найти, а?

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

G>Многие компании в процессе трудоустройства дают тестовое задание, при этом время его выполнения может превышать рабочий день.
G>У меня вопрос к тем, кто бывал по другую сторону баррикады, к тем, кто нанимал людей и давал тестовые задания.
G>1)Зачем нужны задания вообще?
G>2)Разве поиск сотрудника не заходит в тупик, отпугивая большинство претендентов заданиями?
G>3)Зачем нужны объемные задание (8+ часов)?

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

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

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

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

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

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

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


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

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

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

Кё> Если вы простой разработчик, отославший честное резюме на подходящую позицию, шанс его не сделать 0.0%. Откройте пиво, сделайте его, и потом уверенно отвечайте на вопросы.
Лучше я открою пиво и включу футбол

Кё>Вторая половина критериев — не отборочные, а просто плюс-минус, по ним составляется мнение и начальное предложение о зарплате.
Ну так бы и сказали что джуниоров набираете

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

G>>>Разработка — практическая дисциплина и навыки гораздо важнее знаний.
Dog>>Вопросы дисциплины не проверяются написанием тестовых заданий. Я вам в задании даже каменты расставлю там где надо. И о чём это будет говорить ? Правильно — ни о чём.
G>http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D1%81%D1%86%D0%B8%D0%BF%D0%BB%D0%B8%D0%BD%D0%B0
G>Особо думать над первыми двумя пунктами.
А что о главном третьем скромно умолчали ?

Дисциплина — поведение направленное на порядок, подчинение приказам

Dog>>Лучшая мотивация — указаная нормальная вилка зарплат.
G>Написать можно любые цифры, сколько будете получать — совершенно другой вопрос.
Я уже понял, что вы не собираетесь честно указывать вилку.

G>>>ИМХО прием на работу программистов должен выглядеть так:
G>>>1)Формальное тестирование, чтобы отсеять совсем неготовых.
Dog>>В чём заключается ?
G>Тупо тест с 4-мя вариантами например.
Опять тупотест ? Как вы относитеть к ЕГЭ ?

G>>>2)Общение с техническим спецом на тему "где работал?", "чем занимался?", "какие достижения?" итп
Dog>>Дай бог чтобы этот "спец" два слова связал на общие темы.
G>Тогда нафиг не нужен такой спец
У вас любой технический "специалист" сможет провести собеседование на общую тему и разговорить человека ?
Сколько из них вы готовы уволить ?

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

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

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


Кё>>>Если есть свои проекты, или заметное участие в open-source (целые модули), то они прокатывают, так что обязательно стоит указывать. Цель не задание, а оценка, дайте надежный способ оценки, и готово.

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

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

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

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

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

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

A>>Затем,
A>>Если будете искать полгода, то где гарантия что сотрудника все будет устраивать и он не уйдет через день. Затем искать опять полгода.

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

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

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

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

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

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

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

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

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

A>Можно человека выгнать и через неделю. И кстати, потраченное время других разработчиков которые помогают "новичку", оплачивается из его кармана. Т.к. на испытательном сроке денежное вознаграждение ниже. К тому же не всем нужна такая помощь.

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

Здравствуйте, alzt, Вы писали:
A>Если выбирать между двумя вариантами (выгнать через 2 недели или сделать тестовое задание), то лучше сделать тестовое задание, как минимум не надо увольняться с текущего места работы.
Для кандидата раздница очень большая : эти одна-две недели оплачивабтся, а выполнение тестового задания нет.

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

G>>>>Разработка — практическая дисциплина и навыки гораздо важнее знаний.
Dog>>>Вопросы дисциплины не проверяются написанием тестовых заданий. Я вам в задании даже каменты расставлю там где надо. И о чём это будет говорить ? Правильно — ни о чём.
G>>http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D1%81%D1%86%D0%B8%D0%BF%D0%BB%D0%B8%D0%BD%D0%B0
G>>Особо думать над первыми двумя пунктами.
Dog>А что о главном третьем скромно умолчали ?
Dog>

Dog>Дисциплина — поведение направленное на порядок, подчинение приказам

Меня это уже пугает. Предлагаю всетаки прочитать все первое предложение и сходить по ссылке.

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

G>>>>ИМХО прием на работу программистов должен выглядеть так:
G>>>>1)Формальное тестирование, чтобы отсеять совсем неготовых.
Dog>>>В чём заключается ?
G>>Тупо тест с 4-мя вариантами например.
Dog>Опять тупотест ? Как вы относитеть к ЕГЭ ?
Причем тут ЕГЭ?

G>>>>2)Общение с техническим спецом на тему "где работал?", "чем занимался?", "какие достижения?" итп
Dog>>>Дай бог чтобы этот "спец" два слова связал на общие темы.
G>>Тогда нафиг не нужен такой спец
Dog>У вас любой технический "специалист" сможет провести собеседование на общую тему и разговорить человека ?
Dog>Сколько из них вы готовы уволить ?
У меня не так много специалистов, но они все могут разговорить человека, как на технические темы, так и не очень.

Dog>>>Такие вопосы больше для HR или директора, ну или кто там ещё будет присутствовать.
G>>то грамотный технарь на умняке разведет технически неграмотного руководителя.
Dog>Я рыдаю... если технари такие умные, почему ими руководят руководители ?
Наверное потому что руководители нетехническими вопросами занимаются.