Здравствуйте, vyach, Вы писали:

V>Ну и товарищи инсайдеры, а как оно вообще там работается? Стоит ли менять Sr.SDE Intel здесь (РФ) на SDET Microsoft там (Франция) в случае чего? Как там цены, как зряплаты, как с иммиграцией вообще дела обстоят?

Так как это Франция, то я думаю, серьезной девелоперской работы там не будет. В MS product development делают либо в Redmond, либо в Китае, Индии или сейчас еще что-то в Канаде. Даже элементарно зайди на https://careers.microsoft.com/Search.aspx и поищи позиции типа "Software Engineering: Development" во Франции. Находятся всего 2 (две).

Никаких приемуществ для иммиграции в Америку из другой страны, если работаешь в MS, нет. Если ты хочешь в какую-нибудь другую группу внутри MS, то во первых там такая политика, что нужно год в одной группе проработать, если тебя только наняли. Во-вторых, интервью в другую группу ты будешь проходить практически как external hire, если группа за пределами Франции. Но есть приемущество в том, что тебе будет доступна внутренняя база данных по позициям.

Если ты сейчас работаешь на Интел, я бы попытался в Интеле по внутренним каналам поискать девелоперские позиции в Америке.

Еще такой момент. Если ты очень хочешь был девелопером, а не SDET, и ты четко выразишь своё намерение, когда будешь интервьюироваться во Франции, то тебе могут не предложить позицию SDET. Есть такое негласное правило, что если работодатель чувствует, что человек может отклонить предложение, то предложения вообще не будет. Но, если ты очень хорошо пройдешь интервью, то они информацию о тебе зашлют в Redmond, и тобой могут заинтересоваться уже от туда.

Полезно также иметь знакомства с людьми, которые уже работают в MS. Тогда они могут сделать тебе referral.

Здравствуйте, SergeyT., Вы писали:

ST>Есть пара интересных статей, которые описывают, что есть SDET и сравнивают эту позицию с другими.

Я работал в MS в течении некоторого времени в роли SDE, поэтому могу внести свою лепту.

Принципиальное различие SDE и SDET заключается в том, что SDE занимаются разработкой программного продукта, а SDET занимаются тестированием этого программного продукта. Из этого вытекают все остальные различия. Как например, для SDE характерны следующие вещи:

* прямой вклад в разработку продукта. SDE может при желании и наличии времени повлиять на любой аспект разработки.
* строгий контроль кода, обязательные code review, рассылаемые всем (иногда даже и SDET).
* дизайн перед написанием кода, SDE постоянно пишут дизайн документы и устраивают для них review.
* юнит тесты (или если команда следует TDD, то тесты вперед. Но это не характерно в MS, иначе SDET остались бы без работы .)
* SDE отлаживают продукт и фиксят баги, которые находят SDET. Обычно в конце каждого milestone выделяется некоторое время специально для фиксов багов, которые накапливаются пока SDE занимается написанием нового кода.
* коллективно SDE называются словом "dev", а SDET называются словом "test" (например, "dev organization/process/goals/code" и "test organization/process/goals/code").

Для SDET характерны будут следующие вещи:

* нет прямого влияния на продукт.
* продукт работы SDET это либо тесты к продукту, либо инфраструктура для тестирования.
* код SDET живет отдельно от кода продукта (разные ветки в репозитории). Характерна ситуация, когда SDET сабмитят все подряд, включая бинарники, и создают dependency mess. Поэтому девелоперы не дают им сабмитить в основную ветку.
* code review возможно есть. Но качество кода ниже, чем у кода продукта. Во всяком случае, я никогда не видел и не принимал участия в code review для SDET людей.
* дизайн процесс отсутствует как таковой. SDET не пишут дизайн документов.
* SDET пишут test plan документы, где они описывают, что и как они собираются тестировать.
* основная цель и результат работы SDET это баги. Чем больше багов нашел и открыл, тем лучше. Код, который пишут SDET рассматривается как средство для достижения основной цели, багов.
* SDET в большинстве своем в основном коде продукта разбираются плохо, потому что это не нужно им для основной работы. Когда SDET находит баг, он практически никогда не может сказать, где в коде продукта находится этот баг. Что и логично, потому как иначе они бы сами начали фиксить баги. Если же такое начинает происходить с отдельно взятым SDET, то он постепенно перетекает в роль SDE, о чем подробнее ниже.

ST>Интересно, откуда информация о том, что тестеры затем становятся девелоперами?

