Педиатр-программист: Как я попал в Майкрософт | "Подготовка к интервью", часть 4 из 7
Предыдущие части:
Часть 4: Подготовка к интервью
Часть 5: Интервью
Часть 6: Практика в Майкрософт Бинг в Сан-Франциско
Часть 7: Работа в Майкрософт Бинг изнутри
----------
Одновременно с решением сделать практику, примерно в апреле-мае, я начал готовиться к собеседованию.
Прежде всего, поискав информацию в интернете, я с удивлением обнаружил, что даже в Википедии есть отдельная статья об интервью в Майкрософт. На протяжении многих лет Майкрософт был ведущей IT-компанией и её основатель, Билл Гейтс, имел довольно специфический подход к проведению интервью. В частности, во время интервью тестировались не только (и не столько) специфические знания или навыки, а сколько способности кандидата к аналитическому мышлению.
Задачи на аналитическое мышление предполагали два вида заданий: так называемые brain teasers, задачи с «подвохом», решение для которых требует нетривиального хода.
Пример задачи: Используя знаки арифметических операций (плюс, минус, умножить, разделить) добейтесь того, что данное выражение станет истинным: 3 1 3 6 = 8 Если нужно, можно также использовать скобки.
Для того, чтобы успешно решать такие задачи, надо просто натренироваться на решении существующих в интернете задач и пытаться применять известные решения к новым задачам.
Второй тип задач является задачами на оценку некой величины, которую кандидат точно не может знать, но может вывести исходя из общих знаний и каких-то начальных значений.
Пример вопросов: Сколько дорожных люков в Нью-Йорке? Сколько настройщиков пианино в Чикаго?
Для успешного решения подобных задач необходимо уметь проводить оценки нижнего и верхнего пределов своей задач, постепенно переходя от населения страны и города к количеству потенциальных клиентов или улиц, давая шаг за шагом приблизительную оценку. Итоговое число не так важно, и может даже на порядок отличаться от известной величины – важен именно сам путь от базовых знаний до узко-специфического значения. Для того, чтобы научиться решать эти два типа проблем, подходят книги “How to move the mount Fuji” и “The art of guessimation”, где разбираются пошагово различные задачи подобного рода. Однако, эти книги сегодня имеют лишь историческое значение – вероятность напороться на такой вопрос в собеседовании сегодня очень мала.
Собеседования сейчас напоминают мини-экзамен, когда тебя могут спросить любой вопрос в рамках твоей специальности, а также предложить решить любую задачу. При этом решение необходимо представить немедленно, часто «думая вслух» и обсуждая возможные пути решения, их сложность и реализацию с интервьюером. Обычно на небольшие ошибки в ходе такого решения закрываются глаза, если общий ход решения правилен и темп достаточен для решения задачи за то время, за которое ее планировал решить с вами интервьюер.
Самое лучшей книгой для подготовки к интервью в больших IT-компаниях, которую я встречал, является книга Gayle Laakmann “How to crack a coding interview?”. В этой книге рассматриваются все аспекты технического интервью: от составления резюме до того, как правильно торговаться за зарплату и бонусы. Большая (ударение на первом слоге) часть книги посвящена имена технических вопросам и ответам на них, есть также разделы по brain teasers и архитектуре и даже операционным системам. Именно поэтому эта книга и стала основной книгой для подготовки.
В книге к каждой задаче дается пример кода программы, которая могла бы быть решением. К сожалению, в качестве языка везде используется только Java, которую я знаю не очень хорошо. Поэтому я практически не использовал ответы, только проверяя логику решения.
Поскольку решение на собеседовании надо представить обычно либо на доске, либо просто на листочке бумаги (если нет доски), то для тренировки в реальных условиях я решал каждую задачу следующим образом:
1. Сначала решал задачу на листе бумаге, записывая код ручкой
2. Перенабирал код в Блокноте и LinqPAD, исправляя красной ручкой все ошибки в названиях, сигнатурах и прочем – все, что мешало коду скомпилироваться
3. Если решение было правильным – на этом этапе все заканчивалось
4. В случае неправильного решения приходилось либо отлаживать программу и исправлять ошибки зеленым цветом, либо решать задачу заново.
Я старался заниматься не реже, чем два дня в неделю, уделяя этому каждый раз не меньше часа. Больше у меня не получалось (из-за учебы и работы), но за один час я постепенно стал решать вместо одной аж три задачи. Самое долгое было набирать текст и проверять его на корректность, я это делал сначала в самом простом редакторе «Блокнот», и лишь потом копировал в LinqPAD, где мне тут же подсвечивались синтаксические ошибки. Примерно за 9 месяцев таких занятий я решил все задачи из книжки, особенно много внимания уделив задачам из раздела «Сложных» задач.
А тем временем уже шел январь 2011 года. Прошло около пяти недель после подачи резюме в Майкрософт, когда мне написала рекрутер и сообщила, что я успешно прошел первый этап (ура-ура! Хотя я и не сомневался) и что она теперь хочешь провести телефонное интервью со мной в «любое удобное мне время». К письму была приложена табличка в Excel с этими самыми «любыми удобными временами», которые оказались между 11 часами ночи и 6 часами утра – из-за разницы во времени, так как интервью проводилось напрямую из США.
Я выбрал ровно полночь для интервью. С одной стороны, это было бы уже не первое интервью (интервью предполагалось получасовое, то есть до меня еще могло быть до двух других интервью), а с другой стороны интервьюер бы еще не очень устал.
После этого рекрутер выслала мне длинное письмо с тем, как готовиться к этому интервью. Отдельно красным текстом был выделен абзац, в котором стояло, что мне могут дать одну или несколько задач для решения и что я должен быть готов по телефону объяснить решение задачи.
Следуя советам Laakmann я подготовил большую матрицу примерных ответов на вопросы о своём резюме, выписал ключевые слова, которые я мог бы забыть во время телефонного интервью и немного порепетировал эти ответы. Также подготовил ответы на типичные вопросы, которые обычно задают на первом интервью, вроде «Ваши недостатки?», «Что бы Вы сделали по-другому?» и так далее. Я также подготовил ряд материалов для решения задачи по программированию: сложности различных методов в структурах данных, сложности алгоритмов сортировки. Приготовил и чистую бумагу, для черновиков.
Я что-то перепутал со временем, потому что рекрутер позвонил не в полночь, как я ожидал, а на час раньше. Мне повезло, что я так рано начал готовиться и у меня уже все было разложено на столе – но все-равно, звонок застал меня несколько врасплох и первые несколько минут я пытался собраться с мыслями.
Интервью протекало так, как и было описано у Laakmann. Рекрутер (а это был американец со странной для американца фамилией Мюллер) спрашивал меня по моим предыдущим проектам: в чём заключалась моя роль, какие проблемы приходилось решать и что бы я сделал по-другому. Поговорив так около 15 минут, он сказал, что больше вопросов у него ко мне нет и спросил, есть ли у меня к нему вопросы. Я уже к этому моменту уже почти пересортировал свои материалы так, чтобы сразу решать задачу, поэтому я не совсем уловил суть вопроса и автоматически ответил ему, что «вопросов у меня пока нет». “Well, OK, bye!” сказал он и положил трубку.
Вот тут я растерялся по-настоящему. Сначала я даже подумал, что нас просто разъединили и он сейчас перезвонит – но нет. Потом я еще раз проанализировал все, что было сказано им, и вспомнил, что ведь он сказал “bye” прежде чем положить трубку. Значит, он решил не давать мне задачу. Но почему? Все было так хорошо или, наоборот, так плохо? Я вроде бы ответил на все его вопросы во время этих 15 минут, но из-за того, что использовалась Voice-over-IP соединение я порой понимал только половину или треть того, что он меня спрашивал и вполне мог ответить что-то невпопад или неправильно. Эх!
В общем, я решил просто подождать. От друзей в Майкрософт я знал, что второй этап интервью в этом году проводится в Мюнхене в конце февраля, так что ждать оставалось недолго.
Я специально полностью освободил последнюю неделю февраля, ожидая приглашения в Мюнхен. Обычно за неделю-полторы до даты собеседования рекрутер вновь связывается с тобой, чтобы согласовать дату и время. Однако никто со мной не связался. Я даже завел привычку проглядывать папку со спамом, что раньше никогда раньше специально не делал.
Пошла последняя неделя февраля, никто мне не звонил и не писал. Я ждал до вечера пятницы. В субботу у меня был День Рождения, и я почти целый день не было дома – но мне было уже все-равно. Вряд ли меня кто-то пригласил бы на собеседования в понедельник (последнее собеседование) е-мейлом в субботу....
Часть 4: Подготовка к интервью
Часть 5: Интервью
Часть 6: Практика в Майкрософт Бинг в Сан-Франциско
Часть 7: Работа в Майкрософт Бинг изнутри
----------
Одновременно с решением сделать практику, примерно в апреле-мае, я начал готовиться к собеседованию.
Прежде всего, поискав информацию в интернете, я с удивлением обнаружил, что даже в Википедии есть отдельная статья об интервью в Майкрософт. На протяжении многих лет Майкрософт был ведущей IT-компанией и её основатель, Билл Гейтс, имел довольно специфический подход к проведению интервью. В частности, во время интервью тестировались не только (и не столько) специфические знания или навыки, а сколько способности кандидата к аналитическому мышлению.
Задачи на аналитическое мышление предполагали два вида заданий: так называемые brain teasers, задачи с «подвохом», решение для которых требует нетривиального хода.
Пример задачи: Используя знаки арифметических операций (плюс, минус, умножить, разделить) добейтесь того, что данное выражение станет истинным: 3 1 3 6 = 8 Если нужно, можно также использовать скобки.
Для того, чтобы успешно решать такие задачи, надо просто натренироваться на решении существующих в интернете задач и пытаться применять известные решения к новым задачам.
Второй тип задач является задачами на оценку некой величины, которую кандидат точно не может знать, но может вывести исходя из общих знаний и каких-то начальных значений.
Пример вопросов: Сколько дорожных люков в Нью-Йорке? Сколько настройщиков пианино в Чикаго?
Для успешного решения подобных задач необходимо уметь проводить оценки нижнего и верхнего пределов своей задач, постепенно переходя от населения страны и города к количеству потенциальных клиентов или улиц, давая шаг за шагом приблизительную оценку. Итоговое число не так важно, и может даже на порядок отличаться от известной величины – важен именно сам путь от базовых знаний до узко-специфического значения. Для того, чтобы научиться решать эти два типа проблем, подходят книги “How to move the mount Fuji” и “The art of guessimation”, где разбираются пошагово различные задачи подобного рода. Однако, эти книги сегодня имеют лишь историческое значение – вероятность напороться на такой вопрос в собеседовании сегодня очень мала.
Собеседования сейчас напоминают мини-экзамен, когда тебя могут спросить любой вопрос в рамках твоей специальности, а также предложить решить любую задачу. При этом решение необходимо представить немедленно, часто «думая вслух» и обсуждая возможные пути решения, их сложность и реализацию с интервьюером. Обычно на небольшие ошибки в ходе такого решения закрываются глаза, если общий ход решения правилен и темп достаточен для решения задачи за то время, за которое ее планировал решить с вами интервьюер.
Самое лучшей книгой для подготовки к интервью в больших IT-компаниях, которую я встречал, является книга Gayle Laakmann “How to crack a coding interview?”. В этой книге рассматриваются все аспекты технического интервью: от составления резюме до того, как правильно торговаться за зарплату и бонусы. Большая (ударение на первом слоге) часть книги посвящена имена технических вопросам и ответам на них, есть также разделы по brain teasers и архитектуре и даже операционным системам. Именно поэтому эта книга и стала основной книгой для подготовки.
В книге к каждой задаче дается пример кода программы, которая могла бы быть решением. К сожалению, в качестве языка везде используется только Java, которую я знаю не очень хорошо. Поэтому я практически не использовал ответы, только проверяя логику решения.
Поскольку решение на собеседовании надо представить обычно либо на доске, либо просто на листочке бумаги (если нет доски), то для тренировки в реальных условиях я решал каждую задачу следующим образом:
1. Сначала решал задачу на листе бумаге, записывая код ручкой
2. Перенабирал код в Блокноте и LinqPAD, исправляя красной ручкой все ошибки в названиях, сигнатурах и прочем – все, что мешало коду скомпилироваться
3. Если решение было правильным – на этом этапе все заканчивалось
4. В случае неправильного решения приходилось либо отлаживать программу и исправлять ошибки зеленым цветом, либо решать задачу заново.
Я старался заниматься не реже, чем два дня в неделю, уделяя этому каждый раз не меньше часа. Больше у меня не получалось (из-за учебы и работы), но за один час я постепенно стал решать вместо одной аж три задачи. Самое долгое было набирать текст и проверять его на корректность, я это делал сначала в самом простом редакторе «Блокнот», и лишь потом копировал в LinqPAD, где мне тут же подсвечивались синтаксические ошибки. Примерно за 9 месяцев таких занятий я решил все задачи из книжки, особенно много внимания уделив задачам из раздела «Сложных» задач.
А тем временем уже шел январь 2011 года. Прошло около пяти недель после подачи резюме в Майкрософт, когда мне написала рекрутер и сообщила, что я успешно прошел первый этап (ура-ура! Хотя я и не сомневался) и что она теперь хочешь провести телефонное интервью со мной в «любое удобное мне время». К письму была приложена табличка в Excel с этими самыми «любыми удобными временами», которые оказались между 11 часами ночи и 6 часами утра – из-за разницы во времени, так как интервью проводилось напрямую из США.
Я выбрал ровно полночь для интервью. С одной стороны, это было бы уже не первое интервью (интервью предполагалось получасовое, то есть до меня еще могло быть до двух других интервью), а с другой стороны интервьюер бы еще не очень устал.
После этого рекрутер выслала мне длинное письмо с тем, как готовиться к этому интервью. Отдельно красным текстом был выделен абзац, в котором стояло, что мне могут дать одну или несколько задач для решения и что я должен быть готов по телефону объяснить решение задачи.
Следуя советам Laakmann я подготовил большую матрицу примерных ответов на вопросы о своём резюме, выписал ключевые слова, которые я мог бы забыть во время телефонного интервью и немного порепетировал эти ответы. Также подготовил ответы на типичные вопросы, которые обычно задают на первом интервью, вроде «Ваши недостатки?», «Что бы Вы сделали по-другому?» и так далее. Я также подготовил ряд материалов для решения задачи по программированию: сложности различных методов в структурах данных, сложности алгоритмов сортировки. Приготовил и чистую бумагу, для черновиков.
Я что-то перепутал со временем, потому что рекрутер позвонил не в полночь, как я ожидал, а на час раньше. Мне повезло, что я так рано начал готовиться и у меня уже все было разложено на столе – но все-равно, звонок застал меня несколько врасплох и первые несколько минут я пытался собраться с мыслями.
Интервью протекало так, как и было описано у Laakmann. Рекрутер (а это был американец со странной для американца фамилией Мюллер) спрашивал меня по моим предыдущим проектам: в чём заключалась моя роль, какие проблемы приходилось решать и что бы я сделал по-другому. Поговорив так около 15 минут, он сказал, что больше вопросов у него ко мне нет и спросил, есть ли у меня к нему вопросы. Я уже к этому моменту уже почти пересортировал свои материалы так, чтобы сразу решать задачу, поэтому я не совсем уловил суть вопроса и автоматически ответил ему, что «вопросов у меня пока нет». “Well, OK, bye!” сказал он и положил трубку.
Вот тут я растерялся по-настоящему. Сначала я даже подумал, что нас просто разъединили и он сейчас перезвонит – но нет. Потом я еще раз проанализировал все, что было сказано им, и вспомнил, что ведь он сказал “bye” прежде чем положить трубку. Значит, он решил не давать мне задачу. Но почему? Все было так хорошо или, наоборот, так плохо? Я вроде бы ответил на все его вопросы во время этих 15 минут, но из-за того, что использовалась Voice-over-IP соединение я порой понимал только половину или треть того, что он меня спрашивал и вполне мог ответить что-то невпопад или неправильно. Эх!
В общем, я решил просто подождать. От друзей в Майкрософт я знал, что второй этап интервью в этом году проводится в Мюнхене в конце февраля, так что ждать оставалось недолго.
Я специально полностью освободил последнюю неделю февраля, ожидая приглашения в Мюнхен. Обычно за неделю-полторы до даты собеседования рекрутер вновь связывается с тобой, чтобы согласовать дату и время. Однако никто со мной не связался. Я даже завел привычку проглядывать папку со спамом, что раньше никогда раньше специально не делал.
Пошла последняя неделя февраля, никто мне не звонил и не писал. Я ждал до вечера пятницы. В субботу у меня был День Рождения, и я почти целый день не было дома – но мне было уже все-равно. Вряд ли меня кто-то пригласил бы на собеседования в понедельник (последнее собеседование) е-мейлом в субботу....
