Здравствуйте, Паблик Морозов, Вы писали:
ПМ>МГТУ им. Баумана, информатика и системы управления, параллельные вычисления и прочий рокетсайнс, аспирант. Вскрытие показывает: алгоритмы и структуры данных — o(1) (вплоть до того, что поиск у нас в бинарном дереве O(n) или что-то в этом роде), многопоточность — более-менее знает примитивы ОС, но высокоуровневые паттерны не знает, что такое Монитор — тоже. Ну и всякие мелкие задачки вроде посчитать int32 хешь-код от двух int32 — тоже как-то через пень колоду.
Всё это ищется в гугле за 5 минут.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Здравствуйте, gandjustas, Вы писали:
G>>Если знают, то какая разница чем они там в универе занимаются (обычно ничем хорошим в универах не занимаются). ПМ>Зачем тогда вообще универы нужны по-твоему?
Универы как раз должны давать основы детально и обзор технологий — поверхностно.
G>>Если не знают, то какой смысл оплачивать обучение программиста?
ПМ>По-твоему, программист дома CRM выучит, так, для прикола? (в универах программистов, понятное дело CRM не учат)
А думаешь алгоритмическую сложность или разворот списка "для прикола" учить будут?
Я вот как раз "для прикола" изучил SharePoint. Технологии вообще говоря монетизируются лучше чем развороты списков.
Здравствуйте, gandjustas, Вы писали:
G>Универы как раз должны давать основы детально и обзор технологий — поверхностно.
А теперь внимательно читаем исходный пост и выясняем, что он как раз о том, что у людей из универов отсутсвует представление об основах.
G>А думаешь алгоритмическую сложность или разворот списка "для прикола" учить будут?
Вообще-то это стандартная программа обучения по it-специальностям.
G>Я вот как раз "для прикола" изучил SharePoint. Технологии вообще говоря монетизируются лучше чем развороты списков.
Дурак со знанием технологии больше вреда принесёт, чем пользы.
Здравствуйте, IT, Вы писали:
ПМ>>МГТУ им. Баумана, информатика и системы управления, параллельные вычисления и прочий рокетсайнс, аспирант. Вскрытие показывает: алгоритмы и структуры данных — o(1) (вплоть до того, что поиск у нас в бинарном дереве O(n) или что-то в этом роде), многопоточность — более-менее знает примитивы ОС, но высокоуровневые паттерны не знает, что такое Монитор — тоже. Ну и всякие мелкие задачки вроде посчитать int32 хешь-код от двух int32 — тоже как-то через пень колоду. IT>Всё это ищется в гугле за 5 минут.
Отлично. Сотни копий сломано в борьбе кандидатов с работодателями, которые спрашивают основы алгоритмов и структур данных. Если это ищется в гугле за пять минут, что мешает погуглить перед очередным собеседованием? Назло работодателю не буду учить алгоритмы?
И еще надо знать, что искать. Человек должен хотя бы быть в курсе о существовании этих понятий. Если он их никогда не использовал в реальной работе, то столкнувшись с задачей, где неплохо бы их применить, он решит ее в лоб без каких-либо мыслей, можно ли и нужно ли делать оптимально, и вообще правильное ли это решение.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Паблик Морозов, Вы писали:
ПМ>>>Ну и всякие мелкие задачки вроде посчитать int32 хешь-код от двух int32 — тоже как-то через пень колоду. G>>Я вот и не понял о чем ты. Какой еще код от двух интов? Зачем он нужен? Какие к нему требования? Ты вопрос как задаешь?
ПМ>Примерно так: есть ссылочный объект (не struct) с двумя полями типа Int32. Мы хотим использовать этот объект в качестве ключа в хешь-таблице и хотим, чтобы оба поля в равной степени участвовали в формировании хешь-кода. Как бы вы реализовали getHashCode().
И что отвечали? Может лучше сразу спросить читал ли рихтера?
ПМ>З.З.Ы.: А окуда такая заинтересованность? Неповезло оказаться среди отфутболенных мной кандидатов?
Просто написал глупость, вот я и решил узнать что именно ты пытаешься сказать. А когда я был на собеседовании в brightconsult мне технических вопросов не задавали вообще.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Здравствуйте, gandjustas, Вы писали:
G>>Универы как раз должны давать основы детально и обзор технологий — поверхностно. ПМ>А теперь внимательно читаем исходный пост и выясняем, что он как раз о том, что у людей из универов отсутсвует представление об основах.
Искренне верю, и че? Они ведь не "основами" программы пишут.
G>>А думаешь алгоритмическую сложность или разворот списка "для прикола" учить будут? ПМ>Вообще-то это стандартная программа обучения по it-специальностям.
В каком месте? Я учился по такой специальности, про вычислительную сложность только вскользь упоминали.
G>>Я вот как раз "для прикола" изучил SharePoint. Технологии вообще говоря монетизируются лучше чем развороты списков. ПМ>Дурак со знанием технологии больше вреда принесёт, чем пользы.
Умный без знания технологий принесет вреда еще больше, так как будет везде нерелевантный опыт пихать.
Поэтому для начала надо бы удостовериться что человек в курсе того с чем работать надо и умеет задачи решать, а потом же выяснять его способности к разворачиванию списков.
Здравствуйте, gandjustas, Вы писали:
G>И что отвечали?
Как обычно, с ходу отвечает один из 10 (правда потом сразу следует вопрос "а почему именно так и чем хуже вариант Б"). Правда среди сфейлевших были и очень интересные предложения, настолько интересные, что я даже рекомендовал человека (правда дальше его зарубили).
G>Может лучше сразу спросить читал ли рихтера?
Не лучше. Мне не важно, читал ли человек Рихтера, мне надо, чтобы он умел пользоваться хешь-таблицей. Может быть он Advanced Data Structures читал, зачем ему ваш Рихтер?
G>Просто написал глупость
Где именно?
G>А когда я был на собеседовании в brightconsult мне технических вопросов не задавали вообще.
Здравствуйте, Donz, Вы писали:
IT>>Всё это ищется в гугле за 5 минут. D>Отлично. Сотни копий сломано в борьбе кандидатов с работодателями, которые спрашивают основы алгоритмов и структур данных. Если это ищется в гугле за пять минут, что мешает погуглить перед очередным собеседованием? Назло работодателю не буду учить алгоритмы?
Погуглить и запомнить? И сколько мне нужно нагуглить и запомнить перед интервью?
Впрос нужно ставить не так. Если задаёшь такие вопросы на интервью, то дай человеку возможность на том же интервью вопспользоваться гуглом для нахождения ответа. Например, тот же хэш из двух интов я делал в своей жизни несколько раз, но каждый раз иду и ищу алгоритм в гугле или подсматриваю у MS или JetBrains. На самом деле правильный подход здесь
Здравствуйте, gandjustas, Вы писали:
G>В каком месте? Я учился по такой специальности, про вычислительную сложность только вскользь упоминали.
Ну значит так учился, или в таком месте нехорошем. А то, что и сейчас не знаешь, характерезует тебя как неполноценного специалиста.
G>Умный без знания технологий принесет вреда еще больше, так как будет везде нерелевантный опыт пихать.
На основе опыта только обезьянки действуют с квадратно-гнездовым смособом мышления, а умный прежде всего анализирует задачу. Поэтому нерелевантного опыта скорее надо ждать от опытного дурака — неверно распознает паттерн и применит шаблонное решение не подумав, а там раз, и нюанс какой-нибудь выплывет.
Здравствуйте, IT, Вы писали:
IT>Погуглить и запомнить? И сколько мне нужно нагуглить и запомнить перед интервью?
Вычисление хеша от двух интов вполне можно сообразить на месте. Навряд ли кто будет требовать идеальную функцию, но какое-то решение предложить можно.
Сложность поиска в неотсортированном списке тоже запоминать не нужно. И в сортированном не нужно.
На самом деле даже незнание устройства HashMap — это не конец интервью. Один разработчик с наводящего вопроса, как бы сделать o(1), прямо на собеседовании рассказал собственную реализацию этой структуры.
IT>Интервью прежде всего должно выявлять людей умеющих решать проблемы. А это не всегда коррелирует с набором заученных знаний у претендента.
Человек должен видеть проблему. Вполне вероятно, сложность o(N^2) для него совершенно не проблема. А в реальной работе не будет человека, который намекнет, что o(n) лучше. И проще будет реализовать такую задачу самому, чем потом проводить код-ревью и объяснять, в чем тут дело.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>На основе опыта только обезьянки действуют с квадратно-гнездовым смособом мышления, а умный прежде всего анализирует задачу. Поэтому нерелевантного опыта скорее надо ждать от опытного дурака — неверно распознает паттерн и применит шаблонное решение не подумав, а там раз, и нюанс какой-нибудь выплывет.
Не совсем так. Голое знание без умения решать проблемы гораздо хуже, чем незнание вообще, по той причине, что очень сильно повышает самооценку у знающего.
Говорят, что люди бывают умные и глупые, активные и пассивные, и наихудший вариант — это глупые и активные. Так вот применительно к программистам я бы умный/глупый заменил на две другие категории: умеющий/не умеющий решать проблемы и знающий/не знающий. В результате станет ясно, что самая плохая комбинация — это активный/знающий/не умеющий решать проблемы. Как правило у таких людей гипертрофированная самоуверенность в собственной экстрординарности, что в купе со знанием и активностью является исключительной разрушительной силой для любого проекта.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Второй вообще кандидат физ-мат наук, МГУ мех-мат. Писал какие-то алгоритмы для Интеля, позиционуется на должность ведущего разработчика/архитектора. Что такое вычислительная сложность — не знает. Интересно, как он их писал?..
А вот стоит у тебя задача реализовать аппроксимацию солида с помощью меша, или сделать extrusion параметрической поверхности в направлениях, заданных набором узлов. Не "быстро сделать", не "разными способами", а просто сделать чтобы оно без глюков работало. А есть еще масса алгоритмов, которые не найдешь ни в книжках, ни в статьях — их надо делают первый раз и не знают сработает ли вообще что-то или нет. Вот нафига тебе тут сложность? Я вот когда писал такие вещи, то слышал от сложности, имел какое-то очень базовое представление об О(1) или об О(n) тк просто прочитав можно примерно сказать что это может быть, но _никогда_ не использовал. И в дальнейшем я вообще сталкивался с этим в крайне специфических задачах ( ну не считая всякой фигни типа в конец вектора вставляется быстрее чем в середину ).
А еще чаще оптимизировать надо было не по О() а на уровне языка и самой структуры кода — когда при верном алгоритме хреновая реализация.
Так что если человек не твердо знает что такое О() это еще ни о чем не говорит, он вполне мог алгоритмы комп. зрения писать и О ему нафиг никогда не упало.
Здравствуйте, Donz, Вы писали:
D>Вычисление хеша от двух интов вполне можно сообразить на месте. Навряд ли кто будет требовать идеальную функцию, но какое-то решение предложить можно.
Это смотря как на это посмотреть. Можно сообразить и изобрести трехколёсный велосипед, а можно в гугле найти идеальную функцию. Какой разработчик тебе больше понравится?
D>Человек должен видеть проблему. Вполне вероятно, сложность o(N^2) для него совершенно не проблема. А в реальной работе не будет человека, который намекнет, что o(n) лучше. И проще будет реализовать такую задачу самому, чем потом проводить код-ревью и объяснять, в чем тут дело.
Так о том и речь. Нужны не столько знания, сколько умение не только видеть, но и решать проблемы.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Это смотря как на это посмотреть. Можно сообразить и изобрести трехколёсный велосипед, а можно в гугле найти идеальную функцию. Какой разработчик тебе больше понравится?
Тот, который предложит свое решение и скажет, что задача, скорее всего, типовая и надо посмотреть, как она уже решена в готовых библиотеках.
D>>Человек должен видеть проблему. Вполне вероятно, сложность o(N^2) для него совершенно не проблема. А в реальной работе не будет человека, который намекнет, что o(n) лучше. И проще будет реализовать такую задачу самому, чем потом проводить код-ревью и объяснять, в чем тут дело. IT>Так о том и речь. Нужны не столько знания, сколько умение не только видеть, но и решать проблемы.
Понимание, что здесь есть проблема, требует определенных знаний. В общем, нужен не только потенциал и соображалка разработчика, но и уже готовые знания и опыт. Без знаний набирают обычно студентов, в этом случае как раз надо в первую очередь мышление проверять.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Не верьте всему, что пишут в резюме.
ПМ>В общем мне тяжело оценивать всяких там физиков и математиков, т.к. я вообще не знаю, чему их учат и как они докатываются до жизни такой (т.е. становятся программистами), но вот некоторые программисты-по-специальности меня удивляют. Имён и конкретные данные давать не буду просто парочка примеров.
ПМ>МГТУ им. Баумана, информатика и системы управления, параллельные вычисления и прочий рокетсайнс, аспирант. Вскрытие показывает: алгоритмы и структуры данных — o(1) (вплоть до того, что поиск у нас в бинарном дереве O(n) или что-то в этом роде), многопоточность — более-менее знает примитивы ОС, но высокоуровневые паттерны не знает, что такое Монитор — тоже. Ну и всякие мелкие задачки вроде посчитать int32 хешь-код от двух int32 — тоже как-то через пень колоду. Не, в целом всё не так плохо, я даже его рекомендовал, просто не понятно, чем они там в своём МГТУ им. Баумана занимаются на кафедре параллельных вычислений?
В чем смысл вопросов а-ля "Monitor" ? Люди тыщу лет работают с локами и критсекциями, но их "legacy" названия могут и не знать. Я бы не стал спрашивать именно про паттерны, а поинтересовался деталями,вроде
мультипоточных синглтонов. Для понимания ширины кругозора опять-таки не стал бы спрашивать определения книжных терминов, а спросил бы про lock-free алгоритмы
Задачка "посчитать хэшкод от 2х int32" меня вполне могла бы испугать, на собеседовании-то — тут уже не с кондачка ксорить или складывать, а математически доказывать, что хэшкод получится оптимальным как по быстродействию, так и по коллизиям.
Если нам не помогут, то мы тоже никого не пощадим.
.