Да, такое бывает. SDET может начать интересоваться продуктом, разбираться в коде продукта, девелоперов "доставать" и, вообще, тусоваться побольше с девелоперами. В таком случае, когда в команде девелоперов открывается позиция, то SDET может интервьюироваться на нее наравне со всеми остальными. А так как человек уже знакомый среди девелоперов, шансы получить эту позицию у него очень большие. Я видел несколько таких случаев, кода SDET начинали сечь код продукта и в конце концов становились SDE в той же группе.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, WeCom, Вы писали:

WC>>Это точно. С другой стороны, мне кажется, позитивных историй все таки больше.

IT>Куль! Но вот только почему от "позитивности" так сильно прёт индусятиной?

Я не знаю. Я не замечал, чтобы мои успешные соотечественники, как то _специфически_ неприятно пахли.

Здравствуйте, alexeiz, Вы писали:

A>А бывает и другое. Попал на SDET невысокого уровня в каннадское отделение майкрософта один человек, у которого работа раньше было гораздо интереснее чем SDET. Потыкался, помыкался он там, с людьми поговорил. Выяснил, что работа будет примитивная тестерная на неопределенное будущее. Его manager в Редмонде, кстати. В другую группу переместиться нельзя. Для тех, кто только нанялся в компанию, нужно год проработать в одной группе, чтобы потом получить разрешение на интервью в другую. В MS в то время установили также обширный hiring freeze, т.е. очень мало групп нанимало из других групп майкрософта (хотя они могли нанимать извне). И потом из Vancouver в Redmond не так то уж и просто перейти.

A>Человек захотел уйти. Но и это было непросто. Майкрософт, требует чтобы ему возвратили деньги за оплаченный переезд. (В контракте написано, что если уходишь раньше какого-то срока, деньги обязан возвратить.) Да еще и переезд обратно за свои, естественно. Но потом он, по-моему, как то все-таки договорился с менеджером. Так что в конце концов он на этом предприятии больше потерял, чем заработал.

Бывает по всякому.
Как я понял, именно эту историю вспомнил Денис и в общем то на это я и отвечал — некоторые "расстраиваются", а некоторые успешно выходят из не менее сложной ситуации.

Здравствуйте, alexeiz, Вы писали:


A>Человек захотел уйти. Но и это было непросто. Майкрософт, требует чтобы ему возвратили деньги за оплаченный переезд. (В контракте написано, что если уходишь раньше какого-то срока, деньги обязан возвратить.) Да еще и переезд обратно за свои, естественно. Но потом он, по-моему, как то все-таки договорился с менеджером. Так что в конце концов он на этом предприятии больше потерял, чем заработал.

Насколько я в курсе в этом случае человек не пытался делать то, про что говорит WeCom. Родина знала только взгляд с одной стороны, который в данном случае не был репрезентативным. Менеджер был скорее всего прав. Зато знаю примеры людей, которые прошли по пути описываемому WeCom и очень довольных в настроящий момент времени (хотя вначале настоение было скорее грустным).

Здравствуйте, alexeiz, Вы писали:

A>Принципиальное различие SDE и SDET заключается в том, что SDE занимаются разработкой программного продукта, а SDET занимаются тестированием этого программного продукта. Из этого вытекают все остальные различия.

Это точно!

Я ниже добавлю свои пять копеек

A>Как например, для SDE характерны следующие вещи:

A>* прямой вклад в разработку продукта. SDE может при желании и наличии времени повлиять на любой аспект разработки.
Да. Единственное, надо учитывать, что какую-то новую (кульную/любимую) технологию может быть в продукт впихнуть от сложно до практически невозможно.

A>* строгий контроль кода, обязательные code review, рассылаемые всем (иногда даже и SDET).
Здесь "строгость" и необходимость рассылки _всем_ будет зависеть от группы. Хотя конечно же везде чем ближе к релизу, тем строже контроль.

A>* дизайн перед написанием кода, SDE постоянно пишут дизайн документы и устраивают для них review.
Так уж и постоянно!? Еще есть PM'ы — вот у тех бумаготворчество — это основная деятельность.

A>* юнит тесты (или если команда следует TDD, то тесты вперед. Но это не характерно в MS, иначе SDET остались бы без работы .)
В целом да. В разных группах философия юнит тестирования может различаться.

