Как Я: стажировался бекенд-разработчиком (C++) в Яндексе по программе Deep Dive (в формате буткемпа)

Небольшое вступление

Продолжаю свою мини-серию статей «Как Я», созданную поддержать начинающих соискателей. Сегодня расскажу как проходила стажировка в Маркете и немного о внутренней кухне Яндекса. Много информации не будет (NDA), но все равно попытаюсь рассказать исчерпывающе :). Рассказ будет больше в формате ЖЖ, чем лекции про какие-то технологии. Ну все, я вас предупредил, итак, погнали.

О чем поговорим:

1. Офис и выживание жизнь в Москве

2. Тренировочное задание

3. Первая команда

4. Вторая команда

5. Заключение

6. А судьи кто дальше что?

Офис и жизнь в Москве

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

Жили иногородние в хостеле, в таких местах не бывал, потому трудно объективно оценить его качество. Ну а так — кровать, душ, туалет, несколько человек в комнате, лобби где можно поработать, ну и все. Немного скудненько. Но там я практически не находился, в будние дни работа, а на выходных — поездка в офис/прогулки. Офис — суперское место и пора рассказать немного про него.

Впервые попав в офис я просто потрясся его размерами: кофепоинты, куча переговорок, коворкингов, библиотека, игровая, массажист, психолог, тренажерный зал, какое-то огромное лобби, а ну да еще там есть рабочие места. И все это на нескольких этажах. Что ж давайте по подробнее.

Так как основные буткемперы — это студенты старших курсов, то начнем с самого важного — еды). Вообще с этим проблем особых не было, у каждого сотрудника есть бейдж, которым можно расплачиваться за еду. Ежемесячно компания перечисляет на него определенную сумму денег равную НЛО прилетело и опубликовало эту надпись здесь рублей, так что мне вполне хватало на весь день. Потратить их можно на местные кафешки или на вендоматы с едой. В кофепоинтах есть много всяких вкусняшек — чай всех цветов и расцветок, кофе, печенюшки, сладости, овощи, фрукты, хлопья, мюсли и конечно же…сырки по средам!

Во время работы приходится иногда общаться с коллегами, для этого везде натыканы переговорки от 2 до 14 мест, которые можно (и нужно) предварительно бронировать. По пятничным вечерам иногда в них собирались люди, но уже, чтобы поговорить не о работе :). Есть еще маленькие будки на одного человека в них обычно душно, поэтому туда заходят на быстрые разговоры)

Из досуга можно сходить в библиотеку, выбор тут есть, от книг про успешный успех и управления командой до технической литературы. Пару книжек и художественной есть. Как вариант на выходных или вечером можно сходить в спортзал. Потягать железо и более тяжелые снаряды (например поработать с собственным весом:) ), побегать на дорожках, тут же тебе и душ после тренировочки. Большая игровая с кучей настолок скрасит ваш пятничный вечер. Только что-то там нечасто кто-то играл, больше пил (шутка… я же говорил это делают в переговорках) так что придется самому искать компанию. Если же вы устали и хотите размяться — не беда! Есть массажист, к которому можно записаться. Еще есть массажное кресло, но оно, к сожалению, всегда было занято — мной :).

Итак, в целом проживая в хостеле и питаясь частично на казенные деньги можно было вполне жить в достатке и даже кой-чего оставалось на сладенькое. Ну а мы прибыли и приступаем к работе.

Тренировочное задание

В первый день нам дали оборудование, пароли, сказали куда заходить и чего активировать. Тут конечно немного не повезло. При создании заявки при трудоустройстве был пункт на какой ОС хотелось бы работать, я тогда выбрал винду, но выдали всем маки. Так что пришлось быстренько переучиваться.

Затем нас пригласили в офис, провели небольшую экскурсию и посадили в «ясли» для разработчиков — большую комнату, для массовых мероприятий, где мы работали первые 2 недели. Разгруппировали нас по языкам программирования. На нас закрепили опытного разработчика, чтобы курировал нас и координировал. Вообще у разработчика есть и свои какие-то сложные разработческие дела, но он также уделял время на то, чтобы рассказать нам как тут все устроено и, как настоящий ментор и товарищ, помогал в трудную минуту. Зачастую ментор может не только поговорить о работе, но и «по душам» за обедом.

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

