Тоже верно. С другой стороны, вы же понимаете: человек не может знать все одинаково хорошо. Как ни крути, computer science — слишком широкая область, и у каждого разработчика есть та или иная специализация. Смена профиля по необходимости, или по желанию — штука полезная. Другое дело, кому это сделать проще, какой бэкграунд этому способствует — но тут мы рискуем начать холивар «насколько программисту нужно знать математику».
Ну на самом деле, если бы я прошел собеседования, у меня был бы повод задуматься, не факт, что я бы отказался. Просто не было прям сильного рвения (и возможности, если честно) потратить значительное время на подготовку. Почитал Рихтера, GoF и Скиену 4 вечера, освежил в памяти, что-то новое открыл для себя, и пошел.
Как мы уже выше в обсуждениях выяснили, тут срабатывает единый подход к собеседованиям в Яндексе, т.е. спрашивают про хитрые тонкости даже на те вакансии, где это особо не нужно. Если бы я шел на проект поиска или Крипты — безусловно, там без мощных знаний математики и СДиА даже делать нечего. Но для разработки desktop-приложений, плагинов к браузеру — вряд ли нужно обладать таким же багажом.
а чтобы отличить спецов-теоретиков от реальных спецов, нужно не просто спрашивать теорию, а смотреть на опыт. И давать тестовые задачки. Спрашивать академическую теорию имеет смысл для junior-вакансий, когда есть знания, нет опыта. После нескольких лет работы все, что не используется на практике — выветривается напрочь… Зато появляется опыт.
Понимаете в чем дело, есть большие сомнения, кто такие эти суперспецы. Поясню.
С ходу помню как минимум два случая, в разных компаниях, когда человек был очень грамотен, но не умел самого главного — работать. Эти люди делали крутейшие технические презентации своих идей, заваливали названиями ультрасовременных технологий, и я уверен, что на все вопросы Яндекса про деревья и пр. ответили бы без запинки. Проходило время, а прогресса по задачи нет. В итоге в обоих случаях эти суперспецы, знающие всё, так и не доделали свои задачи, запутавшись в сложности своих реализаций, пытаясь решить задачу такими крутыми решениями и алгоритмами, что в итоге это все просто не заработало. Это чуть не завалило весь проект, и мне приходилось выкашивать их код и с нуля делать рабочее решение.
У меня не было цели устроиться, хотелось проверить свой текущий уровень. И если мне для собеседования в компанию нужно зубрить книги, лихорадочно пытаясь запомнить то, что в реальной разработке мне никогда не нужно — то это не та компания, где бы я хотел работать, ее входные требования оторваны от реальности.
Я и не спорю, что для специфических задач такое знание нужно, мы говорили о другом: что базовое, а что нет. Это не базовое) В том проекте, куда я собеседовался, нет кластерных вычислений, но видимо в Яндексе общие для всех проектов требования.
Про то, зачем нужна балансировка деревьев я им ответил, и про несколько разновидностей такой балансировки — но в общих чертах. Знать это недостаточно чтобы с ходу, в условиях интервью сгенерить на бумажке алгоритм удаления в такой структуре. Вам кажется это очевидным, просто потому что вы уже знаете этот алгоритм — смогли бы додуматься до него самостоятельно?
Наша беседа ушла из конструктивного русла. Я описал критерий, по которому определяю, какие знания для программиста считать базовыми. Вы пишите
Минимум такое описание должен уметь дать каждый, кто претендует на какой-то программистский умственный труд.
-никак это не обосновывая. Почему это должен знать каждый программист? А кто-то скажет, что каждый программист должен знать алгоритм .........(вставить нужное)...., лишь описание которого занимает пол книги. А кто-то скажет «достаточно знать что такое int». Если нет критерия, все очень субъективно, все эти «должен-не должен».
Не буду минусовать ваш комментарий, просто отмечу: я ни слова не сказал о недостатках интервьюера, речь шла о подходе к собеседованию в целом. Мне было по чему судить, т.к. я прошел 4 этапа собеседования, все с разными интервьюерами. И еще раз скажу: я не зол на Яндекс, не призываю их сменить подход к найму. У них это работает, результат налицо — это главное. Просто мне непонятно как, вот и все:)
Сложно сказать, какую степень подробности они от меня ждали, поскольку вопрос исчерпал себя почти сразу: я просто не помню шаги этого алгоритма. У нас с вами разное видение того, что считать базовыми знаниями, и я не претендую на то, чтобы как-то вас переубеждать. Просто поясню, по какому критерию я определяю что базовое знание, а что нет.
Если разработчик много лет успешно решает задачи в рамках тех проектов, над которыми работает его компания, к качеству его кода, архитектуре выбранных решений, и производительности в готовом продукте нет претензий у его коллег и тимлида — он обладает базовыми знаниями.
Для тех задач, которые мне приходилось решать в своей жизни (например, это проекты в сфере разработки 3D игр с искусственным интеллектом, Enterprise-системы для обработки геоданных) — мне ни разу не пригодилось знание алгоритмов работы красно-черного дерева.
Так устроена человеческая психика, что поделать. То, что вызвало недовольство, стимулирует к поиску недостатков. Но это не означает само по себе, что недостатков нет, тут уже нужно конкретно рассматривать.
Помнить алгоритм удаления в красно-черном дереве — вы считаете это базовым?
Поясните пожалуйста, каким образом это так, если это изучают на СДиА (на 3-м курсе ВУЗа), и потом за много лет разработки подавляющему числу программистов ни разу не приходится реализовывать красно-черное дерево, покуда быстрее и правильнее (особенно в бизнес-разработке) использовать готовые решения (STL в C++, generics в C#).
Чтобы правильно выбрать контейнер мне не нужно дотошно знать все его алгоритмы реализации, достаточно знать сложность всех его операций (выраженную в О-нотации).
Проходил в Яндексе собеседование на С++-разработчика, было интересно проверить себя. Не прошел, попросил дать обратную связь, и мне скинули примерный список вопросов, где я плавал. Это очень и очень специфичные вещи, типа алгоритма удаления в красно-черном дереве, на каких процессорах встречается big-endian, как внутри устроен boost'овый smart_ptr и пр.
Помнить как можно больше алгоритмов сортировок, помнить тонкости деревьев — может либо вчерашний студент, либо человек, кто с этим постоянно работает (но таких единицы). Вот и получается парадокс: у вчерашнего студента шанс ответить правильно выше, чем у меня, разработчика с 10-летним стажем, за который мне ни разу не пригодились эти специфичные вещи. Даже если бы понадобились: подобные моменты легко гуглятся, являясь по сути справочными данными.
По поводу того, что нагуглить невозможно, не было задано ни одного вопроса, я о реальном опыте разработки. Как строится архитектура высоконагруженных Enterprise-систем, как организуется корпоративная шина данных, отказоустойчивая синхронизация данных от множества систем и многое другое. Нужны годы реальной коммерческой разработки чтобы все это узнать, но Яндексу важнее знания специфических технических деталей, чем опыт разработки. Не осуждаю конечно, это право компании, решать, по какому критерию вести найм, просто был искренне удивлен таким подходом.
Со Smalltalk, увы, не доводилось работать. Если это настолько мощный язык — почему он не в числе основных, используемых для разработки бизнес-приложений? Просто любопытно.
Дело в том, что функции являются фундаментальным понятием, в то время как объекты лишь содержат их.
На первый взгляд да. Но если копнуть чуть глубже:
1. Даже минимальная (но не пустая) функция будет оперировать чем? Правильно, переменными.
2. Объявленная, но не используемая переменная бесполезна.
3. Следовательно, минимальным элементом, «атомом» кода является данные+действие над ними.
Из чего следует, что ни данные, ни функции — не являются первичными. Это обычная дуальная пара, два полюса, не существующие по отдельности.
Ну а объект — это как раз данные + методы. В свете вышесказанного его некорректно сравнивать с функциями. В C# так и есть — «все есть объект», вы можете написать даже так: 42.ToString()
Проблема автора оригинального текста, что он буквально понимает «все». Да, оператор сложения — не объект, запятая — не объект, ну это как бы нормально) Функция (метод) в объекте — тоже не объект, но она, как я показал выше, неотделима от данных объекта.
Я учился в Новосибирском государственном техническом университете,
первый год — язык С (функции, массивы, циклы, указатели, сортировки, основные структуры данных и алгоритмы). Правда фактически мы писали на «С++ без классов», т.е. если переименовать те исходники из *.cpp в *.c — код бы не собрался, он не соответствовал чистому С. Но в целом хорошая база.
второй год — С++, да, ООП… но на уровне книги о языке С++ для начинающих. Основные понятия (классы, конструкторы, наследование, полиморфизм, шаблоны), ни слова о дизайне (SOLID, паттерны), о фреймворках (STL, BOOST), и тем более системе (потоки, синхронизация и пр.). Скажем так, язык и связанные с ним технологии я выучил сам. Впрочем, на разных специальностях немного по-разному.
То что А поступил не вполне корректно — факт.
Смысл моего комментария в том, что хабр — не место для обсуждения плохого поведения людей, для этого есть zadolba.li. и прочие подобные. Жаловаться на людей и обстоятельства — не самое лучшее, чему можно посветить время, свое и читателей. Здесь очень много одаренных людей, стремящихся использовать свои интеллектуальные и творческие способности для создания удивительных вещей, смелых проектов и открытий — так не будем же опускаться до уровня А, публично комментируя чье-то поведение.
Сэкономить время тем, кто ищет работу — мотив хороший, однако:
1. Для меня бы это не стало сигналом «туда не ходи». Может это в целом вполне хорошая компания, я бы не стал делать выводы по одному человеку.
2. Опять же, хабр это не «черный список работодателей».
Уважаемый автор,
как было бы здорово прочитать ваш пост в другом аспекте: смотрите, какие интересные задачи мне задали на собеседовании, давайте вместе их попробуем решить. А так… Вы выносите на всеобщее обозрение свою личную обиду на человека, который позволил себе проявить бестактность. Увы, это было всегда, люди не идеальны — но зачем умножать общее количество «мирового негатива» еще дальше? Вы получили ценный опыт, тот сотрудник наверняка тоже сделал какие-то выводы — все счастливы)
Я не спорю с тем, что нынешняя система даст творческому альтруисту умереть от голода, и озолотит тех, кто выстроил хитроумные схемы по монетизации своей деятельности. И следовательно, людям приходится думать о заработке. Речь о другом: все это не значит, что человек делает все только ради прибыли. Unix — живой пример того, что люди могут сделать не за зарплату.
Как мы уже выше в обсуждениях выяснили, тут срабатывает единый подход к собеседованиям в Яндексе, т.е. спрашивают про хитрые тонкости даже на те вакансии, где это особо не нужно. Если бы я шел на проект поиска или Крипты — безусловно, там без мощных знаний математики и СДиА даже делать нечего. Но для разработки desktop-приложений, плагинов к браузеру — вряд ли нужно обладать таким же багажом.
а чтобы отличить спецов-теоретиков от реальных спецов, нужно не просто спрашивать теорию, а смотреть на опыт. И давать тестовые задачки. Спрашивать академическую теорию имеет смысл для junior-вакансий, когда есть знания, нет опыта. После нескольких лет работы все, что не используется на практике — выветривается напрочь… Зато появляется опыт.
С ходу помню как минимум два случая, в разных компаниях, когда человек был очень грамотен, но не умел самого главного — работать. Эти люди делали крутейшие технические презентации своих идей, заваливали названиями ультрасовременных технологий, и я уверен, что на все вопросы Яндекса про деревья и пр. ответили бы без запинки. Проходило время, а прогресса по задачи нет. В итоге в обоих случаях эти суперспецы, знающие всё, так и не доделали свои задачи, запутавшись в сложности своих реализаций, пытаясь решить задачу такими крутыми решениями и алгоритмами, что в итоге это все просто не заработало. Это чуть не завалило весь проект, и мне приходилось выкашивать их код и с нуля делать рабочее решение.
Наша беседа ушла из конструктивного русла. Я описал критерий, по которому определяю, какие знания для программиста считать базовыми. Вы пишите
-никак это не обосновывая. Почему это должен знать каждый программист? А кто-то скажет, что каждый программист должен знать алгоритм .........(вставить нужное)...., лишь описание которого занимает пол книги. А кто-то скажет «достаточно знать что такое int». Если нет критерия, все очень субъективно, все эти «должен-не должен».
Если разработчик много лет успешно решает задачи в рамках тех проектов, над которыми работает его компания, к качеству его кода, архитектуре выбранных решений, и производительности в готовом продукте нет претензий у его коллег и тимлида — он обладает базовыми знаниями.
Для тех задач, которые мне приходилось решать в своей жизни (например, это проекты в сфере разработки 3D игр с искусственным интеллектом, Enterprise-системы для обработки геоданных) — мне ни разу не пригодилось знание алгоритмов работы красно-черного дерева.
Поясните пожалуйста, каким образом это так, если это изучают на СДиА (на 3-м курсе ВУЗа), и потом за много лет разработки подавляющему числу программистов ни разу не приходится реализовывать красно-черное дерево, покуда быстрее и правильнее (особенно в бизнес-разработке) использовать готовые решения (STL в C++, generics в C#).
Чтобы правильно выбрать контейнер мне не нужно дотошно знать все его алгоритмы реализации, достаточно знать сложность всех его операций (выраженную в О-нотации).
Помнить как можно больше алгоритмов сортировок, помнить тонкости деревьев — может либо вчерашний студент, либо человек, кто с этим постоянно работает (но таких единицы). Вот и получается парадокс: у вчерашнего студента шанс ответить правильно выше, чем у меня, разработчика с 10-летним стажем, за который мне ни разу не пригодились эти специфичные вещи. Даже если бы понадобились: подобные моменты легко гуглятся, являясь по сути справочными данными.
По поводу того, что нагуглить невозможно, не было задано ни одного вопроса, я о реальном опыте разработки. Как строится архитектура высоконагруженных Enterprise-систем, как организуется корпоративная шина данных, отказоустойчивая синхронизация данных от множества систем и многое другое. Нужны годы реальной коммерческой разработки чтобы все это узнать, но Яндексу важнее знания специфических технических деталей, чем опыт разработки. Не осуждаю конечно, это право компании, решать, по какому критерию вести найм, просто был искренне удивлен таким подходом.
На первый взгляд да. Но если копнуть чуть глубже:
1. Даже минимальная (но не пустая) функция будет оперировать чем? Правильно, переменными.
2. Объявленная, но не используемая переменная бесполезна.
3. Следовательно, минимальным элементом, «атомом» кода является данные+действие над ними.
Из чего следует, что ни данные, ни функции — не являются первичными. Это обычная дуальная пара, два полюса, не существующие по отдельности.
Ну а объект — это как раз данные + методы. В свете вышесказанного его некорректно сравнивать с функциями. В C# так и есть — «все есть объект», вы можете написать даже так: 42.ToString()
Проблема автора оригинального текста, что он буквально понимает «все». Да, оператор сложения — не объект, запятая — не объект, ну это как бы нормально) Функция (метод) в объекте — тоже не объект, но она, как я показал выше, неотделима от данных объекта.
первый год — язык С (функции, массивы, циклы, указатели, сортировки, основные структуры данных и алгоритмы). Правда фактически мы писали на «С++ без классов», т.е. если переименовать те исходники из *.cpp в *.c — код бы не собрался, он не соответствовал чистому С. Но в целом хорошая база.
второй год — С++, да, ООП… но на уровне книги о языке С++ для начинающих. Основные понятия (классы, конструкторы, наследование, полиморфизм, шаблоны), ни слова о дизайне (SOLID, паттерны), о фреймворках (STL, BOOST), и тем более системе (потоки, синхронизация и пр.). Скажем так, язык и связанные с ним технологии я выучил сам. Впрочем, на разных специальностях немного по-разному.
Вопрос слегка не по теме: а что плохого в С++? В плане изучения ООП.
Смысл моего комментария в том, что хабр — не место для обсуждения плохого поведения людей, для этого есть zadolba.li. и прочие подобные. Жаловаться на людей и обстоятельства — не самое лучшее, чему можно посветить время, свое и читателей. Здесь очень много одаренных людей, стремящихся использовать свои интеллектуальные и творческие способности для создания удивительных вещей, смелых проектов и открытий — так не будем же опускаться до уровня А, публично комментируя чье-то поведение.
Сэкономить время тем, кто ищет работу — мотив хороший, однако:
1. Для меня бы это не стало сигналом «туда не ходи». Может это в целом вполне хорошая компания, я бы не стал делать выводы по одному человеку.
2. Опять же, хабр это не «черный список работодателей».
как было бы здорово прочитать ваш пост в другом аспекте: смотрите, какие интересные задачи мне задали на собеседовании, давайте вместе их попробуем решить. А так… Вы выносите на всеобщее обозрение свою личную обиду на человека, который позволил себе проявить бестактность. Увы, это было всегда, люди не идеальны — но зачем умножать общее количество «мирового негатива» еще дальше? Вы получили ценный опыт, тот сотрудник наверняка тоже сделал какие-то выводы — все счастливы)
Касательно задачи про Pi == 3, есть разные статьи на эту тему.
Развлечения — это все понятно. Люди делают и что-то ценное для других бесплатно.