A>* SDE отлаживают продукт и фиксят баги, которые находят SDET. Обычно в конце каждого milestone выделяется некоторое время специально для фиксов багов, которые накапливаются пока SDE занимается написанием нового кода.
A>* коллективно SDE называются словом "dev", а SDET называются словом "test" (например, "dev organization/process/goals/code" и "test organization/process/goals/code").
Это да.
* Надо добавить, что SDE еще учавствуют в сопровождении продукта (может быть и достаточно много лет). Зависит от группы. У кастомера случается баг. Девелоперу требуется в максимально краткий срок исследовать проблему и предложить решение (workaround или fix).

A>Для SDET характерны будут следующие вещи:

A>* нет прямого влияния на продукт.
Да. Но зато вот здесь свободы в использовании новейших технологий/инструментов на порядки больше чем у SDE.

A>* продукт работы SDET это либо тесты к продукту, либо инфраструктура для тестирования.
Да.
A>* код SDET живет отдельно от кода продукта (разные ветки в репозитории). Характерна ситуация, когда SDET сабмитят все подряд, включая бинарники, и создают dependency mess. Поэтому девелоперы не дают им сабмитить в основную ветку.
Лучше сказать, что SDET код не включается в билд продукта. То есть располагаться они могут рядом и даже собираться совместно при полном билде, но собараться так, что код теста не оказывает влияние на компоненты продукта.

A>* code review возможно есть. Но качество кода ниже, чем у кода продукта. Во всяком случае, я никогда не видел и не принимал участия в code review для SDET людей.
Тут я бы сказал, что критерии качества кода другие. Ведь по сути качественно то, что хорошо выполняет свои функции, в частности поурытие кода продукта тестами будет важнее, чем сопровождаемость/расширяемость/эффективность кода теста. Девелоперы поменяли код продукта, тестерам надо быстро добавить новые тесты, при этом чистить неактуальный код не так важно. В итоге с девелоперкими критериями, качество кода теста конечно же ниже.

A>* дизайн процесс отсутствует как таковой. SDET не пишут дизайн документов.
A>* SDET пишут test plan документы, где они описывают, что и как они собираются тестировать.
Да.

A>* основная цель и результат работы SDET это баги. Чем больше багов нашел и открыл, тем лучше. Код, который пишут SDET рассматривается как средство для достижения основной цели, багов.
Все таки нахождение багов — это само по себе средство. Цель — продукт к заданному сроку удовлетворяет заданным критериям качества, сценарии работают, test pass успешно пройден. Я это к тому, что не всякие баги будут полезны (пойдут в зачет), особенно ближе к релизу.
Мне кажется SDET в такой же мере мог бы написать "Цель SDE — нахерачить как можно больше кода", что было бы в такой же степени верным, как и твое замечание

A>* SDET в большинстве своем в основном коде продукта разбираются плохо, потому что это не нужно им для основной работы.
Да, есть такая особенность. По моему опыту девелоперу чаше приходится заглядывать в код теста, чем наоборот. С другой стороны, есть некоторые виды тестов которые предполагают достаточно хорошее ориентирование в коде продукта, как например, для отлова всяких там deadlocks или race conditions. Но это редкие случаи.

A>Когда SDET находит баг, он практически никогда не может сказать, где в коде продукта находится этот баг. Что и логично, потому как иначе они бы сами начали фиксить баги. Если же такое начинает происходить с отдельно взятым SDET, то он постепенно перетекает в роль SDE, о чем подробнее ниже.
Да, хороший тестер точно описывает, как баг воспроизвести, сопровождает баг полной информацией которая поможет быстро выявить суть проблемы. Совсем хороший сразу направляет баг правильному девелоперу и может даже дать машину воспроизводящую баг (не в когда то в прошлом словившую баг, а именно воспроизводящую).
Плохой просто открывает баг "я тут чего-то делал-делал и вот эта штука перестала работать".

Здравствуйте, WeCom, Вы писали:

WC>Поздравляю!
WC>Когда обратно? Надеюсь будет время погулять по Парижу.

Спасибо. В Париже буду с утра четверга до полудня субботы, так что день на изучение достопримечательностей будет

WC>Как то рановато об этом заморачиваться. Настрой себя, что готов менять, если предложение будет стоящим и вперед — к успешному результату интервью.
WC>Дадут оффер — будет время подумать и хорошенько все взвесить.
WC>К тому же тогда вариантов уже будет больше двух.
WC>Успешного интервью!

Да я и не заморачиваюсь пока, просто интересно. В штатах был, более менее ситуацию представляю, а вот европа для меня еще не открыта. Посмотрим-с