Тут я набросал небольшой списочек, чего было бы круто изучить, чтобы такое задание давалось легко и непринужденно. И отсортировал по сложности

1. Работа в консоли. Это очевидно, ну правда. И стоит уделить этому внимание. Что-то запустить, посмотреть, погрепать, создать. Простых ls, cd, nano/vim ./start_bin будет хватать в 90% случаев.

2. Системы управления версиями. Это, например, всеми известный гит и не всеми известный svn. В Яндексе очень много своих технологий и система управлениями версиями одна из них, называется Arc. Но для рядового пользователя она ничем особо не отличается от того же гита, add, commit и push он и в Arc-e add, commit и push. Для любознательных дам ссылочку об этом Arc-е. Вообще обычно никакой виртуозности здесь тоже не нужно checkout, add commit, push. Тут даже парится с ветками не нужно, тут коммунизм монорепозиторий).

3. Утилиты автоматической сборки программы. А именно я говорю про CMake. Вообще мне, как человеку, который собирает проект нажав зеленую кнопочку «build» в Visual Studio эта часть показалась немного сложноватой. Но ничего страшного, если вы не знаете CMake (его тут тоже не знают 🙂 и пользуются своей утилитой). Так что знание симейка будет полезным, но опциональным. Тут я заметил что довольно сильные ребята попали в нашу группу, которые знали этот самый CMake и примерно понимали как работать с корпоративной утилитой, а еще подсказали мне куда че тыкать 🙂

4. SQL. Ура супер, на момент написания статьи Яндекс выложил в опенсорс свою субдшку — YDB. Для любознательных тык сюда. Теперь я могу об этом спокойно рассказать. Яндекс использует свою субд для работы с базами данных. А для нее создан свой диалект SQL — YQL (или ласково называемым разработчиками — Ыкль) со строгой типизацией. Вообще особой виртуозности на этом этапе в написании запросов не нужно, обычного SELECT + JOIN будет достаточно.

5. Protobuf. Это гугловский протокол для сериализации(упаковки) данных. Всегда хотелось с ним познакомится, и задание сподвигло меня на это. Для того чтобы написать минимально работающий код (а примерно это нам и нужно для тестового задания) нужно немного — создать message (структуру сериализованных данных), просетать значения суметь его сериализовать (ParseToStream…)/десериализавать(ParseFromStream…) вот и все. Опять-таки для очень любознательных — туториал по протобуфу от разработчиков. Но протобуф это база, поэтому рекомендую не стесняться его изучать и открывать для себя многого интересненького от one of и Arena до рефлексии.

Собственно говоря все. Половину я из этого не знал, так что приходилось схватывать на ходу :). Ну благо во время «акклиматизации» можно спокойненько почитывать туториалы и доки на все, заботливо написанные разработчиками.

Первая команда

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

Итак, в первой команде я пробыл немного, но разработческого пороха удалось немножко понюхать. Сама команда называлась репортом и специализировалась на грамотной фильтрации товаров, которые выходят при запросе пользователя. Фильтров целая куча, больше тысячи. И среди них не только видимые пользователем (на ограничение цены, цвет телефона, например) но и скрытые (не показываем товары, которые дорого доставить с ближайшего склада, используем gps-координаты введенные пользователем или что-то дефолтное, что-то цензурим и тд).

А теперь поделюсь парочкой штук, которые подглядел у крутых дядечек(и тетечек) и взял на вооружение.

• Фича-флаги или же как их у нас называют — rearr-флаги. Слова какие-то страшные, так что скажу по-простецки — стоп-краны. Очень удобная штука. Хочешь добавить какую-то возможность? Да добавляй на здоровье! Оберни во флажок, а флажок добавь в текстовый файл конфига и все. Если что-то упадет, то можно будет элегантно написать:

// config.conf огромный и страшный файл конфига, где хранится все-все-все настройки. ... featureFlag = false; ...  // someHandler.cpp - тут код обработчика http запроса Environment env; //инициализация окружения if (env.featureFlag) { // крутая фича } else { // не включаем крутую фичу, а включаем некрутую, зато надежную как план Уолтера из фильма Большой Лебовски, а он как известно надежен }

