«На стажировке не дают реальных задач», «Тебя и близко к реальному проекту не подпустят!», «Лидам некогда с тобой нянчиться: ошибешься — и на выход!», «Даже если возьмут в штат, все равно будешь „принеси-подай”». Так многие думают про стажировки в IТ-компаниях.



Чтобы развеять стереотипы, мы подготовили три честных истории от сотрудников «Лаборатории Касперского», которые в свое время проходили стажировку Kaspersky Safeboard. Они разбирают реальные кейсы из своей практики и рассказывают, как этот опыт помог им в дальнейшей работе. А какое решение их кейсов предложили бы вы?




Илья Щепакин: Когда я был стажером, работал над проектом Sandbox — платформой-песочницей, в которой на виртуальных машинах проверяются подозрительные объекты. Настройки этих машин можно экспортировать для дальнейшего использования на стороне разработчика. Но в проекте такая опция требовалась довольно редко, потому что использовалась для тестирования ОС со специфическими настройками. Так что файлы настроек просто копились и, соответственно, занимали место в памяти системы.

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

Я думаю: «Ладно, может быть, в UI будет кнопка, или сервис сам будет вызывать нужную задачу». А вот и нет — приходилось все делать вручную. Ну, я все это долго и муторно проделывал, а таска еще и периодически обрастала какими-то дополнительными требованиями от тестировщиков. Я пилил эту задачу и думал: «Неужели нельзя сделать как-то проще?»

Вариантов действий было несколько:

1. Продолжить выполнять задачу в установленных рамках.
2. Пойти к тимлиду и спросить, что делать.
3. Придумать свое решение и предложить его команде.

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

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

Но самое удивительное — что-то похожее мне прилетает спустя несколько месяцев, когда я уже стал джуном. Тогда я просто переупаковал свое решение под новую задачу, а потом позвал руководителя на 10-минутную встречу и предложил внедрить то, что я придумал. 3-4 часа работы — и все: задача отправлена на тестирование и влита в релизную ветку. Так что не стоит бояться своей неопытности или думать, что из-за возраста к тебе не станут прислушиваться. Если у тебя есть крутое решение проблемы, не бойся — предлагай!




Даша Осовская: Я — системный аналитик, работаю в команде разработки продуктов Kaspersky для iOS. Для начала дам немного контекста, чтобы было понятно, чем я занимаюсь. Перед тем как фича идет в разработку, системные аналитики описывают, какой она должна быть, и подготавливают всю базу для разработки. В ходе анализа важно выявить все связи, все узкие места и все сложности, которые могут возникнуть во время реализации. Ведь ошибка на этапе анализа приведет к неправильному пониманию фичи всей командой и затем к неверному исполнению.

Мне поручили минорную правку в масштабах большого обновления продукта. В рамках моей задачи нужно было изменить формат ссылок в продукте. Дело в том, что в разделе «Справка» есть много гиперлинков, которые ведут на сайт с FAQ. И для каждой версии нашего продукта эти ссылки, естественно, должны быть уникальными, ведь и мануалы могут меняться тоже.

Схематично url выглядит так: домен/продукт/операционнаясистема_номерверсии/язык/номердокумента. И каждый раз они обновлялись вручную.

Понадобилось это оптимизировать. Я написала коллегам с предложением сделать так, чтобы ссылки в продукте автоматически обновлялись в соответствии с его версией: то есть чтобы происходил редирект на нужную страницу. Ужас в том, что я случайно опечаталась в ТЗ, и коллеги реализовали не тот механизм! (Это к вопросу о важности работы системного аналитика.) Вследствие чего ссылки стало настраивать еще сложнее: теперь это был обычный редирект, без автоматической переадресации. То есть другие параметры подставлялись (ОС, язык), а сама версия — нет.

Хуже того — это произошло перед самым релизом. И если зарелизить так, как есть, все ссылки будут нерабочими.

Что мне надо было сделать?

1. Скрыть свою ошибку.
2. Попросить тимлида решить проблему.
3. Собрать коллег и постараться решить всем вместе.

Молчать, я, конечно, не стала — побежала к лиду, и он помог разработать спасательный план действий. Да, мне пришлось вручную вставлять костыли и исправлять каждую ссылку, но что поделать…

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




Никита Бирюлин: Я работаю над сборочной системой Bazel, где мы используем язык Starlark, чтобы обеспечить работу C, C# и C++ разработчиков. Пока я был на стажировке, у нас появилась задача по добавлению поддержки нового компилятора в систему сборки: имелся GCC (GNU Compiler Collection), а понадобилось добавить компилятор SAFEC (от Института системного программирования РАН), который нужен для сверки с российскими стандартами. Также потребовалось создать механизм, с помощью которого разработчикам удобнее было бы их различать, потому что разница между GCC и SAFEC минимальна.

В рамках этой задачи я разделил компиляторы на разные «ручки», чтобы разработчики могли проверять код и там, и там. Однако случилось непредвиденное — вылезла проблема, которую на процессе согласований на Pull Request не заметил ни я, ни коллеги, ни средства автотестирования. И в итоге мы сломали коллегам процесс сборки: после этих изменений все настройки, которые разработчики делали под GCC, перестали применяться к SAFEC…

И в этот момент передо мной встал выбор:

1. Попытаться быстро пофиксить проблему, оставив правки.
2. Откатить правки, найти все конфликтные моменты, исправить их и только потом эти правки внести.
3. Перевести эту задачу на более опытного сотрудника.

Я решил не откатывать, и это было неправильно. Чем все это закончилось? Я пофиксил две своих проблемы, а вылезло еще шесть. И в итоге процесс затянулся на полтора дня. И конечно, страдали мои коллеги, потому что пока код был неисправен, некоторые сборки не работали.

В итоге через несколько дней я все равно откатил эти изменения (что стоило бы сделать это с самого начала!), а после руками фиксил все несовместимые места, чтобы потом снова внести эти правки.

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

Оглядываясь назад, я понимаю: это было полностью правильным решением. Моя проблема оказалась довольно сложной, и решать ее было уместно только спокойно и вдумчиво, откатив правки. В целом, насколько я успел изучить IT-индустрию, почти не бывает ситуаций, когда оптимальным решением было бы что-то быстро, на коленке пофиксить. Главное — чтобы рядом оказался нужный человек, который бы подсказал это и помог бы правильно погрузиться в проблему.


Если вы хотите стать стажером в «Лаборатории Касперского», с самого начала включиться в реальные задачи и получать полноценную поддержку от команды, то спешите подать заявку на ближайший набор в Kaspersky Safeboard. Из направлений: разработка, информационная безопасность, тестирование, аналитика и даже DevOps. Стажировка оплачивается, а вместе с этим стажер получает ежемесячную компенсацию питания, бесплатный спортзал и массу других бенефитов.