Нам нужен релиз-инженер одной из самых важных частей поиска – веб робота. По мнению Капитана Очевидности релиз-инженер – это тот человек который интегрирует постоянные изменения команды, собирает, проверяет и выкладывает релизы системы. В нашем случае, это команда из более чем 20 человек (которая является частью команды в 200 человек, от которых тоже регулярно долетают изменения в смежных частях).
Это не значит, что вы в одиночку правите все баги за 200 человек. К вашим услугам команда тестирования, большое количество автоматизированных тестов, команда приемки качества (которая если что вас подстрахует, увидев ухудшенние качества на приборах) и бейзбольная бита(*). Кроме того, у вас нет цели зарелизить все, что было написано, сырой код надо просто выкинуть из релиза и вернуть на доработку автору.
Но все равно эта роль предполагает, что вы очень сильный разработчик со стальными я.. нервами. Т.е. как минимум, вас не пугает разбор с большим количеством чужого кода. В дополнение, у Яндекса есть некоторое отличие от других компаний в том, что помимо кода, у нас есть тонна данных. И если release engineer в «обычной» продуктовой компании, как правило, может легко собрать и протестировать систему на своем компьютере, то у нас полная её копия требует около 400 серверов. Понятно, что есть модели 1:42, но на них не всегда можно протестировать все.
Т.т.х. Зарплата на старт 100–120 тыс рублей (белая, указана до вычета налогов, пересматривается по достижениям), регулярные премии по результатам запусков. Через год работы появится возможность получения опциона. Медстраховка. Хорошее оборудование (на выбор ноут+монитор, или десктоп+2 монитора). Хороший кондиционируемый офис на м. Парк Культуры. Бесплатные обеды, чай, хороший кофе, фрукты, булочки. Оплата технической литературы (включая дорогие книжки с amazon-а). Корпоративная программа ипотечного кредитования. Иногородним кандидатам мы оплатим дорогу на собеседование и можем помочь с переездом. Гражданам других государств получим разрешение на работу в РФ.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Vzhyk, Вы писали:
>> * EULA пользования битой: пугать битой можно, бить нельзя. V>Такой битой даже обезьяну не сможешь воспитывать.
Ну как-бы программисты они сильно умнее обезьян(за всех не поручусь, но мы стараемся именно таких нанимать ;)
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
20.08.2010 17:18, Anatolix пишет: > > Ну как-бы программисты они сильно умнее обезьян(за всех не поручусь, но > мы стараемся именно таких нанимать
А бита тогда зачем?
Здравствуйте, Vzhyk, Вы писали:
V>20.08.2010 17:18, Anatolix пишет: >> >> Ну как-бы программисты они сильно умнее обезьян(за всех не поручусь, но >> мы стараемся именно таких нанимать V>А бита тогда зачем?
Это символ (c)
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A>Кроме того, у вас нет цели зарелизить все, что было написано, сырой код надо просто выкинуть из релиза и вернуть на доработку автору.
А зачем комитить сырой код в релиз? В релиз обычно переносится только протестированный QA отделом на работоспособность код, а все что не прошло через QA так и остается в песочнице до тех пор пока не заработает.
Здравствуйте, UA, Вы писали:
UA>Здравствуйте, Anatolix, Вы писали:
A>>Кроме того, у вас нет цели зарелизить все, что было написано, сырой код надо просто выкинуть из релиза и вернуть на доработку автору. UA>А зачем комитить сырой код в релиз? В релиз обычно переносится только протестированный QA отделом на работоспособность код, а все что не прошло через QA так и остается в песочнице до тех пор пока не заработает.
Есть 2 подхода:
1) Разрабатываемся в бранчах, переносим в стабильную ветку все протестированное.
2) Разрабатываемся всей толпой в одной ветке раз в месяц-два ее отщепляем и стабилизируем, а trunk продолжаем править неустанно.
У каждого есть свои достоинства и недостатки. У нас второй метод.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A> Иногородним кандидатам мы оплатим дорогу на собеседование и можем помочь с переездом. Гражданам других государств получим разрешение на работу в РФ.
Вот это интересная фраза. ЕМНИП раньше ваша фирма такого не предлагала. что-то поменялось?
Здравствуйте, superman, Вы писали:
S>Здравствуйте, Anatolix, Вы писали:
A>> Иногородним кандидатам мы оплатим дорогу на собеседование и можем помочь с переездом. Гражданам других государств получим разрешение на работу в РФ.
S>Вот это интересная фраза. ЕМНИП раньше ваша фирма такого не предлагала. что-то поменялось?
В Москве стало сложнее находить подходящих чуваков?
Здравствуйте, superman, Вы писали:
A>> Иногородним кандидатам мы оплатим дорогу на собеседование и можем помочь с переездом. Гражданам других государств получим разрешение на работу в РФ. S>Вот это интересная фраза. ЕМНИП раньше ваша фирма такого не предлагала. что-то поменялось?
Последние года 3-4 предлагает уже.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A>Есть 2 подхода: A>1) Разрабатываемся в бранчах, переносим в стабильную ветку все протестированное. A>2) Разрабатываемся всей толпой в одной ветке раз в месяц-два ее отщепляем и стабилизируем, а trunk продолжаем править неустанно.
A>У каждого есть свои достоинства и недостатки. У нас второй метод.
А есть ли где-то ещё в открытых источниках инфа — как в Яндексе вообще построен процесс SCM на разных направлениях? Мне описание выше уже дает много информации однако интересны подробности... (да, офтопик, но спросить больше негде и не у кого )
И, да, вакансия очень интересная Повторюсь (в ЖЖ откоментировал утром, это только щас увидел), иногда жалею, что живу не в Москве, потому как описанными обязанностями, почти слово-в-слово, я занимался 3 года, прям читаю и себя вижу
Яндексоидам есть смысл поспрашивать среди знакомых среди нынешних и бывших СМщиков Моторолы (питерский центр разработки), их опыт очень похож на твоё описание, особенно для тех, кто работал на мобильном направлении.
Здравствуйте, Aquary, Вы писали:
A>>Есть 2 подхода: A>>1) Разрабатываемся в бранчах, переносим в стабильную ветку все протестированное. A>>2) Разрабатываемся всей толпой в одной ветке раз в месяц-два ее отщепляем и стабилизируем, а trunk продолжаем править неустанно.
A>>У каждого есть свои достоинства и недостатки. У нас второй метод.
A>А есть ли где-то ещё в открытых источниках инфа — как в Яндексе вообще построен процесс SCM на разных направлениях? Мне описание выше уже дает много информации однако интересны подробности... (да, офтопик, но спросить больше негде и не у кого )
Сейчас боюсь, что нигде, наверное для доклада на технической конференции хорошая тема...
Если есть какой-то конкретный вопрос — спроси.
A>И, да, вакансия очень интересная Повторюсь (в ЖЖ откоментировал утром, это только щас увидел), иногда жалею, что живу не в Москве, потому как описанными обязанностями, почти слово-в-слово, я занимался 3 года, прям читаю и себя вижу
A>Яндексоидам есть смысл поспрашивать среди знакомых среди нынешних и бывших СМщиков Моторолы (питерский центр разработки), их опыт очень похож на твоё описание, особенно для тех, кто работал на мобильном направлении.
Спасибо. Попробую.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Axc, Вы писали:
Axc>Здравствуйте, denisko, Вы писали:
A>>>Все еще актуально. D>>А почему без бегимотика?
Axc>Про розового слоника — знаю. Что за бегемотик?
Исправляюсь:
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
A> Через год работы появится возможность получения опциона.
А что можно делать с опционом компании, чьи акции нигде не торгуются? Перепродать другим сотрудникам и прочим держателям?
Что будет с опционом, если человек уволится, так и не сумев воспользоваться им?
Какие опционы могут быть у российского ООО (ведь даже не ЗАО), или это все делается через какую-нибудь головную иностранную компанию?
Кто-нибудь уже воспользовался? Компания же давно существует. В конце концов, указывать верхнюю и нижнюю границу дохода в правилах форума.
Ну раз еще в 2008, то точно масса людей с опционами.
Вот и напиши верхнюю и нижнюю границу доходов, которые может дать опцион.
Про зарубежные компании плохой пример, там часто по аналогии можно представить, чего ожидать. А в российской действительности чаще банальное "процент с продаж/установок/прибыли" выгоднее и понятнее завуалированных сущностей.
BZ>яндекс был готов выйти на ipo в 2008-м, не успел чуток только afair, тогда они себя оценивали в 33 миллиона бочек нефти
Здравствуйте, modev, Вы писали:
M>Вот и напиши верхнюю и нижнюю границу доходов, которые может дать опцион.
Нижняя граница, очевидно, нуль. Верхнюю границу оценить не просто, но если предположить, что Яндекс в ближайшие несколько лет вряд ли будет стоить более 100 трлн. долларов, а Ваш опцион вряд ли превзойдет 99,8%...