Часть 1: Поворот
Часть 2: (лирическое отступление) Школа и медвуз
Часть 3: Microsoft Student Partners Germany
Часть 4: Подготовка к интервью
Часть 5: Интервью (пост1) (пост2)
Часть 6: Практика в Майкрософт Бинг в Сан-Франциско (пост1) (пост2)
Часть 7: Работа в Майкрософт Бинг изнутри (пост1) (пост2) (пост3)

Для связи используйте мой ник здесь и Гугл :)
---------

Вообще задача твоего менеджера – это стимулировать тебя работать лучше и качественнее. Это совсем не значит, что ты должен работать больше! Вовсе нет. Ты должен работать более охотно, ты должен быть сам более заинтересован в работе, чтобы, приходя на нее утром, у тебя не было необходимости раскачивать и думать «ну вот опять надо делать Х», а вечером постоянно смотреть на часы и спешить домой. И достичь этого совсем не так просто.

С определенного уровня деньги уже не являются мотиватором. Точнее, они являются отрицательным мотиватором – их отсутствие может демотивировать. Но повышение зарплаты на 10% и даже 20% уже не дает ощутимого прироста в производительности. Поэтому, собственно, менеджер часто умело задействует другие ресурсы для того, чтобы смотивироровать сотрудника на эффективную работу.

Вот несколько примеров. Мы все по образованию инженеры-программисты, то есть в дипломе стоит что-то software engineer. Один из команды захотел специализировать в области data science (чем мы то, в принципе, как команда и занимаемся – только из нас напрямую никто этому и не учился). Вместе с менеджером они выбрали подходящий курс в Стенфорде (благо он тут под боком, но там можно и онлайн), и парень вот получает там уже второй сертификат и работает очень много в проектах, где требуется нетривиальный анализ данных (data mining, machine learning и прочее).

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

Кому-то просто дали в качестве рабочего лаптопа MacBook Pro и проекты, связанные с операционной системой от «яблочной» компании, и это было уже достаточным мотиватором, чтобы человек загорелся и стал работать еще больше, чем работал.

В непростую задачу менеджера как раз и входит нахождение тех факторов, которое позволить улучшить производительность каждого отдельного разработчика и нахождение адекватных проектов для них, чтобы таким образом улучшить производительность всей команды. При этом конкретные достижений каждого сотрудника приписываются лично ему – «такой-то запрограммировал то-то» и так далее.

Достижение менеджера – это результат всей команды вместе, при этом основная компетенция менеджера – это правильное планирование и делегирование задач, создание и поддержание хорошей рабочей атмосферы в команде. Если менеджер при этом что-то сам кодит – это как если начальник автоколонны собственноручно толкает застрявшую машину: молодец, конечно, но не обязан и никто за это его не оценивает.

Поэтому отношения менеджер-сотрудник строятся совсем иначе, чем начальник-подчинённый. Эти отношения больше похожи на отношения «диспетчер-таксист» или даже «священник-прихожанин», позволяющие человеку полностью реализовывать себя, при этом сохраняя свою индивидуальность, а также постоянно расти в своей профессиональной сфере.

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

У меня был большой опыт работы в Германии на тот момент, когда я переезжал в США, и когда меня спрашивали: что же мне нравится больше в США, почему я хочу работать тут,-- я отвечал, что это в первую очередь люди.

Конечно, даже в больших компаниях не все звезды и рядовые сотрудники могут быть просто прилежными «рабочими лошадками». Но и ты тоже, особенно в начале своего пути, ничем не отличаешься от них. Хотя нет, отличаешься – у тебя даже нет еще статуса «рабочей лошадки». Его еще нужно заслужить. И постепенно ты начинаешь оглядываться вокруг и видишь, что вроде бы обычные коллеги вокруг тебя все очень индивидуальны, все тратят очень много времени чтобы быть компетентными в своей области, и чтобы делать свою работу хорошо и эффективно, каждый день, несмотря на то, что ты делал это уже недели и месяцы.

Это, казалось бы, простое испытание – просто забыть свои амбиции, свои оценки в ВУЗе, какой ты был крутой и сколько олимпиад или соревнований выиграл – и стать для начала простой «рабочей лошадкой» -- оно дается тоже не всем.

Я видел много разных историй успеха, и что удивительно, успешные люди спустя какое-то время становятся похожи друг на друга: успех как бы притягивает дальнейшие успех. Но вот путь до этого у многих отличается. Кому-то, как, например, Scott Guthrie, одна компания – это все что нужно для успеха. А кому-то, как Яну Куму (родившийся и выросший недалеко от Киева), нужно, чтобы тебя отверг Facebook (а твоего друга еще в придачу и Twitter), для того, чтобы создать собственную компанию и стать миллиардером.

=====================

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

