Комментарии 35
>> умен и доводит дело до конца
эта фраза — отсылка к Спольски и его статье о собеседованиях — russian.joelonsoftware.com/Articles/Interviewing.html
эта фраза — отсылка к Спольски и его статье о собеседованиях — russian.joelonsoftware.com/Articles/Interviewing.html
опытных промышленных программистов, которые не могли сказать мне, что такое бинарное дерево
Простите, а чем их опыт измеряется тогда, годами чтоли?
Кстати, описанная в статье задача выглядит гораздо более адекватной, чем куча мелких задач на комбинаторику или алгоритмы, что заставляют решать на большинстве собеседований. Человек на собеседовании показывает, как быстро генерировать перестановки или какова вероятность бросания n-мерного кубика со смещенным центром тяжести, а потом устраивается на работу и изо дня в день исправляет неправильное отображение диалогов на экране или проектирует базы данных. Если мы говорим не про найм олимпиадников для оптимизации каких-нибудь баз данных в памяти, то большая задача, которая позволяет в комплексе оценить умение человека думать, гораздо более важна, чем
Но про основы автор, безусловно, прав. Меня вот иногда приглашают принимать экзамен по архитектуре компьютеров у студентов второкурсников, мне половина не отвечает, как отрицательные целые числа в памяти представляются в x86. А что такое виртуальная память, отвечает при лучшем раскладе только каждый четвертый. И это топовый российский вуз, ага.
«гораздо более важна, чем знание пары конкретных алгоритмов». Куда-то конец фразы пропал.
Часть людей все таки отвечают на все вопросы, или интерес к невидимым подробностям иссекает со временем?
Невидимые подробности — это Вы о чем? Я не очень понял вопроса, если честно.
Я имею ввиду подробности работы компьютера и ОС. Работает и ладно, что там внутри интересует немногих.
И все таки, были ли случаи когда отвечали на все вопросы, или когда сами задавали такие что глаза на лоб? :)
И все таки, были ли случаи когда отвечали на все вопросы, или когда сами задавали такие что глаза на лоб? :)
Работает и ладно, что там внутри интересует немногих.
Надеюсь, это все же была шутка.
Отвечают на все вопросы многие. К счастью, вершина айсберга никуда не делась, и она не такая уж и маленькая. Многие осознают, зачем пришли в университет, и им интересно учиться.
Но есть ли по-вашему какой-то необходимый предел низкоуровневости знаний? Скажем, нужно ли знать особенности интерфейса взаимодействия процессора с северным мостом? Или, если это был неудачный пример, достаточно ли знать сложность сортировки бинкучи или нужно уметь доказать эту сложность?
Как узнать, в какой момент лучше уже не лезть в эту степь? Думаю, вы не станете спорить, что понимать в программировании все невозможно да и бессмысленно.
Как узнать, в какой момент лучше уже не лезть в эту степь? Думаю, вы не станете спорить, что понимать в программировании все невозможно да и бессмысленно.
Я бы сказал, что есть необходимый минимум, который должен знать каждый уважающий себя разработчик ПО независимо от области, в которой он работает. Если говорить про железо, то это общая архитектуры компьютера и влияние физических характеристик железа на работу программ. Например, человек должен понимать, чем ограничен максимальный объем подключаемой оперативки, что такое кэш процессора, как хранятся типы данных в памяти, как происходит работа с ними и т.п.
Аналогично про алгоритмы и структуры данных — списки, стеки, очереди, деревья, хеш-таблицы, графы: концепции абстрактных типов данных, хотя бы самые базовые реализации и алгоритмы работы с ними. Упрощенно задача программиста — решить задачу наиболее быстро и эффективно, для этого надо быть в состоянии выбрать наиболее подходящие для нее инструменты. Ну а для этого, в свою очередь, надо понимать, чем структуры данных между собой различаются, осознавать понятие сложности алгоритмов.
Это не полный список, но, я надеюсь, идея понятна. Все это составляет базовую культуру в этой области. Не знать таких вещей — это как не знать, что Земля круглая или когда была Вторая мировая война: жить можно, но непонятно, что от такого человека ждать. У меня есть цикл лекций по основам программирования как раз для студентов первого курса (практически нулевой порог вхождения), как раз вот эти фундаментальные вещи. Если интересно, я могу опубликовать тезисно его как-нибудь тут для обсуждения. Вопрос, что есть минимум, правда интересный.
Конечно не стану. Предел каждый для себя сам определяет. Если интересно ковыряться в алгоритмах, например, кто же запретит. Если же задача в «расширении кругозора», то остановиться стоит, на мой взгляд, когда качество начинает требовать количества. Хороший пример — спортивное программирование: чтобы добраться до уровня середнячка, надо очень многое узнать и попробовать, а вот чтобы выбраться в топ, надо очень много тренироваться на однотипных задачах, набивая руку. Понятно, что последнее не имеет особого смысла для тех, кто просто хочет подтянуться в алгоритмах, скажем.
Аналогично про алгоритмы и структуры данных — списки, стеки, очереди, деревья, хеш-таблицы, графы: концепции абстрактных типов данных, хотя бы самые базовые реализации и алгоритмы работы с ними. Упрощенно задача программиста — решить задачу наиболее быстро и эффективно, для этого надо быть в состоянии выбрать наиболее подходящие для нее инструменты. Ну а для этого, в свою очередь, надо понимать, чем структуры данных между собой различаются, осознавать понятие сложности алгоритмов.
Это не полный список, но, я надеюсь, идея понятна. Все это составляет базовую культуру в этой области. Не знать таких вещей — это как не знать, что Земля круглая или когда была Вторая мировая война: жить можно, но непонятно, что от такого человека ждать. У меня есть цикл лекций по основам программирования как раз для студентов первого курса (практически нулевой порог вхождения), как раз вот эти фундаментальные вещи. Если интересно, я могу опубликовать тезисно его как-нибудь тут для обсуждения. Вопрос, что есть минимум, правда интересный.
Как узнать, в какой момент лучше уже не лезть в эту степь? Думаю, вы не станете спорить, что понимать в программировании все невозможно да и бессмысленно.
Конечно не стану. Предел каждый для себя сам определяет. Если интересно ковыряться в алгоритмах, например, кто же запретит. Если же задача в «расширении кругозора», то остановиться стоит, на мой взгляд, когда качество начинает требовать количества. Хороший пример — спортивное программирование: чтобы добраться до уровня середнячка, надо очень многое узнать и попробовать, а вот чтобы выбраться в топ, надо очень много тренироваться на однотипных задачах, набивая руку. Понятно, что последнее не имеет особого смысла для тех, кто просто хочет подтянуться в алгоритмах, скажем.
Очень странно, что перечислив достаточно низкоуровневые вещи, вы упустили вещи уровнем повыше: работа компиллятора, GC, транзакции в базах данных и многое другое. Это тоже вещи, с которыми сталкивается «каждый уважающий себя разработчик ПО». Но какой смысл знать, сколько места занимает указатель в 64хбитной системе, если ты написал код, который после компилляции никогда не освободит этот указатель?
Нужно ли мне уметь написать красно-черное дерево, если оно уже есть в стандартной библиотеке и покрыто всевозможными тестами, или мне достаточно знать ситуации, когда его следует/не следует использовать?
Хватит ли времени на изучение всего вами перечисленного одновременно с перечисленным и не перечисленным мной? Мне кажется, нет. А тут, простите, ни слова еще не сказали об архитектуре приложений, в которой, на мой взгляд, любой уважающий себя программист тоже должен разбираться. И как же быть с новыми технологиями, в зоопарке которых (и это уже не мое мнение, а реальное положение рынка труда) мы все обязаны свободно плавать?
Это, конечно, тема для холивора. Но я понимаю людей, которые предпочитают знание интерфейса знанию реализации. Они, конечно, меньше похожи на седых старцев-волшебников, но тоже имеют свое право считаться «уважающими себя разработчиками ПО».
Нужно ли мне уметь написать красно-черное дерево, если оно уже есть в стандартной библиотеке и покрыто всевозможными тестами, или мне достаточно знать ситуации, когда его следует/не следует использовать?
Хватит ли времени на изучение всего вами перечисленного одновременно с перечисленным и не перечисленным мной? Мне кажется, нет. А тут, простите, ни слова еще не сказали об архитектуре приложений, в которой, на мой взгляд, любой уважающий себя программист тоже должен разбираться. И как же быть с новыми технологиями, в зоопарке которых (и это уже не мое мнение, а реальное положение рынка труда) мы все обязаны свободно плавать?
Это, конечно, тема для холивора. Но я понимаю людей, которые предпочитают знание интерфейса знанию реализации. Они, конечно, меньше похожи на седых старцев-волшебников, но тоже имеют свое право считаться «уважающими себя разработчиками ПО».
Согласен, работа компилятора, управление памятью, основы БД, архитектура ПО, основы ООП, ФП, параллельного, сетевого программирования и многое другое — это все фундамент, который надо знать. Зоопарк технологий я бы в него включать не стал: грамотный человек, понимающий общий принцип (у которого сформирован вот этот фундамент), вполне в состоянии разобраться с новым языком или технологией за вполне разумное время.
Если человек не знает, что такое указатель, но умеет им пользоваться — это все равно карго-культ, который рано или поздно выстрелит ему в ногу или голову. Такого человека я бы на работу не взял даже стажером. А вот если он не умеет написать красно-черное дерево, но знает, зачем вообще нужны деревья и может реализовать BST (или хотя бы рассказать алгоритм работы с ним), например, у него гораздо больше шансов.
Но я понимаю людей, которые предпочитают знание интерфейса знанию реализации. Они, конечно, меньше похожи на седых старцев-волшебников, но тоже имеют свое право считаться «уважающими себя разработчиками ПО».
Если человек не знает, что такое указатель, но умеет им пользоваться — это все равно карго-культ, который рано или поздно выстрелит ему в ногу или голову. Такого человека я бы на работу не взял даже стажером. А вот если он не умеет написать красно-черное дерево, но знает, зачем вообще нужны деревья и может реализовать BST (или хотя бы рассказать алгоритм работы с ним), например, у него гораздо больше шансов.
Ну, в целом я с вами согласен, но я бы смог работать с человеком, который не понимает в алгоритмы, но понимает в красоту кода, что после него хотя бы можно оптимизировать написанное без особого труда. Потому как встречались разработчики, которые замечательно разбираются в таких вещах, но пишут код, сложность которого зашкаливает и в котором кроме них никто не разбирается. Этот код работает и работает быстро, а разраб сел на высокую зарплату и теплое место. Казалось бы, всюду плюсы. Ан нет.
Я бы тоже не смог :)
Хочу сказать, что знания зависит от области, в которой человек работает, и какие задачи он обычно выполняет.
Вот вы, в какой области работаете?
Если будут вопросы по «базовым вещам»: «алгоритмы, структуры данных, тонкости синтаксиса языка» — то с большей вероятностью наймете студента, а не опытного программиста. Просто у студента свежие знания из института, а промышленный программист это все уже подзабудет, т.к. почти никогда не использует в реальных задачах.
Это все, безусловно, полезно знать, но если не нужно использовать в работе, то человек это забудет рано или поздно.
Тогда в чем опытность?
Способность одному и в команде сделать проект длительностью разработки не несколько месяцев, а несколько лет; знание стека технологий в данном направлении; знание различных инструментов разработчика и умение ими пользоваться; умение писать понятный другим код; умение проектировать архитектуру, которую не надо переделывать при каждом малейшем изменении требований; понимание, что есть готовые решение и не нужно писать велосипеды и т.д.
Вот вы, в какой области работаете?
Если будут вопросы по «базовым вещам»: «алгоритмы, структуры данных, тонкости синтаксиса языка» — то с большей вероятностью наймете студента, а не опытного программиста. Просто у студента свежие знания из института, а промышленный программист это все уже подзабудет, т.к. почти никогда не использует в реальных задачах.
Это все, безусловно, полезно знать, но если не нужно использовать в работе, то человек это забудет рано или поздно.
Тогда в чем опытность?
Способность одному и в команде сделать проект длительностью разработки не несколько месяцев, а несколько лет; знание стека технологий в данном направлении; знание различных инструментов разработчика и умение ими пользоваться; умение писать понятный другим код; умение проектировать архитектуру, которую не надо переделывать при каждом малейшем изменении требований; понимание, что есть готовые решение и не нужно писать велосипеды и т.д.
Хочу сказать, что знания зависит от области, в которой человек работает, и какие задачи он обычно выполняет
Специальные знания, конечно, зависят от конкретной области работы, но базовые фундаментальные знания одинаковы для всех. Или Вы считаете, что, скажем, веб-программисту, необязательно знать, как куча и стек работают?
Это все, безусловно, полезно знать, но если не нужно использовать в работе, то человек это забудет рано или поздно.
Что забудет, как бинарное дерево поиска работает или что такое виртуальная память? Опять же, я говорю о базовых вещах, которые нельзя «развидеть», если понял принцип :)
С последним абзацем я согласен, только редко уж больно встречаются такие самородки, которые без образования это все могут.
С последним абзацем я согласен, только редко уж больно встречаются такие самородки, которые без образования это все могут.
Вот тут путаете корреляцию с зависимостью, мне кажется. Хотя и поучиться пришлось в разных университетах и поработать с выпускниками разных университетов, не встречал пока такой учебной программы, где про архитектуру рассказывали бы что-то посложнее UML. Максимум — уровня «паттерн стратегия» и то не преподы, а приглашенные программисты.
Ну вот если как у меня руки дойдут свою программу четырехсеместрового курса выложить сюда, посмотрите, может покритикуете, там весь третий семестр про архитектуру. Правда, практика показывает, что толку от одной теории мало, так что у нас потом все это закрепляется в студпроектах и летних школах по программированию.
По-моему опыту, многие преподаватели в вузах считают фундаментальными именно те предметы, которые сами и преподают :) Так и в программировании, спросите программистов из различных областей (пусть будут, например, микроконтроллеры и JavaScript), какие знания они считают фундаментальными для своей работы — мне кажется пересечений будет мало.
Попробую Вас убедить, что если не используется, забывается все :)
Сможете посчитать дискриминант или вспомнить теорему косинусов? Конечно, может Вы математик, и такой вопрос для Вас простой.
Если в его задачи не входит оптимизация производительности, то скорее всего нет.
Знание, например, что типы значений копируются при присваивании, а у ссылочных типов при этом копируется ссылка — важно, но это не имеет отношение к тому как куча и стек работают.
Про стек как структуру данных полезно знать любому программисту. Нечасто, но когда-нибудь пригодиться.
Сможете посчитать дискриминант или вспомнить теорему косинусов? Конечно, может Вы математик, и такой вопрос для Вас простой.
Или Вы считаете, что, скажем, веб-программисту, необязательно знать, как куча и стек работают?Можете привести пример, как это ему пригодится не в 1% решаемых задач, а хотя в 10%?
Если в его задачи не входит оптимизация производительности, то скорее всего нет.
Знание, например, что типы значений копируются при присваивании, а у ссылочных типов при этом копируется ссылка — важно, но это не имеет отношение к тому как куча и стек работают.
Про стек как структуру данных полезно знать любому программисту. Нечасто, но когда-нибудь пригодиться.
Сможете посчитать дискриминант или вспомнить теорему косинусов?
Оказывается, помню, но не суть. Я же не профессиональный математик, мне теорему косинусов не грех и забыть лет этак через 10, но вряд ли какой-то геометр ее когда-то забудет. То же самое и с программированием, разве нет? Профессионал не может забыть основы своей области.
Можете привести пример, как это ему пригодится не в 1% решаемых задач, а хотя в 10%?
А что, в джаваскрипте сборку мусора уже отменили? Я временами встречаю страницы, на которых была такая дикая работа с памятью, что плакать хочется. Оптимизация производительности в таком случае — это уже исправление последствий неграмотности разработчика.
Профессионал не может забыть основы своей области.Полностью все — нет. Многое из того, что долго не приходилось использовать — забудет:) Или по крайней мере будет гораздо хуже помнить, чем раньше.
Вы преподаете — поэтому основы хорошо помните. Вам их каждый год надо студентам объяснять.
А что, в джаваскрипте сборку мусора уже отменили? Я временами встречаю страницы, на которых была такая дикая работа с памятью, что плакать хочется. Оптимизация производительности в таком случае — это уже исправление последствий неграмотности разработчика.Тут скорее последствие того, что один разработчик пишет серверную часть, работает с базой данных, занимается администрированием сервера, версткой страниц под разные браузеры и пишет js код на клиенте. И все это на постоянно меняющихся технологиях. Это сколько потребуется времени, чтобы во всем этом экспертом стать? Естественно, что будут пробелы в том или ином месте. Ну и второй момент, что большинству работадателей нужно пораньше сделать продукт и начать получать с него прибыль. Кому нужен круто сделанный оптимизированный программный продукт, который не приносит прибыли? Если он уже приносит прибыль и становятся видны проблемы с производительностью и т.п., то тогда встает вопрос об улучшении.
Про javascript — не знаю. Про C# знаю. Но, думаю не важно. Что в сборке мусора конкретно нужно знать, без чего нельзя написать нормально работающую программу?
Ладно, я Вас не убедил. Давайте последний Ваш пост и не будем продолжать далее холивар:)
Все таки
how’s it going so far?переводится как
Как дела?, а не как
Ну как все проходит?, что не имеет смысла в русском языке.
Точно! Спасибо, поправил.
Всё–таки «so far» в этой фразе не просто так. Имеется в виду вопрос: «как проходит собеседование?» — в смысле доволен ли кандидат собой и/или собеседующими, не устал ли он, как вообще себя чувствует, но именно в контексте сегодняшнего дня и конкретно данного собеседования, а не в целом.
Я не знаю, как правильно, понятно и полноценно перевести этот вопрос (мой вариант потребовал 3 строчки пояснений, так что он далек от идеала), да это наверное и не очень важно; я лишь хотел обратить внимание на это «so far», которое придает вопросу более конкретный оттенок, нежели «how's it going?» или «how're you?»
Я не знаю, как правильно, понятно и полноценно перевести этот вопрос (мой вариант потребовал 3 строчки пояснений, так что он далек от идеала), да это наверное и не очень важно; я лишь хотел обратить внимание на это «so far», которое придает вопросу более конкретный оттенок, нежели «how's it going?» или «how're you?»
Описанное интервью, это где-то примерно третье интервью на пути потенциального кандидата. Большинство (не знакомых с особенностями интервью в западных компаниях) не прорвётся даже через первые вопросы первого интервью, которые будут звучать примерно как «Tell me about yourself», «Tell me about a time when you failed», «Tell me how you deal with a conflict situation» и т.д. и т.п. на протяжении часа.
Да, у меня половина знакомых на этих вопросах тихо расплачется и медленно поползет к выходу :)
Пол-года, годик поработают на лесопилке или на разноске газет (реальные истории), и не только не расплачуться, но и выучат ответы штук на 100-200 подобных вопросов так, что от зубов будет отлетать. Конечно, возможно вариации, но если компания достаточно большая, то первая линия защиты будет примерно такой.
Elevator Pitch в статье выше и есть вопрос «Tell me about yourself», на который ожидается вполне определённый ответ (минут на 5-ть). Если кандидат начнёт что-то вроде «в ХХ-ых годах я пошёл в детский сад, потом в школу, потом...» то вероятно на нём тут же поставят крестик, хотя и продолжат интервью.
Elevator Pitch в статье выше и есть вопрос «Tell me about yourself», на который ожидается вполне определённый ответ (минут на 5-ть). Если кандидат начнёт что-то вроде «в ХХ-ых годах я пошёл в детский сад, потом в школу, потом...» то вероятно на нём тут же поставят крестик, хотя и продолжат интервью.
Ну не скажите. Одно дело, когда человека спрашивают о проекте, в котором он работал (конкретные факты, которыми он может оперировать), а другое дело — спрашивают его о том, кем он видит себя через пять лет (невнятная перспектива, про которую он, может, и не думал никогда). И эти товарищи не будут на лесопилке или разноске газет работать. К счастью для них, у нас в России много компаний (и западных в том числе), которые учитывают большой процент интровертов в индустрии и не особо стремятся задавать такие вопросы, особенно в течение часа.
Ой, был я однажды на собеседовании в «западной» конторе, ну позадавали мне подобных тупых вопросов, я был злой, рявкнул на них.
Уже потом я узнал, что мое место занял человек, который программировать нихрена не может, плодит г-код, и только трепать языком умеет.
Так что не ясно, кто тут выиграл, а кто тут проиграл.
Уже потом я узнал, что мое место занял человек, который программировать нихрена не может, плодит г-код, и только трепать языком умеет.
Так что не ясно, кто тут выиграл, а кто тут проиграл.
Верно. К примеру такая штука модная в США, где мол нанимают general developer! «lean team» так что и скорость кодинга и самого кода тоже важна! Хотя ищут конкретно Sr. Android Developer к примеру. Но задать вопросы на тему сортировки списков, бинарный дерев ну просто необходимо, да еще онлайн и по телефону/google hangouts. Так что, нужен обычно Sr. Android Developer, а нанимают студентов у которых свежие знания с универа. Так и живем тут.
p.s. сейчас сам иду через этот процесс, докатился что MIT лекции онлайн смотреть начал оп data structures & algorithms.
p.s. сейчас сам иду через этот процесс, докатился что MIT лекции онлайн смотреть начал оп data structures & algorithms.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
О собеседованиях (от Эрика Липперта)