Сущность метапрограммного интервью: Мета-программное интервью. Основные вопросы Мета-программного интервью.

Теперь давайте более подробно рассмотрим четыре типа собеседований, к которым вы должны быть готовы во время интервью с менеджером программы Facebook. Мы рассмотрим их примерно в том порядке, в котором они важны для менеджеров программ.

• Смысл программы
• Товарищество
• Лидерство
• Специфическая роль / техническая

В следующих подразделах мы также собрали подборку реальных вопросов для интервью с менеджерами программ Facebook, согласно данным Glassdoor (*примечание: мы изменили формулировку некоторых вопросов, чтобы улучшить грамматику или читабельность). Это отличные примеры вопросов, которые вы можете использовать, чтобы начать практиковаться в своих интервью.

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

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

Вот несколько примеров вопросов по программе FB от Glassdoor. Обратите внимание, что вы должны быть готовы ответить на гипотетические вопросы (например, как бы вы сделали XYZ) и поведенческие вопросы (например, расскажите мне о том, как вы сделали XYZ).

Вопросы для собеседования с менеджером программы Facebook — смысл программы

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

2. 2 Партнерство

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

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

Ниже вы найдете список примеров партнерских вопросов от Glassdoor. В дополнение к вопросам из отчетов об интервью Facebook мы также добавили пару вопросов от Google, чтобы предоставить дополнительные практические материалы (вопросы Google помечены в конце круглыми скобками).

 Вопросы для интервью с менеджером программы Facebook – партнерство

• Вы когда-нибудь сотрудничали с несколькими командами? С какими проблемами вы столкнулись?
• Приведите пример того, как вы работали с кросс-функциональными командами и какую роль вы играли?
• Скажи мне, что другие сказали бы о тебе
• Расскажите мне о случае, когда кто-то передумал по какой-то теме. Как вы к этому относитесь? (*вопрос Google)
• Как бы вы убедили кого-то выполнить вашу работу, если бы он оказался сложной личностью? (*вопрос Google)

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

Мы составили список примеров вопросов лидерства ниже. В дополнение к вопросам руководства мы также включили несколько поведенческих вопросов, которые вам могут задать на любом интервью в Facebook (например, «Каковы ваши сильные и слабые стороны?», «Почему Facebook?» и т. д.). Все приведенные ниже вопросы были представлены в отчетах об интервью на Facebook на Glassdoor.

Вопросы для собеседования с менеджером программы Facebook — Лидерство

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

2. 4 Роль/технический

Интервью с руководителями программ Facebook, как правило, сосредоточены на трех областях, которые мы только что рассмотрели. Тем не менее, вам также следует поработать над описанием работы и любыми другими подробностями о роли, которые вы можете найти.

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

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

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

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

Facebook — это престижно, поэтому есть соблазн полностью проигнорировать этот шаг. Но по нашему опыту, престиж сам по себе не сделает вас счастливым изо дня в день. Это тип работы и люди, с которыми вы работаете.

Если вы знаете руководителей программ, TPM, инженеров или менеджеров по проектам, которые работают в Facebook (или раньше), было бы неплохо поговорить с ними, чтобы понять, что такое культура. Кроме того, мы рекомендуем прочитать о 5 основных ценностях Facebook и хакерской культуре.

Как упоминалось выше, у вас будет четыре основных типа собеседований в Facebook: смысл программы, партнерство, руководство и ролевые / технические.

Для интервью по смыслу программы мы рекомендуем начать с нашего учебника по управлению программами, а затем углубиться в то, как Facebook управляет программами. В качестве отправной точки прочитайте эту запись в блоге Ананда Париха. Ананд является старшим TPM в Facebook, и хотя управление программами и техническое управление программами (TPM) не совсем одно и то же, в Facebook они во многом пересекаются.

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

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

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

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

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

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

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

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

Просмотреть бывших интервьюеров Facebook

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

Интервью с Доном Саймом

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

