Вопросы для собеседования андроид

Вопросы и задачи с собеседований на Android разработчика

В прошлом посте я подробно описал процесс поиска работы в Берлине. В течение этого процесса я сталкивался с вопросами, алгоритмическими задачками и Code challenge. В этом посте я распишу свой опыт в этом деле.

Вопросы

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

Архитектура, паттерны

• Какие паттерны знаете?
• Считаете ли вы Singleton антипаттерном?
• Опишите принципы MVP. Какие еще есть похожие MV*, в чем разница между ними?
• Объясните принцип DI
• Объясните принципы SOLID
• Объясните принципы Clean Architecture

Android

• Как можно выявить проблемы в скорости UI и устранить их?
• Какие проблемы были с использованием Dagger?
• Приходилось ли использовать Guard?
• Что такое multidex?
• Приходилось ли сталкиваться с миграцией с Dalvik на новую технологию ART?
• Начиная с какой версии пишете под Android? Какие были сложности с разницей версий?
• Асинхронные механизмы загрузки в Android
• В чем отличие AsyncTask от Thread?
• Минусы AsyncTask
• Опишите, что такое Activity
• Чем Fagment отличается от Activity?
• Разница между Service и IntentService. Пример использования Service.
• Зачем нужен Headless fragment (без View и с setReatinInstance = true)? Приходилось ли использовать?
• Какие новшества были в последней версии Android?
• Как определяете, какой layout надо использовать для смартфона, а какой для планшета?
• Как в коде определите: планшет это или смартфон?
• Пример использования BroadcastReceiver
• Опишите LifeCycle Activity
• Отличия Serializable и Parcelable

• Контракт hashcode и equals
• Виды коллекций в Java: List, Set, Queue, Stack
• Разница между ArrayList и LinkedList. В каком случае что лучше использовать?
• Принцип работы HashMap и HashSet
• Что такое Generic?
• Когда используем bounded type: «T extends Class» и «T super Class»? Каковы их ограничения.
• Отличия Abstract от Interface, когда какой лучше использовать?

• Разница между pull и fetch
• Разница между merge and rebase

Прочее

• Минусы использования сторонних библиотек
• Что вы будете делать, если ваше решение не совпадает с решением коллег или лида?
• Какие свои качества работы в команде вы можете описать?
• Если бы вы могли вернуться на 3-4 года назад, что бы вы изучали?
• У вас есть команда, какие правила вы установите, чтобы писать тесты?
• Какую книгу вы можете посоветовать? Необязательно про программирование.
• Ваша жена не против релокации?

Алгоритмические задачки

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

• Реализация merge сортировки из двух списков
• Реверс массива
• Из «abaaeba» получить (a: 4, b:2, e:1)
• Реализация Set с помощью List (методы int count, boolean add, boolean remove)
• Калькулятор, который парсит строки типа «1+2», «1 + 2 * 3 + 4» и возвращает вычисленное значение. Из операторов могут встречаться только + и *.
• Написать Reentrant блокировку
• Посмотреть код, где несколько потоков меняют одну Integer переменную. Сказать, какое значение получится в итоге. Предложить варианты исправления.

Code challenge

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

Я убрал реальные адреса серверов из ссылок, чтобы не палить конторы.

1) Приложение, отображающее список сообщений

На сервере есть json файлы. До них можно добраться по ссылке: https:// /endpoint/.json, где PAGE — номер файла от 0 до какого-то произвольного числа, например, 15.

Каждый файл — это json массив из 50 сообщений. Сообщение содержит поля id, time и text.

Приложение должно загрузить сообщения с сервера и показать их в списке.

Юзер может удалить сообщение. Предпочтительно — свайпом, но можно и долгим нажатием.

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

• постраничная подгрузка при скролле
• кэширование, чтобы приложение при старте показывало ранее загруженные сообщения
• некоторые сообщения в поле text вместо текста содержат ссылку на картинку, хорошо бы подгрузить и показать эту картинку

Срок выполнения — 5 дней. Про тесты ничего не сказано.

Я от себя добавил:

• action mode, чтобы удалять сообщения
• Retry кнопку, если была ошибка при загрузке данных
• отдельный экран для просмотра сообщения из списка. Переход на экран был с анимацией Activity Transition. Картинка показывалась сначала из кэша в плохом качестве (как в списке), а затем грузилась полная версия.

2) Приложение с картой и поиском

Приложение должно найти и показать на карте 5 объектов, ближайших к вашей текущей локации.

Пример запроса: https:// /places/search?at=52.5311%2C13.3847&q=restaurant

В at передаем координаты своего местоположения, а в q — поисковый запрос. Результат приходит в json формате.

Результаты надо показать на карте. Можно использовать Google Maps. Но у этой компании было свое SDK для отображения карты, и я изучил и использовал его. Тем самым показал, что быстро могу разобраться в новом для себя SDK. При этом я заметил несколько вещей, которые можно было улучшить/исправить в SDK и на последующем собеседовании рассказал об этом.

Приоритет — качество. Про тесты ничего не сказано. Срок выполнения — неделя.

3) Приложение, отображающее список квартир.

По запросу на сервер приходит такой ответ:

items — список квартир. Для каждой квартиры указаны название, цена, локация, фото.

Необходимо в списке отобразить все полученные items. Каждая квартира должна показать первое из доступных фото, заголовок, цену и адрес. Примерный макет layout прилагался, но можно и что-то свое придумать.

Каждая квартира в списке может быть добавлена в избранное. Т.е. надо в layout квартиры добавить какую-то метку (например, звездочку), которая будет кликабельна и отобразит статус: в избранном или нет. Информация о том, что квартира добавлена в избранное, должна храниться локально. Т.е. после перезапуска приложения вы должны видеть, какие квартиры были отмечены

В приложении должен быть экран с картой, которая отображает локации всех квартир из списка.

Про тесты ничего не сказано. Срок выполнения — 5 дней.

Я все сделал и добавил несколько фич:

• поддержка альбомной ориентации. В этом случае слева отображался список, а справа — карта.
• нажатие на иконку в action bar покажет/скроет карту
• нажатие на квартиру в списке центрирует ее на карту
• и наоборот, нажатие на маркер квартиры на карте проскроллит список до этой квартиры

4) Выбор машины

Необходимо сделать что-то типа визарда для выбора автомобиля. На первом экране выбирается производитель (марка), на втором — модель, на третьем — год.

Соответственно, на сервере есть три метода, которые вам необходимо вызывать для получения этих данных.

— первый возвращает список производителей (id, name).

— второй принимает выбранный id из первого и возвращает список моделей этого производителя (name)

— третий метод принимает id из первого методы и name из второго и возвращает годы выпуска.

Первые два метода поддерживают постраничную подгрузку — у них есть параметры page и pageSize, и они возвращают totalPageCount.

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

• минимальный API — 16
• постраничная загрузка на первом и втором экранах. Размер страницы — 15
• идеально, если переход между экранами будет с анимацией
• сделайте разные layout для четных и нечетных строк списка
• поворот экрана должен работать без проблем

Опционально: на втором экране вместо постраничной загрузки грузите все сразу и добавьте текстовый фильтр по названию модели.

Вся работа по идее должна занять 5-6 часов, но они там понимают, что у вас есть дела/работа и вам дают неделю. Тесты писать необязательно, но если напишете, это будет большим плюсом.

5) Список разных данных

Надо собрать данные с двух разных API и отобразить их в одном списке.

1) Получить 50 репозиториев указанного юзера на github, используя GraphQL (https://developer.github.com/v4/)
2) Получить 50 фото с поиска Flickr. Там обычный json или xml (https://www.flickr.com/services/api/flickr.photos.search.html)

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

Изначально экран не должен отображать данные. Есть только кнопка Load, по нажатию на которую начинается загрузка. Последующие нажатия на кнопку должны перезапускать загрузку.

Github данные должны отображаться просто как имя репозитория. Flickr данные должны отображаться как картинка. Нажатие на любой пункт списка должен перезапускать загрузку данных.

Можно писать на Kotlin. Про тесты ничего не сказано. Срок выполнения — 2 рабочих дня.

В этом задании для меня новым было GraphQL. Пришлось повозиться, пока нормально данные с гитхаба пошли. Времени на всякие плюшки в итоге не хватило.

Для всех этих заданий я делал тесты. В качестве архитектуры использовал MVP, а в двух последних еще и Clean Architecture. По возможности старался сделать чуть больше, чем надо, и добавлял какие-то навороты и удобства. Но уложиться в срок и сделать все качественно и красиво — всегда было приоритетом.

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме

Источник

Идеальное (наверное) собеседование мобильного разработчика-мидла

За последнее время на хабре вышло столько рассказов о плохих собеседованиях, что порой закрадывается сомнение, а бывают ли в природе собеседования хорошие? Так что разнообразия ради в этом мы рассмотрим пример хорошего* подхода. Рассказ будет идти с точки зрения разработчика работодателя, который напрямую участвует в процессе найма.

Диспозиция

Маленькая продуктовая команда (30-40 человек) внутри крупной компании (несколько тысяч человек). В команду входят все, кто занимается проектом: фуллстек разработчики и фронтедеры, дизайнеры и интерфейсологи, тестировщики, спецы по пиару, аналитики, авторы текстов и т.п. В общем, мы стараемся поменьше аутсорсить профильную работу в другие проекты, и мобильная разработка — не исключение.

Мобильное приложение у нас кроссплатформенное, написано на Xamarin Native под iOS и Android. При этом мы полностью готовы брать в меру опытного разработчика, писавшего только под одну платформу, при условии, что он готов изучать разработку под вторую ОС.

Этап 0 — встретились два одиночества

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

Эти вопросы — минимальный фильтр на адекватность, никаких технических вопросов не будет. Дальше резюме и ответы передаются уже разработчику со стороны нанимателя, и тот принимает решение, идём дальше или нет. За последний месяц я посмотрел пару десятков резюме, и понятия не имею, что должен написать и ответить кандидат, чтобы мне пришлось сказать «нет» уже на этом этапе. Написать на вакансию Android-разработчика «пишу только под iOS, потому что Android – полный отстой»?

Этап 1 — тестовое задание или пример кода

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

• три экрана: два связанных списка + форма ввода данных, которую при желании можно заменить на модальное окно
• работа с сетью
• работа с хранилищем данных (задание подразумевает БД, если разработчик сможет обосновать другой вывод — милости просим)

Впрочем, не все разработчики готовы писать тестовое, поэтому мы сразу предлагаем альтернативу — прислать код какого-нибудь готового приложения, где будет такой же набор (сеть, БД, навигация по экранам, пользовательский ввод). Ну а дальше возможны варианты:

• приложение слишком маленькое, код не показателен или вызывает слишком много вопросов просим таки сделать наше тестовое
• приложение подходящее, но есть нюансы — просим сделать небольшие доработки (меньше чем на вечер)

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

• кандидат получает код, который потом можно переиспользовать на другом собеседовании с подобными принципами, а также обратную связь для работы над собой. Работает ли оно? Ну, как минимум к нам присылали тестовые задания, изначально написанные для других компаний, так что похоже, что работает;
• работодатель экономит время на опросниках и прочей фигне. А уж как радуется собеседующий-интроверт, которому не нужно проводить по 1-2 собеседованию в неделю, если б вы только знали!

Этап 2 — собеседование

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

Далее будет 1-2 небольшие практические задачки, они зависят от тестового задания. Опять таки даём в руки клавиатуру (подключенную к компьютеру, компьютер с монитором!) и просим что-нибудь написать или отредактировать. Одна из моих любимых вещей — дать рабочую, но плохо написанную функцию строчек на 10-20 и предложить её отрефакторить. Сразу становится понятно, есть ли у кандидата чуйка на «плохой код», что он знает о конструкциях языка, умеет ли читать чужой код и далее по списку.

И это в общем-то всё. Максимум через пару-тройку дней мы дадим кандидату ответ. Впрочем, чаще всего ответ даётся в тот же день). И в случае отказа опять таки будет адекватное обоснование. Ну, а если его будет недостаточно, то кандидат всегда может попросить контакты разработчиков с собеседования для уточнения каких-то моментов, и ему их с высокой долей вероятности дадут.

Но ведь кандидат мог и обмануть

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

Так, стоп! Я узнал команду, о которой идёт речь, собеседовался в неё пару лет назад, и там схема сильно отличалась

Да, каюсь, тогда я грешил небольшими опросами и собеседованиями без тестового. Много времени потратил, и своего, и чужого. Так что когда речь зашла о новых поисках разработчика, то я решил попробовать иной подход. Разработчики пишут код? Отлично! Покажи мне свой код, и я скажу, стоит ли нам собеседоваться.

Но я и в компанию узнал! Устраивался в другой проект, и там тоже всё не так!

А вот тут ситуация с хитринкой. К нам в компанию идёт приличный поток бэкендеров/фулл-стек разработчиков, и таких разработчиков в компании несколько сотен. Поэтому процесс их набора уже достаточно устаканился и стандартизировался. Мобильных же разработчиков в компании пока что мало, так что нам легче экспериментировать с подходами к собеседованиею.

Источник