Мне нравится американская традиция в длинных и запутанных докладах в конце формулировать кратко в виде одного предложения самый главный вывод. Этот вывод называется очень красиво take home message («сообщение, что Вам нужно взять домой»). Так вот, take home message этого длинного текста очень прост: никогда, запомните, никогда не поздно стать хозяином своей судьбы, изменить себя и начать жить так, как Ты этого хочешь и как Тебе нравится. Это – высшая свобода, которую мы можем получить в этой жизни, и нет ничего ценнее в этой жизни, чем это.

(КОНЕЦ // The End)

Я беру небольшую паузу до сентября, чтобы вернуться с постами о том, что такое современная информатика и с какого бока правильно вгрызаться в этот кусок гранита: это самый частый вопрос, который мне задают и в комментариях, и в личной переписке. Ждите. Надеюсь, вам понравится. ;-)

Часть 1: Поворот
Часть 2: (лирическое отступление) Школа и медвуз
Часть 3: Microsoft Student Partners Germany
Часть 4: Подготовка к интервью
Часть 5: Интервью (пост1) (пост2)
Часть 6: Практика в Майкрософт Бинг в Сан-Франциско (пост1) (пост2)
Часть 7: Работа в Майкрософт Бинг изнутри (пост1) (пост2) (пост3)

Для связи используйте мой ник здесь и Гугл.
---------

Если ты вынужден прийти на работу позже, сделать паузу, чтобы сходить к врачу или в какое-то учреждение, уйти пораньше, или просто хочешь сегодня работать из дома, то важно до начала рабочего дня прислать короткое письмо менеджеру и команде, где ты об этом пишешь. Объяснять причину в нашей команде не нужно, достаточно просто сказать «буду к 12 часам» или «работаю из дома, с10 до 12 буду в клинике делать прививки» и все. За все время работы никаких документальных подтверждений того, был ли я в клинике, от меня никто не просил, хотя в больнице каждый раз формально спрашивают – вам нужно подтверждение для работы – и я каждый раз его беру (раз дают).

За этой большой свободой, однако, стоит и большая ответственность. К примеру, недавно у нас администраторами было сделано некоторое изменение в групповых политиках. Это изменение привело к тому, что часть серверов перестала быть видимой в локальной сети, что привело к нарушению работы порядка 40 из 80 наших серверов. К сожалению, проблема была замечена одним и пользователей только ближе к вечеру, по крайней мере именно в 9 часов я получил письмо с проблемой. Пользователь сначала пытался решить проблему сам (он сам старший разработчик, «пользователем» для меня он является только в контексте того, что он использует нашу систему для своих задач), и он даже смог решить ее для своего компьютера, но из-за небольшого бага все-таки был вынужден обратиться ко мне, как ответственному за работу всей системы. В результате с 10 вечера (когда я добрался до компьютера и смог войти в систему) до примерно двух часов ночи, когда я написал автоматический скрипт, анализирующий проблему на каждой из наших машин и переписывающий ряд конфигураций для того, чтобы решить эту проблему, мне пришлось работать внепланово. Подобного рода проблемы случаются обычно раз в 2-3 месяца, один раз мне даже пришлось проработать всю ночь и лишь в 6 утра я смог немного поспать перед новым рабочим днем. Зато пользователи, пришедшие на работу к 8-9 утра, могли работать без проблем и практически не заметили нарушения работы системы, что длилось почти 12 часов…

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

Обычно раз в неделю менеджер неформально приходит к тебе в офис, чтобы спросить тебя о том, чем ты сейчас занимаешься и что примерно следует ожидать по итогам работы на этой неделе. Это не какое-то официальное мероприятие, и иногда оно длится просто секунд 20-30. Иногда же, бывает, ты сидишь по 4-5 часов с менеджером, защищая своё решение и обсуждая возможные за и против. При этом менеджер, если он предлагает какое-то решение, также старается технически обосновать свой выбор. Практически не бывает случаев, когда менеджер пытается навязать тебе решение без достаточного его обоснования и обоюдного согласия о том, что данное решение является лучшим. Однако даже это случается не часто, обычно предложенное тобой самим решение – если оно достаточно разумно и воплощаемо в жизнь – просто принимается без слов и критика идёт в основном деталей реализации или архитектуры.

Менеджер ни в коем случае не контролирует твою работу. То есть даже будучи на рабочем месте, ты не должен все время изображать бурную рабочую деятельность. Достаточно, чтобы ты решал поставленные перед тобой задачи в определенные сроки: то есть если задача стоит ASAP (as soon as possible), то предполагается что ты безотлагательно решаешь задачу пока е решишь. Но в большинстве случаев ты просто должен сделать что-то к концу месяца или недели. Поэтому сотрудники без проблем общаются из офиса по Скайпу с родными, совершают какие-то краткие поездки в магазин (если нужно), пишут что-то в социальные сети. Однажды я случайно открыл фейсбук (я там вообще редко бываю с работы, а тут просто ссылку прислали) и тут же зашел мой менеджер что-то обсудить. Увидев фейсбук, он сказал «а, Алекс, я не знал что ты отдыхаешь» и тут же вышел. Я даже ничего сказать не успел от неожиданности.

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

