Як мені покращитись питаннями інтерв'ю на дошці? [зачинено]

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

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

Як можна краще покращитись питаннями інтерв'ю на дошці? Чи є способи бути краще підготовленими?

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

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

Мораль історії: Не ходіть на інтерв'ю непідготовленими. Вирішення проблем на дошці - це те, що вам слід практикувати.

Є три питання, на які потрібно відповісти, коли ви берете співбесіду на білій дошці:

1. Чи можете ви вирішити проблему?
2. Чи можете ви чітко повідомляти про проблему та рішення?
3. Чи можете ви отримувати відгуки від інших?

Тож рішення не в цьому, а в тому, як ви дійшли до рішення , і саме в цьому оцінюватимуть вас інтерв'юери.

Чи можете ви в цьому краще? Так, ти можеш:

Наступного разу, коли вам доведеться щось пояснити з однолітками (іншими студентами, якщо ви навчаєтесь, або іншими співробітниками, якщо ви працюєте), зробіть це:

1. Перетягніть їх на дошку
2. Візьміть ручку і гумку
3. Почніть пояснювати проблему
4. ???
5. Прибуток

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

Крім написання коду; навчитися малювати діаграми UML та говорити про них. Це всі поля, кола та стрілки, а типи, які ви зазвичай малюєте, - це діаграми класів, діаграми послідовності та (дуже рідко) діаграми регістру. І в усіх інших випадках вам потрібно лише намалювати ящики, кола та стрілки.

Дошки - це не лише інтерв'ю

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

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

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

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

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

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

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

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

Які існують способи покращитись питаннями інтерв'ю на дошці?

Чи є способи бути краще підготовленими?

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

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

Поради щодо того, як діяти під час співбесіди?

Це залежить.

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

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

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

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

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

Ще один важливий фактор - відскок. Проблеми з практикою завжди мають рішення - коли ти застряєш, ти можеш перевірити наступний крок, виписати його, зрозуміти та навчитися. Але ваш інтерв'юер не є посібником для вирішення. Вони допоможуть тобі, але ніхто не каже "наступний крок - зробити х", - вони скажуть "ти думав про y (що пов'язано з x)?" Тому практикуйте, не посилаючись завжди на посібник. Попросіть друга дати вам кілька невиразних, але пов’язаних із цим пропозицій, і спробуйте побудувати звідти. Поясніть, як їх пропозиція допомогла вам вирішити проблему. Завжди показуйте їм, як ви думаєте.

Сподіваюся, це допомагає!

Задавання питань та уникнення припущень - ще один момент для деяких питань на дошці. Що може здатися, "Гей, я робив щось подібне раніше, і ось це рішення ..." - це справді питання про те, чи можна зробити ці припущення і відстріляти ногу. Мало того, що це має бути хитромудрим питанням або бентежити вас, але, як правило, існує маса дрібниць, які, якщо ви потрапите на будь-яку з них, це покаже досить легко. Кілька прикладних областей:

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

Звичайно, є й інші сфери, але це основні, які я б враховував, аналізуючи, як я зробив у насмішному інтерв'ю.