• Фоллбеки. Если наш план А провалился, то эти штуки запускают дефолтный план B. Мы работаем с сетевым приложением, тут постоянно что-то может случиться: обратились к БД, а ответа не получили, не получили ответ от пользователя, в таких случаях надо делать что то дефолтное. Поделюсь своей задачкой — нужно было по координатам пользователя(если он их предоставил конечно) выдать списочек особых складов. Координаты приходят от фронта, а вот список складов надо взять из БДшки. Если нам вдруг этот список не придет, то мы выдадим пользователю пустую выдачу, а пользователям обычно густенько смотреть на пустую выдачу. Получилось что-то типа такого:

// какой-то метод std::vector<TWarehouse> GetNearestSpecificWarehouses(const TCGI& cgi) {   // парсим что там прислали фронты в нормальный вид   auto gps = ParseGPS(cgi.GetGPS());   // посылаем запрос сервису-прокси который умеет обращаться к бд   // и возвращать какие-то специфичные склады   auto response = DBProxy.GetNearestSpecificWarehouses(gps);   if (response.status = EStatus::OKAY) {     return response.data;   } else {     // возвращаем какие-нибудь закешированные данные, пустой список     // или вообще пытаемся получить их другим способом   } }

• Моим последним заданием было сделать в тестиках мок одного тяжелого объекта. Вообще mock-объект это такая штуковина, которая заменяет собой реальный и тяжелый в развертывании и эксплуатации объект. В большинстве случаев для тестирования маленькой функции, которая использует реальный тяжелый объект (или даже может обращается к целому сервису) мы не хотим поднимать сервер, развертывать базу данных, и создавать объект который будет общаться с базой данных :). Мы считаем что реальный объект работает правильно и стабильно, и создаем вместо него глупенького болванчика, которому прямо говорим «ну если к тебе придут с таким-то запросом, ты верни, пожалуйста, вот этот набор данных».

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

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

Но времени тут было мало, полтора месяца прошло, спасибо этой команде, пойдем к другой.

Вторая команда

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

Подождите, как он это сделал…

Крутой программист Вася делает одну важную задачку для проекта А. После того как он с ней закончит, он будет делать другую не менее важную задачу для проекта В. Вася вроде как успевает доделать задачку А, но тут наступает час П — откуда ни возьмись приходит менеджер с проекта В и говорит «Вася, у нас заболел смежник Петя, только ты можешь доделать его кусок, только он остался до запуска, ты наша последняя надежда…».

Вася в недоумении. Если он доделает задачку для проекта А — важная задачка из проекта В не сделается и продукт-менеджеры будут грустить и васина зарплата не прибавит в весе, а если он сделает важную задачку для проекта В, то задачка для проекта А будет грустить вместе с менеджерами этого проекта, а также вместе с васиной зарплатой.

Помогите Васе сделать правильный выбор, можете писать в комментариях свои идеи 🙂

Ответ под катом ката

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

Плюсом я узнал, что если ты что-то не успел, это не всегда твоя вина. Это еще и вина тех, кто этим планированием занимался. В моем случае разработчики мне говорили о том, что задачка действительно сложная и если бы они делали эту задачку, у них бы ушла неделя. Тут я узнал еще один лайфхак планирования для стажера. Время выполнения задачки стажером ≈ время выполнения задачки разработчиком * е * e. Грубо говоря — в четыре раза больше времени, нужное для разработчика.

Итак, задачка доведена до какого-то финала, остальные действия передаются другим разработчикам. А я иду дальше. Во второй команде задача у меня была одна и вполне простая — ускорить мапредьюс пайплайн рутины варки экспортной таблицы, добившись zero-дифа для консюмеров.

Из всех этих слов я знал только слово «варка», но мне почему-то показалось, что тут не хотели проверить мои виртуозные кулинарные способности. Так что пришлось разбираться во всем потихонечку. Благо стажеров в этой команде никуда не торопят.

