Периодически я занимаюсь, в некотором смысле, довольно глупой деятельностью. Я хожу на собеседования. Точнее хожу, зная, что я не хочу там работать, а иду, исключительно, узнать какие сейчас вопросы задаются соискателям высоких зарплат. Почему же тогда парадокс? Об этом позже. Из всех моих личных мнений – это одно из самых сомнительных. А пока перейдем к наиболее интересным, на мой взгляд, вопросам. Оговорюсь сразу – вопросы касаются платформы .NET и для разработчиков других платформ могут быть совершенно не актуальны вплоть до введения в заблуждение.
1. Какая разница между Thread и Task? Вопрос в принципе интересный. Если искать информацию в интернете, то найдется несколько разрозненные взгляды на эту разницу. В целом – Thread низкоуровневая системная сущность, а Task абстрактная надстройка, берущая под собственный контроль управление потоками вплоть до контроля их создания и запуска. То есть использование Thread требует более высокой квалификации для контроля над создаваемыми сущностями. Task берет на себя часть этой работы, позволяя заняться задачами, относящимися сугубо к бизнес-логике процесса. В чем парадокс? Знание ответа на данный вопрос подразумевает что, берясь за задачу, программист задается вопросом «что выбрать?». Нет, не задается. Сейчас либо все используют Task, не вникая в тонкости, либо используют Thread по старой памяти.
2. В чем техническая разница между Dictionary и List при работе с большими объемами данных? Суть – List это абстракция над банальным массивом. Dictionary – ассоциативный массив реализованный через связанный список. При добавлении нового элемента в List – если текущий список исчерпал выделенную память – то будет произведено выделение памяти в двукратном объеме и произойдет полное копирование в новый объект, что, мягко говоря, не быстро. Добавление элемента в связанный список такого действия не вызывает, следовательно очевидна оптимизация. В чем парадокс? Для полноценного использования данной оптимизации и получения реального выхлопа – нужны списки, состоящие из миллионов позиций. Содержание таких объектов в памяти уже задачка интересная. Лично мой профессиональный опыт не содержал задач, требующих содержания длинных списков в памяти. Более того – они требовали свести к минимуму объемы требуемой памяти и использование небольших списков.
3. Какие необходимо создать индексы для оптимизации запроса? Тут без банальных определений никак – Индекс это дерево, узлы которого состоят из ключевых полей, а в листьях (узлах самого последнего уровня) содержатся ссылки на записи таблицы. Кластерный индекс может быть один на таблицу и в листьях содержатся не ссылки на записи в таблице, а сами записи. Не кластерные индексы создаются для оптимизации запросов по полям, по которым производятся поисковые запросы. Вроде ответ достаточно очевиден. В чем же тут парадокс? Знание ответа на данный вопрос очень полезно, но применение этих знаний на практике требует определенных условий. Например, рабочий процесс выстроен так что создание индексов осуществляют не сотрудники, обслуживающие серверва БД и имеющие все необходимые метрики производительности, или SQL-разработчики, глубоко знающие устройство базы данных, а разработчики, знающие всё. На мой взгляд тут маленький ящичек Пандоры.
Мой опыт показывает что подобные вопросы, как и вопросы, касающиеся знаний алгоритмов задаются техническими директорами, которые уже заметное время не занимаются разработкой. При этом собеседование в той же самой компании с программистами или непосредственным руководством, как правило, состоит из достаточно тривиальных практических вопросов. Встает вопрос – а знание ответов на эти вопросы действительно требуется для данной работы? Ваши программисты тонко намекают, что не нужно. Но очередной парадокс будет в том, что незнание ответов на эти вопросы вызовет стремительнейшую деградацию профессиональных навыков разработчиков, а это приведет к утрате знаний об этих тонкостях. А следом – дальнейший рост системных требований программного обеспечения.
