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

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

Якщо чесно, мені стало погано з цього приводу. Я пишу хороший код. Я дотримуюсь стандартних моделей дизайну кодування, використовую структури даних, але на поверхневому рівні, як у API, що піддаються впливу Java, такі як ArrayList, LinkedList і т.д.

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

Тож справді чому все це акцентується на структурах даних?

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

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

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

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

Мушу зізнатися, що я не був таким сильним у структурах даних

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

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

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

чому все це акцентується на структурах даних?

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

Невже знання в структурах даних насправді не впливають на кар'єру в галузі програмування?

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

чи справді знання з цієї теми є достатньою підставою для розмежування доброго та поганого програміста?

Ні. Але майже завжди достатньо виявити розробників, які навряд чи матимуть успіх у Microsoft. Оскільки саме це мене насамперед цікавить виявлення, знання структур даних є одним із факторів, на які я перевіряю інтерв'ю.

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

Чи, не маючи знань у структурах даних, дійсно впливає на кар'єру в галузі програмування?

Так. Безумовно. Якщо ви не хочете витратити все своє життя на написання програм CRUD.

Або знання з цієї тематики справді є достатньою основою для розмежування доброго та поганого програміста?

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

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

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

Структури даних є універсальними, вони є фундаментальним складовим елементом інформатики - червоно-чорне дерево в основному те саме, незалежно від того, чи реалізовано це в Java, Python, PHP чи ін. Тож замість тестування конкретних мов чи конкретних рамок роботодавець (принаймні, роботодавець, який шукає розробників, що виділяються) перевірить, чи знаєте ви основи інформатики, а не будь-який аромат місяця » Ви зараз використовуєте.

(принаймні, вони повинні тестувати основи на додаток до того, що вони зараз використовують ... немає сенсу наймати майстра інформатики, якщо він ніколи не писав кодовий рядок у своєму житті)

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

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

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

Цілком добре знати структури даних не тільки тому, що ви будете використовувати їх у «заздалегідь приготовленій» формі. Це також добре, тому що ви створите щось, що випливає з їх ідеї.

У моєму класі з структур даних, перше, що сказав професор, було: Цей клас - це не про те, що можна швидко шукати. Тоді ми витратили півроку на пошук найкращих можливих структур даних та алгоритмів, щоб дійсно швидко шукати.

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

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

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

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

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

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

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

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

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

PS. Досвід роботи з рудиментарними структурами даних (пов'язані списки, словники, хештелі тощо) повинен бути обов'язковим знанням для будь-якого програміста DS.

Тож справді чому все це акцентується на структурах даних?

Дві причини.

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

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

Вони є основоположними, але також, на чому б ви опитували випускників? Вони можуть мати або не мати досвіду поза їх курсовою роботою. Їх курс, можливо, охоплював технології Microsoft більше, ніж скажімо Java, або навпаки. Структури даних є спільним принципом.

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

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

Структури даних чудові. Структури даних є важливими. Кожен програміст повинен їх розуміти. Однак ми одержимі витісняти ці основи поза їх місця. Це НЕ ВСЕ щодо структур даних, і в 99% випадків немає необхідності задавати питання, що виходять за межі основ структури даних. Якщо ви берете інтерв'ю з бухгалтером, обов'язково запитайте їх, що 81 розділено на 9, але якщо ви продовжуєте запитувати "Що таке корінь куба 98425454242412 * 4512324? ... без калькулятора!" тоді ви будете лякати хороший відсоток розумних, розумних, талановитих і доброзичливих людей, яких ви могли мати. Запитайте, чи можуть вони побудувати базову модель реляційних даних, запитайте, чи можуть вони використовувати розширені структури масивів, що надаються відповідним фреймворком, і запитайте, чи можуть вони пояснити, коли двійковий пошук швидший, ніж плоский пошук, але немає великого сенсу занадто далеко над цим. Якщо вони вміють робити це, тоді почніть шукати найприємнішого, найпрофесійнішого, найкреативнішого з групи.

Мені подобається писати Джоеля, але я вважаю, що його річ "Школи Ява" мертва неправильно. Є багато речей, які можуть довести, що хтось розумний, ніж засвоїти C ++. Подумайте над цим, ви можете поговорити з ким-небудь протягом 10 хвилин, не питаючи їх про арифметику вказівника, і отримати досить гарне уявлення про те, чи є вони типом, який може зробити речі і розібратися. Нам не потрібно бути таким:

Інтерв'юер: "Розкажіть про свої досягнення".

Coder: "На моєму останньому посаді я був єдиним розробником спеціальної ERP-системи для фінансової фірми на мільярд доларів. Ми поставляли місяці достроково, і ця система випускається протягом останніх 3 років".

Інтерв'юер: "Дозвольте мені уточнити. Розкажіть про свої програми програмування "

Кодер: "Гм ..."

Інтерв'юер: "Наприклад, ви коли-небудь склали свій власний пов'язаний список?"

Кодер: "... [гуляючи]"

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

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

Структура даних, часова складність, маніпулювання пам’яттю та покажчики - це все основи, про які той, хто називає себе вченим-комп’ютером, повинен спокійно знати. Будь-яка мавпа з кодом може вивчити мову та навчитися нею користуватися, але там, де фахівці з CS та студенти повинні розставити себе, знає не просто, як використовувати пов'язаний список чи хеш-карту, а ЧОМУ.

ЧОМУ це те, що насправді відрізняє нас від основного дитячого сценарію, кодової мавпи та бурчання в обчислювальному світі. ЧОМУ використовуйте хеш-таблицю замість пов’язаного списку, ЧОМУ моя таблиця хешів має щільність кластера приблизно 6–8, ЧОМУ я повинен тут використовувати кругозв’язаний список замість подвійно пов'язаного списку. ЧОМУ мій код працює з ефективністю 'x' в гіршому випадку і 'y' в середньому.

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

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

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

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

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

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

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

Треба сказати, перед тим, як взяти клас структури даних, я подумав, що вони не важливі, але принаймні зможуть їх переосмислити, коли пов'язаний список (або ArrayList) не є практичним чи важливим є зворотний зв'язок їх.

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

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

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

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

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

Наприклад, у нас була вимога керувати тисячами об’єктів. Час від часу нам потрібно оновлювати часову позначку об’єкта відповідно до його ідентифікатора. Раз у раз нам потрібно було видаляти об'єкти, які не оновлювалися більше X хвилин.

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

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