Во-первых, что такое мапредьюс? Я не претендую на эксперта обработки биг дата, поэтому попробую рассказать по-колхозному (как и все до этого:) ). Товарищи из гуглов придумали эту технологию для того, чтобы обрабатывать большие, ОЧЕНЬ БОЛЬШИЕ данные. Я вспомнил, как на алгоритмических собеседованиях к стажировке мне шутили: «представь, что у нас есть небольшая такая строка, ну 1ГБ, например…». И теперь я понял эту шутку. Нужно было работать не со строкой, конечно, а с таблицей, но в этой таблице были десятки терабайт. На одной машинке, даже с кучей ядер это все считать, переконвертировать, сджоинить с другой таблицей, снова сконвертить, и записать на выход будет немножко долговато. Чтобы все это безобразие как-то обработать по-быстренькому, нужно это как-то распараллелить на больших вычислительных мощностях. Тут то нам и приходит на помощь мапредьюс! Вообще эта модель состоит из трех частей маппинга, сортировки и редьюса, теперь по подробнее, рассмотрим на классическом примере — подсчета слов в строчке/тексте/Войне и мире/Википедии:

0. Разбиваем наши данные на кусочки, в случае с текстом — на слова, а затем разбиваем наши слова на пачки поровну, по N штук в пачке.

1. Map. Применяем к каждому элементу данных map-функцию. В качестве элемента у нас это слово. Зачем мы делили на пачки? А каждую пачку у нас обрабатывает отдельный компуктер! Он проходится по каждому слову и применяет нашу map-функцию. В качестве map-функции может быть все что угодно, что напишет программист. В случае подсчета слов, можно делать простой кортеж {«слово»:1}. Один элемент, назовем его ключом будет являться входным словом, второй элемент, назовем его значением будет являться результатом map-функции. Представим что наша мап-функция подсчитывает количество слов…в одном слове :). Вообщем возвращает константу — единицу.

2. Shuffle. Результаты с прошлого шага сортируются по ключу. У нас ключ — это «слово». Значит сортируем ключи по алфавиту. Отсортированные пары ключ-значение кучкуются таким образом, чтобы одинаковые ключи всегда находились в одной пачке.

3. Reduce. Полученные пачки также читает и обрабатывает каждый компуктер отдельно. На вход компуктеру дается пачка с несколькими парами, с одинаковыми ключами. Над ними применяется reduce-функция, которая как-то агрегирует информацию по этим парам. В нашем случае — суммирует значения пар. Поскольку ключи одинаковые и обозначают одно конкретное слово, а значения в каждой паре — это единица (результат map-функции), то получается, что reduce-функция… подсчитывает количество вхождений этого слова! После обработки пачки данных мы получаем один кортеж {«слово»: количество повторений}.

4. Далее результаты могут сортироваться и куда-нибудь записываться.

Мне кажется я прекрасно по-колхозному рассказал, но если кто-то не до конца понял или хочет немножко углубиться, то это по традиции — тут

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

0. На вход подавались пару разных таблиц, они разбивались построчно и объединялись в пачки (батчи). Каждый батч обрабатывала часть вычислительного кластера.

1. Над каждой строчкой (тем же самым кортежем, что и в примере {«ключ»: поле1, поле2…}) применялась map-операция. Менялись какие-то поля, вычислялись заново и тд. Выхлоп помещался в промежуточную таблицу.

2. Промежуточная таблица так же сортировалась по ключу.

3. Далее все строки таблицы редьюсились по ключу, у нас на вход этой операции могли придти 1 или 2 строчки (одна из первой таблицы, вторая из второй). Там была своя логика, если пришла одна строчка и своя логика если пришли обе, тут не буду вдаваться в подробности. На выходе получалась одна обогащенная данными строчка

4. Каждая выходная строчка записывалась в новую таблицу — экспортную для каких-то внутренних сервисов-потребителей.

Ускорение заключалось в том, чтобы использовать одну таблицу вместо двух :). После удаления использования одной таблицы, нужно было свериться, что выходные данные до ускорения и после ускорения не изменились. Естественно они изменились.

В целом сверка данных до/после изменений работает по одному и тому же принципу.

1. Заморозка семпла данных. Семпл — это пример. Какая-то часть данных. Не хочется сохранять десятки терабайт таблиц и ждать по нескольку часов, чтобы понять что я забыл написать добавление строк в выходную таблицу. Тут я знаю один лайфхак семплирования данных — i have a ключ таблицы, i have a хеш функцию, мммм хеш. I have a хеш, i have a %100<5 ммм 5% выборка.
   Ну, то есть применяем хеш функцию, что дает нам число, берем остаток от деления на 100, сравниваем с желаемым процентом и все. Необходимо когда данные нужно просемплировать с нескольких таблиц по одинаковым ключам.

