Какой твой любимый вопрос для интервью? [закрыто]

Какой вопрос вы нашли особенно ценным при опросе разработчиков программного обеспечения? Что такого в вопросе, который сделал его особенно полезным?

Я ищу конкретный вопрос, который вы хотели бы задать, а не просто подход к собеседованию, например «заставьте их написать код».

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

Это немного специфично для моего сценария, но я думаю, что это был отличный вопрос, тем не менее:

Таким образом, вы говорите здесь, что вы никогда не касались C # или .NET, верно? Итак, вот рабочая станция. Узнайте, как написать программу, которая запрашивает эту базу данных и печатает список клиентов с их заказами, отсортированный по имени клиента. Вы можете использовать любой ресурс, который вы хотите.

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

Это не вопрос кодирования, а вопрос поведения:

Расскажите мне о времени, когда вы просто не смогли выполнить всю свою работу вовремя, чтобы уложиться в срок. Что ты сделал? Каков был результат?

Как ты попал в программирование?

Хороший способ увидеть, есть ли у человека страсть к программированию и сломать лед.

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

Я также спрошу о ArrayListи LinkedListи относительные плюсы и минусы. Надеемся, что это должно доказать, что они, по крайней мере, знают и думают о влиянии на производительность кода, который они пишут.

Мне также нравится, когда они высказывают свое мнение по какой-то технической теме (полезность или иная причина Maven, проверенные и непроверенные исключения и т. Д.), А затем играют адвоката дьявола, чтобы увидеть, насколько хорошо они могут отстаивать свою точку зрения.

«Какую последнюю (лучшую) техническую книгу вы прочитали?»

или, в более общем плане:

"Как вы обновляете свои знания?"

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

Ответ на комментарий :

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

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

Переверните этот связанный список. Теперь сделайте это за линейное время. Теперь сделайте это в линейном времени и постоянном пространстве.

Считаете ли вы себя счастливчиком?

Я прочитал это в интервью одного из основателей Bruel & Kjaer, и это вызвало отклик во мне. Успешные люди с большой вероятностью считают себя счастливчиками. Они рассматривают неудачи как возможности для улучшения и стремятся поделиться своими успехами (удачей) с окружающими их людьми - счастливчики приносят больше удачи. *

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

* В этом контексте « Удача» должна рассматриваться как возможность подготовки к встрече , а не как клевер с четырьмя листьями.

Тот, который всегда работал для меня ...

«Расскажи мне о своих предыдущих проектах» .

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

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

Если бы вы могли иметь какую-либо работу в мире, что бы это было?

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

Это действительно задание для моего самого любимого вопроса:

Если вы хотите стать [рок-звездой], почему вы подаете заявление на работу [инженером по разработке Интернета III] здесь, в [HugeCorp]?

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

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

Проводя интервью на c #, я люблю спрашивать: «Как вы справляетесь с ошибками в методе»? Если я получу достойный ответ на этот вопрос, я задам вопрос: «Как / вы бы настроили обработку ошибок в веб-приложении?»

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

Что-то вроде этого:

умножить значение на 7 без использования *, /и +операций. :)

Похож на Дэвида, но немного отличается:

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

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

много лет назад меня спросили разницу между регулярными выражениями / a * / и / a *? /

Я лично склонен задавать несколько вопросов о рекурсии.

Я удивлен количеством ошибочных ответов на этот вопрос:

Как бы вы искали элемент в несортированном списке?

Мой любимый вопрос:

(Предположительно в сочетании Java / C # и псевдокода)

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