Здравствуйте, landerhigh, Вы писали:
L>И так стопицот раз.
Ну хорошо, и как ты предлагаешь таких отсеивать? Задачками про гномиков?
Ну и, чтоб два раза не вставать — сотрудник, который выберет с самого начала правильное решение (ты, например) — будут у него проблемы с оценкой сложности контейнеров/алгоритмов?
Здравствуйте, integ21hurra, Вы писали:
I>А потом у таких любителей алгоритмов получаются макароны кода, при поддержки которого возникают прямые ассоциации с работой сантехника.
Зачастую макароны получаются у тех кто не разбирается в алгоритмах/контейнерах
Знание алгоритмов/контейнеров не говорит о том, что у человека плохо с дизайном. Зато наоборот, если программист не в состоянии осилить их, то вряд ли он сможет осилить и дизайн
J>>В частности, при написании кода нужно постоянно думать о I>Думать о чем-то надо тогда, когда есть соответствующие ограничения. Если их нет — то это пустая трата времени.
Если изначально использовались premature pessimized решения, то при росте системы некоторые из них могут выстрелить, причём это может произойти в неудобном месте, например на стороне клиента. А это выливается в целую цепочку "траты времени": письмо в support, ticket, assignment, локализация и решение проблемы + для решения возможно понадобится частичный рефакторинг, новый билд + отправка клиенту.
Что бы всего этого избежать, достаточно было немного подумать, а не тупо давить button'ы.
I>Нагуглить алгоритм поиска — это 2 минуты, а вот нагуглить идеальную архитектуру конкретной программной системы не получится.
Если не знать про более оптимальное решение, или про то, что уже есть реализация нужного алгоритма, то может и не возникнуть желание нагуглить.
Например:
1) O( ln N ) поиск — это нормально? "Ну вроде да — общая сложность O(N ln N) — приемлемо".
А вот если знать о готовом решении, либо знать "как его придумать" — посмотреть на паттерны во входных данных — то поиск будет O(1), и общая сложность O(N), да и памяти требуется в разы меньше.
2) Нужно применить некоторую операцию попарно к элементов двух range'ей, а потом с-reduce-ить их результаты. Если не знать про существование inner_product ("А что, и такой есть?") — то и получатся макароны. И google тут ничем не поможет.
I>Мало того, большинство задач будут связаны вовсе не с изобретением велосипедов по стандартным алгоритмам.
Многие задачи решаются путём комбинирования стандартных контейнеров и алгоритмов
При "правильном" дизайне, этот самый дизайн не будет требовать времени намного больше чем непосредственно реализация новых фич/решение задач.
Здравствуйте, integ21hurra, Вы писали:
J>>Один вопрос всего: позиция, где подчеркивается знание ООД, предполагает написание кода? Или это чисто для архитекторов в высокой башне из слоновой кости, а код должны писать чернь, рабы-кодеры?
I>Нагуглить алгоритм поиска — это 2 минуты, а вот нагуглить идеальную архитектуру конкретной программной системы не получится. Мало того, большинство задач будут связаны вовсе не с изобретением велосипедов по стандартным алгоритмам.
I>В рамках хорошего кода важна его сопровождаемость, а вовсе не знание стандартных алгоритмов, поэтому даже если человек ошибется с выбором и это критично скажется, то это можно будет легко найти и исправить.
Сорри, что значит — нагуглить? Оно все — поиск, или там контейнер Ну нагуглится тебе 20 алгоритмов — и как ты будешь выбирать, не имея навыков оценки сложности и, как следствие, оценки применимости данного алгоритма/контейнера в данных условиях? Согласись, понимание сложности стандартных контейнеров и алгоритмов — это все-таки базовые вещи.
Ну и немалая часть архитектуры — это организация данных, т.е. контейнеры и связанные с ними алгоритмы.
Здравствуйте, integ21hurra, Вы писали:
I>В рамках хорошего кода важна его сопровождаемость, а вовсе не знание стандартных алгоритмов, поэтому даже если человек ошибется с выбором и это критично скажется, то это можно будет легко найти и исправить.
Встречал людей которые пишут хорошую архитектуру , они все знали базовые алгоритмы и разбирались в сложности. Хдается мне , это не спроста.
EP>Знание алгоритмов/контейнеров не говорит о том, что у человека плохо с дизайном. Зато наоборот, если программист не в состоянии осилить их, то вряд ли он сможет осилить и дизайн
Если человек не помнит на собеседовании конкретный алгоритм, то это никак не говорит о том, что он не в состоянии его осилить.
EP>Что бы всего этого избежать, достаточно было немного подумать, а не тупо давить button'ы.
Эта вина кого угодно, но не рядового программиста. Тем более, если столько стадий между клиентом и исполнителем, то можно хотя бы одну стадию code review предусмотреть.
Здравствуйте, integ21hurra, Вы писали:
EP>>Знание алгоритмов/контейнеров не говорит о том, что у человека плохо с дизайном. Зато наоборот, если программист не в состоянии осилить их, то вряд ли он сможет осилить и дизайн I>Если человек не помнит на собеседовании конкретный алгоритм, то это никак не говорит о том, что он не в состоянии его осилить.
разговор шёл про хэш-таблицу, стандартные контейнеры.
Вообще-то знание сложности алгоритмов/контейнеров стандартной библиотеки — это базовые знания, типа жи/ши, как-то даже неудобно это обсуждать
...
Как ты сможешь сказать, чем хороша и чем плоха хеш-таблица и как ее качество зависит от качества хеш-функции, если ты не знаешь, как она устроена?
Как можно "не помнить на собеседовании" хэш-таблицу, map или например vector? Даже если "подчеркивается знание OOD"? Что можно на-OOD-шить без таких базовых знаний?
J>>В частности, при написании кода нужно постоянно думать о I>Думать о чем-то надо тогда, когда есть соответствующие ограничения. Если их нет — то это пустая трата времени. EP>>Что бы всего этого избежать, достаточно было немного подумать, а не тупо давить button'ы. I>Эта вина кого угодно, но не рядового программиста.
Так это был ответ на выделенное жирным.
Да, и я считаю что "рядовой" программист тоже должен думать
I>Тем более, если столько стадий между клиентом и исполнителем, то можно хотя бы одну стадию code review предусмотреть.
Ты говоришь что думать нужно при "соответсвующих ограничениях", а не всегда. При таком подходе код с квадратичным поиском может пройти это code review — "а что, сейчас ведь всего 10 элементов?".
Или ты имеешь ввиду, что ревьювер должен думать, а программист нет?
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, landerhigh, Вы писали:
L>>И так стопицот раз.
J>Ну хорошо, и как ты предлагаешь таких отсеивать? Задачками про гномиков?
Про отсеивать отвечу поговоркой — "кто долго жену выбирает, тому кривая достается".
Задача интервьювера — подобрать наиболее подходящего сотрудника для выполнения данной работы. А то ведь отсеять можно и Кнута и Страуструпа, было бы желание.
J>Ну и, чтоб два раза не вставать — сотрудник, который выберет с самого начала правильное решение (ты, например) — будут у него проблемы с оценкой сложности контейнеров/алгоритмов?
У меня таких проблем не бывает. Я не делаю из алгоритмов идола. Это просто инструмент, при работе с которым не зазорно и в справочник подсмотреть, благо справочинков этх дофига. Более того, хороший инженер — это тот, кто строит из себя ходячую энциклопедию, а тот, кто проверяет и перепроверяет в том числе самого себя, и не полагается на остаточные знания.
Другое дело, что нужно понимать, что такое алгоритмическая сложность. Но проблема в том, что действительно понимают это очень немногие.
Вот типичный пример — для решения абстрактной задачи в вакууме можно применить алгоритм с O(1), а можно с O(N). Для абстрактной задачи в вакууме выбор очевиден. Теперь переходим от абстрактной задачи к конкретной. И вот тут уже далеко не до всех доходит, что O(N) может оказаться предпочтительнее.
Здравствуйте, landerhigh, Вы писали:
L>Про отсеивать отвечу поговоркой — "кто долго жену выбирает, тому кривая достается". L>Задача интервьювера — подобрать наиболее подходящего сотрудника для выполнения данной работы. А то ведь отсеять можно и Кнута и Страуструпа, было бы желание.
Ну так с задачей вроде ни у кого проблем нет (кроме Вжика), мы тут процесс обсуждаем — что именно должен делать интервьюер и как, чтобы задачу выполнить.
С учетом того, что "данная работа" всегда подразумевает написание кода.
Ты сам как интервью проводишь? Поделись.
J>>Ну и, чтоб два раза не вставать — сотрудник, который выберет с самого начала правильное решение (ты, например) — будут у него проблемы с оценкой сложности контейнеров/алгоритмов?
L>У меня таких проблем не бывает. Я не делаю из алгоритмов идола. Это просто инструмент, при работе с которым не зазорно и в справочник подсмотреть, благо справочинков этх дофига. Более того, хороший инженер — это тот, кто строит из себя ходячую энциклопедию, а тот, кто проверяет и перепроверяет в том числе самого себя, и не полагается на остаточные знания.
Оно, конечно, так, но если под стандартной библиотекой понимать библиотеку объема STL, то это весьма маленький объем и помнить его не составит труда ни для кого. Это гораздо меньше, чем таблица умножения чисел в пределах десятка, которую мы учим наизусть в школе, тогда когда Кнут/Кормен соответствуют таблице умножения чисел в пределах сотни.
L>Другое дело, что нужно понимать, что такое алгоритмическая сложность. Но проблема в том, что действительно понимают это очень немногие.
Вот-вот.
L>Вот типичный пример — для решения абстрактной задачи в вакууме можно применить алгоритм с O(1), а можно с O(N). Для абстрактной задачи в вакууме выбор очевиден. Теперь переходим от абстрактной задачи к конкретной. И вот тут уже далеко не до всех доходит, что O(N) может оказаться предпочтительнее.
Вот именно для этого я прошу людей оценить сложность написанного ими на бумажке кода. Это сразу отделяет зубрил от сёкарей.
EP>Как можно "не помнить на собеседовании" хэш-таблицу, map или например vector? Даже если "подчеркивается знание OOD"? Что можно на-OOD-шить без таких базовых знаний?
Там выше было про особенности реализации и алгоритмы, а вовсе не про знание их существования. Помнить об этом можно в одному случае — если вы очень внимательно читали непосредственную реализацию или документацию перед собеседованием. Есть еще люди с феноменальной памятью, но ими можно пренебречь.
EP>Да, и я считаю что "рядовой" программист тоже должен думать
Про "Думать" было сказано в контексте ограничений. Можно во главу угла ставить поддерживаемость кода и порой это будет противоречить другим принципам — в том числе и тому, что код не будет оптимизированным с точки зрения затрат памяти или проц. времени.
Да и мы давно уже не в СССР, у любой фирмы есть собственник — нужно ему, чтобы код соответствовал — пусть ставит соответствующим образом задачи.
EP>Ты говоришь что думать нужно при "соответсвующих ограничениях", а не всегда. При таком подходе код с квадратичным поиском может пройти это code review — "а что, сейчас ведь всего 10 элементов?". EP>Или ты имеешь ввиду, что ревьювер должен думать, а программист нет?
Code review — один из инструментов донести стиль кодирования, принятые стандарты до новичка. Люди могут годами работать в проектах по искривленным RAPID-технологиям, где об оптимизации вообще не думают. Лучше иметь гибкого человека, который может научиться, чем человека-зубрилку, да и первые более приятны в общении.
Здравствуйте, jazzer, Вы писали:
L>>Задача интервьювера — подобрать наиболее подходящего сотрудника для выполнения данной работы. А то ведь отсеять можно и Кнута и Страуструпа, было бы желание. J>Ну так с задачей вроде ни у кого проблем нет (кроме Вжика),
Строго говоря, я согласен с Вжиком в том, что в последнее время что-то стало модно скорее отсеивать, нежели искать сотрудников. Даже на примере соседнего отдела в моей конторе. Более того, сейчас есть практика сбора негатива, когда цель собеседований — собрать подтверждение тому, что "никого не найти".
J>мы тут процесс обсуждаем — что именно должен делать интервьюер и как, чтобы задачу выполнить. J>С учетом того, что "данная работа" всегда подразумевает написание кода. J>Ты сам как интервью проводишь? Поделись.
Разговор по резюме и по душам. В зависимости от настроения — пара задачек на устное обсуждение.
J>>>Ну и, чтоб два раза не вставать — сотрудник, который выберет с самого начала правильное решение (ты, например) — будут у него проблемы с оценкой сложности контейнеров/алгоритмов?
L>>У меня таких проблем не бывает. Я не делаю из алгоритмов идола. Это просто инструмент, при работе с которым не зазорно и в справочник подсмотреть, благо справочинков этх дофига. Более того, хороший инженер — это тот, кто строит из себя ходячую энциклопедию, а тот, кто проверяет и перепроверяет в том числе самого себя, и не полагается на остаточные знания. J>Оно, конечно, так, но если под стандартной библиотекой понимать библиотеку объема STL, то это весьма маленький объем и помнить его не составит труда ни для кого. Это гораздо меньше, чем таблица умножения чисел в пределах десятка, которую мы учим наизусть в школе, тогда когда Кнут/Кормен соответствуют таблице умножения чисел в пределах сотни.
Ну-ка, ну-ка, ты когда последний раз использовал set_intersection? Способ применения и сложность set_difference сходу вспомнишь? Уверен, что знаешь, какой минимальный оверхед имеет std::string в используемой у вас реализации STL?
L>>Другое дело, что нужно понимать, что такое алгоритмическая сложность. Но проблема в том, что действительно понимают это очень немногие. J>Вот-вот.
L>>Вот типичный пример — для решения абстрактной задачи в вакууме можно применить алгоритм с O(1), а можно с O(N). Для абстрактной задачи в вакууме выбор очевиден. Теперь переходим от абстрактной задачи к конкретной. И вот тут уже далеко не до всех доходит, что O(N) может оказаться предпочтительнее.
J>Вот именно для этого я прошу людей оценить сложность написанного ими на бумажке кода. Это сразу отделяет зубрил от сёкарей.
Здравствуйте, landerhigh, Вы писали:
L>Ну-ка, ну-ка, ты когда последний раз использовал set_intersection?
Три месяца назад. Правда это был не STL, а Boost.Range — но там только в сахаре отличие. (да и range'вая версия внутри вызывает std::...)
L>Способ применения и сложность set_difference сходу вспомнишь?
Да — два входных range'а, OutputIterator + опционально предикат упорядочивания.
Эти операции работают только с отсортированными range'ами, следовательно сложность линейная от общего числа элементов.
L>Уверен, что знаешь, какой минимальный оверхед имеет std::string в используемой у вас реализации STL?
Код собирается на {5 последних версиях MSVC, трёх GCC}x{x32,x64(там где есть)} + возможно в будущем CLang (как источник дополнительных warnings/errors) — в таких условиях запоминать какие-то конкретные особенности реализации, если в целом работает приемлемо, тем более для строк, которые используются не в critical path — не рационально.
Здравствуйте, genre, Вы писали:
G>Вообще меня искренне удивляет количество людей на форуме искренне считающих, что по рассказу о том, что человек делал можно определить его квалификацию. G>например я сейчас наблюдаю пару десятков программистов квалификации от "кандидат на увольнение" до "способен в одиночку поднять сложный проект". они все работают над одним проектом и рассказывать о том, что они делали будут очень похоже. Причем тот самый кандидат на увольнение раскажет красочнее и убедительнее всех.
Предлагаю провести следственный эксперимент, посадить нескольких кандидатов на увольнение и нескольких "в одиночку" за гномиков и сортировки и посмотреть корреляцию между гномиками и работой.
On 16.02.2013 13:55, genre wrote:
> я не писал про "бездельничать", я писал про качество кода. ты же не > будешь спорить, что программисты пишут код разного качества?
А формулировку разного качества мы сможем от тебя получить?
А то знаешь, в общем случае, что качественнее, белаз или мерседес?
On 16.02.2013 16:57, landerhigh wrote:
> Мне хватает 15 минут общения с человеком, чтобы понять, что он из себя > представляет как специалист. Не ошибался ни разу.
Это потому, что ты отвечаешь за свои действия и осознаешь их
последствия. Противоположная же сторона просто боится, часто даже не
понимая чего и поэтому пытаются прикрыться всякими бумажками,
регламентами и т.п.
On 16.02.2013 17:18, jazzer wrote:
> Т.е. они выбирали контейнер неправильно, несмотря на то, что знали его > устройство до тонкостей?
Тебя это удивляет. Очень много есть людей, которые при достаточно
объемных знаниях делают неправильный выбор. Обычно это уже становиться
понятно еще в институтах, глядя на студентов вокруг.
Неужели у вас небыло отличников, которые не могли и строки кода написать
или сделать хоть какую-то работу самостоятельно (кроме той, что в
методичке расписана)?
З.Ы. Я так понимаю, что ситуацию, когда правильного выбора контейнера
вообще не существует и в течении развития программы он должен меняться
здесь уже можно даже не упоминать.
On 16.02.2013 17:47, landerhigh wrote: > говоря, решили не исходную проблему, а другую, ту, которую умели решать. > а потом попытались натянуть сами знаете что на глобус. И так стопицот раз.
Это естественно при собеседовании в виде экзамена. Это как из древнего
анекдота про экзамен про рыб.
On 16.02.2013 19:14, Evgeny.Panasyuk wrote:
> Если не знать про более оптимальное решение, или про то, что уже есть > реализация нужного алгоритма, то может и не возникнуть желание нагуглить. > Например: > 1) O( ln N ) поиск — это нормально? "Ну вроде да — общая сложность O(N > ln N) — приемлемо". > А вот если знать о готовом решении, либо знать "как его придумать" — > посмотреть на паттерны во входных данных — то поиск будет O(1), и общая > сложность O(N), да и памяти требуется в разы меньше. > 2) Нужно применить некоторую операцию попарно к элементов двух range'ей, > а потом с-reduce-ить их результаты. Если не знать про существование > inner_product ("А что, и такой есть?") — то и получатся макароны. И > google тут ничем не поможет.
Вот эти два пункта очень показательны.
Эти пункты говорят о том, что человек очень плохо учился в институте по
фундаментальным дисциплинам и даже не в курсе скалярного произведения.
Мне становиться понятно, что проиходит. Похоже проблема в образовании.
Большинство местных ВУЗов скатились к уровню ПТУ, в лучшем случае
техникума и просто готовят программистов и не более, тех, кому дали 2-3
языка программирования, типичные контейнеры, немного ООП (понятно все
это на уровне "мертвых" знаний).
Когда я учился в БГУ — программирование — это был самый мусор,
фактически его изучали, как инструмент и не более. Основное это были
фундаментальные курсы и курсы прикладной математики. А программирование
— это лабы делали.
On 16.02.2013 19:23, jazzer wrote:
> Ну и немалая часть архитектуры — это организация данных, т.е. контейнеры > и связанные с ними алгоритмы.
Упс. Ты не сталкивался с задачами, где алгоритмы — это основное и не
элементарные по сортировке данных, а гораздо сложнее?
On 16.02.2013 21:58, minorlogic wrote:
> Встречал людей которые пишут хорошую архитектуру , они все знали базовые > алгоритмы и разбирались в сложности. Хдается мне , это не спроста.
Какое это имеет отношение к собеседованию, озвученному в самом начале
топика?
Здравствуйте, Vzhyk, Вы писали:
V>On 16.02.2013 17:18, jazzer wrote:
>> Т.е. они выбирали контейнер неправильно, несмотря на то, что знали его >> устройство до тонкостей? V>Тебя это удивляет. Очень много есть людей, которые при достаточно V>объемных знаниях делают неправильный выбор. Обычно это уже становиться V>понятно еще в институтах, глядя на студентов вокруг. V>Неужели у вас небыло отличников, которые не могли и строки кода написать V>или сделать хоть какую-то работу самостоятельно (кроме той, что в V>методичке расписана)?
Не, я физик, у нас большинство таких "отличников" на 1-2 курсе вылетели.
Не помню ни одного, с кем дошел до 6-го курса, который бы не владел материалом. Кроме разве что спортсменов, которых деканат не выгонял чисто за их спортивные успехи, но это не та проблема, которую мы тут обсуждаем — они вряд ли смогли бы похвастаться знанием подноготной контейнеров.
Ну да не суть. Допустим, есть опасность нанять зубрилу, который ничего не соображает, но все помнит. Как насчет обратного — пришел человек, не способен ответить на элементарные вопросы по хеш-таблицам или иным стандартным контейнерам, но при этом способен в реальной работе все грамотно выбирать и обосновывать? Вот как-то не верится
V>З.Ы. Я так понимаю, что ситуацию, когда правильного выбора контейнера V>вообще не существует и в течении развития программы он должен меняться V>здесь уже можно даже не упоминать.
В контексте интервью — пожалуй. Хотя, конечно, можно продумать вопрос, чтоб человек подобрал контейнер для начальных условий, а потом при изменившихся требованиях сменил его на другой. Спасибо за идею.