2. Запуск на замороженных данных оригинальной ветки кода.

3. Запуск на тех же данных наших изменений.

4. Смотрим на важные для нас поля, копаем чем они отличаются, правим, идем на пункт 2.

Тут тоже я узнал о некоторых интересных мелочах, о которых я расскажу кратенько.

• Protobuff middle пак. Тут познакомился с ареной. Arena — это такая штука, которая позволяет аллоцировать память для сообщений и вроде как она работает эффективнее чем ручками память под proto message выделять память. Можно и нужно не стесняться свапать поля протобуфа (естественно очень аккуратненько).

• Брокер сообщений. С ним мне удалось поработать прям супер мало. Но если в двух словах — это такой регулировщик данных, кран, который распределяет потоки сообщений по разным трубам (сервисам-потребителям). Классический представитель брокера сообщений — Кафка. В этой теме особо не успел разобраться, поэтому предлагаю старожилам накидать полезных ссылочек и пояснений, мнений про эти ваши семантики доставки, подписчиков и проч.

• Tmux — это утилита, которая позволяет работать с терминалом и не отключать его при потере соединения при подключении по ssh. Вообщем, если вы не будете работать через удаленную машину, то скорее всего вам не нужно этого знать :).

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

Заключение

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

Как я уже упоминал, стажировка длится 3 месяца в разных командах. Выражу свое мнение по этому поводу. В таком подходе есть свой хороший плюс и жирный минус.

• Плюс в том, что начинающему стажеру, не имеющему особого программисткого опыта за плечами, предоставляют возможность попробовать себя в разных сферах. Ну область то одна — маркетплейс, но вот пощупать его можно с разных сторон и определить для себя что ближе. Любишь работать с запросами и хендлерами или тебе по душе возится с базами данных? Будешь работать до пенсии по Scrum или Canban? Посвятишь всю свою дальнейшую жизнь оптимизациями и ускорениями процессов или искусной перестройкой логики приложения? Немного с иронией, но вот примерно на такие серьезные (и не очень) вопросы можно ответить в конце стажировки.

• Жирный минус в том, что для того, чтобы понимать как че в команде вообще работает нужно зачастую чуточку больше времени чем один месяц. Сервисы в Маркете большие, и зачастую нет ни одного разработчика, который бы досконально понимал вообще весь сервис. Часто нужно общаться с другими знающими разработчиками, и чтобы понять как все устроено нужно как по мне месяца 3, а то и больше.

Мне нравится идея закрепления ментора за стажером в команде. Это позволяет сделать деловое предложение:

Стажер получает поддержку и объяснение как чего работает, бесценные советы гуру, ревью кода, тайные практики шаулинских монахов.

Ментор получает бесплатную раб силу для задач до которых не доходили руки возможность заняться управлением рабочего ресурса. Развивает в себе навыки тимлида. И действительно, я знаю что некоторые из моих менторов стали так же и лидами, хочу их поздравить :).

А дальше что?

Я бы хотел рассказать о своем дальнейшем пути. Я же знаю вам интересно, какой шанс после стажки попасть на постоянку)))

На самом деле у меня довольно воодушевляющая история. И я сам очень хочу ее поведать. В конце стажировки, фризы в Маркете не отменили. Нанимали в других бизнес-юнитах, нанимали мидлов и выше, а вот джуны никому не были нужны. Мне предложили отложенный оффер — при нормализации ситуации он бы послужил небольшим подспорьем если бы я устраивался на работу. Мне предлагали подождать, попроходить алгоритмические секции (к слову сказать, они не особо отличались сложностью чем те, что были на алгоритмических секциях для стажировки) и ждать, пока кто-то мной заинтересуется. И тут начинается черная сторона найма. Дни шли, стажировка подходила к концу, а новостей от hr-а не было…

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