Немного предыстории того, почему я решил попросить о встрече с Доном: Дон — человек, стоящий за F#, новым языком программирования, который за последний год или около того превратился из исследовательского проекта в полноценный язык .NET. с полной поддержкой в ​​средствах разработки Microsoft. Ожидайте увидеть возможность создавать проекты F# (так же, как сегодня вы можете это делать с VB и C#) в Visual Studio в ближайших выпусках. Я не видел официального объявления о том, что F# будет частью выпуска Visual Studio 2010, но я должен верить, что это план. (Для ясности: это не вопрос, который я задавал Дону, это чистая спекуляция с моей стороны.)

Раньше я называл Дона и «отцом F#», и «мистером F#», но, учитывая его скромность, он предпочитает титул «дизайнер» или «исполнитель» F#. Ясно одно: Дон был значительной движущей силой F# и в значительной степени руководил как его разработкой, так и его переходом на полную поддержку со стороны Microsoft.

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

Рискуя повториться, я еще раз кратко пройдусь по некоторым основам…

F# — это прежде всего функциональный язык программирования, что означает, что его синтаксис сильно отличается от языков, с которыми в настоящее время работает большинство из нас. самый знакомый. В вашем коде вы определяете ряд значений с помощью вездесущего оператора «let», а значения, которые принимают аргументы, являются функциями. Каждое определяемое вами значение основано на входных данных или значениях, которые вы назначили ранее. И последнее значение, указанное в функции, является ее выходом. Это очень упрощенная точка зрения: в то время как код C# или VB, который следует этому шаблону, в значительной степени можно написать, возможности функциональных языков означают, что определенные типы операций намного проще выполнять: как Дон упоминает в интервью, F# очень хорош для например, работа с большими наборами данных.

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

Чисто функциональное программирование по-прежнему используется в основном в академических кругах: реальные реализации, как правило, время от времени должны выполнять побочные эффекты (классическая шутка заключается в том, что вы можете сказать, что чисто функциональные программы работают только потому, что коробка нагревается:- ), поэтому Дон отстаивал — на мой взгляд, очень мудро — разработку прагматичного функционального языка , который, хотя и способен создавать чистый код, не ограничивает вас в сохранении состояния и создании побочных эффектов. В первую очередь F# — помимо OCaml, прагматичного языка, на котором он основан, — это его способность работать поверх Common Language Runtime (CLR) и взаимодействовать как с компонентами .NET, так и с кодом, написанным на других .NET. языки.

Так почему я считаю, что это важно для нашей работы? Функциональное программирование действительно хорошо подходит для научного программирования в целом, и потребность в нем возрастает по мере того, как инженерный анализ и моделирование все теснее интегрируются в процесс проектирования. И у нас также есть все более полноценный набор инструментов на основе .NET, предоставляемый нашими различными продуктами, что означает, что код F # может быть интегрирован с — например. используется для анализа и модификации моделей почти во всех продуктах Autodesk для проектирования на базе Windows, будь то AutoCAD, Revit, Inventor или что-то еще.

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

В качестве недавнего дополнительного материала по этой теме я настоятельно рекомендую эти два видео, снятых на прошлой неделе на конференции JAOO в Дании. Первый — это основной доклад Андерса Хейлсберга, а второй — интервью с Андерсом Хейлсбергом и Гаем Стилом на канале MSDN 9. .

А теперь интервью с Доном.

[Типографские соглашения: мои собственные слова выделены полужирным шрифтом , слова Дона выделены обычным текстом. Я приложил редакционные комментарии [жирным курсивом в квадратных скобках] .]

Откуда взялась идея F#?

Основная предпосылка F# — убедиться, что типизированное функциональное программирование имеет место на платформе .NET. Это парадигма с огромным количеством возможностей, о чем уже давно знают пользователи таких языков, как Miranda, OCaml и Haskell. На меня также сильно повлияло то, что Intel хорошо использует типизированный функциональный язык (называемый FL) внутри компании. Они используют это при проверке своего оборудования и некоторых конвейерах проектирования.

