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

DKM>Совершенно с этим не согласен.
Ещё бы ты был согласен
Ну расскажи хотя бы, какие же там технически сложные задачи доводится решать... Я вот что-то таких не припомню, прямо чтобы реально сложные были. Там другая проблема — всё нужно "вчера", и соответственно перманентный аврал. После работы приходишь домой выжатый как лимон. Однако это нифига не то, что делает хорошего программиста хорошим программистом.

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

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

B>>Зато платят.

K>Это да. Но мы же говорим про хорошего программиста
K>Там очень специфические условия работы — не всем они по душе.
А что за специфические условия работы?

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

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

S>>Здравствуйте.

S>>А можете на вскидку назвать пяток команд в MS куда, по вашему мнению, стоит пойти работать или которые можно рассматривать для старта в MS.
N>Это очень странный вопрос. Чтобы иметь возможность описать климат в пяти разных командах надо там достаточно много поработать. Отзывам людей, которые скачут с такой скоростью по командам, я бы не верил.

>> Интересует климат в команде, наличие толковых коллег и возможность работать и получать удовольствие.
N>В хорошие команды обычно не набирают неизвестно кого. Именно поэтому они хорошие. Туда либо берут внутри МС, либо таргетированно ищут людей с нужным опытом у конкурентов.

N>В случае, если вас набирают из-за границы, обычно не вы выбираете команду, а команда выбирает вас, и имеет смысл спрашивать про конкретную команду/группу в которой идет набор.
N>Про PowerBI я совсем ничего не знаю, к сожалению.

Т.е. по этой логике, я, как заграничный "неизвестно кто" в хорошую команду не попаду вероятнее всего?

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

K>Ну расскажи хотя бы, какие же там технически сложные задачи доводится решать...

Да не вопрос. Задачи, решаемые нашей группой, можно условно разделить на три группы.

Исследовательско – алгоритмические
Примеры
1) Мы знаем, как делать деньги на pro-rata exchanges, но на price-time мы деньги теряем. Разобраться почему, и придумать, как делать деньги на price-time.
2) Мы быстро накапливаем риск и из-за этого не можем торговать. Придумать и реализовать алгоритм, как избавляться от риска, чтобы в результате делать больше денег
3) Сейчас наш алгоритм работает таким образом, что мы вынуждены посылать большое количество quotes, которые нельзя задерживать. Это создает проблемы на ряде рынков. Разобраться, как изменить алгоритм таким образом, чтобы он посылал на порядок меньше quotes, при этом сведя к минимуму потери в деньгах
4) Имея базу данных trades, ticks theoretical prices etc разобраться для каждой trade кто с кем торгует, почему, с помощью какого механизма и как можно было бы поучаствовать в некоторых из этих trades, избегая другие.
5) Разобраться, почему именно мы сделали или не сделали тот или иной trade (или trades) и исправить проблему

Задачи на производительность
1) Написать алгоритм таким образом, чтобы обрабатывать и реагировать на определенные события быстрее всех в природе, при этом, не упрощая его до такой степени, когда из-за излишней простоты начинаешь пропускать хорошие trades или делать плохие.
2) Редуцировать зашкаливающее-огромное количество market data ticks во время пиковых нагрузок до приемлемого количества, при этом не теряя важной информации, и быстро отправить результат на обработку дальше
3) Иметь возможность сохранить все это зашкаливающее-огромное количество market data ticks для последующего анализа, не теряя ни одного из них.
4) Разобраться, почему мы имеем провалы в производительности в определенных сценариях и исправить проблему

Задачи на инфраструктуру
1) Написать messanging system для общения между нашими компонентами, удовлетворящую нашим требованиям производительности, и оптимизированную под нас.
2) Написать базу данных, в которую необходимо добавлять десятки терабайт в день, при этом поток данных распределен крайне неравномерно. База данных должна быть оптимизирована для чтения под наши типы запросов.
3) Проанализировать структуру и взаимодействие наших компонентов между собой, найти неэффективности, разбить/консолидировать/переместить/создать новые компоненты для устранения неэффективностей.

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

K> Там другая проблема — всё нужно "вчера", и соответственно перманентный аврал.

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

Лично я прихожу в 9, ухожу в 6, правда с утра логинюсь на работу и проверяю, что система поднимается нормально. Занимает 5 минут, если все ок (так бывает в основном). Если есть проблемы, чаще всего они решаются или митигируются за 15-20 минут.

K> После работы приходишь домой выжатый как лимон

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

В Микрософте я начал думать, что это ощущение ушло навсегда. И вот работа в финансах вернула мне его.

K> Однако это нифига не то, что делает хорошего программиста хорошим программистом.
А что делает хорошего программиста хорошим программистом?

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


N>>В случае, если вас набирают из-за границы, обычно не вы выбираете команду, а команда выбирает вас, и имеет смысл спрашивать про конкретную команду/группу в которой идет набор.
N>>Про PowerBI я совсем ничего не знаю, к сожалению.

pkl>Т.е. по этой логике, я, как заграничный "неизвестно кто" в хорошую команду не попаду вероятнее всего?
Вы вполне можете попасть в хорошую команду, если она будет набирать за границей. Не все хорошие команды активно набирают людей за границей. Не все команды, которые набирают за границей, хорошие. Не все они плохие.

Я просто хотел подчеркнуть, что при переезде выбора команд обычно мало или нет совсем.
Я бы рекомендовал соглашаться, а через год-полтора на месте разобраться, в какой команде вам больше всего нравится. Это риск и серьезное жизненное решение, стоит его хорошо обдумать. Можете еще попытаться найти инсайдеров из команд, которые прямо сейчас набирают (насколько я знаю, набирает сейчас как минимум несколько команд из online services и Azure, тут на RSDN были русские люди, постившие вакансии — поищите)

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

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

N>>В случае, если вас набирают из-за границы, обычно не вы выбираете команду, а команда выбирает вас, и имеет смысл спрашивать про конкретную команду/группу в которой идет набор.
N>>Про PowerBI я совсем ничего не знаю, к сожалению.

S>скажите пожалуйста может вы слышали/видели что то хорошее про MS SQL team
Я знаю некоторых программистов оттуда, они производят впечатление очень хороших профессионалов в своей области (базы данных вообще и SQL Server в частности). Это товарищи, которым 40+ лет и у них 15-20 лет опыта работы в МС.
Но "SQL team" это несколько разных команд и надо знать точно, куда ищут — в разных группах очень разные задачи.

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

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

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

N>В хорошие команды обычно не набирают неизвестно кого. Именно поэтому они хорошие. Туда либо берут внутри МС, либо таргетированно ищут людей с нужным опытом у конкурентов.
Логично. А кстати, есть какое-то ограничение на то сколько нужно проработать в команде прежде чем можно будет ее поменять?

N>В случае, если вас набирают из-за границы, обычно не вы выбираете команду, а команда выбирает вас, и имеет смысл спрашивать про конкретную команду/группу в которой идет набор.
N>Про PowerBI я совсем ничего не знаю, к сожалению.

Скажем так у меня по какой-то причине подвисли собеседования в одну команду и поэтому решил и через careers еще отправить свое резюме.

Здравствуйте, Isscander, Вы писали:
I> — Azure считается сильной командой. Можете много чему научиться.
WA уже настолько большой, что ничем уже не считается, там уже больше 4K человек.

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

D>Здравствуйте, Isscander, Вы писали:
I>> — Azure считается сильной командой. Можете много чему научиться.
D>WA уже настолько большой, что ничем уже не считается, там уже больше 4K человек.
Что такое WA и при чём тут его размер?

pkl>Почему бы не пожаловаться наверх про бардак?

Одно из самых сильных впечатлений после перехода из МС в Гугл было то, что я увидел как простые разработчики задают каверзные вопросы самим Ларри и Сергею (TGIF в Гугле), и не боятся что у них с карьерой что-то пойдет не так. Более того, через некоторое время видно что по этим проблемам что-то делается.