Здравствуйте, vyach, Вы писали:

V>Спасибо. В Париже буду с утра четверга до полудня субботы, так что день на изучение достопримечательностей будет
Мне дама написала, что MS оплачивает, при необходимости, только одну ночь. Вторая, получается, за свои?

Здравствуйте, Kh_Oleg, Вы писали:

K_O>Здравствуйте, vyach, Вы писали:

V>>Спасибо. В Париже буду с утра четверга до полудня субботы, так что день на изучение достопримечательностей будет
K_O>Мне дама написала, что MS оплачивает, при необходимости, только одну ночь. Вторая, получается, за свои?

У меня такое расписание получилось потому, что из моего города прямые рейсы летают редко, так что это был единственный вариант. Так что у меня отель оплачен на 2 ночи с соотв. расходами. Всё за их счёт. Хорошо иногда жить в провинции

Здравствуйте, WeCom, Вы писали:

WC>Здравствуйте, Denis, Вы писали:

D>>кроме вас никто не решит этого. но были случаи, когда люди были _сильно_ расстроены насколько я знаю. особенно, когда был архитект в маленькой фирме, где мог принимать решения, а попал в тестеры в большую корпорацию с известной долей бюрократии. на интервью уже можно многое выяснить, слова HR лучше пропустить мимо ушей

WC>Это точно. С другой стороны, мне кажется, позитивных историй все таки больше.
WC>Да, светлые головы приезжают и попадают на позиции несколько ниже того, что они реально заслуживают. Да, более склонные к SDE получают предложение на SDET.
WC>Тем не менее они, вместо того чтобы расстраиваться, просто начинают хорошо работать.
WC>Работают упорно. Выполняют и перевыполняют "план", получают хорошие фидбэки, ревью и как результат промоушены, переходят в другие группы и/или дисциплины, улучшая тем самым как свое общее удовлетворение от работы, так и материальную составляющую оной.
WC>У каждого свой путь.

WC>PS Прошу не рассматривать вышеприведенный текст, как отрицание того, что в любом случае стоит пробовать продать свои мозги подороже (в самом общем смысле этого слова)

я согласен, я просто к тому написал, что не надо кидаться в омут "аааа Майкрософт аааа заграцница". Нужно трезво спрашивать, что предстоит делать. У меня тоже таски плавают, но для этого есть и свой проект и желание посмотреть по сторонам, когда ну совсем тухляк надо прикручивать . Еще не маловажный момент — разница в отношении себя к чему-то и начальственные. Если до этого был спец и на дуде игрец (аля архитектор, пм и дев в одном флаконе), то нужно будет через себя переступать. В МС все достаточно разделено в общем и целом. И до уровня GM будет сложно Плюс часто такие "комбайны" имеют некоторую свободу со стороны начальства, а в МС придется отчитываться и загонять себя в рамки Review. При граммотном менеджере это неочень сложно. Но не всем нужно и не все могут.

Здравствуйте, deniszb, Вы писали:

D>Здравствуйте, deniszb, Вы писали:

D>>Здравствуйте, Kh_Oleg, Вы писали:

K_O>>>Здравствуйте, vyach, Вы писали:

V>>>>Здравствуйте, Dair, Вы писали:

Зовут на 22 или 23. Я честно говоря сомневался после того как девушка попросила проспелить pointer в вопросе про линкед листы.

Здравствуйте, Dair, Вы писали:

D>Щас уже понял, что на один вопрос точно ответил неправильно (английский подвёл, не понял, про что речь).
D>Не возьмут, наверно.
D>Но было интересно

Уже ответили что нибудь?

Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Кстати, если этикеток нет, то одну из коробок можно точно вычислить за 2 или 3 выемки, а вот указать все три за известное наперед количество выемок — нельзя =)

SM>Slicer

Если этикеток нет, 1 коробка 100% вычисляется при первом вытягивании.
Из условий задачи — вытянуть вы можете либо 2 яблока и 1 апельсин, либо 2 апельсина и 1 яблоко. Вытянуть 3 яблока или 3 апельсина вы не можете, т.к. 1 коробка только с яблоками, и 1 только с апельсинами.
В первом случае коробка, откуда вытянули апельсин и есть коробка с апельсинами. Во втором случае коробка, откуда вытянули яблоко — и есть коробка с яблоками.

_>Уже ответили что нибудь?

Не взяли, нет.

Здравствуйте, deniszb, Вы писали:

D>Здравствуйте, deniszb, Вы писали:

