Почему структуры данных так важны в интервью? [закрыто]

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

Честно говоря, я чувствовал себя плохо об этом. Я пишу хороший код. Я следую стандартным шаблонам проектирования кода, я использую структуры данных, но на поверхностном уровне, как в API, предоставляемых Java, таких как ArrayList, LinkedList и т. Д. Но компании обычно фокусируются на сложных аспектах структур данных, таких как манипулирование памятью на основе указателей и временные сложности.

Вероятно, из-за своего опыта работы с Java в то время я понимал эффективность и логику кода только тогда, когда говорил об объектно-ориентированном программировании, например, об объектах, экземплярах и т. Д., Но никогда не углублялся в уровень битов и байтов. Я не хотел, чтобы люди смотрели на меня свысока из-за моего дефицита знаний в структурах данных.

Так почему же все эти акценты на структурах данных?

большинство крупных технологических компаний, таких как Microsoft, сосредоточены в основном на структурах данных. Кажется, что структуры данных - единственное, что они ожидают от выпускника.

Нет, это еще не все. Например, мы также ожидаем, что вы быстро учитесь и сможете за короткое время освоить новые фреймворки, API или даже языки программирования. Это минимальная минимальная планка. Тот, кому потребуется много времени для изучения новой инфраструктуры, API или языка, не будет успешным разработчиком в большинстве команд Microsoft.

И, конечно же, на собеседованиях мы фокусируемся на еще многих аспектах, помимо простого знания структур данных. Способность иметь дело, например, с неоднозначными спецификациями или способность распознавать шаблоны кодирования, которые создают небезопасный код, или дюжину других вещей. Но способность понимать структуры данных, безусловно, очень большая.

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

Я должен признаться, что я не был так силен в структурах данных

Это хорошо, что ты знаешь это о себе. Если вы не можете или не хотите изменить это в отношении себя, я рекомендую вам не подавать заявку на работу, требующую возможности со структурами данных.

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

Тавтологично, что хороший программист - это программист, который умеет создавать программы, которые нужно создавать. Многие программисты работают над задачами, которые не требуют глубокого знания структур данных. Некоторые из них работают, например, над задачами, требующими глубоких знаний в области дизайна пользовательского интерфейса. Или нормализация базы данных. Или что угодно. Эти люди все еще могут быть «хорошими программистами» в своих областях.

Почему все это делает упор на структуры данных?

Я задаю вопросы об интервью о структурах данных, потому что в моей команде разработчики ежедневно проектируют, внедряют и управляют сложными структурами данных. Вчера у нас было четыре часа собраний, на которых полдюжины разработчиков обсуждали плюсы и минусы добавления одного логического поля к конкретному узлу дерева. Наверное, в моей команде нет более важного навыка, чем умение понимать структуры данных на глубоком уровне. Было бы глупо не задавать вопросы об этом на собеседовании, потому что это то, что мы делаем.

Разве знания в структурах данных не влияют на карьеру программиста?

Ну, это, безусловно, помешает вам устроиться на работу в моей команде. Но, как я уже говорил, программирование - это огромное поле. Существует множество видов компьютерного программирования, которые не требуют знания структур данных.

действительно ли знания по этому предмету являются достаточной основой для того, чтобы отличать хорошего программиста от плохого?

Нет. Но почти всегда достаточно обнаружить разработчиков, которые вряд ли добьются успеха в Microsoft. Так как это то, что я в первую очередь заинтересован в обнаружении, знание структур данных является одним из факторов, которые я проверяю в интервью.

Важным моментом в отношении структур данных является то, что они универсальны и вне времени, по крайней мере, для практических целей. Любой, кто был разработчиком в течение последних 30 лет, должен знать базовые структуры данных, такие как одно / двойные связанные списки, двоичные деревья или графики. Если вы спросите двух разработчиков о них, вы можете сравнить знания разработчиков по их ответам. Этого вряд ли можно сказать о фреймворках или даже языках: если вы спросите двух разработчиков о Rails, и один знает намного больше, чем другой, что это вам скажет, правда? Как вы говорите в этом вопросе, умный разработчик может достаточно быстро освоить новую платформу, поэтому проверка его текущих знаний не имеет особого смысла.

