Pull to refresh

Comments 16

И каковы зарплатные ожидания в местах с подобными тестовыми заданиями, если не секрет?
Очень сложно что-то сказать, даже назвать диапазон. Часть компаний были из США. Зарплаты в разных местах отличаются в разы, + сложно сопоставлять зарплату со сложностью задания, так как за ним может еще и последовать череда интервью, например 7 часов, а может и ничего не последовать. Если брать только компании из России (Москва, Спб) то все немного выходит за верхнее значение диапазона из этого исследования. www.macdigger.ru/iphone-ipod/srednyaya-zarplata-ios-razrabotchika-v-rossii-sostavlyaet-ot-48-000-do-100-000-rublej.html
Задание 4. Маленький браузер
Сюда 3500-5000$. Американская компания с офисом в России.
Тестовые задания отлично показывают чего стоит соискатель, но тратят его время. Я считаю идеальным вариантом, оплачиваемое тз. Пусть по не большому рейты, но за любую работу надо платить. На такие варианты я натыкался всего три раза. Они были объемнее и сложнее чем не оплачиваемые, но хорошо показывали уровень.
Здесь часто возникает ситуация: программа работает, но она написана ужасно. Как за это платить? Использую тестовые задания, но маленькие по объему, где-то минут на 30(вместо наборов тестов и дурацких вопросов). Вполне достаточно, чтобы оценить уровень программиста, плюс появляется тема для продолжения беседы.
Так оплачивается не код программы, а время человека, который потратил его на ваше задание. Здесь результат не сам код, а ваши выводы об уровне кандидата, основанные на этом коде.

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

Не вижу разницы, попросить простую архитектуру набросать. Всегда можно придумать небольшое задание с подводными камнями, и смотреть как их кандидат пытается обойти.
Если человек приходит на собеседование не за работой — вы как-то неправильно отбираете кандидатов, или неправильно их зовёте :) Вовсе не обязательно объявлять об оплачиваемом тестовом задании сразу да ещё и на первой же встрече. Но, по-моему, позиция «программа работает, но она написана ужасно. Как за это платить?» это как «если мне не понравится — то не заплачу». Представьте, что после завершения работы над проектом заказчик говорит вам «написано ужасно, я не буду платить». Либо платить независимо от результата, либо вообще не платить, без вопросов «как за это платить?» и каких-то условий
Я имел в виду, что оплачивать тестовое задание, так же как и давать огромное тестовое задание — это неверный шаг.
Условием было использование Objective-C, из этой выборки никто не использует свифт в продакшене или только начинают. Опасаются рисков и некоторого порога вхождения.
Опытный прогер, как и любой другой профессионал, быстро должен определять человек какого уровня пришел на собеседование во время знакомства и общения. Уровень определить не очень сложная задача, куда сложнее увидеть личные качества как усердие, реальная устремленность, способность находить решение без лишних движений. Для этого существует испытательный срок.

Голосую за испытательный срок, не за тестовые задания.
UFO just landed and posted this here
Задания действительно типовые, проверяют способность выполнять каждодневную рутину, что собственно и описано в пункте «Что в среднем». Головоломные вещи и способность делать что-то нетривиальное (если такие качества нужны работодателю) проверяются на этапе собеседования.
Гм… посмотрел AsciiSymbolsCounter. Такое ощущение, что на строке в 129 или 257 символов типа «aaa...ab» решение благополучно выдает неверный результат. Или в Objective-C под char отводится более 8 бит?
Да, похоже есть такая проблема, заведу issue в github, спасибо.
Sign up to leave a comment.

Articles