Кроме основного проекта есть возможность работать над хобби проектами. Для этого в один из дней недели (обычно вторник или среда) проходит так называемая SLC (Stay Late and Code, «останься допоздна и программируй»), где встречаются люди с хобби-проектами и вместе сидят, работая над проектами и помогая друг другу. Часто в начале таких встреч проходят короткие доклады на новые интересные темы, например, о трехмерной печати.

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

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

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

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

(Окончание в третьем посте)

Заключительная часть моей истории. Вот предыдущие части:

Часть 1: Поворот
Часть 2: (лирическое отступление) Школа и медвуз
Часть 3: Microsoft Student Partners Germany
Часть 4: Подготовка к интервью
Часть 5: Интервью (пост1) (пост2)
Часть 6: Практика в Майкрософт Бинг в Сан-Франциско (пост1) (пост2)
Часть 7: Работа в Майкрософт Бинг изнутри (пост1) (пост2) (пост3)

Для связи используйте мой ник здесь и Гугл :)
---------

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

Однако именно этот год и помог нам решить – по крайней мере отсрочить – основную проблему, а именно хорошую работу, на которой работала моя жена и которую не хотелось просто так терять. Так получилось, что незадолго до начала оформления визы, через год, у нас родился второй сын и моя жена смогла взять трехгодичный отпуск по уходу за ребенком, сохранив, таким образом, своё рабочее место на этот срок. Этот срок истекает в апреле 2016 года, то этого у нас еще есть время подумать, взвесить все и решить – хотим ли мы строить наше будущее в США или в Германии.

Все, что я описываю ниже – это лишь моё личное мнение. Это не официальная позиция компании, это не реклама (никто мне не платит за написание этого). Это просто моя попытка рассказать немного о том, как я вижу жизнь внутри компании.

Мне не очень просто рассказывать о том, как организована работа во всем Майкрософт: я работал и работаю только в одной команде (если не считать практику, которую я подробно описал раньше). В пределах большой компании работа в отдельных командах может разительно отличаться в зависимости от того, кто твой менеджер и как он представляет себе организацию работы. Это очень известный факт и есть даже такая поговорка: “You don’t quit your company, you just quit your manager" (Ты не уходишь с работы, ты лишь уходишь от своего менеджера).

Я работаю в команде, которая напрямую не связана с поиском, мы анализируем работу поисковой машины и рассчитываем различные показатели (метрики) её работы. Основная задача нашей команды – оценка удобства работы с поисковиком Bing и определение путей улучшения этой работы.

Хотя наша команда состоит на 90% из инженеров, основной продукт нашей команды – это не код, не какие-то программы и алгоритмы, а итоговые цифры оценок («метрики», metrics) и специальные страницы, где можно делать различный анализ полученных результатов (dashboards). Только небольшая часть метрик разрабатывается непосредственно нашей командой. В большинстве случаев мы предоставляем движок, позволяющий сторонним командам описывать их собственные метрики и автоматизировать их расчеты.

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

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

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

Я не знаю, как правильно расшифровать PM, кто-то говорит, что это Project Manager, кто-то Product Manager. Зачастую это человек с инженерным опытом, который предпочитает меньше кодить и больше заниматься именно развитием проекта, в частности написанием спецификаций, документаций, созданием презентаций и прочего. Обычно PM появляется в командах от определенного числа человек и только для важных проектов. В моем случае на тех проектах, где работаю я, нет никакого PM и мне приходится самому делать презентации, писать документацию и делать все остальное, что занимает времени не меньше, а даже больше чем кодинг.

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

Software Development Engineer (SDE) – один или два небольших проекта с ограниченным набором задач, с небольшими требования интеграции с другими проектами, в случае отказа кода нарушится работа твоей команды.

Software Development Engineer II (SDE II) – один-три проекта большой сложности, с требованиями к интеграции с другими продуктами и системами, с документацией и SLA, в случае проблем с проектами пострадает твоя команда и 2-3 команды, что работает с тобой.

Senior Software Development Engineer (Senior SDE) – проекты наивысшей сложности, требующие большой ответственности, быстрого реагирования, повышенные требования к интеграции и к стабильности, в случае багов в коде может остановиться работа в 10 и больше командах. Обычно Senior SDE занимаются целым направлением и довольно автономны в том, что и как они делают.

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

По контракту ты должен работать 40 часов в неделю. Однако это время не учитывается напрямую, просто объем твоих задач и ожидаемые от тебя результаты определяются менеджером исходя из такой загрузки. Я обычно уже около 9 утра нахожусь на рабочем месте, потратив около часа чтобы добраться до работы на поезде и шаттле (см. предыдущие посты), однако большинство моих коллег приходит лишь к 11 часам – они просто работают с 9 до 11 из дома, избегая тем самым пробку по дороге на работу, и с 8-9 утра их можно видеть онлайн и даже позвонить им по Сайпу, если нужно. Часто и после 9 вечера вся команда встречается снова онлайн, бывает что-то срочное и можно быстро обсудить и в случае необходимости даже быстро что-то запрограммировать (баг, какое-то маленькое расширение и прочее).

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

