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

Яке питання ви вважаєте особливо цінним при опитуванні розробників програмного забезпечення? Що це за питання, яке зробило його особливо корисним?

Я шукаю конкретне запитання, яке ви хочете задати, а не просто підхід до інтерв'ю, як "змусити їх написати код".

Погляньте на цей зразок коду та скажіть, як би ви його покращили.

Це трохи специфічно для мого сценарію, але я вважаю, що це було велике питання:

Отже, ви кажете тут, що ніколи раніше не торкалися C # або .NET, правда? Гаразд, ось ось робоча станція. З'ясуйте, як написати програму, яка запитує цю БД тут, і надрукує список Клієнтів із їхніми замовленнями, відсортованими за іменем клієнта. Ви можете використовувати будь-який ресурс, який хочете.

Єдине питання, яке я коли-небудь виникав, що насправді перевірило мою здатність до навчання.

Це не питання кодування, а поведінкове:

Скажіть мені про час, коли ви просто не змогли завершити всю свою роботу вчасно, щоб виконати термін. Що ти робив? Яким був результат?

Як ви потрапили в програмування?

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

Під час інтерв'ю хто - то , хто стверджує , щоб мати нетривіальне кількість досвіду Java, я питаю їх про hashcode()та equals()і відносинах між ними. Набути значного досвіду на Java не вдається, не усвідомлюючи потенційних підводних каменів, і хтось, хто не знає проблеми, додасть у мій проект важко знайдені помилки.

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

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

"Яку останню (найкращу) технічну книгу ви прочитали?"

або, загалом,:

"Як ви оновлюєте свої знання?"

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

Відповідь на коментар :

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

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

Поверніть цей пов'язаний список. Тепер зробіть це в лінійний час. Тепер зробіть це у лінійному часі та постійному просторі.

Ви вважаєте себе щасливою людиною?

Я прочитав це в інтерв'ю одного з членів-засновників Bruel & Kjaer, і це вразило мене. Успішні люди з великою ймовірністю вважають себе щасливчиками. Вони сприймають невдачі як можливості вдосконалитись і прагнуть ділитися своїми успіхами (удачею) з оточуючими людьми - удачі приносять більше удачі. *

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

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

Той, який завжди працював для мене ...

"Розкажіть про свої попередні проекти" .

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

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

Якби ви могли мати будь-яку роботу у світі, що б це було?

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

Це дійсно налаштоване моє улюблене запитання:

Якщо ви хочете бути [Рок-зіркою], чому ви подаєте заявку на посаду [Інженер з розвитку Інтернету III] тут, у [HugeCorp]?

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

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

Роблячи інтерв'ю c #, я люблю запитати: "Як ви обробляєте помилки в методі"? Якщо я отримаю гідну відповідь на це питання, я запитую "Як зробити / чи налаштували б обробку помилок у веб-програмі?"

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

Щось на зразок цього:

помножити значення на 7 без використання *, /і +операцій. :)

Схожий на Девіда, але трохи інший:

Погляньте на брудний фактичний виробничий код з попередньої версії, який ми згодом виправили та вдосконалили. Скажи мені, що це робить. Скажіть, де проблеми (правильність та стиль). Скажіть, як би ви це виправили та вдосконалили.

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

багато років тому мене запитали різницю між регулярними виразами / a * / та / a *? /

Я особисто схильний задавати кілька питань щодо рекурсії.

Я здивований кількістю невдалих відповідей на це питання:

Як би ви шукали предмет у несортованому списку?

Моє улюблене питання:

(Імовірно, у поєднанні Java / C # та псевдокоду)

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