UPDATED! Яндекс:нагр.тестирование, Linux (Москва)

Хорошие спецы по тестированию уже пристроены и чтобы их переманить надо предложить лучшие условия.

Или таких специалистов просто нет на рынке? Как бы вы исключали такую гипотезу, поделитесь опытом?

А я думал, здесь форум по разработческим вопросам, а не по КЗОТу и налоговому законодательству. Ведь уже объяснили коллеги, что фактически налоги перечисляет компания, но формально считается, что они входят в оклад.

Данный раздел форума - о работе, поэтому все такие моменты лучше сразу уточнить.

Вы же спросили, какой смысл называть суммы до налога. Смысл в том, что (а) мы белая компания, и в трудовом договоре фигурируют именно суммы до исчисления подоходного налога; (б) подоходный налог для нерезидентов какое-то время больше, чем для резидентов -- и мы фиксируем сумму до налогов.

Про а) - согласен, там, конечно, д.б. "грязная" з/плата, про б) - если Вы, конечно, берете нерезидентов, то тогда понятно у них другие несколько налоги.

Ну и дискуссию можно закрыть на тему налогов, так как понятно, что Вы хотели сказать и понятно, что я имел в виду.

Или таких специалистов просто нет на рынке? Как бы вы исключали такую гипотезу, поделитесь опытом?

Ну наврядли прямо совсем нет таких, хотя их скорее всего действительно немного (хотя одного я знаю лично, например). Но ведь есть специалисты в области просто нагрузочного тестирования, которые достаточно легко смогут переключится на вашу специфику.
Кроме того, много QAев используют нагрузочное тестирование как один из видов тестирования, входящий в общий цикл тестирования продукта, и тоже в курсе проблем и вполне могут вам подойти как специалисты среднего уровня.

И уж совсем оффтопик - ситуация на рынке труда IT специалистов в Москве не в пользу работодателей. Компаний много, они растут и требуют много специалистов, ну а их просто физически столько нет. Ну а из регионов поток тоже иссякает с ростом з/плат там.

Забавно, но я думал что QA должен заниматся вопросами
связаными с изучением необходимости нагрузочного
тестирования и порядка проведения его, а не непосредственно
нагрузочным тестированием.

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

Забавно, но я думал что QA должен заниматся вопросами
связаными с изучением необходимости нагрузочного
тестирования и порядка проведения его, а не непосредственно
нагрузочным тестированием.

Мы все глядим в Наполеоны.

Мы все глядим в Наполеоны.

Плох тот генерал, что быв солдатом не умел рыть окопы

Забавно, но я думал что QA должен заниматся вопросами
связаными с изучением необходимости нагрузочного
тестирования и порядка проведения его, а не непосредственно
нагрузочным тестированием.

Хм, а интересно, а кто же должен заниматься тестированием как не QA/тестировщики?

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

Ну не согласен. Конечно, студенты м.б. тестерами без опыта, в задачи которых можно поставить запуск тест кейзов и несложное ручное тестирование. Более опытные QA должны знать язык, на котором пишется продукт, один или несколько языков для разработки тест кейзов автоматизированного тестирования, один и несколько языков для разработки специфических тестов (обычно это Perl, Phyton etc). Поэтому обычно хороший QA это бывший Dev с особым складом ума.

Хм, а интересно, а кто же должен заниматься тестированием как не QA/тестировщики?

Формализацией процесса QA, реализацией соглассно процессу тестировщики

Ну не согласен. Конечно, студенты м.б. тестерами без опыта, в задачи которых можно поставить запуск тест кейзов и несложное ручное тестирование. Более опытные QA должны знать язык, на котором пишется продукт, один или несколько языков для разработки тест кейзов автоматизированного тестирования, один и несколько языков для разработки специфических тестов (обычно это Perl, Phyton etc). Поэтому обычно хороший QA это бывший Dev с особым складом ума.

Чтобы бывший девелопер перешел в QA у него действительно болжен быть особый скалд
ума, либо он должен стать прожект менеджером и формализовывать не только процесс
разработки но и тестирования. Для того чтобы девелопер стал тестировщиком .... ну
вобщем не девелопер и был =)