Нет формальных требований к одежде, а также к пребыванию в офисе. Ты можешь одеваться как тебе удобнее (в рамках приличий) и можешь работать из дома, если ты так хочешь или если тебе это необходимо. В моем случае 90% тех, с кем я работаю, находится все-равно либо в Сиэтле, либо в Индии, поэтому совершенно не важно откуда я говорю – из своего офиса в Sunnyvale или из дома. Однако ожидается, что ты будешь доступен онлайн (через внутреннюю систему коммуникаций, построенную на Skype for Business решении) – то есть в окне пользователей около твоего имени будет гореть зеленый огонёк, показывающий, что ты в данный момент находишься у компьютера – примерно с 10-11 утра до 5-6 вечера.

(продолжение в следующих постах )

Второй 6-й части про практику, первый был здесь.

Часть 1: Поворот
Часть 2: (лирическое отступление) Школа и медвуз
Часть 3: Microsoft Student Partners Germany
Часть 4: Подготовка к интервью
Часть 5: Интервью (пост1) (пост2)
Часть 6: Практика в Майкрософт Бинг в Сан-Франциско (пост1) (пост2)
Часть 7: Работа в Майкрософт Бинг изнутри

Для связи используйте мой ник здесь и Гугл :)
----------

В общем, я перебрал несколько подходов, остановился на наиболее перспективном и занимался анализом различных факторов на тип блока текста. Я написал несколько программ для анализа текста, его разметки вручную для генерации gold standard (который мне был нужен для расчета метрик, таких как precision и recall), самообучающийся движок для анализа текстов на основе многих страниц из одного источника (то есть для случая, когда мы можем предполагать одинаковый дизайн, но разный контент в n связных документах).

Предварительная же оценка моей работы, написанная моими двумя руководителями по итогам первых 6-8 недель, была скорее негативной, чем позитивной. «Не всегда способен оценить сложность и приоритет задач», «зачастую работает над менее приоритетными задачами, в то время как более приоритетная задача остается без внимания», «небрежно относится к срокам, которые может пропустить без какой-либо видимой причины» -- все это оказалось для меня совершенно неожиданным. И правда, примерно на 7-й неделе я потерял две недели работы из-за того, что у меня приказал долго жить жёсткий диск и была потеряна работа порядка полутора недель (я не делал бакапы каждый день), да, мне бывало откровенно скучно на наших рабочих встречах, так как мой проект не имел прямого отношения к тому, над чем работала наша группа. Но даже с учетом этого я не ожидал такой степени негатива.

Я попытался прояснить ряд моментов, особенно что касалось «сроков», со своими руководителями, ведь мы никогда не определяли сроки, на что получил просто феерический ответ – “we had some implicit deadlines” (у нас был ряд негласных сроков). Ну кто бы мог подумать, что их вопросы – «а успеешь ли ты до пятницы?» и т.п., которые я просто принимал за предположения, считались ими конкретными сроками выполнения работы.

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

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

В этот момент как раз проходил Global Intern Event, на который я полетел в Сиэтл, и там я встретился снова со своим рекрутером. По его совету я по возвращении обсудил свою характеристику еще раз со своими руководителями, и мы чуть изменили формат наших встреч, обговаривая в конце что ожидается к следующей встрече и к концу недели. Это помогло мне, с одной стороны, более правильно понимать их приоритеты и ожидания, а, с другой стороны, я стал больше рассказывать им о неудачах или тупиковых ветвях развития проекта.

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

Однако не самая хорошая характеристика придала мне сил – терять мне в любом случае было нечего (кроме, возможно, опасности попасть в какой-нибудь «черный список» с пометкой no hire, но об этом я в тот момент совсем не думал). Поэтому я решился на такой шаг и за 5 недель до окончания проекта я бросился со всеми силами на изучение и, по мере изучение, внедрение методик машинного обучения в своем проекте.

Это сейчас, в 2015 году, когда машинное обучение стало модной технологией, найти хороший и даже бесплатный курс в интернете не представляет больших проблем. Coursera предлагает целый ряд курсов, от объемно-теоретических, как курс профессора Andrew Ng, до сугубо-прикладных, как курс от университета John Hopkins. Да и на других платформах предостаточно интересных курсов с заданиями и разобранными ответами. Тогда же я смог найти лишь какой-то мутный туториал на R, который мне посоветовали использовать мои руководители, но который за три дня изучения и «научного тыка» не сильно продвинул меня к моей цели.

Когда я уже начал выдыхаться я вдруг вспомнил, что я же блин специалист по MS SQL Server, а в состав этого сервера входит отдельный движок для машинного обучения – SSAS, SQL Server Analytical Services. Когда, еще в целях подготовки докладов для Microsoft Student Partner Program, я занимался этим движком и у меня были базовые знания о том, как создавать модель, как распределять данные, как обучать модель и проводить cross-validation.

В результате я за три дня сделал несколько моделей для своих данных: от простых decision trees и nave bayes, до довольно большой по размерам (насколько мне позволил сервер) нейронной сети, которую я особенно долго тренировал на своих данных. После сравнения всех трёх моделей, к моему удивлению, модель, построенная на decision trees, выдавала наилучшие значения как для precision, так и для recall для моей задачи.

Кроме построения самой модели, SSAS позволил мне оценить вклад отдельных факторов в принятие решения о том, какой тип (реклама или текст) имеет данный блок (так называемая discriminative power), что позволило мне сосредоточиться на этих факторах и улучшить их, разбив некоторые из них на подкатегории и добавив сходные факторы. По итогам первой итерации моей модели я смог достичь рекордных значений метрик.

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

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

(завершение истории по тех причинам в первом комментарии)

Для тех, кто пропустил предыдущие части:

Часть 1: Поворот
Часть 2: (лирическое отступление) Школа и медвуз
Часть 3: Microsoft Student Partners Germany
Часть 4: Подготовка к интервью
Часть 5: Интервью (пост1) (пост2)
Часть 6: Практика в Майкрософт Бинг в Сан-Франциско
Часть 7: Работа в Майкрософт Бинг изнутри

Для связи используйте мой ник здесь и Гугл :)
----------
Для того, чтобы сделать практику в США, необходимо иметь статус студента (быть студентом очного отделения ВУЗа) и получить специальную визу категории F, которую для этих целей выдают сроком ровно на 12 недель – на период прохождения практики. Получение американской визы процесс непростой, но в принципе и не такой сложный. Самым сложным была подача документов в посольстве, куда нельзя проносить ни сотовые телефоны, ни USB-накопители, вообще никакую электронику, включая электронные часы. А куда же их девать? Как мне подсказал охранник, бабушка в ближайшем цветочном киоске за 2 Евро охотно присматривала за твоим добром и даже вела какой-то учет. Но при этом не выдавала никаких квиточков, полностью полагаясь, видно, на свою память. Было несколько стрёмно отдавать ей пакет со смартфоном, брелок с ключами от всего на свете и еще кучу нужных вещей, которые мигом можно толкнуть минимум за две-три сотни Евро, и всё это удовольствие всего за два евро – кто же знает её бизнес-модель и вдруг она меня больше и не вспомнит? Но у бабушки глаз оказался наметан хорошо и с совестью тоже все в порядке – после всего я получил свой пакет обратно, в целости и сохранности. Но больше на такое не решался и всегда просил друзей пойти со мной и подождать снаружи пока я завершу дела.

Есть несколько видов практики, которую предлагает Microsoft. В данной статье я описываю только Business Internship и жизнь Business Interns, которые по сути являются студентами технических специальностей, еще не закончившими ВУЗ.

Практика в Майкрософте подразумевает работу над проектом в течение 12 недель. Работа интерна в принципе ничем не отличается от работы обычного сотрудника: интерны получают зарплату, сравнимую с зарплатой специалиста (всего лишь на 20-30% меньше, чем начальная зарплата выпускника ВУЗа), они самостоятельно работают над проектом и представляют свои результаты, их менеджер дает оценку их работе используя те же критерии, что и для остальных сотрудников.

Кроме этого, Майкрософт дает возможность оформить по очень низким ценам временное жилье (от 650 долларов в месяц за однокомнатную студию и 1200 в месяц за двухкомнатную квартиру, полностью меблированную и со всеми приборами), снять машину (около 400 долларов в месяц), а также перенимает частично стоимость велосипеда, если так тебе проще добираться. Тебе и твоей семье (если она хотел поехать с тобой) оплачивается перелет. Также в середине практики организуется большое мероприятие для всех интернов с участием Билла Гейтса и всего руководства компании, с приглашением звезд эстрады и с подарками. В наш год, к сожалению, первый раз не было Билла Гейтса, вечеринка проходила в зоопарке Сиэтла, приглашенную звезду я не знал (какой-то Dave Matthews), а в качестве подарков были Xbox 360 Slim.

Так получилось, что я жил в самом центре Сан Франциско, в комплексе с романтическим названием Bayside Village прямо под мостом Bay Bridge (это второй мост, находящийся примерно в 10 милях от своего намного более известного собрата Golden Gate Bridge), всего в 15 минутах пешком от своего офиса. К сожалению, об этом я не знал в тот момент, когда мне нужно было решать беру ли я машину или велосипед, поэтому я выбрал машину и она практически все время стояла в гараже комплекса. Даже в магазин мне было легче сходить пешком, чем пытаться запарковаться в тесном подземном гараже.

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

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