Зачем использовать OCaml в качестве основы?

Типизированное функциональное программирование — это простые, композиционные, высокоуровневые манипуляции с данными с использованием основных ортогональных строительных блоков. OCaml — отличный пример системы функционального программирования с типизированными данными, оказавший большое влияние на направление работы в этой области. Подход OCaml к разработке языка имеет правильный характер для создания практичного функционального языка, а базовый язык хорошо известен и хорошо протестирован и часто используется в качестве основы для экспериментов. Сам OCaml стал результатом такого рода экспериментов, основанных на системе под названием Caml-Light.

С 1999 по 2003 год мы закладывали основы F#. В 1999 году мы начали проект 7, в рамках которого мы работали с исследовательскими группами по всему миру, чтобы ориентироваться на различные языки в .NET Common Language Runtime (CLR). Проект 7 привел непосредственно к включению .NET Generics в C# 2.0. Следующим логическим шагом была непосредственная реализация языка в стиле OCaml, и разработчики OCaml были очень воодушевлены, когда мы говорили с ними о переносе этого класса языков в пространство .NET. Это привело к ранним версиям F#.

Могут (и делают) ли люди выполнять кросс-компиляцию между F# и OCaml? Это возможно?

На практике кросс-компиляция не так важна: часто мешают различия в библиотеках между .NET и OCaml. Это больше касается перехода и повторного использования методов, а иногда и основных механизмов, таких как пример обработки PDF.

Тем не менее, это возможно, и мы делаем это в нашей группе для некоторых компонентов. Этот метод также используется в коммерческих целях — есть компания, которая создает инструменты для работы с PDF на основе OCaml — отличное применение функционального программирования — они выполняют кросс-компиляцию между F# и OCaml.