Каналов такой обратной связи много — простые email на самый верх, TGIF (каждую неделю происходит презентация каких-либо результатов с вопросами из зала/электронной доски), ежегодный опрос почти всех работников на животрепещущие вопросы (типа довольны ли вы зарплатой .

Например: ежегодный опрос показывал что недовольство зарплатой растет, в 2010 году руководство провело исследование и решило поднять зп всем на 10%.
Google Gives All Employees Surprise $1,000 Cash Bonus And 10% Raise
МС кстати тоже пришлось поднимать зарплаты в 2011, из-за такой диверсии Гугла.

Здравствуйте, pkl, Вы писали:
pkl> Что такое WA и при чём тут его размер?

Windows Azue (хотя его вроде уже просто в Azure переименовали)

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


S>Понимаю, что странный. Пока в компании или скорее даже в команде не поработаешь какое-то время врят ли сможешь составить свое мнение о ней. Потому меня интересует скорее информация, доступная на уровне разговоров в курилке или за ланчем. Хорошо тогда перефразирую вопрос. Куда точно не стоит идти?
я слышал стабильный негатив про Windows Phone.

N>>В хорошие команды обычно не набирают неизвестно кого. Именно поэтому они хорошие. Туда либо берут внутри МС, либо таргетированно ищут людей с нужным опытом у конкурентов.
S>Логично. А кстати, есть какое-то ограничение на то сколько нужно проработать в команде прежде чем можно будет ее поменять?
Его официально вроде нет, но на практике нужно хотя бы одно ревью пройти. Т.е. 6-12 месяцев в зависимости от того, когда начали работу.

S>Скажем так у меня по какой-то причине подвисли собеседования в одну команду и поэтому решил и через careers еще отправить свое резюме.
Это обычно бесполезно. Резюме оттуда почти всегда попадают в /dev/null. Нужно писать лично людям, которые набирают.

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

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

DKM>Исследовательско – алгоритмические
Всё это бизнес.

DKM>Задачи на производительность
Всё это бизнес. Ну 4 с некоторой натяжкой можно считать технически сложной.

DKM>Задачи на инфраструктуру
Принимается, но часто ли ты разрабатываешь новые платформы с нуля?

DKM>Какая из вышеперечисленных задач кажется тебе тривиальной? Я имел отношение примерно к половине из вышеуказанных задач, и многие из них были полностью решены мною. С интересом послушаю твое мнение, особенно про исследовательско-алгоритмические и задачи на производительность.
Судя по твоему ответу, ты не понял, о чём я говорю. Я разделяю технически сложные задачи от сложных с точки зрения бизнеса, но (когда задача решена на уровне аналитики) относительно тривиальных технически.

DKM>Одно из преимуществ работы в команде хороших программистов состоит в том, что все неплохо представляют сложность задачи, что необходимо сделать и, примерно, сколько времени это займет.
У нас дело было не в квалификации людей, а в том, что работы было объективно много для того количества людей, которые были в команде. Ну ещё и бизнес "помогал" со своей идиотской привычкой вспоминать в последний момент о том, что нужно сделать.

DKM>Лично я прихожу в 9, ухожу в 6, правда с утра логинюсь на работу и проверяю, что система поднимается нормально. Занимает 5 минут, если все ок (так бывает в основном). Если есть проблемы, чаще всего они решаются или митигируются за 15-20 минут.
Ну значит тебе относительно повезло в том, что ты торгуешь на одной площадке. А у нас вот контора торговала на почти всех биржах мира, и потому система должна работать 24 часа в сутки. И да, приходилось порой подниматься среди ночи и разбираться, что и где упало.

DKM>Я когда был маленький, работал в одной московской конторе, занимающейся написанием виртуальных машин. Вот там действительно был перманентный аврал, но работа была настолько интересна, что я каждый день просыпался с мыслью, что как же хорошо, что уже скоро на работу и я разберусь с тем-то и тем-то.
Мне работа в финансах была интересна с бизнес-точки зрения (то есть разобраться как работает биржа, что означают все эти страшные слова типа "дериватив", "опцион", "дефолт своп" и т.д.), и в этом плане я работал с "огоньком", плюс чисто психологический момент — проверить себя "на прочность", нравилось быстро разруливать возникающие проблемы, когда счёт идёт на минуты, на ходу организовывая попавших под руку людей (многие в стрессовой ситуации просто "зависают", и без внешнего руководства неспособны помочь даже если они хорошо разбираются в сути проблемы, и в спокойной обстановке легко бы всё исправили). Это всё было круто (безо всякой иронии!), но это не является работой для хорошего программиста ИМХО, да и сил такая работа отнимала очень много.

DKM>А что делает хорошего программиста хорошим программистом?
Технический уровень задач. Вообще сейчас ИМХО техническая сложность в прикладной сфере заключается в основном в том, чтобы знать, каким именно образом скомбинировать 100500 готовых "кубиков" так, чтобы всё заработало нужным образом. То, что я считаю "реальной" технической сложностью, присутствует только в очень узких нишах.

B>Ни один не смог назвать отличие между value и reference types, ни один не смог толком объяснить что такое полиморфизм (хотя почти все примерно представляют что это такое), все назвали singleton одним из первых паттернов, но никто не смог объяснить зачем в нем может быть нужен lock и что это вообще такое, половина смутно представляет что такое generics, никто не смог толком объяснить почему в javascript функциях не стоит декларировать переменные где-то в середине, половина смутно смогла ответить что такое closure, и конечно же никто не смог ответить сколько в javascript областей видимости (visibility scopes), а так же что же такое visibility scope.
Невозможно не знать различия между типами значений и ссылочными типами. Это спрашивают на 90% собеседованиях.
Как мне кажется, разработчикам достаточно понимания, мы не лекторы красиво объяснять. Нет соответствующего навыка.
Относительно количества областей видимости, если заранее не обратить на это внимание, то никто не вспомнит все и смысла в этом нет. Достаточно понимать общие принципы.

Очевидно, что-то людей демотивировало в общении с Вами. Очевидно, никто не скажет через пять минут собеседования: "что-то мне расхотелось у вас работать".

PS Лично для меня показатель профессионализма — способность человека изъясняться на родном языке на профессиональные темы и подыскивать эквиваленты английским терминам.

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


S>>Скажем так у меня по какой-то причине подвисли собеседования в одну команду и поэтому решил и через careers еще отправить свое резюме.
N>Это обычно бесполезно. Резюме оттуда почти всегда попадают в /dev/null. Нужно писать лично людям, которые набирают.
по моему опыту реакция есть

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

N>Очевидно, что-то людей демотивировало в общении с Вами. Очевидно, никто не скажет через пять минут собеседования: "что-то мне расхотелось у вас работать".
Обожаю русские форумы за такие пассажи

N>PS Лично для меня показатель профессионализма — способность человека изъясняться на родном языке на профессиональные темы и подыскивать эквиваленты английским терминам.
Я более чем уверен, что собеседуемые были бы не против рассказать нам что-то на своем родном языке — итальянском, португальском, польском, но увы, этого было недостаточно.

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

N>подыскивать эквиваленты английским терминам.
Но зачем?

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

N>>подыскивать эквиваленты английским терминам.
CC>Но зачем?
Да потому что, цитата, "никто не вспомнит все и смысла в этом нет".

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

K>Как я и ожидал, ты путаешь технически сложные задачи со сложными с точки зрения бизнеса.
Я думаю, что для выведения дискуссии в более продуктивное русло тебе нужно:
1) Дать определение технически сложной задачи.
2) Привести примеры задач, удовлетворяющих твоему определению, которых нет в финансах, но есть в других предметных областях.