Прежде всего, у меня было два руководителя. Один – мой непосредственный менеджер, с отличием закончивший Гарвардский университет по информатике и защитивший диссертацию по лингвистике в Амстердаме, член общества «фи-гамма-каппа», говорящий на 6 языках и имеющий очень цепкий и быстрый ум. Его первой фразой при встрече, которую он произнес просто как скороговорку, было – «не пугайся, если ты вдруг не всё понимаешь из того, что я говорю – тут родившиеся здесь американцы меня не всегда могут понять: не бойся задавать вопросы!». Так примерно я понял тогда эту фразу, надеюсь правильно.

Вторым руководителем была девушка, младше меня на 2 года, консультант-помощник, выпускница Стэнфорда, тоже владеющая несколькими языками и кроме того очень высококлассный программист. Не смотря на тот факт, что она была младше меня, она была одним из самых жестоких критиков моей работы и моего стиля программирования, и всегда ее критика была «по делу».

Они оба встретили меня в первый день практики и представили мне мой проект, который заключался в следующем: Поисковые пауки обходят страницы, сохраняли их полное содержание в виде HTML файла в индексе поисковой базы данных. Для улучшения поиска необходимо было создать алгоритм (или систему), которая бы из HTML документа извлекала бы только полезный контент, игнорируя рекламные блоки, блоки навигации, header и footer, какие-то нетекстовые элементы разметки и прочее. По возможности надо было извлечь еще и примерную структуру документа – основной заголовок, подзаголовки и разделы.

На решение этой задачи мне давался полный carte blanche и около 10 недель времени. На протяжении этого времени у меня два раза в неделю по часу были syncs с моими руководителями, которые выслушивали мои предложения и критиковали их, разбирая их по косточкам и не оставляя от них камня на камне. Они указывали мне на все недостатки предлагаемых мною методов решения, но когда я пытался задать встречный вопрос «а как правильно делать это?», то неизменно получал ответ в форме «это же твой проект – вот ты думай и предлагай, а мы тут только для того, чтобы обсуждать твои предложения, а не сами предлагать что-то» (отмечу еще раз, что это не совсем типично для практики в большой фирме, поэтому мне в определенной степени повезло!) Из-за того, что мои решения постоянно подвергались критике мне казалось, что на протяжении всей практики мне казалось, что я постоянно пытаюсь изобрести тот велосипед, который уже давным-давно изобретен здесь, и весь смысл моей работы сводится к тому, чтобы посмотреть, как быстро я его изобрету.

Я должен признать, что я до начала практики был мало знаком с работой поисковых систем и с проблемами, которые приходятся решать в рамках их функционирования. Поэтому во время практики мне приходилось очень много читать и изучать такие новые для меня темы, как Information Retrieval, Data Mining, Machine Learning и прочее. Каждый день, вечером, приходя домой с работы около 9 часов, я старался уделять хотя бы час чтению учебников и статей по этой теме. В некоторые выходные я даже оставался дома, чтобы лучше изучить эти темы. Перед сном я ходил плавать в бассейн в комплексе и во время заплыва думал над своим проектом, пытаясь применить то, что я прочитал в теории, к своей практической деятельности.

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

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

Алгоритм также сначала сканировал текст в поисках заголовка – небольшого (1-2 предложения) текста размерами больше чем медианный размер текста на странице. Если такой блок находился и морфосемантический анализ этого текста показывал, что это скорее нормальный текст нежели реклама, то все блоки до этого текста игнорировались из дальнейшего анализа.

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

(продолжение во втором посте)

Это окончание 5-й части, начало в предыдущем посте, предудыщие части у меня в ленте.
====
Третье интервью стало же полным провалом.

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

Задача 3: «Допустим, у нас есть веб-приложение, которое поддерживает компоненты, называемые виджеты. Каким образом можно реализовать синхронизацию времени в двух разных виджетах?»

Первый раз я не понял условие совсем. Что требовалось от меня? Разработка API для протокола синхронизации? Два произвольных виджета должны быть синхронизованы просто между собой, или все виджеты должны иметь одно и то же время? Мои вопросы остались без ответов, индус лишь добавил, что мне нужно предложить «концепты». К такому я был несколько не готов, и из-за волнения у меня ряд названий заело на немецком (я учил всю информатику на немецком). Сначала я рассказал о Verbraucher-Konsumer-Pattern, который я в последний момент таки сумел перевести как publisher-subscriber architecture. Потом рассказал про merge replication, как оно реализовано в SQL Server. Оттуда мы перешли к high availability models, на примере кворума баз данных и распределенных транзакций. Неожиданно интервьюер повернул разговор на тему многозадачности, и я еще успел рассказать о критическом пути и семафорах на последних минутах интервью. На мой вопрос, удовлетворен ли он моим ответом, он сказал «я услышал все, что хотел услышать».

