Педиатр-программист: Как я попал в Майкрософт | "Интервью", часть 5 из 7 (пост 2)

Это окончание 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.

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

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

10/10 

С каждой частью все интереснее и интереснее!

раскрыть ветку (13)
1
Автор поста оценил этот комментарий

Спасибо, с каждой частью, к сожалению (или нет?) все длиннее и длиннее получается.

Рад, что Вам нравится -- значит не зря старался! :)

раскрыть ветку (12)
1
DELETED
Автор поста оценил этот комментарий

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

раскрыть ветку (3)
Автор поста оценил этот комментарий

Отлично. Если вдруг почувствуете перегрузку деталями -- давайте отмашку.

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

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

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

Если этого не нужно, я пишу "продложение в комментариях".

Если этого текста нет -- то появляется небольшая интрига :)

DELETED
Автор поста оценил этот комментарий

Александр, а приходиться решать задачки в ходе работы на подобии тех, что на интервью? Или использовать эти алгоритмы?

раскрыть ветку (5)
Автор поста оценил этот комментарий

Ну из того, что мне приходилось решать за полгода на работе:


1) есть список имен файлов (до 10 миллионов строк), надо найти общий путь для них всех за разумное время.

2) есть зависимости между отдельными задачами, скажем выражение В может зависить от А и от Б, в своё время Б тоже зависит от А. Нужно построить график, где отобразить эти зависимости, причем так, чтобы убрать "очевидные" зависимости -- сделать цепочку А -> Б -> В (В зависит и от А и от Б, но если Б выполнено, значит А уже тоже выполнено).

3) очень много задач было на паралелльное программирование -- синхронизация тредов, повторное использование тредов, передача и обработка cancellation token, собственная реализация диспетчера пулов и потоков и прочее.


Но в целом на работе 90% работы -- это рутина и знания определенных технологий, а не решение алгоритмических задач. Оно то и понятно -- я же все-таки по профессии Software Engineer, а не Researcher.

раскрыть ветку (4)
DELETED
Автор поста оценил этот комментарий

Спасибо!

Автор поста оценил этот комментарий
А можно поинтересоваться, почему такое внимание уделяется параллельности, а не асинхронности? Просто почти во всех современных технологиях, для больших нагрузок, используется именно асинхронность с конечными автоматами и event-driven programming, т.к. переключение контекста тредов довольно затратная операция. Извиняюсь, если это глупый вопрос. Я просто новичёк))
И ещё по задаче №4 хотел спросить) Почему именно вариант с генерацией всех слов, а потом сравнение с маской оказался проще? Так же дольше получается, да и кодить больше) Мне почему-то кажется, что тот путь по которому вы пошли с самого начала - более очевиден. Если к примеру только 2 пропуска, то это получается только 2 цикла (1 вложен). Или я чёт вообще не то понял((
раскрыть ветку (2)
1
Автор поста оценил этот комментарий

Просто асинхронность проще программировать, C# компилятор сам переписывает вызовы async/await в state-machine и получается красивый, линейный код, безо всяких этих callbacks и кучей делегатов с событиями. Это удобно и тут не нужно много чего изобретать, есть только ряд тонких моментов в exceptions management, но у нас до этого не доходило.

Parallel programming, в отличие от asyncrounous требует куда большего управления, даже если используется TPL (за счет самой парадигмы). Есть более продвинутые парадигмы параллелизма (actor's model, fibers и прочее), но мы их не используем. TPL очень удобна для стандартных задач, но в ней все-равно приходится выписывать довольно много кода, если требуется тонкое управление многозадачностью.


По поводу второго вопроса -- простота решения заключается в том, что не надо ГЕНЕРИРОВАТЬ решения для конкретного случая, надо просто один раз сгенерить их и потом искать их по маске. Второе -- довольно стандарная задача, первое тоже проще, чем решать "в лоб", как я попытался.

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

а почему про про Сан франциско было сказано "к сожалению"? или круто там считается только в главном офисе?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

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

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку