Зачем компании этот этап
Тех-скрининг ставят перед длинной секцией, чтобы не тратить час senior-инженера на тех, кто отвалится на третьем вопросе. Отсюда и формат: созвон на 40-60 минут, вопросы короткие, на ответ - минута-две. Глубина маленькая, ширина большая: за час пробегают язык, платформу, UI и немного многопоточности.
Главное отличие от полноценной тех-секции: здесь не ждут долгих рассуждений и не дают раскачаться. Ждут, что ответишь быстро и точно, а на уточняющий вопрос не поплывёшь. Порассуждать «смотря в каком контексте» получится на следующем этапе. Если до него дойдёшь.
Что спрашивают
В моём пуле на тех-скрининг больше 100 вопросов, и раскладка по темам примерно повторяет то, что я вижу на реальных собесах в финтехе:
Обрати внимание на перекос: Compose спрашивают столько же, сколько платформу. Пять лет назад этого блока не было вообще, а сейчас на нём сыпется едва ли не больше людей, чем на корутинах. Если ты до сих пор «в основном на XML» - самое время.
А вот Kotlin стали спрашивать меньше, и в основном самую базу. Освободившееся время ушло на корутины и многопоточность: корутины на скрининге теперь всплывают чаще, чем сам язык.
К каждому вопросу заготовлено по два-три уточняющих. Они и решают исход. Первый ответ звучит прилично почти у всех, кто читал статьи на Хабре. Разница видна на «а почему?» и «а что будет, если…». Вот тут и выясняется, кто читал, а кто понял.
И ещё одна вещь, которую лучше знать заранее. Больше половины вопросов закрывают переход junior → middle, почти все - уровень middle, и лишь примерно каждый пятый дотягивает до middle+. Тех-скрининг почти никогда не показывает, что ты senior. Он показывает, что ты не junior. Звучит обидно, но работает именно так.
На чём сыпятся
Всё ниже - не придуманные примеры. Эти формулировки я слышал на секциях, и за каждой стоит отметка в моих заметках.
- ➖«copy() у data class делает глубокую копию». Копия поверхностная, вложенные объекты остаются общими. Рядом второй частый промах - считать, что в equals участвуют все поля. Участвуют только те, что объявлены в основном конструкторе.
- ➖«ANR - это когда приложение зависло». ANR - это про заблокированный главный поток и конкретные таймауты на разные типы событий. Если в ответе нет главного потока, дальше разговор не идёт.
- ➖Корутина прямо в теле composable. Без LaunchedEffect она стартует на каждой рекомпозиции. Самый частый провал во всём блоке про side-effect API.
- ➖async там, где не нужен результат. И отдельный жанр - async и сразу await подряд: последовательный код, который очень старается выглядеть параллельным.
- ➖«Добавлю synchronized везде». Ответ на вопрос про гонки, после которого обычно выясняется, что разница между deadlock и race condition тоже как-то размыта.
Как готовиться
Совет «почитай про корутины» бесполезен, поэтому конкретнее:
- ➖Проговаривай ответы вслух. На скрининге оценивают, как ты формулируешь за полторы минуты, а не что знаешь про себя. Между «понимаю» и «могу объяснить» пропасть больше, чем кажется, пока не попробуешь.
- ➖К каждой теме готовь второй слой. Не определение, а «что будет, если». Определение спросят один раз, второй слой - всегда.
- ➖Не пропускай Compose. Самая свежая часть: заученных ответов по ней меньше всего, провалов больше всего. Side-effect API, ключи, рекомпозиция.
- ➖Не пытайся закрыть всё. За час спросят двенадцать-пятнадцать вопросов из пяти тем. Лучше уверенно держать базу, чем героически плавать в экзотике.
Теорию по всем этим темам я разобрал в курсе на Stepik - Kotlin, корутины, многопоточность, архитектура, UI и Compose. Письменный разбор после мока ссылается ровно на эти уроки.
Проверить это на себе
Тех-скрининг - самый дешёвый способ понять, где ты стоишь. Разовая диагностика идёт по всем темам сразу и за одну сессию показывает, что держится, а что сыпется. Лучше узнать это на моке, чем на созвоне с компанией мечты.