Я написал более чем десятку руководителей команд, которые искали разработчика. Многим я был неинтересен, многие ожидали более опытного работягу. Многим не нравилось, что я хотел бы работать удаленно (напомню, я не из Мск), и никто — не хотел принимать на 0,75 ставки(напомню, я студент). Я понимал, что шансов у меня немного и нужно чем-то жертвовать. Дистанционно и на полную ставку со мной решили побеседовать 4 руководителя. 4 Финала.

Один финал был на самом деле и не особо-то финалом. Это был сервис телефонии, руководитель хотел разработчика и подумал что мои силы недооценены, но нет, они верно оценили :). Руководитель хотел увидеть знания кафки, postgresql, каких-то алгоритмов в телефонии. Но этого не увидел 🙂

Следующий руководитель был руководителем смежного сервиса с первой моей командой и я даже что-то спрашивал у него по задачам. Но и для него моих знаний было недостаточно. Я запомнил очень интересный вопрос:

Что происходит после того, как мы ввели запрос в строку поиска браузера и нажали enter?

Потом я узнал что это весьма классический бекендерский вопрос.

Следующий руководитель дал мне задачку создать класс для работы с указателями на некоторый текст или числовую последовательность, я не помню задачи, но точно помню что делался акцент на то как я мыслю при написании кода, на какие возможные проблемы смотрю, не трачу я лишней памяти и ресурсов. Это была задачка не просто на «реализуйте алгоритм», а больше про «у нас есть такая-то задача, подумай архитектуру, которая могла бы ее решить». Мне понравился такой подход и свобода в действиях. В итоге я все же написал не вполне работающее решение, но у меня спросили почему оно не работает. И тут для руководителя было важно, понимаю ли я ошибку. Я объяснил ошибку до уровня «ну здесь у нас произойдет инвалидация итераторов, что приведет к undefined behavior». И смог переделать решение. У меня было ощущение что этот финал очень неплох, но и тут я получил отказ.

Четвертый (но не по хронологическому порядку) руководитель был знаком с ментором моей второй команды, и оказывается я ускорял создание таблицы именно для этой команды. Этот финал был больше про поговорить и про дальнейшие цели и планы. Руководитель был очень лояльным и рассудительным в вопросах. Начали мы разговор с формальности — задачки, которая сразу же показала специфику команды — не изобретать велосипеды и пользоваться готовыми решениями. Меня не просили реализовать какой-то алгоритм, а применить известную формулу к числовому ряду, о которой я не смог сразу догадаться. Десятки алгоритмических собесов с применением хешмап дали о себе знать :). Тем не менее с небольшой подсказкой «а может нам дать что-нибудь знание об этом ряде, метаинформация о нем?» получилось добить задачку.
Мне подробно рассказали о сервисе и о том, чем занимается команда, это первый руководитель, который собесил меня вместе с разработчиком. Впечатление осталось от разговора очень приятным, а в моих глаза появился интерес к работе, которую делает эта команда и к людям которые там могут работать. И кажется у них тоже сложилось обо мне хорошее впечатление. Как я полагаю многую информацию обо мне дал мой ментор в качестве отзыва и это сыграло хорошую роль.

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

Благодарности?

Я писал эту статью без малого год. Это не значит что я каждый день пыхтел над каждым словом и абзацем. Просто моя лень не позволяла мне встать и написать пару строк :).

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

Не хочу обходить стороной всех участников этой истории, но дабы никого не обидеть, оставлю только инициалы :). Итак, я благодарю девушку П из hr, которая была первым проводником в мир стажировки, Л и Н, очаровательных девушек из команды адаптации стажеров за чудесную адаптацию (А девушке Н за чашечку чая и случайную вечернюю беседу на балконе после окончания стажировки), сибиряка П за его серьезное, деловое, но не лишенное уважения и доброты общение и человеческое отношение, И как первого бадди, за обедочат и обедообщение, А за засиживание до ночи и по выходным и распитие чая в положеном месте, Е как второго бадди :), и который, я надеюсь, стал приходить на работу в 10 утра, а не уходить с нее в это время, замечательную К, которая всегда была готова помочь, с которой можно было обсудить задачки в воскресенье ночью, М за офигенные советы, что я помню до сих пор и импрув моих скилов. С за то, что увидел во мне потенциал для работы в команде и Д, за хоть и недолгое знакомство, но достаточное для восхищения.