Не смотря на такой вроде бы позитивный ответ в конце у меня было крайней негативное впечатление от интервью. И волнение, с которым я вынужден был бороться с самого начала интервью, не могло, конечно, не сказаться на моём языке. В общем если до этого я себе ставил плюсы за собеседование, тут я был вынужден поставить себе минус – ведь я так и не понял, чего же хотел от меня интервьюер.

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

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

Задача 4: «В численных кроссвордах вместо слов и букв используются числа и цифры. В любом «численном слове» цифры не могут повторяться, и все цифры идут либо в возрастающем, либо в убывающем порядке. При этом отдельные цифры можно пропускать. Например, 1245 и 9832 являются допустимыми, а 1223 (две одинаковых цифры) и 9835 (смешанный порядок) недопустимыми. Также никакое число не может начинаться на 0, но может содержать 0 в себе. Для данного слова, в котором известны несколько цифр, например, хх5хх9 или 87хх21 надо найти возможные комбинации допустимых слов.»

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

И тут интервьюер решил мне помочь. Он спросил меня, почему я иду таким странным путем, и не легче бы было сначала сгенерировать все возможные слова (благо их число ограничено из-за правил), и потом просто для любой «маски» проверять все «слова» из этого списка. Мне сразу захотелось ударить себя по лбу изо всей силы – это ведь классическая ошибка, о которой пишут на всех интервью – сначала уточни, какое решение от тебя хотят, а потом пытайся решить. Я почему-то выбрал самый сложный вариант, даже не спросив, устроит ли такое вот решение «в лоб».

В результате за оставшиеся 20 минут я быстро набросал алгоритм, похожий на тот, что был у меня в первой задаче, который на выходе давал мне все возможные слова. На большее у меня уже не хватило времени, та часть задачи, где нужно было искать слова по заданной маске, так и осталась нерешенной, хотя я описал примерный алгоритм решения. Из-за сильного волнения я совсем забыл английский, в частности слово «присваивание», и постоянно пытался заменять его синонимами, как to let, to set и борясь с пытающимся прорваться немецким zuweisen.

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

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

Началась лекция, в которой лектор рассказывал об SLA облачных технологий и как эта SLA достигается. Неожиданно выяснилось, что кроме меня никто не знал, что такое SLA (или не хотел этого показать?). Также выяснилось, что из порядка 17 кандидатов только двое было не из университетов США: я из Германии и еще один поляк из Англии. Было много индусов, была даже девочка из Казахстана, которая училась в MIT у Barbara Liskov.

После лекции к нам пришли рекрутеры (они почему-то каждый раз менялись, тут я впервые увидел своего рекрутера, который со мной раньше переписывался). Они сказали, что совещание закончилось, и что решение по практике принято. Они будут вызывать нас по одному, и мы должны выходить из комнаты со всеми вещами, так как мы больше сюда не вернемся и не увидим своих «товарищей». Те, кто получат место практикантов, потом смогут поехать на экскурсию в Сиэтл, остальные должны будут вернуться в гостиницу либо в аэропорт, в зависимости от того, когда они возвращаются.

Первым назвали моё имя. Я не особо удивился. Рекрутер ждал меня в конце длинного коридора около стола, больше напоминавшего барную стойку. Когда я подошел, он сразу начал «Знаешь, Александр, с твоей практикой есть проблемы…». Да что там, мне было и так всё понятно, я собственно, внутренне уже подготовился и совсем не расстроился…

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

Поездка не прошла без приключений. Так как у меня не было навигации для США, я скачал на телефон бесплатную навигацию на основе Open Street Maps, но неожиданно выяснилось, что у них нет номеров домов, и я так и не смог найти свою гостиницу: сделав два круга я запарковался на какой-то стройке и там позвонил друзьям, что ждали меня в фойе, чтобы они помогли мне найти въезд в подземный гараж гостиницы, который я каждый раз пропускал, принимая его за служебный въезд.

На следующий день, в воскресенье, я целый день готовился к интервью, повторял наиболее сложные задачи и алгоритмы, а также места, где я часто делал ошибки. Выйдя из номера только для того, чтобы покушать, я опять прокололся: заказав в небольшой вьетнамской забегаловке что-то дешевое за 10 долларов я получил счет на 14, и заплатил ровно 14, ни оставив никаких чаевых, что очень разозлило и огорчило официантку. Ну откуда ж я знал, что в меню была указана kitchen price, без налогов и чего-то еще, и туда еще нужно добавить 15% чаевых? Для меня это и сейчас довольно много, а тогда вообще казалось дикостью.

Вечером в воскресенье у нас была небольшая вечеринка вместе с остальными кандидатами, которых пригласили на собеседование в понедельник. Всего, как оказалось, было около 30 кандидатов, которые собеседовались в два различных департамента: Windows Phone и OSD.

