Вопрос - как сформулировано - не является конструктивным, но имеет несколько хороших ответов. Перефразируйте вопрос, чтобы он соответствовал лучшим ответам, и я порекомендую, чтобы он был вновь открыт.
ChrisF
@ChrisF: я перефразировал, чтобы попытаться получить немного больше от «обмена опытом» и «спрашиваю почему», что должно также затронуть больше «приглашает более длинные ответы» Дайте мне знать, если это требует дальнейшего пересмотра.
Тим Гудман
Так-то лучше!
ChrisF
Глядя на вопрос и ответы сейчас, он все еще кажется довольно неконструктивным. Похоже, что ни один из ответов не содержит «почему» и просто перечисляет вопросы.
Адам Лир
Ответы:
29
Взгляните на этот пример кода и расскажите, как вы можете его улучшить.
Это немного специфично для моего сценария, но я думаю, что это был отличный вопрос, тем не менее:
Таким образом, вы говорите здесь, что вы никогда не касались C # или .NET, верно? Итак, вот рабочая станция. Узнайте, как написать программу, которая запрашивает эту базу данных и печатает список клиентов с их заказами, отсортированный по имени клиента. Вы можете использовать любой ресурс, который вы хотите.
Единственный вопрос, который у меня когда-либо возникал, на самом деле проверял мою способность учиться.
Э-э, разве это не тот вопрос, который тебе нравится задавать?
паддислакер
8
+1, это идеальный вопрос. Если они не могут понять основные языковые конструкции с Google, ничто не спасет их.
Джош К
Мне это нравится, это показывает, насколько хорошо они могут выбрать язык программирования, который они никогда не использовали. Я мог бы украсть это для моих вопросов интервью :)
Ричард
1
Кажется бессмысленным, любой может скопировать и вставить дрянной код .net прямо из msdn.
dotjoe
15
Это не вопрос кодирования, а вопрос поведения:
Расскажите мне о времени, когда вы просто не смогли выполнить всю свою работу вовремя, чтобы уложиться в срок. Что ты сделал? Каков был результат?
Почему это хороший вопрос? Мне кажется бессмысленным
Джо Филлипс
9
Дело в том, что от ответа разработчиков я получаю много информации. Во-первых, если они не признаются, что такая ситуация когда-либо случалась с ними, то они либо обманывают себя, либо у них нет опыта в реальных проектах. Во-вторых, если они не говорят о том, как сообщают об этой проблеме команде, а просто говорят о том, как усердно они работают, чтобы решить ее, я не хочу их нанимать. Плохое общение является причиной большинства проблем, которые я вижу в проектах. Я хочу нанять инициативных коммуникаторов.
Paddyslacker
3
Я задаю подобный, более общий вопрос ( «скажите мне о времени , когда что - то пошло не так, и что вы делали в ответ ...») Очень открытого состава, и все же у меня был один опрашиваемый клянутся вверх и вниз , что ничто не было никогда пошло не так для него. Излишне говорить, что я не рекомендовал его на прокат.
Алекс Фейнман
13
Как ты попал в программирование?
Хороший способ увидеть, есть ли у человека страсть к программированию и сломать лед.
Во время интервью кто - то , кто утверждает , чтобы иметь нетривиальное количество опыта Java, я спрашиваю их о hashcode()и equals()и отношениях между ними. На самом деле невозможно получить значительный опыт работы с Java, не осознавая потенциальных подводных камней, и любой, кто не знает об этой проблеме, будет добавлять трудно обнаруживаемые ошибки в мой проект.
Я также спрошу о ArrayListи LinkedListи относительные плюсы и минусы. Надеемся, что это должно доказать, что они, по крайней мере, знают и думают о влиянии на производительность кода, который они пишут.
Мне также нравится, когда они высказывают свое мнение по какой-то технической теме (полезность или иная причина Maven, проверенные и непроверенные исключения и т. Д.), А затем играют адвоката дьявола, чтобы увидеть, насколько хорошо они могут отстаивать свою точку зрения.
+1 Мне нравятся ArrayList и LinkedList. Я видел множество комментариев о том, что люди говорят, что списки ArrayLists должны быть отменены, но я могу придумать множество вариантов использования, где они лучше, чем LinkedLists
Эван Плейс,
СМЕШНО! Однажды два интервьюера спросили меня о разнице между списком и картой. Я изумленно посмотрел на них, они на самом деле извинились (а потом я ответил на их вопрос, и мы, конечно, продолжили интервью).
Хила
6
«Какую последнюю (лучшую) техническую книгу вы прочитали?»
или, в более общем плане:
"Как вы обновляете свои знания?"
Удивительно, сколько людей никогда не читали техническую книгу с тех пор, как закончили школу. И если вы никогда не читали книгу с тех пор, как закончили школу и закончили школу десять лет назад, вы, вероятно, никогда не слышали о таких вещах, как модульные тесты, шаблоны проектирования, принципы SOLID ...
Ответ на комментарий :
Вы можете отказаться от меня, если хотите, но это один из моих любимых вопросов для интервью. Блоги, Википедия, SO - все это отличные источники последних новостей о высоких технологиях. Но я не думаю, что вы можете изучать действительно сложные предметы (например, материал, который вы найдете в книгах Кнута), читая блоги.
Если мне придется выбирать между двумя разработчиками, где один демонстрирует желание изучать новые сложные предметы, а другой нет, я найму первого. Даже если он или она хочет больше денег. Это окупится в долгосрочной перспективе.
-1. Я редко открываю технические книги, но знаю, что такое TTD, и знаю некоторые шаблоны проектирования. Я узнал намного больше от SO (например, что такое фабричный шаблон) и из блогов Джона Скита и других специалистов, чем я узнал бы из посредственной книги. Ни одна из книг, которые я видел, не объясняла, например, почему проверки FxCop и StyleCop так важны для написания исходного кода спуска, который можно использовать повторно (даже не упомянув эти инструменты).
Арсений Мурзенко
3
+1 Вы можете многому научиться с помощью онлайн-статей и блогов, но даже если я не читаю технические книги, мне тоже не хватает инициативы и посредственности.
Данк
5
Переверните этот связанный список. Теперь сделайте это за линейное время. Теперь сделайте это в линейном времени и постоянном пространстве.
Я прочитал это в интервью одного из основателей Bruel & Kjaer, и это вызвало отклик во мне. Успешные люди с большой вероятностью считают себя счастливчиками. Они рассматривают неудачи как возможности для улучшения и стремятся поделиться своими успехами (удачей) с окружающими их людьми - счастливчики приносят больше удачи. *
Люди, которые считают себя несчастными, скорее всего, будут плохим яблоком в вашей команде.
* В этом контексте « Удача» должна рассматриваться как возможность подготовки к встрече , а не как клевер с четырьмя листьями.
+1 Я бы хотел, чтобы это повторилось в несколько раз.
ocodo
Наполеон однажды сказал: «Дайте мне генералов, которым повезло!»
Захари К
4
Тот, который всегда работал для меня ...
«Расскажи мне о своих предыдущих проектах» .
А затем использовать их ответы в качестве отправной точки, чтобы спросить их об их роли в проектах и почему они приняли определенные решения. Вместо того, чтобы делать интервью в SAT, я просто беседую с ними. Этого всегда было более чем достаточно, чтобы судить, подходит ли разработчик для данной должности.
Меня только однажды наняли на работу, где я уже знал используемый язык, поэтому вопросы, касающиеся языка, не имеют для меня большого значения. Я также лично не сильно беспокоюсь о синтаксических мелочах ( как бы вы делали сортировку сахарной ваты, будучи в ловушке в загоне, полном голодных зебр? ) И возникали вопросы, поэтому я никогда не задаю такой вопрос.
+1. Я тоже это спрашиваю. Но иногда трудно понять, какова была функция кандидата в проекте (руководитель проекта? Ведущий разработчик? Разработчик сопровождения? Оператор кофемашины?), Особенно когда они работали над большим проектом со многими людьми.
nikie
2
Если бы вы могли иметь какую-либо работу в мире, что бы это было?
Я действительно только ищу одну вещь: серьезную попытку ответить на это. Единственный неправильный ответ, так что смейтесь и скажите интервьюеру, что это самый ключевой вопрос интервью в мире. (Я проголосовал без найма).
Это действительно задание для моего самого любимого вопроса:
Если вы хотите стать [рок-звездой], почему вы подаете заявление на работу [инженером по разработке Интернета III] здесь, в [HugeCorp]?
Лучше всего, если они действительно дадут смелый ответ. Они редко видят, что это происходит, и для кого-то это действительно реальная возможность заявить что-то вроде «часы здесь лучше» или «моя карьера здесь продлится дольше, чем у обычной рок-звезды».
Я также соврал, что на первый вопрос нет неправильного ответа. Если вы не берете интервью для какой-то совершенно потрясающей работы своей мечты, тогда работа, за которую они берут интервью, является неправильным ответом. И если вы проводите собеседование на работу мечты и у вас ее еще нет, вы должны спросить себя, почему вы не подаете заявку на нее.
«И если вы проводите собеседование на работу мечты и у вас ее еще нет, вам следует спросить себя, почему вы не подаете заявку на нее». - Похоже на «проклятый, если вы делаете, проклятый, если вы не делаете» вопрос - особенно если вы относитесь к ответу так, как вы описываете. Если у кого-то есть работа мечты, возможно, он еще не чувствует, что готов ее взять, и нуждается в большем опыте в том, что он может узнать в вашей компании. Зачем им это против?
Марк Фридман
4
-1 Я отклонил предложения о работе от компаний, где люди задавали глупые, совершенно не относящиеся к делу вопросы, подобные этим. # 1 Это не имеет ничего общего с работой или тем, как вы будете выполнять # 2 Вместо того, чтобы брать интервью у человека, который интервьюер действительно пытается показать, насколько он умнее, чем собеседник, обманывая его, и поверьте мне, их высокомерие встречается довольно сильно # 3 Я не думаю, что хотел бы работать с pr @ # k $, который задает эти типы вопросов на собеседовании, если мне так не понравились они на собеседовании. Задавать вопрос о пиве, это другая история.
Данк
@Dunk: Вы правы, вопросы с подвохом говорят больше об интервьюере, чем об интервьюируемом. Но спрашивать о целях и желаниях человека в целом имеет смысл. Вы хотите, чтобы ваши сотрудники были довольны своей работой (несчастные люди не продуктивны), поэтому вы хотите знать, есть ли у вас подходящая работа для них.
nikie
@ Так как клиенты, с которыми я сталкиваюсь ежедневно, задают клише-вопросы и часто повторяют одни и те же глупые ошибки, такой клише-вопрос также помогает самому выбрать тип людей, которые не могут иметь дело с клиентами на моей работе. Плюс в том, что работа платит, чтобы компенсировать необходимость терпеть такое поведение. Так что в этом смысле это действительно вопрос префекта.
Шемнон
@ Марк Фридман - я не против этого. Это дает им возможность быть честными и прямыми в своей карьере. Если интервьюируемый чувствует, что он «проклят, если он делает, и проклят, если не делает», тогда работа не для них. Если вы не готовы высовывать шею честным ответом, это уже один знак против.
Шемнон
2
Проводя интервью на c #, я люблю спрашивать: «Как вы справляетесь с ошибками в методе»? Если я получу достойный ответ на этот вопрос, я задам вопрос: «Как / вы бы настроили обработку ошибок в веб-приложении?»
Я всегда удивляюсь тому, сколько разработчиков не имеют проблем с первым вопросом и не имеют ни малейшего понятия о втором. Я даже взял интервью у многих, кто не мог описать, как ошибки обрабатывались в их текущем проекте.
Требует ли ваша кодовая база знаний о сложностях, или это просто для того, чтобы оценить интерес к мельчайшим деталям?
Питер Тейлор
2
Обратите внимание, он не сказал «или»
Бен Л
1
@Ben, я думаю, ты просто бросил логическую бомбу в люк -: /
ocodo
2
Разве это не просто (x << 3) - x?
user13278
1
Или даже проще:x -(-x) - (-x) -(-x) - (-x) -(-x) - (-x)
nikie
1
Похож на Дэвида, но немного отличается:
Взгляните на грязный реальный рабочий код из более ранней версии, которую мы позже исправили и улучшили. Скажи мне, что он делает. Скажите, где проблемы (правильность и стиль). Скажи мне, как бы ты это исправил и улучшил.
Это помогает отличать людей, которые могут просто написать новый код, и людей, которые могут справиться с реальностью унаследованных кодовых баз.
Это довольно глубокий вопрос: как определяется совпадение? у вас есть какие-либо знания о частичном порядке в списке? Что это за список? Являются ли предметы сортируемыми? Насколько большой список? Какова относительная вычислительная стоимость сравнения и проверки соответствия? Разные ответы на эти вопросы могут изменить оптимальный подход .....
Микера
Как часто будет происходить этот поиск? Может ли это быть узким местом для производительности?
Justsalt
WTF, ребята. Начните с первого или последнего элемента, сравните, если нет совпадения, переходите к следующему элементу. Единственный вопрос: заботимся ли мы о нескольких совпадениях или мы прерываем поиск по первому совпадению? Если вы хотите дать некоторую информацию, вы можете добавить: Для связанных списков это не имеет значения, но для индексированных списков, если я также хочу извлечь совпадения, я бы прошел список в обратном порядке, поэтому мне не нужно обновлять индекс вне условия цикла.
NotGaeL
0
Мой любимый вопрос:
(Предположительно в сочетании Java / C # и псевдокода)
Используя неэкзотические контейнеры, спроектируйте класс, который будет вести себя как словарь с максимально возможной производительностью, что также позволяет перечислять ключи не в «случайном» порядке, а в том порядке, в котором эти ключи были добавлены в словарь, поскольку он был впервые создан.
Это приводит к слишком большому количеству уточняющих вопросов. Справедливо ли просто использовать две хеш-таблицы или хеш-таблицу и список массивов: одну, которая содержит порядок, а другую - порядок? Должна ли быть возможность удалить вещи? (Это делает его несколько более сложным.) Если значение обновляется, считается ли это его повторным добавлением?
дсимча
@dsimcha, хорошая мысль. У меня есть 20-30 минут для разговора, и я начинаю с: Пожалуйста, не стесняйтесь просить разъяснений в любой момент. Если вы чувствуете, что застряли, я был бы рад дать подсказку или направить вас в правильном направлении. Если человек все еще крутит свои колеса, то я бы сказал, что они не понимают структуры данных. Что касается разъяснения того, что я хочу - я бы предпочел оставить это открытым и взять его в разные стороны.
Ответы:
Взгляните на этот пример кода и расскажите, как вы можете его улучшить.
источник
Это немного специфично для моего сценария, но я думаю, что это был отличный вопрос, тем не менее:
Единственный вопрос, который у меня когда-либо возникал, на самом деле проверял мою способность учиться.
источник
Это не вопрос кодирования, а вопрос поведения:
источник
Как ты попал в программирование?
Хороший способ увидеть, есть ли у человека страсть к программированию и сломать лед.
источник
Во время интервью кто - то , кто утверждает , чтобы иметь нетривиальное количество опыта Java, я спрашиваю их о
hashcode()
иequals()
и отношениях между ними. На самом деле невозможно получить значительный опыт работы с Java, не осознавая потенциальных подводных камней, и любой, кто не знает об этой проблеме, будет добавлять трудно обнаруживаемые ошибки в мой проект.Я также спрошу о
ArrayList
иLinkedList
и относительные плюсы и минусы. Надеемся, что это должно доказать, что они, по крайней мере, знают и думают о влиянии на производительность кода, который они пишут.Мне также нравится, когда они высказывают свое мнение по какой-то технической теме (полезность или иная причина Maven, проверенные и непроверенные исключения и т. Д.), А затем играют адвоката дьявола, чтобы увидеть, насколько хорошо они могут отстаивать свою точку зрения.
источник
«Какую последнюю (лучшую) техническую книгу вы прочитали?»
или, в более общем плане:
"Как вы обновляете свои знания?"
Удивительно, сколько людей никогда не читали техническую книгу с тех пор, как закончили школу. И если вы никогда не читали книгу с тех пор, как закончили школу и закончили школу десять лет назад, вы, вероятно, никогда не слышали о таких вещах, как модульные тесты, шаблоны проектирования, принципы SOLID ...
Ответ на комментарий :
Вы можете отказаться от меня, если хотите, но это один из моих любимых вопросов для интервью. Блоги, Википедия, SO - все это отличные источники последних новостей о высоких технологиях. Но я не думаю, что вы можете изучать действительно сложные предметы (например, материал, который вы найдете в книгах Кнута), читая блоги.
Если мне придется выбирать между двумя разработчиками, где один демонстрирует желание изучать новые сложные предметы, а другой нет, я найму первого. Даже если он или она хочет больше денег. Это окупится в долгосрочной перспективе.
источник
Переверните этот связанный список. Теперь сделайте это за линейное время. Теперь сделайте это в линейном времени и постоянном пространстве.
источник
Считаете ли вы себя счастливчиком?
Я прочитал это в интервью одного из основателей Bruel & Kjaer, и это вызвало отклик во мне. Успешные люди с большой вероятностью считают себя счастливчиками. Они рассматривают неудачи как возможности для улучшения и стремятся поделиться своими успехами (удачей) с окружающими их людьми - счастливчики приносят больше удачи. *
Люди, которые считают себя несчастными, скорее всего, будут плохим яблоком в вашей команде.
* В этом контексте « Удача» должна рассматриваться как возможность подготовки к встрече , а не как клевер с четырьмя листьями.
источник
Тот, который всегда работал для меня ...
«Расскажи мне о своих предыдущих проектах» .
А затем использовать их ответы в качестве отправной точки, чтобы спросить их об их роли в проектах и почему они приняли определенные решения. Вместо того, чтобы делать интервью в SAT, я просто беседую с ними. Этого всегда было более чем достаточно, чтобы судить, подходит ли разработчик для данной должности.
Меня только однажды наняли на работу, где я уже знал используемый язык, поэтому вопросы, касающиеся языка, не имеют для меня большого значения. Я также лично не сильно беспокоюсь о синтаксических мелочах ( как бы вы делали сортировку сахарной ваты, будучи в ловушке в загоне, полном голодных зебр? ) И возникали вопросы, поэтому я никогда не задаю такой вопрос.
источник
Я действительно только ищу одну вещь: серьезную попытку ответить на это. Единственный неправильный ответ, так что смейтесь и скажите интервьюеру, что это самый ключевой вопрос интервью в мире. (Я проголосовал без найма).
Это действительно задание для моего самого любимого вопроса:
Лучше всего, если они действительно дадут смелый ответ. Они редко видят, что это происходит, и для кого-то это действительно реальная возможность заявить что-то вроде «часы здесь лучше» или «моя карьера здесь продлится дольше, чем у обычной рок-звезды».
Я также соврал, что на первый вопрос нет неправильного ответа. Если вы не берете интервью для какой-то совершенно потрясающей работы своей мечты, тогда работа, за которую они берут интервью, является неправильным ответом. И если вы проводите собеседование на работу мечты и у вас ее еще нет, вы должны спросить себя, почему вы не подаете заявку на нее.
источник
Проводя интервью на c #, я люблю спрашивать: «Как вы справляетесь с ошибками в методе»? Если я получу достойный ответ на этот вопрос, я задам вопрос: «Как / вы бы настроили обработку ошибок в веб-приложении?»
Я всегда удивляюсь тому, сколько разработчиков не имеют проблем с первым вопросом и не имеют ни малейшего понятия о втором. Я даже взял интервью у многих, кто не мог описать, как ошибки обрабатывались в их текущем проекте.
источник
Что-то вроде этого:
умножить значение на 7 без использования
*
,/
и+
операций. :)источник
(x << 3) - x
?x -(-x) - (-x) -(-x) - (-x) -(-x) - (-x)
Похож на Дэвида, но немного отличается:
Взгляните на грязный реальный рабочий код из более ранней версии, которую мы позже исправили и улучшили. Скажи мне, что он делает. Скажите, где проблемы (правильность и стиль). Скажи мне, как бы ты это исправил и улучшил.
Это помогает отличать людей, которые могут просто написать новый код, и людей, которые могут справиться с реальностью унаследованных кодовых баз.
источник
много лет назад меня спросили разницу между регулярными выражениями / a * / и / a *? /
Я лично склонен задавать несколько вопросов о рекурсии.
источник
?
Обозначает ли жадность или ноль или единицу ? Я видел оба синтаксиса.Я удивлен количеством ошибочных ответов на этот вопрос:
Как бы вы искали элемент в несортированном списке?
источник
Мой любимый вопрос:
(Предположительно в сочетании Java / C # и псевдокода)
Используя неэкзотические контейнеры, спроектируйте класс, который будет вести себя как словарь с максимально возможной производительностью, что также позволяет перечислять ключи не в «случайном» порядке, а в том порядке, в котором эти ключи были добавлены в словарь, поскольку он был впервые создан.
источник