а зачем знать точные названия, если с помощью русского мата он мог вам объяснить, как всё работает и что для чего нужно. В комментах уже было, не требуется ждать ответа «по учебнику», пусть говорит своими словами.
Ну так объясни мне, такому невежде, как с помощью интерлокед-функции остановить поток для ожидания.
Дядюшка Рихтер имел в виду, что критические секции реализуют подсчет блокировок с помощью интерлокед функций.
И не кажется ли вам что стоит уже завязывать с оффтопиками.
А про сроки, коммуникабельность и т.д. и т.п. я писал, в рамки статьи это не входит и это вопросы которые решаются уже после первичного отсева по техническим навыкам.
А я и не считаю вопрос «Назовите методы класса Object» простым, я также как и вы считаю его книжным, не элементарным и тоже думаю что на практике знать все методы какого-нибудь класса — это ненужно и это вообще утопия. А вот знать для чего нужен «Object» — я думаю важно.
Постараюсь. Я по зову судьбы последние 2 года имею к написанию кода посредсвенное отношение, да и если приходится писать/смотреть код то в основном на C#. Данная статья, в совокупности со статьей про разворачивание сервера символов, является больше статьей на расширение рабочего пространства разработчиков и подстегивания их использовать инструментарий повышающий качество продукта. В ближайшем будущем постараюсь сделать статьи по развертыванию сервера индексации исходников и по удаленной отладке (в контексте взаимодействия с отделом качества)
Творческие способности претендента тяжело выявить на собеседовании, для этого можно и нужно использовать испытательный срок. Конечно материал из статьи не подойдет если вы набираете в компанию джуниоров-студентов, которых будете обучать и растить (т.е. у вас на это есть время и деньги) я описал подход для поиска конкретных профессионалов на конкретные должности в софтверную компанию на существующий или новый проект который требует быстрого входя для получения отдачи.
Уже писал и ещё раз повторю, внимательнее читаем то что в статье помечено как Profit, мой коментарий-разъяснение: «Я не требую энциклопедических знаний, я смотрю на то что мне человек отвечает». Например, тот-же вопрос по объектам ядра, челоек, много лет успешно программивший малтитрединг обильно пользовался допустим эвентами и критическими секциями. Я не буду заканчивать интервью, если он не вспомнит про семафоры, я дальше просто спрошу с какими проблемами он сталкивался в подобной работе. Если человек упоминает критические секции и мъютексы — то я спрошу про их различие. Если человек программил базы данных, то я неприменно попытаюсь у знать о том как он пользовался транзакциями и т.п.
Это вопросы взятые не из книг, это вопросы реальной жизни, непонимание которых в короткой перспективе не несет особых проблем, но чревато страшными поседствиями в будущем.
Примеры? ловите:
1. Человек не знающий различий между мъютексом и крит. секцией может везде вам в коде напихать мъютексов. А потом вы будете сидеть неделю с Intel VTune в поисках того, почему пограмма так долго живет «в ядре».
2. Человек который не умеет пользваться IUnknow, а также шаблонами (типа ATL) для управления наследниками IUnknown вам наплодит кучу AV в коде когда пойдут обращения к объектам которые уже давно удалены. Или наоборот будут утечки памяти.
3. Человек, который не умеет работать с указателями в C++ вам наваяет столько проездов по памяти, что век будете его матом вспоминать.
Ну тем более, а я рассматриваю интервью практически как ваш директор по разработке. Мы немного с разных колоколен смотрим на процесс проведения собеседования, поэтому и процессы у нас разные, хотя цель одна.
Это уже на совести HR'а, насколько он честно сообщает наши решения кандидату. Поверьте, меня и самого не раз так кидали. Почему-то практика не сообщать, что ты послан и не сообщать причину — это нормальное явление. Я как-то беседовал со знакомой руководительницей HR подразделения по этому поводу. Она мне плела что-то про какие-то судебные иски на опротестование решений и т.д. и т.п. в общем я не компетентен в этом вопросе (о поведении HR'ов) так что не могу нормально оправдать или осудить такое поведение.
потому что по командности мы «примеряем» человека к нашей команде, пытамеся оценить как он туда впишется и насколько эффективно будет взаимодействовать с остальными членами, аналогично с лояльностью а к проф навыкам я для их динамичности прибавлю ещё и обучаемость.
К тексту статьи — на правах лирического отступления, ну и ещё из-за того что основной темой статьи является экономия времени на собеседованиях, ну и отступление про KPI было про то-же.
А вам не попадались экземпляры, которые на такой вопрос начинали длинную, минут на 10-15, руладу о своих программерских приключениях подмешивая туда как можно больше аббревиатур, пытаясь напрочь забить вам слуховой канал восприятия и полностью сбить вас с толку? И потом этот клубок вам долго распутывать цепляясь за мелкие вещички которые вам удалось разобрать в бесконечном потоке слов.
Когда секция ждет, она упирается в объект ядра, с высокой долей вероятности именно в неименованый мъютекс. Прежде чем зайти упереться в мъютекс проверяются данные структуры о занятости секции, этим и избегается контекст-свитч при незанятой секции.
Кстати, насчет самоутверждения… знаете как бывает, я несколько раз был наблюдателем на интервью в которых человек который собеседует, понимая что канидидат overqualified и не подойдет, всё равно продолжал разговоры и выяснял детали работы разных библиотек (ну для собственного развития).
Суть не в этом. И топик не про компиляторы, а про подбор персонала.
Ещё раз распишу:
я привел не удачный пример, который может трактоваться по разному на разных платформах и разными компиляторами, но это не меняет сути. Потому что я задам человеку вопрос «Почему?» (если мне он не ответит сразу развернуто) и по его ответу можно будет понять, насколько он в теме.
Если бы оно не сваливалось бы в ядро, оно бы жрало проц :)
Дядюшка Рихтер имел в виду, что критические секции реализуют подсчет блокировок с помощью интерлокед функций.
И не кажется ли вам что стоит уже завязывать с оффтопиками.
Это вопросы взятые не из книг, это вопросы реальной жизни, непонимание которых в короткой перспективе не несет особых проблем, но чревато страшными поседствиями в будущем.
Примеры? ловите:
1. Человек не знающий различий между мъютексом и крит. секцией может везде вам в коде напихать мъютексов. А потом вы будете сидеть неделю с Intel VTune в поисках того, почему пограмма так долго живет «в ядре».
2. Человек который не умеет пользваться IUnknow, а также шаблонами (типа ATL) для управления наследниками IUnknown вам наплодит кучу AV в коде когда пойдут обращения к объектам которые уже давно удалены. Или наоборот будут утечки памяти.
3. Человек, который не умеет работать с указателями в C++ вам наваяет столько проездов по памяти, что век будете его матом вспоминать.
К тексту статьи — на правах лирического отступления, ну и ещё из-за того что основной темой статьи является экономия времени на собеседованиях, ну и отступление про KPI было про то-же.
Ещё раз распишу:
я привел не удачный пример, который может трактоваться по разному на разных платформах и разными компиляторами, но это не меняет сути. Потому что я задам человеку вопрос «Почему?» (если мне он не ответит сразу развернуто) и по его ответу можно будет понять, насколько он в теме.