Для заданий по разработке приложений для SQL и C # интервьюеры обычно задают вопросы о обходе дерева, графика и связанного списка, используя чистый C и указатели. За 3 года, которые я провел на работе, мне никогда не приходилось
найти путь к 1-му узлу справа от данного узла, который кратен данному узлу
например
Я вижу, что эти навыки могут быть использованы в работах, где вам нужно писать компиляторы, драйверы и работать с ядром ОС. Кроме тех, где еще используются эти навыки?
Ответы:
Прочитайте некоторые из ответов Джоэла ниже.
Особенно обратите внимание на что-то вроде художника Шмиля. На работе вам, возможно, никогда не придется переписывать связанный список, но вы наверняка должны знать под капотом, как он работает, чтобы вы могли избежать Шмиля.
По сути, если вы идете к врачу, вы бы хотели, чтобы этот врач изучал анатомию. Несмотря на то, что она просто прописывает вам немного антигистамина, врач узнает в медицинской школе, что определенные лекарства вредны для людей с «хронической фракцией диамадабада к бедренной кости» или чем-то еще. Такое глубокое знание ВСЕГО по этой специальности может иногда отличать жизнь и смерть, а также информационные технологии - жизнь и смерть продукта или работы.
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
http://www.joelonsoftware.com/articles/fog0000000319.html
«... проведите хотя бы семестр, приближаясь к машине, или вы никогда не сможете создать эффективный код на языках более высокого уровня ...»
«... насколько я понимаю, вы программируете, основываясь на суеверии: врач, который не знает основ анатомии, раздает рецепты на основе того, что, по словам ребенка из фармацевтической компании, будет работать».
http://www.joelonsoftware.com/articles/CollegeAdvice.html
источник
Они не. Многие интервью проводятся людьми, которые не знают, как искать умелых разработчиков , и не знают, какие вопросы им следует или не следует задавать.
Большинство интервьюеров вообще не задают технические вопросы и больше сосредоточены на бессмысленных, но измеримых вещах, таких как количество проектов, в которых вы участвовали (чем больше, тем лучше для этих интервьюеров) или высшее образование (чем выше, тем лучше для них) ). Они рады нанять человека, который потратил пять лет в колледже, ничего не изучая, а затем потратил десять лет на десятки сайтов электронной коммерции, но они не будут нанимать человека, который бросил колледж через несколько лет и работал над несколькими. крупные технически сложные проекты.
Задавать хотя бы теоретические вопросы лучше, чем не задавать ни одного. Это дает преимущество проверки того, что у человека достаточно теоретических знаний, и он не является программистом, который может иметь опыт программирования в течение нескольких лет, но на самом деле не понимает, что происходит под капотом. Разработчики, которые обычно не имеют этих теоретических знаний , не знают разницы между списком, связанным списком, поиском или хэш-набором и используют их взаимозаменяемо.
Хорошие (технические) вопросы, плохие вопросы
Во время интервью вы можете столкнуться с вопросами от очень хороших до очень плохих:
(Вредно) «Какова длина в строках самой длинной рабочей программы, которую вы написали на этом языке?»
Этот вопрос явно неправильный. Я уже объяснил, почему в другом ответе . Компания, где интервьюеры задают такие вопросы, имеет большие шансы оценить производительность разработчиков в LOC / мес. Если я должен дать совет: вам не нужна такая работа.
Этот пример отличается от бессмысленных, но измеримых вещей, которые я цитировал в начале своего ответа. Здесь интервьюер также показывает, что он не имеет даже самого базового понимания метрик, выбирая тот, который известен как вредный.
(Плохо) "Кто такой Деннис Ритчи?"
По крайней мере, иметь некоторую культуру действительно очень полезно, но задавать эти вопросы не имеет смысла. Если компания ищет талантливых разработчиков, способных заниматься проектами разработки программного обеспечения и писать код, тот факт, что они не знают имени человека, создавшего C и Unix, не должен иметь большого значения.
(Хорошо) «Каковы новые функции .NET 4.5?»
Этот вопрос гораздо интереснее, чем вопрос о Деннисе Ричи. Если кандидат не может говорить о новых функциях в .NET 4.5, почему он называет себя разработчиком C #? Недостаток таких знаний:
Показывает, что человек может не интересоваться ни языком программирования, ни сообществом .NET,
Указывает, что человеку может не хватать некоторых важных знаний о функциях C # / .NET, которые другие разработчики используют, если не ежедневно, по крайней мере часто.
Смотрите также ответ Джерри Коффина, который содержит более подробный анализ такого рода вопросов.
(Средний) "Какой из них быстрее, SSD или RAM?"
Это может быть полезно и показывает, достаточно ли у человека знаний об оборудовании, но кандидат, который не может ответить на этот вопрос, не должен быть отклонен.
(Среднее значение) "Как реализованы стек и очередь?"
Это те вопросы, о которых вы говорите. Они теоретические, может быть, даже слишком теоретические, но знание того, что происходит внутри, может помочь в написании лучшего кода.
Я не отклонил бы кандидата, который не может ответить на этот вопрос, но проверим более тщательно, действительно ли он знает материал, например, задавая связанный, но менее теоретический вопрос:
(Хорошо) "Как вы можете пройти через дерево, не используя рекурсию?"
Если кандидат отвечает на этот вопрос, говоря о FILO / FIFO и о преимуществах и недостатках использования стека по сравнению с рекурсией для обхода дерева, на самом деле не имеет значения, что он не смог ответить на предыдущий вопрос.
Задание этого вопроса также является хорошим способом выявления кандидатов, которые годами изучали степень бакалавра, но не имеют опыта работы на местах.
Как задать хорошие технические вопросы?
Комментарий Кодзиро интересен и заслуживает более длинного ответа:
Найти хорошие вопросы может быть непросто, особенно когда вы нанимаете своего самого первого разработчика или когда вы нанимаете разработчика, который, как ожидается, будет более опытным, чем все разработчики, которые фактически работают в компании.
Вот три подсказки, которые могут помочь:
Найдите друга / коллегу, которого вы считаете квалифицированным, и попросите его сделать отзывы. Это требует большого доверия, но может принести пользу вашей компании.
Найдите консультанта, которого вы считаете квалифицированным, и попросите его помочь вам или выполнить техническую часть интервью.
Напечатайте "вопросы интервью" в Google. Это работает довольно хорошо, и обычно объясняет возможные ответы. Пример:
Питон : эти десять вопросов кажутся довольно хорошими. Они, возможно, немного просты, но помогут отфильтровать 95% кандидатов, которых вы не хотите нанимать.
SQL Дэйва Пинала, отлично, как обычно.
C # : немного слишком просто, но опять же, они отфильтруют 95% кандидатов,
JavaScript : вопросы более открытые, что может быть не очень хорошо для технических вопросов, если вы хотите, чтобы интервью было коротким и оставляло больше времени для открытых технических вопросов. Список по-прежнему помогает легко фильтровать кандидатов, которые не понимают базовых понятий в JavaScript.
Недостатком этого подхода является то, что кандидат может использовать ту же технику для подготовки к собеседованию. Если он проверяет каждый вопрос первого веб-сайта, который он нашел в Google, он может получить хорошие результаты, фактически не имея необходимых навыков.
Developers Есть некоторые разработчики, которые не смогут объяснить, что такое B-дерево (за исключением того, что это «некоторая структура данных»), но все еще способны правильно развиваться.
источник
Из моего опыта работы в компании, где я проводил много собеседований, есть большая вероятность, что собеседник не имеет ни малейшего представления о том, как это сделать правильно. Таким образом, они подготовили набор технических вопросов и подсчитали оценку этого и сделали это вашим резюме. Это, однако, имеет много недостатков и не должно быть сделано по следующим причинам:
Вы спрашиваете точку знаний. Если программисту никогда не приходилось что-то делать в этой области, он все равно мог бы быть отличным сотрудником, но просто не знает этого конкретного ответа. Напротив, если кто-то подготовился к собеседованию и нашел ответ на этот конкретный вопрос в сети, вы получите правильный ответ, но этот человек может вообще не иметь никакого представления о актуальной теме.
Люди нервничают на собеседованиях. Мозг обладает этой замечательной возможностью отключать многие области более высокого уровня (например, логику), если они находятся в панике, что означает: если вы нервничаете, вы можете не обеспечить качество ответов, которое было бы в повседневной ситуации. Некоторые люди могут справиться со стрессовой ситуацией, как интервью, многие не могут.
С помощью одного правильного ответа вы проверяете умение людей найти этот конкретный ответ. Это один из многих навыков, в которых нуждается коллега, но не тот, который требуется только. Поэтому одного или двух из этих вопросов должно быть достаточно для проверки этой области знаний, а затем следует запросить другие навыки. Интервью, содержащее только вопросы для решения проблем, снова и снова проверяет один и тот же навык.
Какие вопросы хороших задач программирования?
У этих знаменитых вопросов «Можете ли вы написать короткую программу» есть огромная проблема, заключающаяся в том, что большинство программистов не могут написать ни одной строки кода без помощи IDE. Но это в повседневных рабочих ситуациях вообще не проблема, потому что программисту всегда помогает его IDE. Поэтому, задавая такие вопросы, как «Найди ошибку», «Напиши 50 строк кода, которые делают ...» или даже простые вопросы, необходимо принять во внимание, что у кандидата нет доступных инструментов (IDE, Google).
Например, я могу ответить вам практически на любой вопрос в течение 1 минуты, если мне поможет Google, но без подключения к Интернету я выгляжу беспомощным. Я называю это аутсорсингом памяти, и вместо того, чтобы мешать мне, это очень помогает мне сосредоточиться на том, что действительно важно - понимании основополагающей механики - потому что все остальное можно посмотреть. Но не спрашивайте меня о деталях каких-либо случайных API, потому что я их не знаю, у меня есть Google для этого.
Тем не менее, хороший вопрос задачи программирования не должен фокусироваться на знании API или специальных навыках программирования, если это не является абсолютным требованием для работы. Знания могут быть получены, поэтому лучше узнать, насколько хорош этот человек в получении знаний, чем спрашивать, что он / она уже знает.
Хороший вопрос для задачи программирования должен быть коротким, простым, с возможностью кодирования на каждом языке всего лишь несколькими строками кода, и он - особенно - должен рассказать вам как можно больше о том, как человек работает и находит ответы. Пример:
Первое, что любой заявитель должен спросить в этот момент: «Извините ... не могли бы вы объяснить задачу?». Потому что ни один программист не получил четкого описания того, что делать когда-либо. Далее следует объяснение, что код в вопросах должен выполнять сдвиг влево содержимого массива с переполнением, добавляемым справа.
Эта задача настолько проста, что любой, кто закончил любой уровень программирования, сможет ответить правильно. При этом учитывается, что программист должен работать без инструментов, а нервозность снижает способность логически мыслить. Тем не менее, он по-прежнему говорит о том, как люди решают проблемы, исходя из того, как сформулирован вопрос, и того, как люди к нему подходят, просто потому, что сдвиг влево противоречит общему инстинкту «слева направо» и заставляет людей думать Второй.
Существует множество возможных ответов на этот вопрос, поэтому важно внимательно посмотреть на то, как разрабатывается код, а не на то, будет ли решение действительно работать. Претендент проверяет на ноль? Как сохраняется переполнение? Используется ли цикл или набор записей? Как заявитель проверяет правильность кода? Этот простой вопрос рассказывает вам всю биографию о том, как работает этот человек.
Каковы хорошие вопросы общего знания?
На хорошие вопросы легко ответить, они позволяют получить большое количество ответов (так называемые «открытые вопросы») и позволяют вам узнать как можно больше о заявителе за короткое время.
Примеры:
Это вопросы начального уровня, которые дают заявителю реальную возможность выручить в данный момент, если он ничего не знает о заданной теме. «Нет» в этот момент лучше, чем мучить его / ее еще несколькими вопросами, на которые он / она должен ответить: «Извините, я ничего об этом не знаю».
Кроме того, он говорит вам, прежде всего, о том, какие другие языки знает этот человек, кроме того, вы узнаете, насколько заинтересован этот человек, чтобы получить более широкое представление о мире программирования, или если у вас есть кто-то только с единственным языком (и, следовательно, особенностями / методами). ) Посмотреть.
Это открытый вопрос, который позволяет получить много ответов, поэтому у заявителя есть хорошие шансы найти как минимум три. Запрашивание (тройка личных мнений) не только ограничивает возможные ответы, но и вынуждает кандидата сортировать по приоритету. Тем не менее, это (или должно быть) легко ответить.
Это простой вопрос, который проверяет много глубоких знаний о разных языках программирования. Насколько глубоко знание этих тем на самом деле? Из этих ответов вы можете многое рассказать о знании и реальном понимании основополагающей механики языков программирования. Сколько этот человек потратил на грязные детали, или если он или она просто кто-то, кто связывает воедино различные функции API, не зная, что происходит под ними.
Эта концепция вопросов начального уровня, за которыми следуют простые вопросы с углубленным знанием, может использоваться и для большинства других тем. Всегда в этой схеме: вопрос спасения, вопрос проверки, углубленный вопрос. Другой пример (из интервью на Java):
Эти три вопроса расскажут вам больше, чем любой технический вопрос, что кандидат действительно знает об этих темах, и в то же время справедливо ответят с учетом точечных знаний и уровня стресса.
Поэтому в следующий раз, когда кто-то задаст вам 20 вопросов по кодированию подряд, вы поймете, что он или она не имеет ни малейшего представления о том, как правильно провести собеседование с кем-либо. ;)
источник
Предупреждение: это написано как (своего рода) комментарий к ответу @ MainMa, но 1) он слишком длинный, чтобы помещаться в комментарии, и 2) я думаю, что он добавляет несколько иную точку зрения на конструктивные вопросы, так что это сам по себе реальный ответ ,
В своем ответе @MainMa классифицирует «Каковы новые функции .NET 4.5?» как "хороший" вопрос.
Позволю себе не согласиться. По его словам, я бы сказал, что в лучшем случае это довольно посредственный вопрос. Хороший вопрос больше напоминает: «Чем код, который вы пишете сегодня, отличается от кода, который вы написали N лет назад?» (для некоторого значения N меньше, чем годы опыта, указанного в резюме, предпочтительно от 3 до 5).
По его словам, вопрос о запоминании. Этот кандидат полностью запомнил список функций? По праву, тот, кто цитирует список Microsoft наиболее точно, должен быть победителем.
То, что вы должны заботиться о его программировании. Как это повлияло на его код? Какие из этих функций он действительно использует ? Что еще более важно, показывает ли он хорошее суждение о том, когда использовать какие новые функции и когда более старые достаточно хороши?
Сама возможность сказать «LINQ» практически ничего не говорит о кандидате. Возможность сказать: «LINQ помог сделать мой код намного более компактным и читабельным, потому что я могу выразить понятия X, Y и Z четко и прямо, где мне раньше приходилось прыгать через следующие пламенные обручи для выполнения этих задач». (или что-то подобное) многое говорит вам о кандидате, о том, какой код он пишет, о его суждениях, гибкости и так далее. Это также дает вам гораздо больше возможностей для последующих вопросов о том, как этот человек думает о проблемах, пишет код, думает о коде и так далее. Наконец, это дает вам гораздо лучшее представление о том, является ли это кандидат, у которого действительно есть N-летний опыт, или тот, у кого есть один год опыта, повторенный N раз.
Резюме: возможность процитировать список функций, созданный несколько лет назад, бесполезен и мало говорит о кандидате, который, вероятно, будет иметь какое-либо реальное применение. Прогресс кандидата в качестве программиста, вероятно, будет представлять гораздо больший интерес, поэтому гораздо лучше спросить об этом более прямо.
источник
Реальность такова, что большинство повседневных задач, которые большинство разработчиков выполняют в своей профессиональной жизни, тривиально; Это означает, что некоторые вопросы, с которыми вы сталкиваетесь на собеседовании, могут никогда не встретиться с вами на самом деле, но это не значит, что нет смысла задавать эти вопросы.
Допустим, в вашей компании есть открытая позиция, и вы в настоящее время проводите собеседование с людьми. У вас уже 20-30 разработчиков в очереди. Итак, как бы вы выбрали лучшего кандидата на эту должность? Допустим, самая сложная задача, которую они должны выполнить в этой работе, - это открыть файл из файловой системы, построчно прочитать данные, слегка изменить их и вернуть обратно в исходный файл.
Собираетесь ли вы спросить их, как бы вы открыли файл? Могу поспорить, что вы не видите большой разницы между ответами. Таким образом, вам нужно найти решение, позволяющее различать разработчиков, которые знают только, как открыть файл, и тех, кто может разработать плохое приложение для реального времени. Даже если вы не хотите, чтобы они создавали такое приложение, вы все равно хотите нанять лучшего кандидата.
Как и любая другая вещь в нашей жизни, есть некоторые моменты, которые вы понимаете, что вам нужно пойти и узнать больше. Если вы, как программист, не знаете, что такое связанный список, это буквально означает, что вы в действительности не достигли того момента в своей профессиональной жизни, чтобы почувствовать, что вам нужно идти и изучать эту конкретную вещь. Почему? Просто потому, что вы никогда не участвовали в проекте, достаточно большом, чтобы требовать от вас повышения навыков до этого уровня. Если вы на начальном уровне, вы могли бы сказать, что у меня нет никакого опыта работы для этой конкретной работы, но все же, если вы знаете это, это значит, что вы достаточно мотивированы, чтобы поставить себя на уровень выше среднего. по крайней мере.
источник
Навыки, необходимые для выполнения этих задач, редко важны. Навыки, продемонстрированные в подходе к ответу на вопрос и в последующем диалоге, представляют собой весь смысл.
Когда я беру интервью у разработчиков, я ищу (а) умный (б) добивается цели (в) будет соответствовать. Существует базовый уровень технических знаний, необходимых для выполнения любой роли, которая должна идти с готовностью учиться и приобретать новые навыки и умения. Интервью о проверке этих ящиков.
Я предпочитаю читать код, написанный заявителем. Мне не нравятся консервированные вопросы интервью, но они дают что-то, о чем можно поговорить в отсутствие кода. Я предпочитаю спрашивать о RAII или IOC или о реализации IDisposable, а не о списках и коллекциях, но все будет так, пока мы сможем сделать это достаточно техническим .
Худший страх перед интервьюером - это нанять человека, который на самом деле мало знает о кодировании. Вы должны говорить о чем-то кроме опыта работы, чтобы отсеять подделки.
источник
Эти вопросы предназначены для отбора людей, которые не могут программировать. Иногда люди, которые не могут программировать, но знают много пустяков, обращаются за вакансиями по разработке, и если они пишут что-то полезное и нетривиальное, это слишком много времени для собеседования.
источник
Как насчет написания поисковых систем, веб-серверов, веб-браузеров, текстовых процессоров, электронных таблиц, графических редакторов, программ для рисования, серверов баз данных, биоинформатики, торговых программ, игр, симуляторов физики и так далее, и так далее.
Я предоставлю вам, что большинство программных заданий включает в себя извлечение данных из базы данных, вывод их на экран, редактирование, удаление данных с экрана и помещение их обратно в базу данных. Однако даже в этом случае вы можете столкнуться с приложением, в котором ограничения не могут быть удовлетворены встроенными функциями платформы. На этом этапе вы можете либо сдаться, либо использовать свой инструментарий алгоритмов и структур данных и попытаться решить проблему.
источник
Теоретические объекты используются для удобства, потому что вы должны знать, что такое реализация среднего дерева / графика / списка, и, таким образом, знать, как решить случайную задачу обхода, но эти вопросы вовсе не касаются теоретических объектов.
Они о возможности работать с абстрактной моделью, понимать абстрактную проблему и решать ее с помощью алгоритма любого рода. Это чистый навык развития, так что он, безусловно, имеет значение. Вот почему эти вопросы имеют смысл, а не потому, что они должны быть точными в реальной жизни.
источник