Но с другой стороны опыт программирования очень, очень полезен. Во первых,это
конечно автоматизация. Здесь достаточно знание хотя бы одного скриптового
языка (я не говорю про методологию автоматицации, 90% кто автоматизируют,
автоматизируюит свои руки, причем, опять же, даже последнее достуно не всем)
Во вторых понимание принципов работы SW в целом, что позваляет тестировать
более осмысленно (не важно ручками или скриптами)

Язык и ТестТул - это руки, руки приставленные к дурной голове будут еще беспомощнее
чем тестируемое приложние.

Хм, а интересно, а кто же должен заниматься тестированием как не QA/тестировщики?

Формализацией процесса QA, реализацией соглассно процессу тестировщики

В общем случае, тестировщики входят в QA департамент, поэтому деление здесь весьма и весьма условно.

В общем случае, тестировщики входят в QA департамент, поэтому деление здесь весьма и весьма условно.

Условно исходя из культуры IT в стране, бывает так что тестировщики еще и саппортом
занимаются....

В общем случае, тестировщики входят в QA департамент, поэтому деление здесь весьма и весьма условно.

В общем случае тестировщики входят в проектную группу и подчиняются ПМ-у, так как никакого выделенного подразделения тестирования попросту нет, не то что QA (да что там QA, SEPG и то редкость).

В общем случае тестировщики входят в проектную группу и подчиняются ПМ-у, так как никакого выделенного подразделения тестирования попросту нет, не то что QA (да что там QA, SEPG и то редкость).

Ну это в варианте когда нет QA отдела. Просто по идеологии тестеры ближе к QA, чем к девелопменту. И с нынешним развитием средств автомат. тестирования необходимость в "чистых" тестерах уменьшается (IMHO) и при необходимости это можно возложить на QA девелоперов.

(По этой вакансии повышен оклад и уточнены некоторые условия -- 18.05.2007)

======

• Какую среднесуточную нагрузку выдержит новый интернет-сервис Яндекса?
• К каким всплескам посещаемости он должен быть готов, чтобы пользователь ничего не заметил?
• Через сколько месяцев (или кварталов) нужно менять архитектуру сервиса при текущем росте посещаемости?
• Если сервис выдерживает нагрузку N на одном лабораторном сервере, сколько он выдержит на боевом кластере, где <крутится> ещё десятком других сервисов?

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

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

Перспектива тоже есть: с самого начала нужна большая инициатива и самодвижимость; через 1-1.5 года вполне реально возглавить собственную группу.

Начальная зарплата: 50 тыс. руб для начинающего/стажёра; 58 тыс. для хорошего специалиста; 68 тыс. руб для действительно сильного кандидата (суммы до вычета налогов). Зарплата может пересматриваться хоть каждый квартал. Квартальная премия платится по результатам работы (в случае запусков проектов может достигать до 1 месячного оклада в квартал).

Прочие блага: оплата технической литературы; рабочее место -- десктоп с двумя 19" TFT-мониторами, либо ноутбук + 19" монитор.

Корпоративная жилищная программа; медстраховка; бесплатные обеды; корп.
условия в фитнесс-центре рядом с офисом.

Работа в московском офисе (м. Курская,
http://company.yande...de/contacts.xml) на полный день, график работы в разумных пределах свободный. Удаленная работа невозможна. Испытательный срок 3 месяца, оклад тот же.
Иногородним кандидатам оплатим приезд на собеседование и можем помочь с переездом. Оформление иностранцев в принципе возможно; детали нужно обсуждать индивидуально.

Оставляйте резюме на сайте Яндекса - там же все формальные требования:
http://company.yande...ding_tester.xml

Задавать вопросы можно прямо здесь, либо на yurkennis@yandex-team.ru

а тестовое задание есть?

Теперь есть: за ссылкой "Хотите выполнить тестовое задание?" на всё той же странице вакансии: http://company.yande...ding_tester.xml

Это первый эксперимент с задачками -- просьба не слишком критиковать ;-)

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

Задачка хорошая, я такого типа но без привязки к компьютерной области, давал на собеседованиях старших тестеров: про сеть автозаправок в городе.

а тестовое задание есть?

Теперь есть: за ссылкой "Хотите выполнить тестовое задание?" на всё той же странице вакансии: http://company.yande...ding_tester.xml

