В текущей компании прошедшее ревью для меня стало пятым, а самыми сложными были первые два, когда еще не до конца знаком с процессом и не понимаешь чего именно от тебя ожидают. Что мне помогает и почему я уже начал готовиться к следующему? Свой опыт я решил сгруппировать по периодам, которые можно рассматривать отдельно на каждом из этапов ревью. 💪 Готовимся период: окончание перф. ревью -> начало следующего перф. ревью Оставляйте цифровой след.➤ Читать полностью...

Однажды Хемингуэй поспорил, что сможет написать самый короткий рассказ, способный напугать любого… Он выиграл спор: Performance Review Разберемся что это такое, почему наступает неожиданно и можно ли что-то с этим сделать? Если кратко, то это процесс подведения итогов работы за определенный период. Подробнее можно найти здесь Наличие такого процесса говорит об определенном уровне зрелости компании, но он должен работать правильно, чтобы не доставлять вам хлопот (ведь вы пришли код писать, а не отчеты для менеджеров).➤ Читать полностью...

Самый ценный совет, который я получил в начале карьеры программиста: пишите юнит-тесты. У многих неопытных разработчиков требование написать их вызывает прокрастинацию или скуку. Я до сих пор иногда ленюсь, но все равно делаю это. И тут речь не про то, что в Авито для бэкенд-разработчика написание юнитов на свою логику считается в большинстве случаев необходимым требованием, чтобы тебе одобрили пул-реквест, но больше про то, что я реально понимаю ценность этого.➤ Читать полностью...

Я много думал на эту тему. Раньше у меня были ожидания, что такой специалист пишет «неземной» код и делает это быстро. Он способен решить сложную задачу и знает ответ на любой вопрос в своей области. Конечно, это преувеличение, но такое было направление мысли. Со временем, когда я стал чаще пересекаться с инженерами такого уровня или даже выше, я понял, что код они могут писать также долго, как и джуны, и у них, очевидно, нет ответа на любой вопрос.➤ Читать полностью...

Сперва ответьте себе на вопрос: стоит ли туда идти прямо сейчас с текущим опытом? И с какой целью? Если рассмотреть инженера в компании, где налажены процессы и есть понятное разделение ответственности, то умение проектировать системы ожидают от старших разработчиков ближе к уровню синьор. Зачастую собеседования на такой грейд сопровождаются классическим system-design interview, где вас попросят спроектировать твиттер, ютуб или другую популярную систему. Конечно, не мало стартапов или гос. компаний, где джуны занимаются проектированием сложной системы, но это нездоровая практика и мы не будем про нее говорить.➤ Читать полностью...

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

Вчера было ровно 2 года с момента, как я работаю в Авито. За это время мне удалось качественно вырасти как специалист. У меня отличная команда, которая поддерживает друг друга, помогает достигать результата и готова разделить любой досуг. Конечно, есть ощущение, что не всем так повезло с коллегами и ситуации бывают разные. Но именно для этой цели существует финальное интервью (или фит-интервью), которых у меня при трудоустройстве было целых три. Если меня спрашивают куда лучше идти работать, часто призываю стремиться именно в крупные компании.➤ Читать полностью...

Одной из важнейших компетенций, на которую смотрят при возможном пересмотре грейда, является “инженерная культура”. В Авито на уровень E5 (синьор) ее признаки обозначаются как: Улучшает общие инженерные инструменты компании. Тестирует сложные корнер-кейсы. Проектирует тестопригодные системы и исправляет те, которые сложно тестировать. Ищет неэффективные места в коде/архитектуре/тестовых моделях. Пополняет технический бэклог команды. Устанавливает и тестирует нефункциональные требования или привлекает для этого экспертов. Знает и использует безопасные подходы к реализации функциональности. Когда целишься в следующий грейд, то полезно время от времени сверяться с ожиданиями на нем, чтобы была возможность их продемонстрировать.➤ Читать полностью...