Наше ИТ и их Computer Science

В принципе наши Информационные Технологии и их Computer Science вещи очень похожие. Мы также как и они пишем софт, но общаемся мы при этом преимущественно на русском. На собеседованиях мы так же как и они спрашиваем теорию и практику. Правда на разных разговорных языках, и в процессах интервью есть серия модных трендов, как логично предположить, они у нас немного отличаются. Они отличаются так незначительно, что без подготовки западный процесс интервью пройти русскому разработчику будет крайне сложно.

К примеру, решение алгоритмических задач для разработчика важнее знания спецификации языка. Процесс интервью Java разработчика в Москве будет начинаться с Java Core и заканчиваться JVM(Java Virtual Machine) и JMM(Java Memory Model) в частности, потом мы пройдемся по паттернам программирования, возможно проблемам архитектуры. У них же вместо паттернов и архитектуры будет System Design. В европейских и американских компаниях от вас для начала захотят увидеть способность эффективно писать код. А если вы захотите попробовать свои силы в Google или Facebook, или в любую другую компанию- ИТ гигант - вам назначат собеседование с расшареным текстовым редактором, именно текстовым редактором, без подсказок IDE, где вам представится возможность написать решение какой-то задачки и обьяснить его словами. Вас будет интервьюировать человек, мозг которого будет напоминать компилятор. Он не будет полагаться на случай, он будет точно знать как работает этот код или же этот код с дефектом. 

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

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

При этом, что интересно, разброс алгоритмических проблоем будет покрывать проблемы от оптимального выбора, сортировки, анализа строк и до высокоуровнеых проблем, сводящихся к необходимости запрограммировать машину состояний, с ограниченным количеством возможных переходов. Или же вам предложат к решению упрощенную проблему ввода вывода, многие ведь забывают, какой оверхед могут создать такие операции. Или же наоборот, вам преддожат задачу по распределенной системе, где вам нужно будет изобрести метод индексации данных. Если уйти поглубже то понимаешь - не такие уж эти алгоритмические проблемы и игровые, просто упрощенное представление реальной преблемы очищенной от контекста специфики отрасли или фреймворка, или архитектуры ОС.

Точно так же, по началу, когда я стал читать о том, что такое поведенческое собеседование разработчиков (behavior interview) мне встретилось много странных слов, но со временем я понял, что это мало чем отличается от вполне понятного интервью с бизнесом, где мы просто непринужденно общаемся … на русском. И вопрос: опишите неоднозначную ситуацию из своего рабочего опыта, с использованием слова ambiguity услышанный впервые поставит вас скорее всего в ступор. Но если подумать, в сущности все очень похоже.

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