Услышав это, я облегченно вздохнул. Windows Phone только вышел в прошлом году, но у меня уже было неплохое приложение в маркте, одно из первых приложений из Германии, которое мы написали с моим другом из Гамбурга Eike. Это было указано в моем резюме, и я не сомневался, что собеседование я буду проходить именно в этой группе – и уж что касалось программирования для Windows Phone, тут я вроде неплохо разбирался.

Тем не менее, в той папке, что мне дали после вечеринки, с ознакомительными материалами перед собеседованием, стояло OSD. Во время боулинга, что мы играли на вечеринке, я даже и не поинтересовался, что же это за второй такой департамент – о чем сейчас жалел. Поиск в интернете ничего не прояснил, вариант On-Screen Display (экранное меню) меня тоже не очень устраивал.

Сбор был утром в 8:15, я быстро позавтракал и в 7:45 уже был в фойе, ожидая автобус, который должен был повезти нас на интервью. Одновременно я нашел еще пару других ребят, которые должны были проходить собеседование в OSD, которые и просветили меня, что за этой аббревиатурой, означающей Online Services Division, скрывается Бинг и относящаяся к нему инфраструктура. Очевидно, кандидатов распределяли по департаментам совершенно случайно, без учета их резюме. Иначе как объяснить тот факт, что я попал на собеседование в OSD, к которому не имел никакого отношения…

Автобус приехал ровно в 8:25, но ехать оказалось всего около 10 минут (пешком идти, в общем, столько же) – мы поехали не в Редмонд, а в большое здание Бинга в Bellevue, где и должны были проходить собеседования кандидатов из Бинга. Во время поездки нам рассказали о том, как запланирован этот день: у каждого из нас сначала должно было быть 4 интервью по 50 минут, после которых был небольшой обед и лекция про облачные технологии. Затем нам объявляли результаты собеседования и у нас было свободное время для поездки в Сиэтл, чтобы осмотреть его достопримечательности.

Лифт привез нас на 18-й этаж в большой зал, где можно было оставить свою одежку и комфортно сидеть за столами в ожидании интервью. В этот зал с нескольких уровней спускались лестницы, а параллельно им шли горки – видно для сотрудников, которые не признавали лестницы для спуска. Рядом была кухня с чаем и кофе-автоматом, а с окна открывался чудесный вид. Но наслаждаться им мне было суждено не так долго, потому что уже через 5 минут, одним из первых, за мной пришел первый интервьюер и повел меня в свой офис.

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

Задача 1: «Для данного телефонного номера США необходимо выдать все возможные комбинации букв, которыми он может быть записан».

В США, оказывается, на каждом телефонном аппарате есть буквы рядом с цифрами, и многие фирмы даже свои телефоны записывают как 1-800-YOUR-FURNITURE или что-то подобное – очень удобно в рекламных целях и не нужно учить последовательность цифр.

Так как последовательность полученных «слов» была не важна, то для решения можно было использовать любой алгоритм для обхода дерева, поэтому любой алгоритм такого обхода подходил для решения этой задачи. Единственное, что меня смутило в задаче – какой структурой данной воспользоваться для хранения и передачи этого списка слов. В целях простоты синтаксиса я выбрал List, при этом соответствие цифра – буквы у меня хранились в readonly структуре List.

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

Вообще, использование char вместе со string оказалось не очень хорошим решением. С одной стороны, всегда можно было легко получить нужную цифру номера из строки, но это добавляла дополнительные сложности в алгоритм усечения. Но в целом алгоритм работал. В оставшиеся 10 минут интервью мы обсудили возможности его улучшения, и я даже сумел аргументировать наличие метода размером в одну строку тем, что компилятор, скорее всего, при оптимизации кода сделает method inlining.

По итогам первого интервью я был очень доволен собой и уже значительно более спокойно стал ждать второго интервьера.
Второй собеседующий оказался из Канады, и мы сначала несколько минут поговорили по-французски (в моем резюме было указано, что я владею им). Он сразу признался, что он работает в back-end и не знает С# -- моего основного языка – а использует только С++. Он спросил меня, могу ли я для решения задачи использовать С++. Мне хватила ума и осторожности сказать, что я могу попробовать использовать синтаксис этого языка, если нужно. Он согласился и сразу дал следующую задачу:

Задача 2: «Дана матрица n x m, заполненная целыми числами (положительными и отрицательными и нулями). Необходимо обнулить все строки и столбцы матрицы где встречается элемент с нулевым значением.»

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

Это задание показалось мне проще, нежели остальные. Ключевым было слово «вектор бит» (bit vector), которое я произнес достаточно рано и остаток времени ушел на реализацию этого вектора (я не знал, есть ли он в стандартной библиотеке C++, поэтому решил реализовать сам). Также отдельное внимание пришлось уделить работе с памятью, так как для упрощения решения я передавал в метод расчета одномерный массив и размерности матрицы.

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

Третье интервью стало же полным провалом.

(продолжение во втором посте )