8 наставлений для выполнения тестовых заданий

Родин Илья

Вместо предисловия...

Для кого этот доклад?

1. Не бери на себя больше чем сможешь сделать

Не уверен, что на решение задачи дают достаточно времени?

- Скажи сколько тебе ПОТЕНЦИАЛЬНО надо для решения поставленной задачи

PROS:

- Ты покажешь, что в состоянии адекватно оценить свои навыки и сложность поставленной задачи

- Получишь больше информации о своих потенциальных работодателях, как минимум, станет понятен темп "гребли" ;-)

CONS:

- Возможно, больше ничего делать не понадобится...

Не уверен, что у тебя достаточно опыта/знаний для решения поставленной задачи?

- Тут уже надо смотреть по ситуации:

Если дело пахнет как-нибудь rocket science и ты банально даже не знаешь в какую сторону смотреть, то лучше сразу отказаться или сказать об этом, сэкономишь себе и другим людям кучу времени. Возможно, тебе дадут задание попроще.
Если примерно догадываешься что и где искать для решения поставленной задачи, то можешь рискнуть. Риск, обычно, хорошо оплачивается ;-) Как минимум, будет повод прокачать какой-то новый навык и получить обратную связь по результату выполнения работы.

2. Дьявол кроется в деталях...

1. Что-то не понятно в постановке задачи?

- За спрос денег не берут! Попроси дать больше информации по непонятным для вас требованиям.

2. Видите в постановке задачи какой-то изъян?

- Скажите об этом. Возможно это часть проверки вашей компетентности ;-)

P.S.: Недостаток информации может играть как против так и за вас! Этим можно воспользоваться...

3. Не берись за работу, которую НЕ ГОТОВ* доделать

*не хватает мотивации

1. Время-деньги!?

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

3. Начали, но по мере выполнения поняли, что вам это "не итнересно" или ничего не получается и вы сдаетесь?

- Как минимум, предупредите людей чтобы они не ждали от вас решения. Уважайте своей и чужое время! НЕ ПРОПАДАЙТЕ!

2. В принципе, не хотите начинать...

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

4. Не пренебрегайте подготовкой*

*конечно, если только у вас уже нет готового решения

1. Стоит задача интегрироваться с NoNameAPI?

- Перед тем как начать пробегитесь по нужным вам методам через Rest Console. Изучите структуры данных в рамках данного API

Могут быть полезными:

https://www.getpostman.com/

http://jsonviewer.stack.hu/

http://www.jsonschema2pojo.org/

2. Нужно использовать 3rd party sdk?

- Если уже работали с этим SDK, на всякий случай, просмотрите что поменялось с момента вашей предыдущей "встречи". Если не работали, то первым делом ознакомьтесь с официальными туториалы и Git аккаунтом.

- Если есть возможность, то потренируйтесь "на кошках" (соберите небольшой пример, попробуйте на нем сделать те операции которые нужны будут для выполнения тестового задания)

3. Определитесь с архитектурным подходом и стеком технологий которые вы собираетесь использовать

- Старайтесь ограничится тем с чем вы уже работали и более-менее хорошо знакомы.

P.S.: СуперНовомодныйФреймворк о котором вы вчера прочитали на Хабре - определенно не ваш выбор. Как минимум, если вы не планируете всю ночь разбираться как он работает ;-)

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

5. Копипаста - ЗЛО!!!

1. Старайтесь как можно меньше копировать чужие решения*, даже если они рабочие**

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

*а если копируете, то делайте это так чтобы никто никогда не смог вычислить настоящего автора ;-)

**Open Source - уже давно не образец качества решений, а интернет - мусорник мнений

2. Не перегните палку с 3rd party SDK/библиотеками!

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

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

6. Качество должно превалировать над количеством

1. Не делайте "заделов на будущее"*

*а если делаете, то делайте через TODO + описание что там должно быть

public class RemoteRepository {

    private static RemoteRepository instance;

    private static Context context;

    private RemoteRepository() {
    }

    public static RemoteRepository getInstance(Context ctx) {
        context = ctx;
        if (instance == null) {
            instance = new RemoteRepository();
        }
        return instance;
    }

}

2. Определитесь с стилем оформления кода и выдерживайте его до конца

Может пригодиться:

https://source.android.com/setup/code-style

public class Foo {

private int mPrivateInt;

private int private_int;

private int privateInt;

}

3. Хорошие вещи - простые вещи.

- Если что-то выглядит слишком сложно чтобы работать, скорее всего не работает.

- Придерживайтесь принципов DRY, KISS,

YAGNI

- Решайте задачу поставленную в тестовом задании, а не "тараканов: в своей голове!

4. Не надо никого "впечатлять"!

- 100500 зависимостей в сборочном скрипте без законченного и работающего задания ничего не значат. Если хватает знаний/времени решить проблему быстро и эффективно без привлечения чужого кода - то так и делайте. Это только вам в плюс.

- Результат вашей работы должен делать только то что от него хотят. Лишний функционал скорее всего будет источником ошибок.

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

5. Комментарии хороши тогда когда они уместны

- Если стоит выбор написать больше кода или больше комментариев, то пишите код. Хороший код - самодокументируемый код ;-)

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

6. Пишем тесты?

- Если времени достаточно то можно и написать. Но делайте это осмысленно! Написать хороший тест не так просто как кажется. Можно легко "погореть" на деталях.

- Если это явно оговорено в задании - то нужно писать.

- Во всех остальных случаях лучше написать больше кода.

7. Не забывайте проверять результат своей работы!

1. Проверяйте изменение ориентации экрана

*если не планируете ее поддерживать то лучше сразу отключить

2. Проверяйте как ваше приложение будет работать с активированной опцией Don't keep activities

3. Проверьте сборку в monkey runner

https://developer.android.com/studio/test/monkey.html

4. Не забывайте проверить на различных версиях Android API: runtime permissions, doze mode, background limitations, e.t.c.

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

ГЛАВНОЕ!

Убедитесь что сборка собирается вне вашего рабочего окружения!

8. Получаем обратную связь

Отзыв позитивный?

- Вы молодец/умница!

- Не надо "стелиться" с благодарностями за высокую оценку вашего труда, и т.п.

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

- Если есть какие-то замечания. То разберите их. Лишним не будет.

Отзыв негативный?

- Попросите комментарии, разберите их.

- Не стоит спорить!

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

Во-вторых, вы можете попасть на крайне упёртого "персонажа" которому все равно ничего не докажите. Он уже принял решение, так тому и быть.

- НЕ НАДО ИСТЕРИТЬ!

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

Отзыв нейтральный?

- Просят сделать что-то еще или подправить?

Тут надо смотреть по ситуации... Возможно они просто тянут время и морочат вам голову.

- Долго не отвечают?

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

*Но не надо делать это каждый день и давить!

Примеры тестовых заданий

Задание 1

Вводные:

Написать приложение, которое будет состоять из карты на которой будут находится маркеры публичных мест, в соответствии с указанной локацией или данными GPS

Дополнительная опция 1: должен быть альтернативный режим для отображения объектов в виде списка (отсортированного по мере удаленности объекта от указанно локации) + поддерживаться ZoomIn/Out на карте.

Дополнительная опция 2: по нажатию на маркер должна появляться информация об объекте (например, рейтинг) + по мере прокручивания списка должна расширяться зона поиска.

Дополнительная опция 3: должен поддерживаться offline режим и выделяться маркер объекта с наибольшим рейтингом.

Задание 2