Действительно ли отсутствие знаний в структурах данных влияет на карьеру программиста?

Да. Определенно. Если вы не хотите тратить всю свою жизнь на написание приложений CRUD.

Или знание этого предмета является достаточной основой для того, чтобы отличать хорошего программиста от плохого?

Нет, этого недостаточно. Но есть несколько вещей, которые вы можете спросить на собеседовании, которые являются достаточными. И я бы сказал, что знание алгоритмов - один из лучших индикаторов, по крайней мере, для тех, кто только что закончил школу, и вы не можете спрашивать об опыте работы.

Я быстро учусь и могу выучить новые фреймворки, API или даже языки программирования в течение довольно короткого времени.

Звучит не слишком резко, но любой полу-приличный разработчик сможет выбрать новый язык или фреймворк за относительно короткий промежуток времени.

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

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

Вы верите, что гонщики Формулы 1 просто водят быстрые машины? Нет, они понимают машину, на которой ездят, и работают с механиками / инженерами, чтобы настроить ее. Конечно, обычный драйвер просто рулит.

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

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

Очень хорошо знать структуры данных не только потому, что вы будете часто использовать их в «предварительно приготовленном» виде. Это также хорошо, потому что вы будете создавать то, что вытекает из их идеи.

В моем классе, посвященном структурам данных, самое первое, что сказал профессор, было следующее: этот класс не предназначен для быстрого поиска. Затем мы потратили полгода на поиск наилучших из возможных структур данных и алгоритмов для быстрого поиска.

И все же он остался прав. Способность анализировать структуры данных, применять правильную структуру данных к конкретной проблеме или даже придумывать новые структуры данных требует многих качеств инженера:

• Поиск абстракций для моделирования конкретной проблемы
• Возможность разлагать проблемы
• Умение логически / формально рассуждать
• Креативность
• и т.п.

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

Конечно, можно обладать большим набором этих качеств и все же сосать структуры данных. Но тогда, если это так, вам не понадобится много времени, чтобы стать экспертом в области структур данных.

Тем не менее, есть еще проблема, которая ArrayListпросто не совсем масштабная. Когда системы становятся большими, для их выполнения требуются более адаптированные решения. А без хорошего понимания структур данных вы не сможете найти и составить структуры и алгоритмы, которые масштабируются в целом в вашем конкретном сценарии.

В общем, алгоритмы и структуры данных рассматриваются как две самые «сложные» темы в программировании. Это потому, что есть огромный объем работ и исследований в области компьютерных наук. Они также привлекают типичных программистов "левой доли", которые любят такие вещи, как математика и естественные науки (а это очень много программистов)

При этом знание этого может повлиять на вашу карьеру с точки зрения проведения собеседований, особенно если вы проводите собеседование на инженерно-ориентированных рабочих местах, таких как Google. Однако другие компании теперь могут заботиться об этом аспекте вообще.

По моему опыту, требования к алгоритму / структуре данных могут иногда восприниматься как «элитарность программистов», когда альфа-фанаты пытаются обмануть, чтобы показать, кто самый умный. Всегда полезно знать, что там, но есть очень много разных заданий по программированию, где вам никогда не понадобится знать, как использовать красное / черное дерево или кодировать поиск Бойера-Мура.

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

PS. Знание элементарных структур данных (связанных списков, словарей, хеш-таблиц и т. Д.) Должно быть обязательным знанием для любого программиста DS.

Так почему же все эти акценты на структурах данных?

Две причины.

С одной стороны, это показывает, что вы можете думать о проблеме в абстрактных терминах, а не в терминах конкретного языка программирования. Знаете ли вы, почему хеш-таблица может быть лучшим или худшим выбором, чем красно-черное дерево в данной ситуации, независимо от базовой реализации?

С другой стороны , есть страшное количество людей там собеседования на работу , которые просто лежат об их опыте и имеют очень мало , если какую - либо возможность программирования; вопросы о структурах данных - быстрый способ отсеять этих людей.