Мой опыт программирования включает достаточно широкий спектр задач от написание драйверов, программных патчей ядра винды, написания комплиляторов и высокооптимизированных функций под конкретные CPU до написания GUI и макросов на VBA. На основе своего опыта я сделал вывод, что техническая сложность задач не зависит от предметной области вообще. Любое программирование в конечном счете – это манипулирование структурами данных с помощью вызова нужных функций в правильном порядке.

Технически сложной задачу делают следующие факторы:
1) Отсутствие удобных инструментов
2) Отсутствие необходимых данных для анализа
3) Отсутствие информации о функциях и методологии их применения

Например, задача нахождения источника memory corruption технически сложна и в общем случае неразрешима, если у тебя есть только crash dump. Однако, она сводится к технически тривиальной, если есть возможность использовать какой-нибудь дебажный аллокатор и гонять программу до тех пор, пока проблема не воспроизведется (удобные инструменты)

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

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

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

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

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

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

K>Принимается, но часто ли ты разрабатываешь новые платформы с нуля?

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

K>У нас дело было не в квалификации людей, а в том, что работы было объективно много для того количества людей, которые были в команде. Ну ещё и бизнес "помогал" со своей идиотской привычкой вспоминать в последний момент о том, что нужно сделать.

У нас тоже много работы. Я точно могу найти себе работу на ближайшие лет пять. Это, однако, не означает, что я буду сидеть на работе по 24 часа в сутки, пока работа не закончится. Работа приоритезируется и выполняется в рабочее время. При появлении срочных проблем должны существовать механизмы их митигирования до тех пор, пока не наступит рабочее время. Если таких механизмов нет, хороший программист может их предложить и убедить начальство, что данные механизмы необходимо реализовать с высоким приоритетом. Если убедить начальство не удается, то начальство ставится перед фактом, что работа во внерабочее время на постоянной основе выполняться не будет, если только это не прописано в контракте и специально не оговорено. Хорошие программисты в этом смысле имеют практически неограниченный потенциал убеждения, поскольку их увольнение принесет фирме намного больше проблем, чем самому программисту.

K>Ну значит тебе относительно повезло в том, что ты торгуешь на одной площадке.
Я торгую на многих площадках, но они все в северной Америке, поэтому в этом смысле да, повезло.

DKM>Я когда был маленький, работал в одной московской конторе, занимающейся написанием виртуальных машин. Вот там действительно был перманентный аврал, но работа

Кажется, у нас есть кое-что общее...