Який сенс у детальному питанні про інтерв'ю для старшого розробника? [зачинено]

У мене було інтерв'ю з внутрішнього просування, щоб здобути звання програміста вищого рівня, щось на кшталт Senior plus. І мене опитали близько 7 людей, які використовують різні технології, і люди, які використовують одну і ту ж технологію зі мною (. Net), зазвичай задають детальний запитання про техніку, яке насправді легко можна знайти через Google, наприклад, що таке JIT, як працює GC , різниця між списком та масивом, абстрактним класом та інтерфейсом, делегатом та подією, навіть яким є ім’я класу при обробці файлу завантаження тощо. проста дискусія. Але для більшості мого вибору дизайну вони, здається, просто не зацікавлені.

Я ще не отримав результат, і це було б близько кінця цього тижня, але ось моя стурбованість:

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

Я відчуваю себе чудово, якщо ви виявили, що я не надто багато досвіду в цій галузі, наприклад, від юніорського до середнього рівня, але коли ви прагнете співбесіду з хлопцем вищого рівня, чи не варто більше зосереджуватися, щоб побачити, наскільки це хлопець логічне мислення та як добре він / вона вирішує проблеми? Чи всі просто думають, якщо ви знаєте кожен детальний дрібний технічний матеріал, то ви старший +. Перевіряючи ці запитання із інтерв'ю, я виявив, що таких питань є більше.

Якщо я витрачу 5 днів на те, щоб переглядати ці запитання із запитаннями про інтерв'ю, я можу з легкістю змусити цих хлопців почути себе нічого, але чи це насправді щось означає? Таке інтерв'ю може легко дати людям добре запам'ятати речі, які отримують більшу зарплату, навіть якщо вони не мають уявлення, як вирішити проблему з труднощами.

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

Або це насправді лише моя проблема, що мені слід більше намагатися запам’ятати все в MSDN у своєму розумі, щоб я міг працювати навіть без нього та Інтернету?

EDIT

Для кращого пояснення моєї ситуації з приводу стурбованості Франка щодо завдань. Вибачте, це моє погано не з’ясувало ці передумови.

Насправді змін у завданні конкретно не буде, я особисто думаю, що я вже грав як старший, як перегляд коду, члени наставника, перегляд доктора бакалавра та надання думок про техніку, архітектура дизайну нових проектів, це ще тільки моя назва я залишився без старших, і я попросив отримати одну, щоб відобразити платіж і провести таке інтерв'ю. Це компанія Saas, тому люди залишаються в одному проекті до тих пір, поки цей продукт ще живий, це призводить до того, що вони потребують спроможності людей розробляти нові функції на основі поточного продукту, виправляти труднощі з технікою на живих серверах, дизайн / перегляд коду / наставництво члени А назви вищого рівня, засновані на техніці, були б Архітектором, і у нас немає жодної роботи, подібної до Технічного експерта. І я погоджуюся, якщо ви хочете зіграти роль Технічного експерта, ви повинні дізнатися більше про техніку, яку ви використовуєте. Вибачте, це моє погано не з’ясувало ці передумови.

Як старший інженер і людина, яка наймає інженерів, здається, що процес інтерв'ю пропустив цілу частину концептуальної інформації.

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

Сподіваюся, це спрацює добре.

Не зовсім впевнено, які завдання старішого + у вашому випадку включатимуть. Завжди майте на увазі, що набагато важливіше знати, якими є завдання вашої роботи, а не те, як називається ваша посада. Хоча наявність старшого перед посадою може вплинути на ваш фінансовий результат, це жодним чином не говорить про те, що ви насправді робите у своїй роботі. Однак існують два різні типи "розробників" старшого рівня.

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

Якщо вас опитали на таку посаду, то справді щось не так. Я погоджуюся з gahooa, що таке інтерв'ю має зосередитись на великій картині думки кандидата, яка, здається, у вашому не вистачає.

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

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

У цьому випадку ви, можливо, не зможете сильно вплинути на загальну архітектуру системи та напрямок компанії. Натомість ви зосередитесь на рівні дизайну. Зверніть увагу, що всі питання, які ви навели як приклади, ідеально вписуються в цю категорію. Від старшого розробника, відповідального за розробку SW, я очікую, що він / вона знатиме такі речі, як JIT, GC, структури даних тощо тощо - без потреби шукати нічого, крім самих складних деталей. Якщо ви повинні створити програмне забезпечення, але не знаєте різниці між масивом і списком, ви опинилися в неправильному положенні.

Читаючи ваше запитання, я підозрюю, що ваша посада (поточна та запропонована) орієнтована на розробку програмного забезпечення. У такому випадку ви можете переосмислити, що ви насправді повинні знати / пам’ятати, а що ні. Зважаючи на те, що ви працюєте з цими речами день у день, мало би щось шукати, щоб відповісти на елементарні запитання, як-от такі.

Зі сторони: колишній мій професор мав цікаву звичку задавати питання з елементарних предметів на усних іспитах на курсах підвищення кваліфікації. Хоча ці предмети ніколи не були чітко висвітлені в курсі підвищення кваліфікації, студент повинен був знати їх з початкової освіти. В інтерв'ю (будь-якого роду) я також дотримуюся такої поведінки, тому що за останні роки я був свідком того, як студенти / кандидати на щось "просунуте" сильно бракують підстав. Враховуючи це міркування, я, наприклад, не маю жодних сумнівів щодо запитання кандидата на вищу посаду, що таке модель слухача, або які плюси є в тому, щоб утримувати слухачів у масиві проти списку проти набору.

Мені дуже шкода, але я не думаю, що такі запитання, які вам задавали, - це дрібниці, які слід виконувати в Google за потреби. Це може бути правдою для назви класу під час обробки файлу завантаження, але:

• що таке СІТ: Це фундаментальна технологічна проблема. Старший програміст обов'язково повинен знати, що це означає принаймні на високому рівні. Наприклад, це впливає на продуктивність різних віртуальних машин та режимів виконання, тому це слід принаймні враховувати при оцінці нової технології.
• як працює GC: аналогічно вище. Алгоритми для GC є по суті досить простими, і, принаймні, слід ознайомитись із поколінням GC порівняно з позначкою & sweep, порівняно з підрахунком посилань та різними компромісами.
• відмінність між List та Array: це основне питання, про яке я б очікував, що молодший програміст повинен знати
• абстрактний клас та інтерфейс: те саме, що вище. Я не розумію, як слід очікувати архітектури складної системи, не знаючи принаймні інтерфейсів
• делегат та подія: знову ж таки, щоб створити надійну та гнучку систему, делегування подій є однією з основних моделей.

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