Какой-либо хороший связанный с потоками вопрос о собеседовании?
При интервьюировании выпускников я обычно задаю им вопросы о структурах данных, алгоритмах и теории сложности. Я действительно хотел бы задать вопрос, который позволит им показать свое знакомство с многопоточными понятиями, не живя в конкретные вопросы языка.
Какие-либо хорошие вопросы? Единственный вопрос, о котором я мог думать, состоит в том, как записать Singleton, которая поддерживает многопоточный доступ.
4 ответа
Я считаю, что классический вопрос «напишите мне очередь потребителя-производителя» неплохим. Вы можете поговорить о синхронизации заранее в течение пяти минут или около того (например, начните с «Что делает Object.wait () ? Какие другие методы для Object связаны с «Не могли бы вы привести мне пример, когда вы могли бы их использовать? Какие другие методы параллелизма вы могли бы использовать на практике (потому что на самом деле использование примитивов wait / notify - довольно редкий подход)?»). Убедитесь, что кандидат обращается (или, по крайней мере, ясно дает понять, что он знает) как атомарность («пропущенные обновления»), так и волатильность (видимость нового значения в других потоках)
Затем, после того, как вы побеседуете о теории из них, заставьте их потратить несколько минут на написание кода для примитивной очереди производитель-потребитель. Это должно быть простым для всех, кто действительно понимает, о чем они говорили выше, но отсеивает тех, кто может «говорить о разговоре», но на самом деле не понимает его на практике (возможно, самая опасная группа).
Что мне нравится в этих мини-упражнениях по кодированию, так это то, что их часто легко расширить. Например, если кандидат легко выполняет задачу, вы можете спросить, как он расширил бы ее для ситуации ХХХ - придумывайте требования, которые, как вы знаете, будут раздвигать пределы запрошенного вами простого решения.Это не только позволяет вам адаптировать глубину вопросов, которые вы задаете, но и дает некоторое представление о том, насколько хорошо кандидат справляется с разъяснением требований и модификациями существующего дизайна (что очень важно в этой отрасли).
Здесь вы можете найти несколько тем для обсуждения:
- реализация потоков (ядро против пользовательского пространства)
- локальное хранилище потоков
- примитивы синхронизации
- взаимоблокировки, живые блокировки
- Различия между мьютексом и семафором.
- Использование переменных условий.
- Когда не следует использовать потоки. (например, мультиплексирование ввода-вывода)
Поговорите с ними о популярной, но малоизвестной теме, где важна обработка потоков.
Я рекомендую вам построить веб-сервер с ними, конечно, только на бумаге или просто на словах. Результат должен выглядеть примерно так: есть основной поток, он прослушивает сокет. Когда что-то приходит, он передает сокет в пул, а затем этот поток возвращается к прослушиванию сокета. В пуле есть фиксированное количество слотов. Потоки обработки запросов предназначены для получения работы из пула. Выясните, что лучше, если потоки одновременно проверяют пул или основной поток списка выбирает свободный слот / поток для нового входящего запроса. Попробуйте написать небольшой псевдокод или график для обеих сторон обработки пула.
Давайте представим небольшое приложение: счетчик страниц , которое сообщает, сколько запросов страниц было выполнено с момента запуска сервера. Не говорите им, что счетчик должен быть защищен от одновременной модификации, пусть они узнают, как это сделать, с помощью мьютексов, синхронизации или чего-то еще. Возможно, вы могли бы пропустить часть веб-сервера, проще указать приложение счетчика страниц.
Другой пример - чат , с 2+ клиентами и сервером, выясняющий, как решить проблему, чтобы все сообщения приходили в одинаковом порядке для всех клиентов. Или рефлекторная игра : сервер ждет 1..5 секунд в случайном порядке, затем говорит «пика-бу», и побеждает игрок, который первым нажмет пробел. Укажите его с 2 игроками, затем попробуйте расширить его до N игроков.
Также следует помнить об АЭС.НПП расшифровывается как «непрограммирующий программист». Есть парни, которые могут говорить о проблемах программирования, они знают все 3/4-буквенные сокращения (в мире Java есть лот , EJB, JSP, XSLT, и мой любимый: POJO, который означает чистые старые объекты Java, лол), они понимают и модифицируют коды или делают аналогичные программы из базы, но они терпят неудачу даже с небольшими проблемами, они должны делать это сами, например поиск ближайшего к базе элемента в массиве. Иногда на это уходят месяцы. Они хорошо выступают на собеседованиях, потому что готовятся к ним. Может, они даже не знают, что это АЭС, это известный эффект: http://en.wikipedia.org/wiki/Dunning-Kruger_effect
Трудно распознать противоположных парней, которые не слышали о модных библиотеках или шаблонах, но могут узнать это даже на собеседовании. (Личное замечание: мое последнее интервью было в 1999 году, и, похоже, я больше не буду давать интервью. Я никогда раньше не слышал о динамических веб-страницах, но я понял термин «сеанс» во время интервью, вопрос был о том, как создать простое веб-приложение о повешенном человеке. Меня наняли.)