Каковы преимущества «функционального мышления» или «мышления FP» для людей, кодирующих на других языках (C++, C#, VB.NET)?

Вы должны посмотреть на проблемный домен, чтобы понять, применима ли FP. Мне нравится характеризовать области, в которых функциональное программирование наиболее применимо, как интенсивно использующие данные или интенсивно управляющие . Программирование AutoCAD является примером работы с интенсивным использованием данных. Символьное программирование также требует больших объемов данных: например. манипулировать PDF как форматом — всасывать его, анализировать, преобразовывать. Параллельное и асинхронное программирование требуют интенсивного управления и хорошо подходят для функционального программирования.

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

Первое, что замечают программисты на C# или C++, когда переходят к F#, — это то, как функциональное программирование меняет «программирование в малом»: их удивляет отказ от шаблонного кода и снижение сложности реализации объектов и функций. Следующее, что замечают люди, — это ориентация на неизменность. Я видел, как люди проводили целые доклады о том, как неизменность меняет ваш взгляд на программирование.

Верно и то, что концепции функциональных языков определенно оказывают влияние и на другие языки .NET.

Мне нравится говорить, что почти все, что мы добавили к платформе .NET в отношении языков начиная с версии 1.0, было функциональным программированием. Если мы посмотрим на дополнения к C#: дженерики, добавленные группой функционального программирования, основанные на принципах функционального программирования. Анонимные функции, синтаксис запросов в C# 3.0, метапрограммирование на основе дерева выражений — на все это сильно повлияло функциональное программирование. Даже итераторы C# ближе к функциональному программированию, чем к объектно-ориентированному программированию, что ясно проявляется в версии F# этой языковой функции.

.NET сама по себе также хорошо подходит для функционального программирования. Вы заметите, что в .NET нет действительно глубоких иерархий наследования; он больше ориентирован на делегатов и интерфейсы. Также многие типы являются неизменяемыми — например, System.DateTime. В целом я вижу в этом часть долгой тенденции к интеграции функциональных идей в объектно-ориентированное программирование.

Некоторые функции .NET 2.0 в значительной степени позволили вам реализовать F#, одним из которых являются дженерики. Предвидели ли вы это, реализовали ли вы дженерики, чтобы реализовать F#?

Да, безусловно. Это определенно был фактор. Первая версия F# — самая, самая первая версия — была выпущена в 2003 году, когда мы еще работали над дженериками .NET.

Так что это определенно было частью плана.

Мы планировали обеспечить поддержку этого класса языков. Мы получили то, что нам нужно, в .NET 2.0.

Кем вы себя считаете пуристом или прагматиком?

Меня никогда раньше об этом не спрашивали. 🙂  Для пуриста я прагматик, для прагматика я, наверное, пурист. Я, наверное, как раз посередине. 🙂

Моя работа определенно заключалась в преодолении разрыва между академически ориентированным миром программирования и промышленностью. Если вы вернетесь в 2004 год, то в наших сводных докладах по дженерикам .NET у нас есть эти слайды, на которых с одной стороны были научные круги, а с другой — промышленность, а между ними огромная пропасть. До Проекта 7 между этими лагерями было очень мало общения, за некоторыми заметными исключениями, такими как работа с дженериками Java. Было очень весело иметь возможность помочь преодолеть этот разрыв.

И у вас есть коллеги из Microsoft Research, которые очень консервативны.

Да, мы делаем все: в самой Microsoft у нас есть все, от ультра-пуристов до ультра-прагматиков.

И у вас все ладится?

Мы все ладим. Это так. 🙂

Что касается других языков, вы можете определить Haskell как более чистый. Я очень рад поддержке, которую мы получили от исследовательской группы Haskell здесь, в MSR: это был отличный период сотрудничества.

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

Да, очень. Было очень интересно послушать на прошлой неделе пользователей на конференции «Коммерческие пользователи функционального программирования» от Говарда Мэнселла из Credit Suisse. Credit Suisse широко использует F# в своей глобальной группе моделирования и анализа. Они описали, почему они используют F#, и это было очень забавно, их описания того, что люди думают о F# [см.0203 этот документ для заметок, которые случайно сделал мой старый профессор во время конференции] .

Они обсудили пару возможных будущих расширений F#, которые они хотели бы увидеть, например, предварительные условия. Что меня заинтересовало, так это то, что они поняли, почему мы не делаем этого, по крайней мере, в F# V1: часть нашей цели с F# состоит в том, чтобы все было просто. Это означает, что команда разработчиков F# сделала несколько преднамеренных ограничений в дизайне F#, чтобы сделать его простым и доступным.

Это важно: когда вы встретите другого программиста F#, он, вероятно, будет использовать одни и те же языковые устройства аналогичным образом. Языки — это не только мощь и выразительность: они также предназначены для совместного использования и согласованности.

С F# у вас есть прагматичная среда разработки, в которой вы можете создавать побочные эффекты по своему усмотрению. Изменчивость не используется по умолчанию, и вы сообщаете, когда переменные изменяются, потому что у вас есть явный оператор для этого… Ожидаете ли вы ситуацию, когда чистота будет проверяться автоматически, а код будет профилирован и развернут соответствующим образом?

Имеется в виду какое-то автоматическое распараллеливание?

Да, на самом деле это то, что я записал в первоначальном вопросе. 🙂

Внедрение чистого подмножества в F# — это не то, что мы будем делать в первой версии F#, но это направление разработки, которое мы будем рассматривать в будущем. Нашим главным приоритетом является гладкое взаимодействие без барьеров. Если вы посмотрите на пример программирования AutoCAD, который вы мне показывали, где вы перешли от данных к объектам AutoCAD: взаимодействие имеет важное значение. Эти объекты AutoCAD не имеют никакой гарантии чистоты, но крайне важно не ставить барьеры на пути создания этих объектов и управления ими.

Что касается распараллеливания, основное внимание в F# V1 уделяется явному распараллеливанию, чтобы дать вам инструменты для управления сложностью явного распараллеливания. Шаблон управления Async.Parallel fork-join, который вы использовали, является одним из примеров этого [Дон имел в виду пример в этого поста ] . Точно так же вы можете зафиксировать суть архитектуры на основе агентов, отправив результаты обратно в поток визуализации. Например, архитектура моделирования.

Автоматическое распараллеливание в конце концов дойдет до промышленности. Мы увидим сочетание технологий компиляции и распараллеливающих движков: база данных, такая как SQL Server, извлекает все виды параллелизма в движке, как и веб-сервер, как и графический конвейер. Компиляторы исходного языка могут обрабатывать относительно простые случаи, такие как автоматическое распараллеливание циклов for, интенсивно использующих ЦП, над чистыми объектами. Мы собираемся укротить параллелизм с помощью сочетания методов: ни один из них не станет серебряной пулей для решения проблемы параллелизма.

Чем вас привлекла парадигма функционального программирования?

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

Промышленность тоже начинает соглашаться.

Да, забавно, как все происходит. Для меня ключевым моментом является то, что такие платформы, как . NET, действительно позволяют вам взглянуть на мир на нескольких языках, что открывает возможности повторного использования и использования подходящего инструмента для работы. Сам F# реализован на смеси F#, C# и Visual Basic. Мы можем просто добавить эти компоненты, внести некоторые изменения, и они заработают.

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

Вы не увидите, чтобы F# захватил мир в смысле вытеснения C# и VB.NET.

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

Презентация означает разработку пользовательского интерфейса.

Верно. Для многих приложений F# уровень представления использует инструменты конструктора C# и Visual Basic с основными вычислительными и алгоритмическими компонентами в F#. Это не означает, что компоненты F# просто обрабатывают числа и символы — например, они могут обрабатывать асинхронное программирование — но реальная работа дизайнера презентаций, мы очень рады видеть, что это делается с использованием инструментов, которые генерируют, скажем, C# или VB. .

Похоже, интерес к F# проявлялся в секторе финансовых вычислений. В каких других областях вы ожидаете найти F# привлекательным?

На ум приходят инженерные области. Они связаны с основными приложениями, такими как AutoCAD и ГИС, и традиционно эти приложения не имеют хорошей расширяемости с помощью типизированного функционального языка программирования. Таким образом, F# — это первый случай, когда люди смогут использовать типизированное функциональное программирование в сочетании с этими инструментами.

В более широком смысле мы видим большой интерес со стороны технических областей вычислений, то есть науки, технологии, инженерии, математики. Еще одна область — статистическое машинное обучение. Посмотрите, что делает такая компания, как Google: умные веб-приложения и реклама, основанная на статистической обработке массивных наборов данных. Поначалу не так уж очевидно, зачем веб-рекламная компания нанимает так много программистов, но программирование лежит в основе их бизнеса, и это своего рода программирование, в котором F# превосходит другие. У нас было несколько тематических исследований внутри Microsoft, использующих F# для обработки данных веб-рекламы, и он был чрезвычайно успешным в этой роли. Поэтому, когда я говорю «статистическое машинное обучение», это звучит как какая-то нишевая сфера: но на самом деле на хороших алгоритмах теперь можно строить целые предприятия.

Часто ли F# используется на стороне сервера?

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

Я полагаю, что после того, как F# превзойдет стадию CTP и станет более доступным, клиентская сторона получит более широкое распространение.

Случаи, подобные AutoCAD, интересны тем, что данных больше на клиентской машине. На самом деле, я бы не обязательно классифицировал F# как клиент или сервер: на самом деле речь идет о том, где находятся данные. Например, внутри Microsoft используется F# для анализа списков управления доступом (ACL) на компьютерах во внутренней сети. ACL очищаются процессом системного администратора и анализируются программой F#. Программы F# выполняются в момент объединения данных.

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

Итак, когда вы спрашиваете «где находится код F#?» это весь путь от разработки концепции до фактического исполнения на серверах. Так что это на стороне сервера, но пользователи не думают об этом таким образом: они будут думать о себе как о парнях, занимающихся количественными финансами, которые пишут алгоритм.

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