Лайв-кодинг и code review на Android-собеседовании

Чаще дают чужой код, а не задачу с LeetCode

У меня в пуле на этот этап 12 задач. Восемь из них - code review: кусок рабочего кода с заложенными багами, который нужно разобрать вслух и отрефакторить. Ещё четыре пишутся с нуля: дебаунс для поля поиска, потокобезопасный кэш на N элементов, обход иерархии View и своя хеш-таблица.

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

Мой любимый жанр: «джуниор написал фичу и ушёл в отпуск, код прилетел тебе на ревью». В таком коде намеренно намешаны три слоя проблем - то, что не компилируется, то, что компилируется и падает, и то, что работает, но написано так, что глаза слезятся. Кандидат, который видит только третий слой, получает по грейду ровно то, что заслужил. Щито поделать.

Что оценивают на самом деле

Скорость печати не оценивает никто, выдыхай. Смотрят на другое:

• ➖Рассуждение вслух. Пятнадцать минут молчания и правильный ответ в конце - хуже, чем неидеальное решение с проговоренным ходом мысли. Интервьюер оценивает мышление, а видит его только через речь. Телепатию на собесы пока не завезли.
• ➖Вопросы до кода. Сколько элементов, откуда вызывается, из скольких потоков, что важнее - память или скорость. Если человек начинает печатать сразу, дальше обычно выясняется, что он решал не ту задачу. Проверено на себе, к сожалению.
• ➖Порядок работы. Сначала работающее, потом красивое. Попытка сразу написать идеально почти всегда заканчивается тем, что не написано ничего.
• ➖Цена решения. Назвать сложность, объяснить, чем платишь за выбранный вариант, и сказать, что бы поменять при других вводных. Тут как раз уместно «it depends» - но с аргументами, а не вместо них.

На чём сыпятся

• ➖@Volatile на счётчике и вывод «теперь потокобезопасно». Volatile даёт видимость, но не атомарность. value++ - это чтение, инкремент и запись, и между ними спокойно вклинивается другой поток. Самая живучая иллюзия из всех, что я вижу на моках.
• ➖«Synchronized же есть». Сказано про код, в котором дедлок виден невооружённым глазом. Родственная ошибка - навешивать новые локи вместо того, чтобы упростить схему блокировок.
• ➖Activity в ViewModel и GlobalScope. Классика, которая в реальных проектах живёт годами. На ревью её не замечают примерно так же часто, как в проде.
• ➖Проглоченные исключения. catch на всё подряд без различения CancellationException - и структурная отмена перестаёт работать, а корутина живёт своей жизнью.
• ➖Не замечают, что код не компилируется. val в параметре функции, getter-only var, обращение к context из companion. В задачах про джуниора это заложено специально - и проходит мимо примерно половины кандидатов.

Как вести себя на секции

1. 1️⃣Прочитай код вслух и скажи, что видишь, до того как что-то править. Заодно это даёт время подумать.
2. 2️⃣Спроси про контекст: откуда вызывается, из скольких потоков, что уже в проде.
3. 3️⃣Раздели находки на «падает», «не компилируется» и «некрасиво». Свалить всё в одну кучу - значит потерять приоритеты.
4. 4️⃣Начни с самой простой рабочей версии. Оптимизации - после того, как решение работает.
5. 5️⃣Объясняй правку так, будто рядом сидит автор кода. На секциях с ревью это буквально часть задания.

Как готовиться

Тренироваться на LeetCode здесь почти бесполезно, sorry. Работает другое:

• ➖Возьми свой собственный код двухлетней давности и проведи по нему ревью вслух, с таймером на двадцать минут. Заодно узнаешь много нового о себе.
• ➖Разбери базу по многопоточности до уровня, где можешь объяснить разницу между видимостью и атомарностью, не заглядывая в статью.
• ➖Напиши руками дебаунс, LRU-кэш и хеш-таблицу. Эти три всплывают чаще всего и требуют не алгоритмов, а аккуратности.
• ➖Потренируй проговаривание. Самый дешёвый способ - решать задачу с включённой записью экрана и потом послушать себя со стороны. Первый раз будет больно, дальше легче.