Як упорядкувати свої думки на дошці та розчавити технічне співбесіду

Про організаторські здібності та прикладну науку склеювання багатьох речей у розробці програмного забезпечення

Кілька тижнів тому яскрава особа опублікувала в Hacker News продуману та стислу публікацію про найважливіший навик у розробці програмного забезпечення. У цьому дописі Джон Д. Кук вказав на цитату зі статті "Організаційні навички, які перемагають алгоритмічну майстерність" Джеймса Хейга. Обидва автори вирішують питання організації програмного забезпечення як навичку . Вони протиставляють цеволодіння інформатикою перевіряється в інтерв’ю, викладається в академічних колах або рекламується в публікаціях блогу. Їх споглядання змусили мене замислитись над тим, як можна вдосконалити наше ремесло.

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

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

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

... як ви уявляєте розумну частинку організації?

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

Тож я почав вирішувати деякі типові проблеми біля дошки, нервово, абсолютно сам.

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

Кращий підхід

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

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

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

Три секції будуть організовані для тимчасового простору для роботи над вирішенням проблеми.

Крок 1: проблема

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

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

Крок 2: Припущення

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

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

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

Крок 3: підхід

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

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

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

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

Крок 4: Впровадження коду

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

Навіть якщо ви боретеся з рішенням, ви - майстер організації.

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

Будьте господарем організації. Якщо ви вдарилися об стіну або виявили щось, що просто неправильно, пам’ятайте, що боки будуть вести вас.

Бонусний крок 5: тест

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

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

Підсумовуючи

Ось так. Це було кілька хвилин чистої організації без особливої ​​теорії. Він спирається на кілька простих концепцій.

  1. Секціонування -розрізання проблеми на шматки від початку до кінця.
  2. Риштування - концепція тимчасової архітектури або де ми встановлюємо несучу конструкцію, будуючи навколо нас.
  3. Ворота - нам не слід продовжувати наступний крок, доки ми не будемо впевнені в справах вирішення проблеми. Виявляйте впевненість, але активно взаємодійте із запитанням “Чи я пропустив якісь припущення? або "Чи мій підхід має дірки?" перед продовженням.
  4. Державна  організація обробляється візуально для збереження зважувальної складності проблеми. Уникайте використання гумки, якщо можете.

Висновок

Я хотів закінчити тріщинками, які повернуть мій процес думок додому.

Ви не можете оцінити подвиг організації, поки не відчуєте дезорганізації. - Джон

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

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

Ніколи не недооцінюйте це явище.

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

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

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

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

Якщо ви опинилися в такій ситуації, попросіть більшу дошку!