Что вы думаете о тестовых заданиях?

[EVGL]

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

[belugin]

Цитата:

Сообщение от EVGL

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

Какого объема? Можно пример?

[EVGL]

Цитата:

Сообщение от belugin

Какого объема? Можно пример?

На день работы: сделать таблицу и написать форму, которая являлась бы источником складских проводок. Например, расщепляла бы строку на delivery schedule.

Ныне для AX2012 я бы попросил соорудить нечто, реализующее концепцию SourceDocument и создающее проводки в ГК. Сам бы за день не справился, признаю, но я и не разработчик уже как 7 лет.

[ax_mct]

Цитата:

Сообщение от EVGL

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

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

Апофеоз глупости (довольно распространенный) когда дают 40-60 минут с секундомером, отключают интернет и смотрят толпой на твой экран насколько уверенно ты печатаешь. До сих пор я в шоке после такого изнасилования

Более мягкие варианты когда просто в их офисе в условиях ограниченного времени ( 40-60 минут) являются меньшим злом но все равно глупость уместная только для отбора тех у кого нет реального опыта. Нормальные задачи чтобы было что оценивать уместнее давать на дом.
-----------------------------------------------------------------------------------------
Все выше про постоянную работу. В случае временной/контракторской/сдельной любые тесты IMHO - признак неадекватности. Потому как априори такие подрядчики обязаны иметь старший (senior) уровень и это сразу видно по опыту в резюме и через разговор.

Но есть как раз вторая часть как бы "на недельку в офис" в виде нотиса в 1 день в первую неделю контракта а то и двух. Притом и далее при отсутствии удовлетворительных результатов можно просто не заплатить. Что вполне само по себе тестирование.

[Morpheus]

Цитата:

Сообщение от ax_mct

Но есть как раз вторая часть как бы "на недельку в офис" в виде нотиса в 1 день в первую неделю контракта а то и двух. Притом и далее при отсутствии удовлетворительных результатов можно просто не заплатить. Что вполне само по себе тестирование.

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

[ax_mct]

Цитата:

Сообщение от Morpheus

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

Я именно про настоящие контракты (contract for services, contractor-client contract) когда человек фрилансер.
Использование контрактов при найме постоянного работника (contract of service, employee-employer contract ) это совсем другие по своей сути и содержанию контракты.

В первом случае (contractor) все проблемы вами описанные клиента просто никак не касаются.

Во втором случае (employee) такие жизненные обстоятельства касаются работодателя настолько насколько он в вас вложился и верит в ROI c вас.
И даже здесь все лишь ограничивается нотис-периодом. 1-2 месяца обычно. Никто никому ничего не должен IMHO.

[Bobkov]

Цитата:

Сообщение от EVGL

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

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

[EVGL]

Цитата:

Сообщение от Bobkov

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

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

[ax_mct]

Цитата:

Сообщение от EVGL

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

То есть когда консультант еще сам не знает про все доступные сценарии использования/тестирования, а программист предусматривает их все даже если они не описаны.
Не так ли?

[EVGL]

Цитата:

Сообщение от ax_mct

То есть когда консультант еще сам не знает про все доступные сценарии использования/тестирования, а программист предусматривает их все даже если они не описаны.
Не так ли?

Именно так! Но минимум - это чтобы работал тестовый пример, приведенный в техническом задании. Очень часто не работает даже это.

[ax_mct]

Цитата:

Сообщение от EVGL

Именно так! Но минимум - это чтобы работал тестовый пример, приведенный в техническом задании. Очень часто не работает даже это.

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

То есть вопрос в ролях и ожиданий насколько самостоятелен должен быть водитель.

[gudzon]

Цитата:

Сообщение от ax_mct

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

То есть вопрос в ролях и ожиданий насколько самостоятелен должен быть водитель.

Очень правильные слова.

[Ivanhoe]

Цитата:

Сообщение от ax_mct

То есть когда консультант еще сам не знает про все доступные сценарии использования/тестирования, а программист предусматривает их все даже если они не описаны.
Не так ли?

Цитата:

Сообщение от EVGL

Именно так! Но минимум - это чтобы работал тестовый пример, приведенный в техническом задании. Очень часто не работает даже это.

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

[ice]

Цитата:

Сообщение от Ivanhoe

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

а время потраченное программистами на уточнение ТЗ будет оплачено?

Цитата:

Сообщение от ax_mct

То есть когда консультант еще сам не знает про все доступные сценарии использования/тестирования, а программист предусматривает их все даже если они не описаны.
Не так ли?

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

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

Если делим что-то на что-то нужно сначала проверить, не появится ли в знаменателе 0.

Если что-то ищем, потом нужно поверить нашли ли и решить что делать, если не нашли.

Если есть if нужно подумать, что делать в случае else и нужно ли.

Если есть swith в нем обязателен default.

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

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

[ax_mct]

Цитата:

Сообщение от Кирилл

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

Это все верно на уровне реализации конкретного метода или методов, но не решения/проекта в АОТ. То есть это необходимо но часто недостаточно.
То есть хороший программист АХ должен думать не только о вариантах на уровне кода но и о вариантах использования на функциональном уровне то есть пользовательского интерфейса. Иначе он "плохой"