Примеры тестовых заданий для iOS-разработчиков

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



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

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

    Задание 1. Поиск GIF.


    Внимание: в коде отсутствует API key для giphy.com — нужно вставить самому
    github.com/PavelKatunin/GifSearcher
    Создать приложение которое стучится по запросу в API giphy.com и достает оттуда гифки по запросу из
    UITextField. Отображает анимированные гифки в UICollectionView.

    Никаких ограничений по переиспользованию кода озвучено не было, поэтому смело был подключен RestKit через cocoa pods, взяты категории для инициализации UIImage с Gif и написана несложная логика.

    Скриншоты


    Задание 2. Поиск картинок.


    github.com/PavelKatunin/GoogleImagesSearcher
    Здесь примечательного то, что написание кода нужно было демонстрировать через скайп в течение примерно часа, но доделать можно было потом. Так же было запрещено использовать сторонние библиотеки — только NSURLConnection — только хардкор. Нужно было используя Api Google по запросу доставать картинки и отображать их в UITableView. Так что был создан базовый класс для запросов реализующий NSOperation и пара конкретных реализаций запросов.

    Скриншоты


    Задание 3. Поиск наиболее часто встречающегося символа в ASCII последовательности.


    github.com/PavelKatunin/AsciiSymbolsCounter
    Нужно найти самый частый символ в ASCII строке, при этом мы никак не ограничены по памяти.
    Еще все это нужно было распараллелить на 2 потока.

    Задание 4. Маленький браузер.


    github.com/PavelKatunin/TinyBrowser
    Написать простейший браузер с адресной строкой, отображением прогресс бара при загрузке и возможностью ходить назад и вперед по истории, не возбраняется использование WKWebView. Дополнительно к этому делу был реализован поиск из адресной строки и несколько тестов.

    Скриншоты



    В работе еще несколько тестовых заданий, которые я тоже собираюсь выложить в open source если это кому-то будет интересно.

    Что в среднем.


    Бывало и так, что просили просто написать контроллер c UITableView с фиктивными данными, но при этом демонстрировать свой экран. Но обычно работодатель хочет удостовериться в том, что вы в состоянии взаимодействовать с серверным API, загружать что-то в бэкграунде и отображать на UI (Часто это вездесущие UITableView или UICollectionView, кстати, работодатели могли бы придумывать что-то похитрее). Важным еще является читаемость кода и архитектура решения. Гораздо шире, но поверхностнее другие вещи обсуждаются на самом интервью. Все в целом — далеко не Rocket science, но будьте внимательны и постарайтесь оставить хотя бы один день для исправления багов, утечек памяти и отладки производительности приложения — это тоже очень важно, они хотят увидеть маленькое, но законченное приложение. Меня пару раз халатность подвела — и это тоже хороший детектор того, что человек не очень то и хочет в эту компанию.

    Кстати некоторые задания выкладываются публично, тоже интересно посмотреть goo.gl/PCqa0i
    Желаете показать примеры задания + решения (?) — можно поделиться в комментах.

    Спасибо за внимание.

    Опрос:

    Only registered users can participate in poll. Log in, please.

    Я участвую в интервью как кандидат и считаю, что тестовые задания

    • 73.9%это хорошо587
    • 26.1%это зло207

    Я отбираю людей, провожу интервью и считаю, что тестовые задания

    • 73.6%это хорошо359
    • 26.4%это зло129

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 16

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

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

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

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

                  Only users with full accounts can post comments. Log in, please.