Это первый эксперимент с задачками -- просьба не слишком критиковать ;-)

Кажется у Джоэла или Силивана в одной из глав посвещенных набору персонала, было про
задание вопросов требующих размышления от кандидатов. Причем главное не результат,
а желание и умение размышлять.

матёрый специалист в нагрузочном тестировании web-приложений

Мне кажется, что справедливо было бы исключить одно из трёх выделенных италиком слов. :) "Чистые" массовые вёб-приложения с html-ным передом, с не особо транзакционным задом - это не та задача, на которой можно заматереть в нагрузочном тестировании, ИМХО. Просто хотя бы из-за достаточно популяризованного протокола и понятности предметной области.

Ну отчего же, вполне есть примеры -- возьмите ту же Goranka Bjedov, вполне себе прикладной специалист в этой узкой области:
http://www.google.co...nce-Testing.pdf
http://video.google....978643577501895

Это её презентация на лондонской конференции по автоматизации тестирования, сентябрь 2006 года.

Кажется  у Джоэла или Силивана в одной из глав посвещенных набору персонала, было про
задание вопросов требующих размышления от кандидатов. Причем главное не результат,
а желание и умение размышлять.

Такие задачки мы давно практикуем, особенно на разработческих вакансиях, где рынок позволяет довольно хорошо поднимать планку и по problem-solving-вообще в том числе.

возьмите ту же Goranka Bjedov

Я смотрел это выступление на видео раньше, и, насколько я помню, там упоминался предыдущий опыт в телекоме. Кроме того, мне показалось, я привёл агрументы в поддержку своего мнения о не особой перспективности специализации в нагрузочном тестировании решений базирующихся на LAMP, если смотреть с точки зрения профессионального роста. У меня есть и ещё, если хотите, я свои конкурентные преимущества буду отстаивать до конца. :)

http://company.yande...ding_tester.xml

Это первый эксперимент с задачками -- просьба не слишком критиковать ;-)

А со ссылками какой эксперимент? :)

Чисто для поинтересоваться, открываю ссылку в новом окне (я их все в новых окнах открываю) - нет тестового задания.
Оказалось надо просто кликать.

И кстати, тоже предлагаю задачку:
А и Б сидели на трубе (канале, информационном), А упало Б пропало, что осталось на трубе?
(шуточные задачки тоже должны быть, потому как здоровое чувство юмора в требованиях)

возьмите ту же Goranka Bjedov

Я смотрел это выступление на видео раньше, и, насколько я помню, там упоминался предыдущий опыт в телекоме.

Горанка работала раньше в AT&T, но вся презентация про опыт Google'а. На AT&T ссылаются разве что короткие устные ремарки в одном месте, не более того. Все проблемы, о которых она рассказывает, есть и в Google, и в Яндексе -- тут телеком совсем ни при чём.

Кроме того, мне показалось, я привёл агрументы в поддержку своего мнения о не особой перспективности специализации в нагрузочном тестировании решений базирующихся на LAMP

Ну какой, скажите на милость, LAMP в Веб-Почте Яндекса., где даже Oracle дохнет под нагрузкой даже на метаданных о письмах, не то что на хранении самих писем? Или на Маркете..
Или Карты . с их временем отрисовки и Маркет с глубокой переработкой данных. Упомянул бы ещё Фотки, но у тех пока аудитория далека от проектных цифр.
Про кастомную морду, которая отрисовывается, если не ошибаюсь, вообще без хождений в базу, я не говорю.

...если смотреть с точки зрения профессионального роста. У меня есть и ещё, если хотите, я свои конкурентные преимущества буду отстаивать до конца. :)

То есть строить тестовый стенд для кластера из сотен машин, где только разных типов машин (ролей) больше полудюжины -- для вас пройденный этап? И смасштабировать цифры по нагрузке от такого стенда до боевого кластера -- плёвое дело? И подготовить user-generated content боевых объёмов задолго до запуска социального сервиса не составляет никакого труда? Снимаю шляпу.

Да, если вы ещё с нами -- посмотрите вводный рассказ об XScript'е, он изрядно проясняет, в какой архитектуре мы живём на большинстве сервисов: http://www.rit2007.r....obolenskiy.avi