Они фундаментальны, но также, на чем бы вы выбрали выпускников? Они могут иметь или не иметь опыт вне своей курсовой работы. Их курс мог охватывать технологии Microsoft больше, чем, скажем, Java или наоборот. Структуры данных - это общий язык.

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

• управление проектами / временем: способность идти в ногу с реальным миром, основанным на бизнесе, а не с новым связанным списком, который работает на 1% быстрее.
• минимальное количество социальных навыков: разработчик, который высокомерен и не может ужиться, - это просто якорь.
• способность быстро и непрерывно изучать новые вещи: структуры данных с годами почти не меняются ... но все остальное меняется. Структуры данных являются отличными основами, и каждый разработчик должен знать их достаточно хорошо, но бухгалтер не проходит тестирование на их навыки длительного разделения, когда они идут на собеседование. Великие разработчики - это тот тип людей, которые могут придумывать новые вещи и им это нравится.

Структуры данных великолепны. Структуры данных важны. Каждый программист должен понимать их. Тем не менее, мы стали одержимы выталкиванием этих основ за пределы своего места. Это не ВСЕ о структурах данных, и в 99% случаев нет необходимости задавать вопросы, выходящие за рамки основ данных. Если вы проводите собеседование с бухгалтером, обязательно спросите его, что такое 81, деленное на 9, но если вы продолжаете спрашивать: «Что такое корень куба из 98425454242412 * 4512324? ... без калькулятора!» тогда вы будете пугать хороший процент разумных, умных, талантливых и приятных людей, которых вы могли бы иметь. Спросите, могут ли они построить базовую модель реляционных данных, спросите, могут ли они использовать расширенные структуры массива, предоставляемые соответствующей структурой, и спросите, могут ли они объяснить, когда бинарный поиск быстрее плоского поиска, но нет особого смысла зайти слишком далеко. Если они могут делать такие вещи, то начните искать самый хороший, самый профессиональный, самый творческий из всех.

Мне нравится сочинение Джоэла, но я думаю, что его "Java Schools" совершенно неправ. Есть много вещей, которые могут доказать, что кто-то умный, помимо освоения C ++. Подумайте об этом, вы можете поговорить с кем-то в течение 10 минут, не спрашивая их об арифметике указателей, и получить довольно хорошее представление о том, являются ли они типом, который может сделать что-то и разобраться. Нам не нужно быть таким:

Интервьюер: «Расскажи мне о своих достижениях».

Кодер: «На своей последней должности я был единственным разработчиком нестандартной ERP-системы для финансовой фирмы на миллиард долларов. Мы поставили месяцы с опережением графика, и система была в производстве в течение последних 3 лет».

Интервьюер: «Позвольте мне уточнить. Расскажите о ваших достижениях в программировании »

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

Интервьюер: «Например, вы когда-нибудь создавали свой собственный связанный список?»

Кодер: "... [уходит]"

Быть хорошим программистом не значит уметь изучать языки и основы. Речь идет о возможности решения сложных проблем. Чтобы эти решения были эффективными и надежными, они почти всегда будут полагаться на хорошие алгоритмы и надлежащее использование структур данных. Знание существующих структур данных недостаточно. Вы должны понимать, что структуры данных будет достаточно, чтобы использовать правильную структуру для решения проблемы. Списки и карты предлагают некоторые ценные функции, но они сопряжены с затратами, и использование неправильных может значительно снизить производительность вашего программного обеспечения.

Хороший интервьюер знает это и пытается определить, можете ли вы быть ценными для его команды или компании. Язык (языки), которые вы будете использовать через 2 года, могут сильно отличаться, но потребность в эффективных алгоритмах и структурах данных не изменится.

Структуры данных, сложность времени, манипулирование памятью и указатели - все это основы, которые должен знать тот, кто называет себя компьютерным ученым. Любая обезьяна кода может выучить язык и научиться его использовать, но где профессионалы CS и студенты должны выделиться, это знание не только того, как использовать связанный список или хэш-карту, но и ПОЧЕМУ.

