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

Останнім часом я замислювався над питаннями інтерв'ю і розмірковував про поганий досвід інтерв'ю, який мав у минулому. Однією з особливих приміток є те, де я запитав інтерв'юера, чому команда вирішила використовувати EJB 3 над Spring у своєму продукті. Інтерв'юер дуже сильно зірвав мені обличчя, кричачи "Оскільки весна - це не все, і закінчиться вся розробка програмного забезпечення Java, хочете ви цю роботу чи ні?". У відповідь на це я сказав йому, що це, мабуть, не для мене робота, і я негайно пішов з інтерв'ю.

На початку інтерв’ю мені повідомили, що компанія має високу плинність кадрів, продукт, над яким вони працювали, спочатку створювався в Modula-3, потім переносився на Perl і нарешті на Java. Мені вручили буклет з 10 сторінок технічних питань, що стосуються Java, EJB, SQL та JDBC, і мені було задано питання про стеки технологій, з якими я працював. Коли я запропонував задавати питання, я вважав, що розумно запитати їх про їхній стек технологій і отримати розумні відповіді, а не відправляти інтерв'ю в полум’я.

Запитання: Чи корисно вивчити вибір архітектури, прийнятий в інтерв'ю? Якщо ні, то чому?

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

1) З'ясуйте, який їхній розум та ставлення до розробки програмного забезпечення. 2) Визначте, чи відповідає їх підхід тому, як я підходив би до таких проблем.

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

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

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

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

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

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

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

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

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

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

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

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

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

який один раз спав з продавцем продавця Oracle і вирішив, що вся подальша розробка буде здійснюватися за допомогою веб-служб Java 1.4, Oracle ERP та інтерфейсу Borland C ++, використовуючи в основному відмінені сторонні компоненти графічного інтерфейсу, і ми швидше витрачаємо 60 000 доларів на місяць, підключаючи отвори, щоб утримати клієнтів. від перестрибування судна, ніж переглядати будь-які рішення та робити постійні вдосконалення, які можуть принести новий дохід, якщо нам пощастить. Не качай човен, що з тобою не так. "

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

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

Запитання: Чи корисно вивчити вибір архітектури, прийнятий в інтерв'ю? Якщо ні, то чому?

Це абсолютно добре, я б розглядав це як позитив.

Якщо ваш інтерв'юер не може з цим впоратися, він говорить про них багато - не ви.

Я б хвилювався, якби молодший НЕ зацікавився дизайнерськими рішеннями, це виявило б недоцільність / інтерес до предметної області і не виявляє бажання вдосконалювати себе.

Я з розуму, це важливо . Я працював надто багато робочих місць над безглуздими дизайнерськими рішеннями або тому, що ніхто не знав кращого, не піклувався про навчання, або був мандат керівництва використовувати все, що читав генеральний директор в журналі / бачив в Інтернеті / мав когось скажіть йому, що це "наступна велика річ", без розгляду альтернатив. Ці роботи були всі жалюгідні місця для роботи.

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

Задавання таких питань також призводить до підвищення інтересу компанії до вдосконалення та компетенції. Як сказав хтось вище, це одне, якщо ви отримаєте відповідь на кшталт (я не знаю Java, але використовуйте .NET, тому буде використовувати .NET приклади) Коли ми писали додаток, не було зрілих ORM, тому ми використовували збережені процедури з рівень шлюзу даних. Ми хотіли б перейти до Entity Framework в майбутньому та ще одна річ, щоб отримати відповідь, як-от ми просто використовуємо збережені процедури. Entity Framework виглядає страшно і може зажадати роботи над рефактором, і ми не можемо нічого переробляти, оскільки у генерального директора є список нових функцій, над якими він хоче працювати, і якщо ми витратим час на перегляд Entity Framework, він звільнить нас для того, щоб витрачати час. Один вказує на розуміння та прагнення до вдосконалення, інший вказує на посереднє в кращому середовищі, де кожен робить найменший мінімум, щоб висколити.

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

відповідь: Це гарна ідея запитати про прийняття архітектурних рішень. Але вам потрібно бути обережним, як ви ставите такі питання.

Простіше кажучи: ви повинні запитати " Як ви вирішили обрати технологію X над технологією Y? ".

Ви хочете сформулювати це таким чином, щоб повідомити, що вас, як правило, цікавить процес прийняття рішень в команді. Ніхто не захоче переглядати кожне спадкове рішення, яке компанія коли-небудь приймала зі своїм кандидатом.

Коли ви запитаєте " Чому ви вибрали технологію X над технологією Y? ", Може вийти з того, що ви не погоджуєтесь з їх рішенням (що нормально ... але це можна сприймати як вороже) або ви хочете похвалитися тим, наскільки ви знайте про технології, про які йдеться (що для когось буде дратувати), незважаючи на ваші добрі наміри.

Мені подобається просити інтерв'юера розповісти мені про невдале дизайнерське рішення, і що було зроблено далі. Це дає кілька корисних відомостей:

1. Якщо начальник не може визнати будь-яку помилку форми або тимчасовий збій, це, напевно, начальник, на який ви не хочете працювати.
2. Ви можете розповісти, як компанія справляється зі стресовою ситуацією.

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

Зрештою, якщо ви говорите про задоволення роботою, технологія (мова / платформа / компілятор / що завгодно) має значення не так як особи, які займаються, та робоче середовище.

Кілька років тому я був на співбесіді і мені задавали різні технічні питання щодо мови програмування ... що я не робив добре (60/40 правильно / неправильно). Дискусія перейшла до проекту, який вони мали в руках, і я почав задавати питання щодо дизайну, а потім вказав на кілька проблем та обмежень, які вони запровадять.

Мені запропонували роботу наступного дня. На жаль, я не зміг прийняти це з особистих причин.

Задавати питання щодо дизайну не повинно бути проблемою, якщо це інтелектуальні запитання, особливо якщо ви потім можете пов’язати їх зі своїм бізнесом.

Я не робив багато інтерв'ю, але, з вашого досвіду, я зробив би висновок:

а) Добре, якщо ви хочете прийняти зважене рішення про те, чи бажаєте ви роботи;

б) Не нормально, якщо ви вже вирішили, що хочете роботу.

Люди можуть легко образитися на доброякісні переписки щодо їх вибору. Це жахливо погана риса, але звичайна.

Ось кілька порад

1. Питання, чому вони обрали якесь існуюче рішення, може бути поганим питанням, оскільки, ймовірно, команді розробників не було надано шансів змінити чи обрати його.
2. Також команда, ймовірно, вже знає, чому технологія не була найкращим вибором
3. Але, на жаль, останнє, що потрібно будь-якій команді розробників, - це люди, які намагаються змінити архітектуру або поставити під сумнів вибір, який було зроблено 10 років тому, - це створює враження, що їх технологія - це вже старі спадщини, і такі повідомлення, що відбуваються в команді, можуть зробити розробників нещасними. про поточну ситуацію
4. Таким чином, в інтерв'ю, останнє, що ви повинні зробити, це створити враження, що ви збираєтесь весь час скаржитися на вибір, над яким команда не має контролю