Проходим технические интервью в крупных IT-компаниях

Если тема технического интервью для вас ещё не раскрыта, советую это исправить. В новой статье объясняем, что ждет вас на техническом интервью в крупную IT-компанию, но для начала несколько вводных слов.

Мы с компанией InfoShell провели в Краснодаре митап, посвященный техническим собеседованиям. В коворкинге CO-PLACE с нами выступали спикеры из Rutorika и Speek Corp. Получилась довольно полезная встреча для молодых специалистов. Спасибо Krasnodar Dev Days, что дали огласку мероприятию!)
Но вернемся к предметной части.

Во-первых, однозначно сказать, что вас спросят на тех. интервью и в каком порядке, сложно. Сценарий интервью одному лишь интервьюеру известен и в каждой компании он может быть разный. Во-вторых, в статье будет не список конкретных тем для подготовки к экзамену: «Сдал и забыл!». Все, о чем я напишу от лица компании – действительно необходимые разработчику навыки и знания. Цель данной статьи – заострить внимание на основных вещах и сделать подготовку к техническому интервью более структурированной, а значит, эффективной.

Начните с трех китов: инкапсуляции, наследования и полиморфизма.

Дальше по списку SOLID – принципы, правила, установки, руководство к действию – как хотите, но тут должно от зубов отскакивать. Если кто не знает, что это, вот вам краткий гайд по пяти главнейшим принципам объектно-ориентированного программирования:

Существуют так называемые “признаки плохого проекта”. Они подробно расписаны в Википедии, так что здесь приводить их не будем, но если вам не доводилось встречаться с описанными в них проблемах - вы либо вундеркинд, либо не ходили дальше “Hello, World!”. SOLID – это пять принципов (по букве на каждый), которые нужно применять, чтобы минимизировать эти проблемы

S (The Single Responsibility Principle) – принцип единственной ответственности. На каждый объект должна приходиться единственная обязанность. Если пишете для интернет-магазина, то должен быть свой класс для заполнения массива, свой для подсчета скидки и т.д.

O (The Open Closed Principle) – принцип открытости/закрытости. Изменения в программе должны происходить при написании нового кода, а не модификации старого.

L (The Liskov Substitution Principle) – правило подстановки Барбары Лисков. Объекты в программе могут быть заменены их наследниками без изменения свойств программы.

I (The Interface Segregation Principle) – принцип разделения интерфейса. Много интерфейсов лучше, чем один универсальный.

D (The Dependency Inversion Principle) – принцип инверсии зависимостей. Этот принцип рассказывает об иерархии зависимостей абстракций и подробностей. Чтобы объяснить, что это значит, придется написать отдельную статью.

Кроме того, внимательно повторите структуры, типы данных, модификаторы доступа, сборщиков мусора. Будьте уверены, что у вас нет проблем с синтаксисом, постарайтесь делать код понятным и читаемым. Ну, и напоследок, кто такой объект?

Они позволяют выделить часто встречающиеся проблемы (помним про SOLID), дают им имя и рассказывают, что с этим делать – круто, да? Поэтому в вашем технологическом арсенале должно быть несколько хорошо известных, востребованных экземпляров: singleton, adapter, decorator, bridge, observer, abstract factory, builder и т.д. Можете кратко пробежаться по антипаттернам – приятно и полезно.

Если паттерны – это знания и опыт, то фреймворки – исполняемая программа, инструмент реализации паттернов. Не надо заучивать, достаточно хорошо знать несколько и уметь характеризовать те, с которыми вы имели дело.

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

Существует последовательная (serial) очередь, в которой задачи выполняются последовательно (тут из очереди задачи выходят ровно в том же порядке, в каком они поступали на выполнение) и параллельная (concurrent) – это очередь, в которой задачи выполняются параллельно ( несколько процессов в один момент времени).

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

Знать, что происходит за пределами программной оболочки, в которой dы привыкли работать, необходимо. Зачем? Чтобы уметь этим управлять: экономить вычислительные ресурсы машины и время пользователя.

Вспоминаем про стек и управляемую кучу ( разделы памяти), сильные и слабые ссылки. Если коротко, то стек – быстрая память, обеспечивающая быструю обработку событий и управляемая процессором, но ограниченная по объему, за счет которого и достигается её быстродействие. Управляемая куча ограничена лишь физической памятью, но работает не так шустро. По поводу ссылок: сильные ссылки создаются в памяти и не позволяют сборщику мусора удалить объект, пока он используется в программе, а слабые – дают. Также почитайте про кэши и виртуальную память, а самое главное – как все это использовать для оптимизации работы продукта.

Понятно, что требования ко всем разные. В основном они зависят от должности, на которую вы претендуете. Если вы стажер-junior, необходимо уметь писать код внутри класса и знать ООП. Помните, что вашим заглавным качеством должно быть умение учиться и стремление развиваться! Проходите техническое интервью на middle-разработчика – из нашего списка можете опустить многопоточность и асинхронность плюс некоторые паттерны. Senior должен уметь работать со всем вышеперечисленным: важно не только качество кода, но и его производительность.

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

Удачи, друзья!