ПОЧЕМУ это то, что на самом деле отличает нас от основного сценария «детишка», «обезьяна кода» и ворчание вычислительного мира. ПОЧЕМУ используйте хеш-таблицу вместо связанного списка, ПОЧЕМУ моя хеш-таблица должна иметь плотность кластеров примерно 0,6-8. ПОЧЕМУ я должен использовать здесь циклически связанный список вместо двусвязного списка. ПОЧЕМУ мой код должен работать с эффективностью 'x' в худшем случае и 'y' в среднем.

Эти базовые структуры данных и знание не только того, КАК они используются (как это должно быть в любом случае в каждом программном обеспечении), но и не зависит от языка, ПОЧЕМУ они используются, что, как правило, больше того, что они ищут в этих случаях.

Во многих местах вам придется писать код на языке, с которым вы хорошо знакомы, но это скорее общность, поскольку C больше не является языком мира программирования, а структурирование псевдокода может быть путаницей, и все и в большинстве случаев с псевдокодом / p & p кодом, который на самом деле не преподается, совершенно невозможно разобраться.

Структуры данных являются фундаментальной основой всех программ. Вам не обязательно иметь глубокое понимание их, но вы обязательно должны знать, как они работают.

Почему? Потому что весь ваш код взаимодействует с данными и манипулирует ими. Если набор данных не может быть сохранен в структуре, он не может быть использован. Данные похожи на строительные материалы дома. Пока вы не соберете это в структуру, у вас просто будет бесполезная куча досок.

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

Когда вы выходите за рамки обычных программ, почти все требует структуры данных. Что бы вы предпочли, профессиональный архитектор, который проектирует ваш небоскреб с лучшими методами и математикой, или дядя Джо Боб, который сразу начинает строить?

Чтобы понять, что говорит @Pelshoff , нужно показать, что вы знаете, что делаете. Если вы используете LinkedList для всего, это может показать, что вы не знаете, что делаете, или вам не хочется останавливаться и думать о проблеме. Кроме того, по крайней мере, курс по структурам данных, который я изучил, охватил базовую теорию сложности этих структур данных, которая при работе с большими наборами данных очень важна. Вот почему такие компании, как Amazon или Microsoft, будут делать такие вещи.

Я должен сказать, что до того, как я взял класс структуры данных, я подумал, что они не важны, но, по крайней мере, возможность распознавать их, когда связанный список (или ArrayList) не практичен или важны их недостатки.

Пишете ли вы хороший код или нет, это субъективное утверждение. Важно знать, что функциональный код не всегда создает хороший код.

Тем не менее, структуры данных важны, потому что они похожи на закулисных работников, которыми вы, как программист, руководите. Это правда, что вы можете вызывать методы для структуры, не понимая, что она делает, и вы можете использовать структуру, не понимая, как хранятся данные, но знание этих деталей поможет вам лучше понять, когда целесообразно использовать одну структуру поверх еще один.

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

Это всего лишь небольшие примеры, и, в конечном счете, если вы чувствуете, что преуспеваете в своей карьере без глубокого знания структур данных, то, возможно, вам не нужно больше учиться. Понимание того, что происходит внутри, может действительно помочь превратить функциональный код в хороший код.

Структуры данных являются строительными блоками многих вещей, которые вы хотите сделать. Если вы знаете использование каждой структуры данных, ее слабые и сильные стороны, то вы легко сможете решить проблемы.

Например, у нас было требование управлять тысячами объектов. Время от времени нам нужно обновлять временную метку объекта в соответствии с его идентификатором. Время от времени нам нужно было удалять объекты, которые не обновлялись более X минут.

Если вы знаете свои структуры данных, вы можете легко определить проблему, а также очень легко найти решение. Когда программист, который не знает достаточно структур данных, пытался найти решение, его решение было неловким. Он был как ты - умный программист, умеющий быстро изучать фреймворки. Но без знания структур данных ему пришлось изобретать колесо самостоятельно. Более того - ему было трудно понять более простые решения, поскольку они основывались на структурах данных, которые он не понимал, таких как красно-черные деревья (ваш старый TreeMap в Java).

Итак, я бы сказал, что важно знать, как и когда использовать каждую структуру данных, не думая об этом. Но я не думаю, что есть какой-то способ достичь этого без реального понимания того, как они работают.