D>>Здравствуйте, deniszb, Вы писали:

D>>>Здравствуйте, Kh_Oleg, Вы писали:

K_O>>>>Здравствуйте, vyach, Вы писали:

V>>>>>Здравствуйте, Dair, Вы писали:

D>Зовут на 22 или 23. Я честно говоря сомневался после того как девушка попросила проспелить pointer в вопросе про линкед листы.

должен лететь завтра, собеседование назначили на 19-е, но из-за извержения вулкана непонятно когда откроется аэропорт в Париже.
из MS написали, что какая-то девушка будет специально работать в выходные, чтобы смогли перенести собеседование, если не долечу.
+ написали, что собеседование, конечно, постараются перенести, но не факт, что получится.

A>А бывает и другое. Попал на SDET невысокого уровня в каннадское отделение майкрософта один человек, у которого работа раньше было гораздо интереснее чем SDET. Потыкался, помыкался он там, с людьми поговорил. Выяснил, что работа будет примитивная тестерная на неопределенное будущее. Его manager в Редмонде, кстати. В другую группу переместиться нельзя. Для тех, кто только нанялся в компанию, нужно год проработать в одной группе, чтобы потом получить разрешение на интервью в другую. В MS в то время установили также обширный hiring freeze, т.е. очень мало групп нанимало из других групп майкрософта (хотя они могли нанимать извне). И потом из Vancouver в Redmond не так то уж и просто перейти.

A>Человек захотел уйти. Но и это было непросто. Майкрософт, требует чтобы ему возвратили деньги за оплаченный переезд. (В контракте написано, что если уходишь раньше какого-то срока, деньги обязан возвратить.) Да еще и переезд обратно за свои, естественно. Но потом он, по-моему, как то все-таки договорился с менеджером. Так что в конце концов он на этом предприятии больше потерял, чем заработал.

Я думаю, что знаю, о ком вы говорите, и поверьте, не все так однозначно в этой истории

Здравствуйте, green.nsk, Вы писали:

GN>Я думаю, что знаю, о ком вы говорите, и поверьте, не все так однозначно в этой истории

я думаю о нем знает почти все русскоязычное население МС . Alexeiz, кстати, помойму вполне близко к тексту написал (если убрать все личностные эпитеты).

Здравствуйте, Denis, Вы писали:

D>Здравствуйте, green.nsk, Вы писали:

GN>>Я думаю, что знаю, о ком вы говорите, и поверьте, не все так однозначно в этой истории

D>я думаю о нем знает почти все русскоязычное население МС . Alexeiz, кстати, помойму вполне близко к тексту написал (если убрать все личностные эпитеты).

Часть просто работает (работало) из MCDC, поэтому знают немного больше

К>Цель тестирования — определить работоспособность за минимум времени:
К>1. Выключаем. Наливаем сначала холодную воду. Ожидается, что светодиод не горит. Наливаем горячую воду. Ожидается, что светодиод не горит.
К>2. Включаем. Наливаем сначала холодную воду. Ожидается, что светодиод горит. Наливаем горячую воду. Ожидается, что светодиод не горит.
К>3. Далее одно из двух:
К>- если знаем температуру, которая должна поддерживаться, то наливаем воду чуть холоднее. Ожидается, что светодиод горит. За несколько доливов доводим температуру до чуть теплее. Ожидается, что светодиод погаснет.
К>- если температуру, которая должна поддерживаться, не знаем, то можем порезвиться в бинарный поиск . Сменяя воду разной температуры, находим ту температуру, при которой светодиод гаснет.
К>4. И чуть не забыл... Нужно удостовериться, что чашка греет: пальцем там попробовать, языком, локтём, градусником .

К>Я прошёл пункт тестирования?

Как то длинно все у вас...
ответ же очевиден — берем USB градусник и....

Сегодня прилетел в Минск. Позже отпишусь подробнее, а так я прибыл на собеседование к двум часам пятницы. Таких как я набралось пять человек — один земляк из минска, из украины и карелии. на человека было по пять собеседований — три технических (комбинаторика, скл и простенький валидатор скобок) сдобренных вопросами как тестировать плюс собеседование с проджект менеджером американцем и тест менеджером (предполагаемый начальник, женщина). Эти два собеседования самые трудные для понимания какое ты произвёл впечатление IMHO. Набирать планируеться вроде бы восемь человек. Zune будет запускаться в пяти европейских странах и набраных специалистов кинут на амбразуру.