В программировании очень жёсткие собеседования. Они похожи на сложный экзамен, который длится 1-2 часа. Очень часто вам будут задаваться вопросы, которые фактически не часто применяются в реальной работе. Но так чаще всего делают неопытные интервьюеры, которые ещё не научились проводить собеседования.
Идеальное техническое собеседование строится от простого к сложному. И останавливается в тот момент, когда человек начинает тонуть. Это делается в естессенном изучении, понимании и применении знаний о разработке.
Все начинается с рассказа о вашем опыте и в целом общении о технологиях. Тут можно узнать об интересах и увлечениях человека. Я люблю спросить про самые крутые слеланные штуки, это обычно интересно разработчикам и по этому вопросу можно понять реальный уровень и принятые работой вызовы. Тут можно услышать про рефакторинг, улучшения производительности, архитектуры и паттерны, законченные приложения, организацию сложных экранов и просто красивые и сложные анимации вьюх. Как подходит к поиску и разрешению багов? Как подходит к новым задачам? Можно спросить об устройстве каких-то их работ, что использовали и какие были сложности.
Далее переходят к простым вещам. Я видел случаи, когда человек очень интересный и хорошо рассказывает, но в элементарных вещах начинает тонуть. И в такие моменты очень расстраиваешься.
Начать можно с синтаксиса и устройства языка. Но тут часто получаешь хорошие ответы. Можно спросить про Дженерики. Часто спрашивают про примитивные типы, ссылки на объекты и как они передаются в методы. Тут можно поговорить про чистоту кода, общепринятые и проектные договоренности по стилю написания кода, можно обсудить книжки и идеи чистого кода. Можно обсудить switch например. И меня раздражают вопросы, которые я могу проверить за пару минут в реальности, но почему то должен это держать в голове. Спрашивают про модификаторы доступа и тут можно сделать переход к следующей части.
Это понимание объектно-ориентированного программирования, абстракций, композиции и замыканий, отличие интерфейсов и абстрактных классов. Хорошим разработчикам это кажется элементарным, но они часто забыли как они это поняли и что это было сложно. Не понимая этого, невозможно общаться на сленге и коверкании слов и сокращениях. Тут можно пообщаться о названиях и важности этого, принципов SOLID и KISS. Были ли случаи сложных названий? Как относиться к словам сервис, менеджер, контроллер и комбаин. Можно предложить организовать какую-то структуру объектов из вашей работы или спросить как он сделал свою.
Далее можно перейти к структурам данных. Часто спрашивают про списки, таблицы, матрицы, стеки, деревья и графы. Очень редко кто-то использует другие структуры и почти все знают эти. Я долго думал зачем вы меня это спрашиваете? Я знаю как это работает, но не знаю устройства, но зачем мне это знать? Сейчас я бы сказал прикольно это знать, это определенная любознательность. Вы можете обойтись и без этих знаний, но этому учат в университете и это суперчастые вопросы и обидно будет тонуть, не зная такой фигни. Подтяните это, это не так сложно как кажется. Просто посмотрите какие они бывают, а дальше интерес сам проснется. Ну а их использование нужно знать. Для чего какая структура лучше подходит и как выбрать. Зная их можно быть гораздо гибче. Вы можете использовать ноутбук, но не знать его устройство. Просто так вышло что в нашей профессии использование ноутбука и его устройство сильно связаны. Тут вопросы по устройству и применению. Что вы делали, использовали графы?
После этого обсуждают алгоритмы. Алгоритмов очень много, вы составляете свои и поэтому тут просто проверяют ваше умение их составлять и придумывать решения. Тут могут дать вам задачку, её нужно не решить, а начать решать. Она проилюстрирует, как вы умеете думать, как отсекаете ненужные проходы и ветки в процессе решения. Могут спросить про популярные и общеизвестные алгоритмы на поиск, сортировки или обход. Не могу сказать что они необходимы, если вы умеете хорошо решать задачки. Просто некоторые из них довольно сложные и их решают годами. И проще прочитать о них чем придумвать новое решение. Для этого есть сайты для подготовки в сильных командах их точно будут спрашивать.
Разговор об Андроид. Что и как использовали? Можно обсудить проблемы фрагментов и активити архитектуру, возможные способы из коробки для многопоточности. Как сохраняли информацию. Устройство жизненных циклов активити, фрагментов и вьюх. Особенности оптимизации, функции Андроид студии, скрипты на Грейдл. Сборка и доставка приложения до тестирования и пользователя. Тестирование юнит и интеграционное.
Паттерны. Это такие конструкции, которые развивают тему ООП и взаимодействие объектов. И если их понимать, то можно избегать дублирования, писать очень сложное просто. Тут как и везде нужно и хочется проверить опыт. Для этого вам нужно посмотреть, понять какие они бывают и начать применять. Есть классические паттерны их придумала Банда четырех крутых программистов более 20 лет назад. Это фундаментальные паттерны и они не устаревают, но могут преобразовываться. Есть и современные паттерны как MVVM. Их применение любят обсуждать. Какие и при каких условиях выбрать, какие пробовали, в чем преимущество.
Реактивное и функциональное программирование. Его можно никак не получится использовать в полной мере без процедурного, можно в каких-то отдельных специальных программах поделках. Но сейчас мы везде используем процедурно-функциональную спайку. Тут тоже есть свои специфические вопросы. Но в основном реактивное программирования построено на паттернах Обозреватель и Подписчик
Котлин. Как давно использует? В чем видит его крутость в Java? Какие крутые фишки показались интересными? Корутины или RxJava?
Глубинная Java. Более глубокие вопросы связанные с многопоточностью и управлением потоками вручную. Модификаторы используемые для работы, какие ошибки встречались и как их разрешали.
На последующем уровне всегда можно вернуться и поболтать на прошедшие уровни. Помните это не допрос с пристрастием. Никто не хочет вас унизить, обидеть или показать свой уровень. Люди просто хотят найти к себе в команду хорошего и опытного человека. А для этого нужно понять его уровень. Но из-за неопытности, опыта предыдущих своих плохих интервью, где ты отвечал на плохие вопросы, не понимания целей и собственного страха показаться некомпетентным люди переносят этот опыт и задрачивают не важными вопросами. Забывая, как стремно быть на той стороне.
Если в какой-то момент вы поняли что человек не подходит, прекратите собеседование. Не тратьте свое время, время коллег и время разработчика. Скажите что к сожалению он вам не подходит. Объясните причины и дайте обратную связь. Покажите точки роста, что нужно подтянуть, с чем поработать и поблагодарите. Нет ничего более раздражающего и расстраиваюшего, чем отсутствие понимания, почему нет и в чем вы плохи. А так понятно что нужно делать и что еще узнать и прокачать, все хотят стать лучше. Это можно сделать позже, написать и передать самому или вместе с HR. Можно сказать что как получится, пусть попробует ещё раз.
Как видите, можно провести собеседование в виде просто разговора 2х специалистов и профессионалов без лишнего дрочилова, чтобы всем было приятно и полезно.