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

Поширене питання в Tech Interview - це розробка певної системи, як правило, існуючого продукту компанії. Наприклад, "Дизайн Google Документів".

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

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

• Зверху вниз - дивлячись на дуже високий рівень, складіть дизайн та складіть дизайн, коли різні компоненти будуть виконані, і ось кілька компонентів, які я міг бачити ....

• Знизу вгору - дивлячись з нуля, ось шматочки та шматочки, які можна було б скласти, щоб спробувати зібрати разом ....

• Роз’яснення вимоги - задайте питання щодо прогнозованого масштабу, розміру, бюджету та команди, використовуваної для цього проекту. Ви можете спробувати, щоб людина кодувала дуже спрощений текстовий процесор, або ви могли задумати витратити сотні мільйонів доларів на те, щоб зробити остаточну систему управління документами, на яку ви вважаєте, як ви Google Doc довели до крайності. Також тут є можливість запитати щось на кшталт "Що ви маєте на увазі під Google Doc? Скільки цієї функції ви хочете дублювати?" питання також.

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

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

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

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

• Зберіть вимоги, щоб відповісти на питання (наприклад, сфера застосування)
• Розбити проблему на більш керовані частини; можливо визначити інтерфейси або об'єкти, які можуть знадобитися, або розбити логіку на передній, бек-енд, БД тощо.
• Продемонструйте ознайомлення зі структурою та поняттями, що стоять за цим типом системи, наприклад, веб-додатками у випадку з Документами Google
• Покажіть, на що ви схильні зосередитись, коли представлені проблеми дизайну (Дизайн об’єктів? SQL таблиці? Шаблони дизайну?)
• Покажіть начальнику попередній перегляд того, як виглядатиме розробка нової системи з вами, де начальник заходить із специфікацією і каже: "Що потрібно для цього?"

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

Йдеться про те, щоб бачити ваші мислені процеси в дії; їх не цікавить рішення, а як би ви підходили до вирішення проблеми, які питання ви б задавали, які проблеми ви б визначили тощо.

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

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

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

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

Погана відповідь:

Гм, я б, мабуть, використовував Ethernet або щось подібне.

Гарна відповідь:

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

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

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

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

Розглянемо проблему Документів Google:

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

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

Немає єдиного правильного способу створення додатка, наприклад, Google Docs, вам не потрібно визначати, що б ви робили для кожного компромісу, але дійсно чудово знайти область, яка має цікаву проблему, і чітко пояснити, що таке торгівля -виклики можуть бути

-т.

Я підозрюю, що інтерв'юері хочуть почути:

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

Що ви хотіли б обговорити далі?

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

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

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

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

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

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

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

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

Це означає читати блоги, статті, http://www.infoq.com , Hacker News тощо. Навіть апаратні блефи від Coding Horror.

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

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

Справа в тому, щоб задавати подібне питання - це зрозуміти свій розум. Поширене питання, яке я використовую, - це попросити програмістів розробити систему, яка може імітувати PacMan.

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

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