Какой смысл в этом методе подробного интервью для Senior dev? [закрыто]

У меня было внутреннее собеседование, чтобы получить звание программиста более высокого уровня, что-то вроде Senior plus. И у меня было интервью около 7 человек, использующих разные технологии, и люди, использующие одну и ту же технологию со мной (.Net), обычно задают очень подробный вопрос о технике, который может быть легко найден через Google, например, что такое JIT, как работает GC , разница между List и Array, абстрактный класс и интерфейс, делегат и событие, даже каково имя класса при обработке файла Upload и т. д. И у меня есть только один вопрос об одной из моих идей проекта в моем проекте и просто простое обсуждение. Но для большинства других моих дизайнерских решений они кажутся просто неинтересными.

Я еще не получил результат, и это будет примерно в конце этой недели, но вот мое беспокойство:

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

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

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

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

Или это на самом деле просто моя собственная проблема, что я должен стараться помнить все, что у меня есть в MSDN, чтобы я мог работать даже без него и без интернета?

РЕДАКТИРОВАТЬ

Для лучшего объяснения моей ситуации относительно беспокойства Фрэнка по поводу рабочих заданий. Извините, это плохо, я не прояснил этот фон.

На самом деле никаких изменений в заданиях не будет, лично я думаю, что я уже играл в качестве старшего, например, в обзоре кода, наставниках, в просмотре документации бакалавра и в высказывании технических соображений, в дизайне архитектуры новых проектов, это всего лишь мое название до сих пор остался без старшего, и я попросил получить один, чтобы отразить платежную ведомость и привести к такому собеседованию. Это компания Saas, поэтому люди остаются в одном проекте до тех пор, пока этот продукт еще жив, поэтому им нужно, чтобы люди могли разрабатывать больше новых функций на основе текущего продукта, устранять трудности с техникой на живых серверах, проектировать / проверять код / ​​наставлять члены И звание более высокого уровня, основанное на технике, было бы Архитектором, и у нас нет никакой работы, подобной Техническому Эксперту. И я согласен, что если вы хотите сыграть роль технического эксперта, вам следует больше узнать о технологиях, которые вы используете. Извините, это плохо, я не прояснил этот фон.

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

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

Надеюсь, это сработает.

Не совсем уверен, что задачи старшего + в вашем случае будут связаны. Всегда имейте в виду, что гораздо важнее знать, каковы задачи вашей работы, а не как называется ваша должность. Хотя наличие старшего сотрудника перед вашей должностью может повлиять на ваш финансовый результат, оно никоим образом не говорит о том, что вы на самом деле делаете в своей работе. Однако есть два разных типа «разработчиков» высшего уровня.

Системный архитектор

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

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

Технический эксперт

В этом случае вы не сможете сильно повлиять на общую архитектуру системы и направление деятельности компании. Вместо этого вы сосредоточитесь на уровне дизайна. Обратите внимание, что все вопросы, которые вы дали в качестве примеров, идеально вписываются в эту категорию. От старшего разработчика, ответственного за дизайн ПО, я ожидаю, что он / она будет знать такие вещи, как JIT, GC, структуры данных и т. Д. - без необходимости искать что-либо, кроме самых сложных деталей. Если вы должны сделать программный дизайн, но не знаете разницу между массивом и списком, вы находитесь в неправильном положении.

Прочитав ваш вопрос, я подозреваю, что ваша должность (текущая и предлагаемая) сосредоточена на разработке программного обеспечения. В этом случае вы можете переосмыслить то, что вы должны знать / помнить, а что нет. Учитывая, что вы работаете с этими вещами изо дня в день, вам не нужно искать что-то для ответа на такие элементарные вопросы.

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

Извините, но я не думаю, что вопросы, которые вам задавали, - это пустяки, которые нужно гуглить при необходимости. Это может быть верно для имени класса при обработке файла Upload, но:

• Что такое JIT: Это фундаментальная технологическая проблема. Старший программист должен обязательно знать, что это значит, хотя бы на высоком уровне. Например, это влияет на производительность разных ВМ и времени выполнения, поэтому, по крайней мере, это следует учитывать при оценке новой технологии.
• как работает GC: похоже на вышеизложенное. Алгоритмы для GC по своей сути довольно просты, и, по крайней мере, нужно быть знакомым с поколением GC в сравнении с меткой и разверткой, в сравнении со счетчиком ссылок и различными компромиссами
• Разница между List и Array: это основной вопрос, который, как я ожидаю, должен знать младший программист
• абстрактный класс и интерфейс: такие же, как указано выше. Я не понимаю, как от архитектора ожидается сложная система без знания хотя бы интерфейсов
• делегирование и событие: опять же, для разработки надежной и гибкой системы делегирование событий является одним из основных шаблонов.

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