Forwarded from Блог Махача
Отцу не объяснишь, что ты сеньор
Это два самых дорогих грузчика, которых я видел
Это два самых дорогих грузчика, которых я видел
😁27🤣8👍5
📈 Про перформанс-ревью
Совсем недавно в Яндексе завершился период ревью — оценки работы сотрудников за последние полгода.
Если коротко — вы описываете результаты своей работы, пишете отзывы на коллег, после чего руководители путем хитрых манипуляций выставляют вам оценку. По итогам одни получают премии, другие повышения, а кто-то открывает сайт с вакансиями 🫠.
Эта практика есть во многих крупных компаниях. Чуть больше можно узнать в докладах от😊 Яндекса и 😊 Авито.
При написании селф-ревью (отчета о своей работе) важно делать это через призму пользы для бизнеса. Результат вашей работы позволил бизнесу либо заработать больше, либо потратить меньше. К примеру, не просто «оптимизировал поиск», а «оптимизировал поиск, что уменьшило количество отказов на 10%».
Бизнес-ценность зачастую можно извлечь из описания задачи (для чего-то ведь ее ставили), а метрики «до/после» пообщавшись с аналитиками. Кстати, это вырабатывает привычку думать о ценности задачи еще на этапе грумминга. При правильном подходе даже для чисто технических задач можно найти ее. Пример: «оптимизировал линтинг» → «ускорил CI» → «уменьшил время доставки фич».
В процессе первого для меня ревью я прошерстил задачи и коммиты за последние полгода, чтобы вспомнить все детали. Зачастую в этих деталях и кроется вся соль задачи, о которой важно написать.
В результате я начал фиксировать детали выполняемых мною задач в отдельной заметке: в чем заключалась задача, какие были сложности, с кем приходилось взаимодействовать. При таком подходе для написания селф-ревью останется только немного подредактировать собранную инфу. Плюс это помогает сразу определиться у кого стоит запросить фидбек.
Параллельно с этим я делаю пометки о работе своих коллег — это позволяет написать более развернутый фидбек, если они его запросят. Если вспомнить свои задачи за полгода бывает непросто, что говорить о работе коллег.
К примеру, я заметил, что один из наших тестировщиков очень скрупулезно подходит к тестированию и пишет очень подробные, хорошо оформленные отчеты. Вряд ли я бы вспомнил эти детали в конце полугодия, учитывая, что с ним мы взаимодействовали только в самом его начале.
Проводить селф-ревью полезно даже если в вашей компании нет такого процесса:
🟠 Можно оценить свой прогресс
🟠 Обосновать повышение ЗП для руководства
🟠 Использовать при описании опыта в резюме и на собесах
В комментариях можем обсудить как в вашей компании происходит оценка работы сотрудников.
Совсем недавно в Яндексе завершился период ревью — оценки работы сотрудников за последние полгода.
Если коротко — вы описываете результаты своей работы, пишете отзывы на коллег, после чего руководители путем хитрых манипуляций выставляют вам оценку. По итогам одни получают премии, другие повышения, а кто-то открывает сайт с вакансиями 🫠.
Эта практика есть во многих крупных компаниях. Чуть больше можно узнать в докладах от
При написании селф-ревью (отчета о своей работе) важно делать это через призму пользы для бизнеса. Результат вашей работы позволил бизнесу либо заработать больше, либо потратить меньше. К примеру, не просто «оптимизировал поиск», а «оптимизировал поиск, что уменьшило количество отказов на 10%».
Бизнес-ценность зачастую можно извлечь из описания задачи (для чего-то ведь ее ставили), а метрики «до/после» пообщавшись с аналитиками. Кстати, это вырабатывает привычку думать о ценности задачи еще на этапе грумминга. При правильном подходе даже для чисто технических задач можно найти ее. Пример: «оптимизировал линтинг» → «ускорил CI» → «уменьшил время доставки фич».
В процессе первого для меня ревью я прошерстил задачи и коммиты за последние полгода, чтобы вспомнить все детали. Зачастую в этих деталях и кроется вся соль задачи, о которой важно написать.
В результате я начал фиксировать детали выполняемых мною задач в отдельной заметке: в чем заключалась задача, какие были сложности, с кем приходилось взаимодействовать. При таком подходе для написания селф-ревью останется только немного подредактировать собранную инфу. Плюс это помогает сразу определиться у кого стоит запросить фидбек.
Параллельно с этим я делаю пометки о работе своих коллег — это позволяет написать более развернутый фидбек, если они его запросят. Если вспомнить свои задачи за полгода бывает непросто, что говорить о работе коллег.
К примеру, я заметил, что один из наших тестировщиков очень скрупулезно подходит к тестированию и пишет очень подробные, хорошо оформленные отчеты. Вряд ли я бы вспомнил эти детали в конце полугодия, учитывая, что с ним мы взаимодействовали только в самом его начале.
Проводить селф-ревью полезно даже если в вашей компании нет такого процесса:
В комментариях можем обсудить как в вашей компании происходит оценка работы сотрудников.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Нужно ли быть нормальным? – Андрей Стыскин, Яндекс
Слайды: https://yadi.sk/i/N3X5E3YcPaLnsA
О спикере:
Андрей Стыскин с 2019 года возглавляет поисковый портал. До этого руководил управлением поисковых продуктов, отделом ранжирования, занимался качеством международного поиска и создавал поиск для Турции.…
О спикере:
Андрей Стыскин с 2019 года возглавляет поисковый портал. До этого руководил управлением поисковых продуктов, отделом ранжирования, занимался качеством международного поиска и создавал поиск для Турции.…
👍33🔥9❤6
🧠 Когнитивные искажения
В последнее время довольно много читал про различные когнитивные искажения (ошибки восприятия и интерпретации информации). Советую ознакомиться со списком таких искажений в Википедии — это очень интересно.
В какой-то момент мне захотелось собрать список искажений, свойственных для разработки (если брать шире — для любого бизнеса), но оказалось, что он уже есть — проект UXCore на сайте KeepSimple.
Для каждого искажения приводится описание и примеры влияния на продукт или HR-менеджмент (наём, бренд компании, управление кадрами). Для некоторых ситуаций приводятся решения. По мне просто находка для менеджеров, HR-ов, да и просто бизнесменов.
Несколько примеров таких искажений:
🛑 Синдром неприятия чужой разработки или NIH (not-invented-here) — когда вместо использования готового инструмента или библиотеки, пилится свой велосипед.
🛑 Ловушка невозвратных затрат или эффект Конкорда — ситуация, когда большое количество потраченных ресурсов мешают вовремя бросить бесперспективное дело. Решение этой ситуации выражено в поговорке: «Лошадь сдохла — слезь».
🛑 Ошибка планирования — когда вторую неделю работаешь над задачей, на которую закладывалось три дня, а света в конце тоннеля все еще не видно.
Параллельно стоит заглядывать в Википедию, т. к. там тоже можно подчерпнуть что-то полезное. К примеру, на UXCore не приводится решение ошибки планирования, а вот в Википедии — да.
В последнее время довольно много читал про различные когнитивные искажения (ошибки восприятия и интерпретации информации). Советую ознакомиться со списком таких искажений в Википедии — это очень интересно.
В какой-то момент мне захотелось собрать список искажений, свойственных для разработки (если брать шире — для любого бизнеса), но оказалось, что он уже есть — проект UXCore на сайте KeepSimple.
Для каждого искажения приводится описание и примеры влияния на продукт или HR-менеджмент (наём, бренд компании, управление кадрами). Для некоторых ситуаций приводятся решения. По мне просто находка для менеджеров, HR-ов, да и просто бизнесменов.
Несколько примеров таких искажений:
Параллельно стоит заглядывать в Википедию, т. к. там тоже можно подчерпнуть что-то полезное. К примеру, на UXCore не приводится решение ошибки планирования, а вот в Википедии — да.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍26🔥12❤5
На этих выходных вместе с Махачом aka Архитектор (@architector_notes) посетили Грозный, где нас встретил Иса Эзербаев (@monoteistBlog) — старший брат IT-бороды.
У Исы было запланировано интервью с Go-разработчиком, студентом Школы 21. Так мы попали на съемки 🙃. Интересно было наблюдать за процессом, увидеть всякие закулисные фишки, поснимать бэкстейдж.
Видео появится на его
Please open Telegram to view this post
VIEW IN TELEGRAM
👍31
💫 Фичелидинг
Один из способов делегирования в разработке — фичелидинг (feature leading), когда разработчик становится ответственным за какую-то относительно крупную фичу. По сути он берет на себя обязанности техлида, но для определенной части проекта.
Лид фичи ответственен за нее от этапа идеи/первоначального ТЗ до момента запуска ее на проде. Он общается с заказчиками и другими стейкхолдерами, уточняя детали, прорабатывает архитектуру, разбивает ТЗ на задачи и затем приносит все это команде. Также он является конечной точкой во всех возникающих вопросах.
Для разработчика фичелидинг — это возможность прокачать навыки проектирования, управления, лучше прочувствовать сам продукт и процессы, да и просто отметиться на ревью, а для тех/тимлида — возможность вырастить своих подчиненных и снять с себя часть нагрузки.
Один из способов делегирования в разработке — фичелидинг (feature leading), когда разработчик становится ответственным за какую-то относительно крупную фичу. По сути он берет на себя обязанности техлида, но для определенной части проекта.
Лид фичи ответственен за нее от этапа идеи/первоначального ТЗ до момента запуска ее на проде. Он общается с заказчиками и другими стейкхолдерами, уточняя детали, прорабатывает архитектуру, разбивает ТЗ на задачи и затем приносит все это команде. Также он является конечной точкой во всех возникающих вопросах.
Для разработчика фичелидинг — это возможность прокачать навыки проектирования, управления, лучше прочувствовать сам продукт и процессы, да и просто отметиться на ревью, а для тех/тимлида — возможность вырастить своих подчиненных и снять с себя часть нагрузки.
👍19❤7🔥6
🏄 Мой опыт онбординга
По следам поста Муаммара.
Онбординг — процесс адаптации сотрудника на новой работе, который помогает ему быстрее включиться во все процессы.
Мне довелось пройти два онбординга — в Авито и в Яндексе. В моем случае это была удаленка: для тех, кто выходит в офис, процесс немного отличается.
В Яндексе этим занимается целая команда и работа по адаптации начинается еще до момента выхода сотрудника.
1. Выдача оборудования. В офисе это отдельные ребята, которые занимаются всеми вопросами по оборудованию. В моем случае ноут мне принес курьер.
2. Вход в корпоративный аккаунт. У крупных компаний обычно есть внутренний сервис, хранящий всю информацию о сотрудниках. С его помощью мы авторизуемся во всех остальных сервисах, в том числе внешних.
3. Созвон с командой адаптации. Рассказывают про оформление документов, различные плюшки а-ля ДМС, к кому обращаться с вопросами. Также добавляют в отдельный чат для новичков.
4. Знакомство с командой. В зависимости от формата работы — может быть вживую, в виде созвона или просто сообщением в чате.
5. Обучающие созвоны для новичков. Многие из которых можно пропустить.
6. Чеклист новичка. Обычно это задача в трекере с пунктами типа “Подписать документы”, “Добавиться в рабочие чаты”, “Получить доступы к коду”, “Пройти курс XXX”. У Яндекса есть отдельный красивый лендинг, который рассказывает, что нужно сделать в первые день, неделю и месяц.
7. Курсы. У тройки Яндекс, ВК, Авито есть внутренние LMS с различными курсами. В чеклисте обычно половина курсов — это всякие формальности типа “Охрана труда и безопасность в офисе”, которые можно прокликать, а другая половина — уроки по внутренним инструментам, которым стоит уделить внимание. Сюда же входит и NDA, который подскажет, что не стоит выносить за пределы компании.
8. Наставник/бадди. Обычно это опытный член команды. В Авито это был мой коллега-фронтендер, в Яндексе — мой тимлид, т. к. нас было всего двое 😀. Бадди отвечает на все вопросы новичка — по процессам, коду, корпоративной культуре и т. д. Если это офис, то он поможет получить бейдж и покажет что и где находится.
9. Личные встречи с руководителем. На них новичок и руководитель обсуждают прогресс по адаптации, могут глянуть чеклист, обсуждают возникшие вопросы. В первое время они были каждый день, со временем стали реже.
10. Цели и ожидания на период адаптации. Ставятся руководителем и представляют собой чеклист вида: “Должен уметь то-то и то-то, уметь решать такие-то задачи”.
11. Промежуточная и итоговые встречи. Встречи в середине и конце периода адаптации, где обсуждаются итоги онбординга.
Из интересного: когда на работу выходил наш новый сотрудник, я предложил нашему тимлиду сделать меня бадди. В этот период я как раз готовился перейти на позицию лида и этот опыт помог войти мне в эту роль более плавно.
В следующем посте я расскажу, что вы можете сделать, чтобы быстрее включиться в работу.
По следам поста Муаммара.
Онбординг — процесс адаптации сотрудника на новой работе, который помогает ему быстрее включиться во все процессы.
Мне довелось пройти два онбординга — в Авито и в Яндексе. В моем случае это была удаленка: для тех, кто выходит в офис, процесс немного отличается.
В Яндексе этим занимается целая команда и работа по адаптации начинается еще до момента выхода сотрудника.
1. Выдача оборудования. В офисе это отдельные ребята, которые занимаются всеми вопросами по оборудованию. В моем случае ноут мне принес курьер.
2. Вход в корпоративный аккаунт. У крупных компаний обычно есть внутренний сервис, хранящий всю информацию о сотрудниках. С его помощью мы авторизуемся во всех остальных сервисах, в том числе внешних.
3. Созвон с командой адаптации. Рассказывают про оформление документов, различные плюшки а-ля ДМС, к кому обращаться с вопросами. Также добавляют в отдельный чат для новичков.
4. Знакомство с командой. В зависимости от формата работы — может быть вживую, в виде созвона или просто сообщением в чате.
5. Обучающие созвоны для новичков. Многие из которых можно пропустить.
6. Чеклист новичка. Обычно это задача в трекере с пунктами типа “Подписать документы”, “Добавиться в рабочие чаты”, “Получить доступы к коду”, “Пройти курс XXX”. У Яндекса есть отдельный красивый лендинг, который рассказывает, что нужно сделать в первые день, неделю и месяц.
7. Курсы. У тройки Яндекс, ВК, Авито есть внутренние LMS с различными курсами. В чеклисте обычно половина курсов — это всякие формальности типа “Охрана труда и безопасность в офисе”, которые можно прокликать, а другая половина — уроки по внутренним инструментам, которым стоит уделить внимание. Сюда же входит и NDA, который подскажет, что не стоит выносить за пределы компании.
8. Наставник/бадди. Обычно это опытный член команды. В Авито это был мой коллега-фронтендер, в Яндексе — мой тимлид, т. к. нас было всего двое 😀. Бадди отвечает на все вопросы новичка — по процессам, коду, корпоративной культуре и т. д. Если это офис, то он поможет получить бейдж и покажет что и где находится.
9. Личные встречи с руководителем. На них новичок и руководитель обсуждают прогресс по адаптации, могут глянуть чеклист, обсуждают возникшие вопросы. В первое время они были каждый день, со временем стали реже.
10. Цели и ожидания на период адаптации. Ставятся руководителем и представляют собой чеклист вида: “Должен уметь то-то и то-то, уметь решать такие-то задачи”.
11. Промежуточная и итоговые встречи. Встречи в середине и конце периода адаптации, где обсуждаются итоги онбординга.
Из интересного: когда на работу выходил наш новый сотрудник, я предложил нашему тимлиду сделать меня бадди. В этот период я как раз готовился перейти на позицию лида и этот опыт помог войти мне в эту роль более плавно.
В следующем посте я расскажу, что вы можете сделать, чтобы быстрее включиться в работу.
👍32❤10🔥4
Кстати, не так давно я завел веб-версию блога. Сделан на Gatsby, хостится на Netlify + GitHub. Cами посты пишутся в формате Markdown.
Выглядит пока неказисто, но мне почему-то всегда хотелось иметь блог именно в виде сайта, не запариваясь при этом с хостингом, базами данных и прочим.
Выглядит пока неказисто, но мне почему-то всегда хотелось иметь блог именно в виде сайта, не запариваясь при этом с хостингом, базами данных и прочим.
👍19🔥5🤨1
🚀 Как быстро влиться в работу
… и пройти испытательный срок.
Выходите на работу отдохнувшим
Первое, что стоит сделать перед выходом на новую работу — это хорошо отдохнуть. На мой взгляд, первые два-три месяца работы — это немного не про work-life balance. Придется разбираться в продукте, процессах, инструментах, кодовой базе и лучше сделать это быстро. И хотя в первое время от вас не ожидается серьезного вклада в проект — это не повод расслабляться.
Изучите ваш продукт
Продукт — товар или услуга, несущие какую-то ценность для клиента, закрывающая его потребность.
Знание продукта позволит лучше понимать задачи и говорить с коллегами на одном языке.
Что можно сделать для этого?
🟠 Попользуйтесь вашим продуктом, изучите различные пользовательские сценарии
🟠 Почитайте пользовательскую документацию
🟠 Изучите глоссарий проекта — словарь часто используемых терминов
Немного неочевидный момент (по крайней мере, был для меня) — обычно на многие вопросы по продукту кроме продакта могут ответить тестировщики, т. к. они проходят все эти сценарии по многу раз. У них же можно спросить про тестовые стенды, креды и все прочее.
Созвонитесь с наставником
🟠 Спросите про продукт, архитектуру проекта, процессы, с кем придется взаимодействовать (бэк, фронт, дизайнеры, тестировщики, смежные команды)
🟠 Можно спросить про текущие подпроекты и их статус — какие-то крупные фичи с долгим циклом разработки
🟠 Определите цели на испытательный срок
Задавайте вопросы
Не стесняйтесь задавать вопросы бадди, руководителю и в чатах, особенно на этапе онбординга.
Не исключено, что вы делаете все правильно и ошибка не на вашей стороне: документация могла устареть, задача плохо описана, что-то сломалось и т. п. Если поиск решения занимает больше пары часов — лучше пойти с вопросом к коллегам.
Держите руку на пульсе
🟠 Периодически сверяйтесь с ожиданиями на испытательный срок и проводите ретроспективу своей работы — все ли идет по плану?
🟠 Используйте one-to-one: подсвечивайте проблемы и опасения, запрашивайте фидбек
Записывайте потенциальные места для улучшения
Это могут быть как технические улучшения, так и улучшения в процессах.
Пока все ново глаз не замылен, можно увидеть то, что не замечают коллеги. Зафиксируйте их и отложите до момента, когда вы разберетесь в проекте, поймете почему сделано так или иначе и получите какой-то авторитет в команде. После этого можно вернуться к своим заметкам и, если они актуальны, предложить их команде.
Post Scriptum
Для себя я составил небольшой чек-лист действий и вопросов при вливании в проект, которые касаются технических моментов, процессов и т. д., вы можете сделать так же. Если дойдут руки нормально оформить его — выложу сюда, ин шаа Ллах.
Все написанное основано на личном опыте, либо на том, что я наблюдал со стороны.
Предлагаю обсудить в комментариях, что помогает вам при адаптации на новой работе.
… и пройти испытательный срок.
Выходите на работу отдохнувшим
Первое, что стоит сделать перед выходом на новую работу — это хорошо отдохнуть. На мой взгляд, первые два-три месяца работы — это немного не про work-life balance. Придется разбираться в продукте, процессах, инструментах, кодовой базе и лучше сделать это быстро. И хотя в первое время от вас не ожидается серьезного вклада в проект — это не повод расслабляться.
Изучите ваш продукт
Продукт — товар или услуга, несущие какую-то ценность для клиента, закрывающая его потребность.
Знание продукта позволит лучше понимать задачи и говорить с коллегами на одном языке.
Что можно сделать для этого?
Немного неочевидный момент (по крайней мере, был для меня) — обычно на многие вопросы по продукту кроме продакта могут ответить тестировщики, т. к. они проходят все эти сценарии по многу раз. У них же можно спросить про тестовые стенды, креды и все прочее.
Созвонитесь с наставником
Задавайте вопросы
Не стесняйтесь задавать вопросы бадди, руководителю и в чатах, особенно на этапе онбординга.
Не исключено, что вы делаете все правильно и ошибка не на вашей стороне: документация могла устареть, задача плохо описана, что-то сломалось и т. п. Если поиск решения занимает больше пары часов — лучше пойти с вопросом к коллегам.
Держите руку на пульсе
Записывайте потенциальные места для улучшения
Это могут быть как технические улучшения, так и улучшения в процессах.
Пока все ново глаз не замылен, можно увидеть то, что не замечают коллеги. Зафиксируйте их и отложите до момента, когда вы разберетесь в проекте, поймете почему сделано так или иначе и получите какой-то авторитет в команде. После этого можно вернуться к своим заметкам и, если они актуальны, предложить их команде.
Post Scriptum
Для себя я составил небольшой чек-лист действий и вопросов при вливании в проект, которые касаются технических моментов, процессов и т. д., вы можете сделать так же. Если дойдут руки нормально оформить его — выложу сюда, ин шаа Ллах.
Все написанное основано на личном опыте, либо на том, что я наблюдал со стороны.
Предлагаю обсудить в комментариях, что помогает вам при адаптации на новой работе.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍30❤10🔥6
السلام عليكم ورحمة الله وبركاته
Поздравляю всех мусульман с праздником 'Ид аль-Фитр!
تقبل الله منا ومنكم
Поздравляю всех мусульман с праздником 'Ид аль-Фитр!
تقبل الله منا ومنكم
❤43❤🔥7👍5😡1
🧑💻 Как я провожу финальные собеседования
За последнее время я провел чуть более 30 финальных встреч с кандидатами на позицию разработчика в нашу команду — относительно небольшое количество, если сравнивать с бывалыми тимлидами, но дающее полезные инсайды для рядового разработчика.
В посте я расскажу:
🟠 Какие этапы собеседований есть в крупных компаниях
🟠 Как выглядит финальная встреча с нанимающей стороны
🟠 Какие вопросы я задаю и на что обращаю внимание
🟠 Как определяется итоговый грейд и почему важно сделать это точно
🟠 Что опыт собеседования дает мне
https://imangazaliev.dev/blog/how-i-conduct-final-interview
За последнее время я провел чуть более 30 финальных встреч с кандидатами на позицию разработчика в нашу команду — относительно небольшое количество, если сравнивать с бывалыми тимлидами, но дающее полезные инсайды для рядового разработчика.
В посте я расскажу:
https://imangazaliev.dev/blog/how-i-conduct-final-interview
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21👍5❤4
Были времена 😆
В свое время подолгу зависал на форуме boolean.name в разделе про MIDletPascal. На этом языке мы с братом писали приложения для своих нокий, иногда соревнуясь чье приложение круче.
Где-то здесь можно найти наши проекты — я писал движок для мобильных журналов (в то время они были очень популярны), а брат — приложение для подбора цвета.
А еще GitHub хранит мои первые шаги в веб-разработке: первый сайт на PHP и проект на Vue. Тогда я еще не знал про Git, поэтому в некоторых проектах можно заметить папки «v1», «v2» 😁
В свое время подолгу зависал на форуме boolean.name в разделе про MIDletPascal. На этом языке мы с братом писали приложения для своих нокий, иногда соревнуясь чье приложение круче.
Где-то здесь можно найти наши проекты — я писал движок для мобильных журналов (в то время они были очень популярны), а брат — приложение для подбора цвета.
А еще GitHub хранит мои первые шаги в веб-разработке: первый сайт на PHP и проект на Vue. Тогда я еще не знал про Git, поэтому в некоторых проектах можно заметить папки «v1», «v2» 😁
❤12😁9👍2
🤔 О чем спросить на собеседовании?
Часто мы воспринимаем собеседование как экзамен, где наша главная цель — просто пройти его. На самом деле компания не меньше нашего заинтересована в найме подходящего кандидата — задачи-то ждут 🙂 И если джунам выбирать особо не приходится, то у мидлов и выше такая возможность есть.
Чтобы выбрать правильный оффер и не разочароваться после выхода на работу, просто задавайте вопросы 🤷♂️
Какие моменты нужно прояснить для себя:
🟠 Продукт — что из себя представляет, какую ценность несет для пользователя и сколько этих самых пользователей
🟠 Технологии — стек, архитектура
🟠 Команда — размер, состав
🟠 Процессы — откуда приходят задачи, как планируют, работают, оценивают результаты
🟠 Планы на ближайшее время (условно, год)
🟠 Задачи, которые будут стоять перед вами
Хорошо бы записать ответы, чтобы взять время подумать или сравнить офферы.
Часто ситуацию, когда мы задаем вопросы называют обратным собеседованием (reverse interview) — можно погуглить и найти список вопросов. Есть пара неплохих подборок: раз и два.
Не стоит задавать все вопросы из списка — проанализируйте свой предыдущий опыт и выберите важное для себя. Еще вопросы зависят от самой компании. К примеру стартапам свойственны горящие дедлайны, переработки, ограниченные финансы и неожиданные закрытия — имеет смысл спросить об оплате переработок, наличии реальных клиентов. В других компаниях стоит спросить про легаси и т. д.
В комментариях можем обсудить какие вопросы задали бы вы.
Часто мы воспринимаем собеседование как экзамен, где наша главная цель — просто пройти его. На самом деле компания не меньше нашего заинтересована в найме подходящего кандидата — задачи-то ждут 🙂 И если джунам выбирать особо не приходится, то у мидлов и выше такая возможность есть.
Чтобы выбрать правильный оффер и не разочароваться после выхода на работу, просто задавайте вопросы 🤷♂️
Какие моменты нужно прояснить для себя:
Хорошо бы записать ответы, чтобы взять время подумать или сравнить офферы.
Часто ситуацию, когда мы задаем вопросы называют обратным собеседованием (reverse interview) — можно погуглить и найти список вопросов. Есть пара неплохих подборок: раз и два.
Не стоит задавать все вопросы из списка — проанализируйте свой предыдущий опыт и выберите важное для себя. Еще вопросы зависят от самой компании. К примеру стартапам свойственны горящие дедлайны, переработки, ограниченные финансы и неожиданные закрытия — имеет смысл спросить об оплате переработок, наличии реальных клиентов. В других компаниях стоит спросить про легаси и т. д.
В комментариях можем обсудить какие вопросы задали бы вы.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20🔥8
👨💻 Так ли тяжело найти первую работу в IT?
Часто от джунов можно услышать жалобы насколько тяжело стало найти первую работу: то на отклики не отвечают, то на собеседовании слишком много требуют. Но на самом ли деле джуны прикладывают все усилия, чтобы получить желанный оффер?
Что сделал бы я на месте джуна с текущими знаниями о поиске работы:
🟠 Проанализировал свой день и исключил все отвлекающие факторы — фокус только на поиске работы
🟠 Хорошо оформил резюме: проанализировал чужие резюме, посмотрел разборы на Ютубе и попросил ревью у эксперта
🟠 Разместил его на всевозможных площадках. Есть около десятка популярных сайтов кроме hh.ru или Хабр Карьеры, каналы в Telegram и группы в ВК, сайты крупных компаний, аутсорс и аутстафф-контор
🟠 Адаптировал сопроводительные письма под каждую вакансию
🟠 Оформил GitHub с несколькими пет-проектами, красивым README и демо (!)
🟠 Просмотрел записи интервью на Ютубе, которых там десятки
🟠 Нашел топ 50 / 100 вопросов на собеседовании в своем направлении и отточил их до совершенства
🟠 Прошел мок-интервью
🟠 Подался на стажировки, которых тоже десятки
🟠 Нашел контакты HR, менеджеров или разработчиков и написал им в личку, либо нашел еще более оригинальные способы выделиться из толпы
🟠 Записался на карьерную консультацию на Хабр Карьере, Solvery, GetMentor, Эйч (есть кто делает это бесплатно)
🟠 Нашел себе ментора
Как это обычно выглядит на самом деле:
🛑 Резюме: в графе «О себе» максимально общее описание, места работы указаны без каких-либо подробностей
🛑 Резюме размещено на одной-двух площадках
🛑 Отклики с шаблонным текстом
🛑 Пустой GitHub или проекты, сделанные на курсе под копирку (которые рекрутеры уже знают наизусть)
🛑 Не могут внятно ответить на базовые вопросы по своему стеку
IT-сфера повзрослела и не нужно сравнивать ее с ситуацией 10-летней давности, когда для устройства на работу было достаточно самых базовых знаний.
Напоследок подкину пару полезных ссылок:
🟠 Пример ревью резюме
🟠 Сайт EasyOffer. Автор проделал большую работу: собрал частые вопросы на собесах, привел ответы для многих из них + к этому проанализировал мок-интервью и дал ссылки с таймкодами, чтобы вы могли посмотреть как отвечают другие.
🛑 Подписаться на Imangazaliev Blog
Часто от джунов можно услышать жалобы насколько тяжело стало найти первую работу: то на отклики не отвечают, то на собеседовании слишком много требуют. Но на самом ли деле джуны прикладывают все усилия, чтобы получить желанный оффер?
Что сделал бы я на месте джуна с текущими знаниями о поиске работы:
Как это обычно выглядит на самом деле:
IT-сфера повзрослела и не нужно сравнивать ее с ситуацией 10-летней давности, когда для устройства на работу было достаточно самых базовых знаний.
Напоследок подкину пару полезных ссылок:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍38❤8🔥8
السلام عليكم ورحمة الله وبركاته
Поздравляю всех мусульман с праздником 'Ид аль-Адха!
تقبل الله منا ومنكم
Поздравляю всех мусульман с праздником 'Ид аль-Адха!
تقبل الله منا ومنكم
❤30❤🔥5👍2🔥2😎2
🗓 Квартальное планирование
На этой неделе у нас в Яндекс 360 прошло очередное планирование. На нем примерно 150 человек и 20 команд пытаются понять, что они будут делать следующие три месяца. Процесс сложный, немного выматывающий, но очень интересный.
🗂 Сбор бэклога и капасити
Примерно за 2 недели до планирования начинает формироваться бэклог — список задач, которые мы потенциально можем взять. Задачи приносят продакт, техлид и другие команды. Плюс к этому часть задач можем переехать с предыдущего квартала.
Чтобы не забивать на техническое развитие, в бэклоге должно быть определенное соотношение продуктовых и технических задач.
Каждую задачу нужно оценить в днях дизайна, разработки и тестирования. Точность оценки зависит от степени проработки задачи — где-то уже есть дизайн и описание API, а где-то только тех. задание.
Еще у команды есть ограниченные ресурсы дизайна, разработки и тестирования. Для них рассчитывается капасити (емкость) с учетом отпусков, дежурств, созвонов и т. д. Объем бэклога больше, чем команда реально способна переварить — просто потому что часть задач может отвалиться на следующих этапах.
🤝 Согласование бэклогов
Когда бэклоги команд сформированы, начинается самое интересное — нужно согласовать их друг с другом. Происходит это на общем созвоне, где десятки курсоров бегают по доске в Miro и раскладывают стикеры на табличке со спринтами (скрин выше). У каждой команды своя комната в зуме — по ним можно ходить и разруливать связанные задачи.
Кроме задач прописываются риски — факторы, которые влияют на выполнение задачи. У каждого риска есть причины, последствия и возможные решения. К примеру, это может быть нехватка каких-то ресурсов, из-за чего могут поехать сроки и команда не уложится дедлайн. Для такого случая можно придумать разные решения — нанять новых людей, взять на время из других команд, взять аутстафф, изменить ТЗ — и у каждого такого решения есть свои плюсы и минусы.
В финале команды представляют свои планы стейкхолдерам, получают фидбек и могут скорректировать их по этому фидбеку.
🎯 Удается ли уложиться в сроки?
Квартал состоит примерно 6 спринтов, из которых планируется в норме только 5. Шестой спринт нужен для того, чтобы добить хвосты и подготовиться к следующему планированию.
Часть задач так или иначе съезжает на следующий квартал, либо целиком, либо в виде доработок, но с каждым разом процесс совершенствуется и, надеюсь, попадание будет более точным.
Например, в первом квартале мы допустили ошибку, запланировав на меня задачи наравне с другими разработчиками, из-за чего мне не удалось уделить достаточно времени найму и работой над процессами. Во втором квартале мы это пофиксили, благодаря чему удалось нанять троих разработчиков и немного улучшить процессы.
Также теперь мы чуть раньше начинаем проработку задач, запланированных на квартал — сразу после планирования я смотрю какие вопросы можно решить в самом начале, чтобы потом это не стало блокером — согласовать контракты API, доступы и т. д.
Если интересна тема, можно погуглить про PI-планирование и Scaled Agile Framework (SAFe).
🛑 Подписаться на Imangazaliev Blog
На этой неделе у нас в Яндекс 360 прошло очередное планирование. На нем примерно 150 человек и 20 команд пытаются понять, что они будут делать следующие три месяца. Процесс сложный, немного выматывающий, но очень интересный.
🗂 Сбор бэклога и капасити
Примерно за 2 недели до планирования начинает формироваться бэклог — список задач, которые мы потенциально можем взять. Задачи приносят продакт, техлид и другие команды. Плюс к этому часть задач можем переехать с предыдущего квартала.
Чтобы не забивать на техническое развитие, в бэклоге должно быть определенное соотношение продуктовых и технических задач.
Каждую задачу нужно оценить в днях дизайна, разработки и тестирования. Точность оценки зависит от степени проработки задачи — где-то уже есть дизайн и описание API, а где-то только тех. задание.
Еще у команды есть ограниченные ресурсы дизайна, разработки и тестирования. Для них рассчитывается капасити (емкость) с учетом отпусков, дежурств, созвонов и т. д. Объем бэклога больше, чем команда реально способна переварить — просто потому что часть задач может отвалиться на следующих этапах.
🤝 Согласование бэклогов
Когда бэклоги команд сформированы, начинается самое интересное — нужно согласовать их друг с другом. Происходит это на общем созвоне, где десятки курсоров бегают по доске в Miro и раскладывают стикеры на табличке со спринтами (скрин выше). У каждой команды своя комната в зуме — по ним можно ходить и разруливать связанные задачи.
Кроме задач прописываются риски — факторы, которые влияют на выполнение задачи. У каждого риска есть причины, последствия и возможные решения. К примеру, это может быть нехватка каких-то ресурсов, из-за чего могут поехать сроки и команда не уложится дедлайн. Для такого случая можно придумать разные решения — нанять новых людей, взять на время из других команд, взять аутстафф, изменить ТЗ — и у каждого такого решения есть свои плюсы и минусы.
В финале команды представляют свои планы стейкхолдерам, получают фидбек и могут скорректировать их по этому фидбеку.
🎯 Удается ли уложиться в сроки?
Квартал состоит примерно 6 спринтов, из которых планируется в норме только 5. Шестой спринт нужен для того, чтобы добить хвосты и подготовиться к следующему планированию.
Часть задач так или иначе съезжает на следующий квартал, либо целиком, либо в виде доработок, но с каждым разом процесс совершенствуется и, надеюсь, попадание будет более точным.
Например, в первом квартале мы допустили ошибку, запланировав на меня задачи наравне с другими разработчиками, из-за чего мне не удалось уделить достаточно времени найму и работой над процессами. Во втором квартале мы это пофиксили, благодаря чему удалось нанять троих разработчиков и немного улучшить процессы.
Также теперь мы чуть раньше начинаем проработку задач, запланированных на квартал — сразу после планирования я смотрю какие вопросы можно решить в самом начале, чтобы потом это не стало блокером — согласовать контракты API, доступы и т. д.
Если интересна тема, можно погуглить про PI-планирование и Scaled Agile Framework (SAFe).
Please open Telegram to view this post
VIEW IN TELEGRAM
👍25🔥8❤6🤔1