Частенько в дискуссиях на тему работы я встречаю тезисы о том, как плохо работать в том или ином проекте/компании/отрасли и т.д. И несмотря на то, что в отечественном IT в целом очень распространено нытье, многое из обсуждаемого действительно имеет место в реальности. Однако, спустя годы разработки, смены проектов, компаний и даже стека технологий, у меня выработалось понимание проблемы и ее решения с другого ракурса. Об этом и поговорим.
Тимлид – это снежинка. При детальном рассмотрении в каждой компании тимлид принимает разную форму. Где-то от него ждут только передвижения задач по доске, где-то – наймов и увольнений, а где-то просят одновременно проектировать архитектуру, ставить бизнес-цели и думать о болях пользователей продукта. На самом деле все обстоит еще сложнее. Различия встречаются не только между разными компаниями, но и даже в рамках команд, находящихся в одном офисе.
Это становится особенно заметно, когда компания сталкивается с одним из следующих вопросов: как собеседовать тимлида, как оценивать его работу, как составить ему план развития. Тимлиды тоже довольно много фрустрируют – они не понимают, насколько их текущий опыт работы останется релевантным при переходе в новую компанию, какие пробелы в знаниях и навыках существуют и как их можно заполнить. Короче говоря, куда не посмотришь, везде с тимлидами как-то сложно.
С этой проблемой столкнулись и мы со Стасом Цыгановым. Но в этот раз вместо того, чтобы обойтись простым решением текущих проблем, мы захотели подойти к вопросу фундаментальнее, собрать информацию об ожиданиях от тимлидов в разных компаниях и обобщить ее в единую общую модель. И, кажется, у нас получилось.
Сначала о том, как 5 месяцев назад я проходил собеседование на работу. Меня посоветовал друг, и прошло уже немало времени, с момента как я ответил рекрутеру. Я был поражён, как сильно весь процесс изменился за последние 5 лет.
После первичного созвона меня отправили на сторонний сайт (HackerRank), чтобы я решил три небольших задачки за 1 час. Для меня это был первый подобный опыт. Первые две задачки были простыми, но третья оказалась посложней. Когда время подошло к концу, моё решение не проходило все тесты, а только где-то 8 из 10 необходимых.
Всем привет! На Хабре можно найти множество статей о переезде в разные города и страны в поисках лучшей жизни. Вот и я решил поделиться своей историей переселения из Москвы в Томск. Да, в Сибирь. Ну это там, где 40-градусные морозы зимой, комары размером со слона летом и ручные медведи у каждого второго жителя. Сибирь. Несколько нетрадиционный путь для простого российского программиста, скажут многие, и будут правы. Обычно миграционный поток идёт в направлении столиц, а не наоборот. История о том, как я дошёл до жизни такой, довольно длинная, но, надеюсь будет интересна многим.
Я живу на периферии технологической тусовки. И на периферии в географическом смысле. А это значит, что:
Привет, меня зовут Дмитрий, мне 35 лет. Раньше я часто слышал, что программист — профессия для молодых. Тем не менее прошлым летом я получил приглашение в Яндекс и перебрался работать в Москву.
В этой статье я хотел бы затронуть вопрос, который не раз обсуждался на Хабре: насколько реально быть программистом после 35–40 лет? Не ведущим архитектором, не тимлидом, не менеджером проекта, а именно программистом? Я не согласен с мнением, что программирование — это удел молодых. Считаю его вредным и сейчас расскажу почему.
Существует несколько доводов, на которые опирается этот миф. Давайте-ка их подробно рассмотрим.
