Здравствуйте, Aleksey82, Вы писали:

A>Врядли есть много людей кто реально не может придумать как это сделать.
Достаточно много.

A>А вот написать на "белой доске" я бы уже наверно не написал. По крайней мере без какого-нибудь ассиста и гугла я мало какие функции помню точно.
Там не надо ничего кроме операторов самого языка.

A> Ну или что-то маломальски сложное уже точно бы не написал без ошибок.
Интересуют только ошибки в логике алгоритма, остальные пофигу.

A>Человек может быть богом отладки, но при этом совершенно хреново писать код с ноля. Вообще никак.
А зачем нужны такие люди там, где надо как раз в первую очередь писать код?

A>А встречаются особо одаренные, которые всех будут собеседовать "как в гугле"
Ничего что речь тут про сам гугл?

A>А про зп я упомянул в контексте что человек, не умеющий решить дебильную задачу у доски,- левый в профессии.
Хехе, дебильную, ага. Задача то элементарная, букварь Computer Science.

A> Может и левый, но огорчены скорее всего будут как раз многие работающие онсайт в америке.
Ты мне хочешь рассказать за Америку?

Здравствуйте, CreatorCray, Вы писали:

CC>>>Задачку, которая делается не приходя в сознание, если знаешь как устроено бинарное дерево.
C>>Справедливости ради, бинарные деревья руками пишутся редко и можно просто даже забыть терминологию.
CC>О чём ты? Какую ещё там терминологию можно забыть?
"Инвертирование дерева".

C>> Потому лично я спрашиваю token bucket. Почему-то его нет в обычных книгах по подготовке к интервью, хотя на практике встречается сплошь и рядом.
CC>Да не то чтобы, этож довольно специфичный по области применения алгоритм.
Ну так я собеседую на позиции по инфраструктуре и сетевым сервисам. В этих областях мне лично приходилось token bucket писать примерно так раз 5.

Здравствуйте, Cyberax, Вы писали:

CC>>О чём ты? Какую ещё там терминологию можно забыть?
C>"Инвертирование дерева".
Тоже мне беда. Если не понятно что именно требуется то всегда можно задать уточняющие вопросы. И минусом это не будет.

CC>>Да не то чтобы, этож довольно специфичный по области применения алгоритм.
C>Ну так я собеседую на позиции по инфраструктуре и сетевым сервисам. В этих областях мне лично приходилось token bucket писать примерно так раз 5.
О чём и написано: "этож довольно специфичный по области применения алгоритм"
Кандидатам на такие позиции всё таки следует быть в курсе его существования, но generic кандидаты сам алгоритм по названию могут и не знать.
Тогда как бинарное дерево это таки азбука Computer Science и не знать про них будет как минимум весьма странно.

ECR>Это, по-моему, чисто сетевая приблуда.

Да такой же вопрос из серии "я как-то пару раз писал". Столь же бессмысленный, сколь и беспощаный. А то ведь, чего б не спросить CoDel, да так, чтоб не говорить, что оно такое, и википедии не давать.

Уж тысячу раз говорил, и столько же писал, что сам формат такого собеседования неверен. Просить кандидата что-то писать, в конторе, где уже написаны миллионы строк кода, — способ получить очередного велосипедостроителя. И далее по курсу, когда в одной конторе десять дублирующих друг друга систем. Которые есть результат "написать", вместо того, чтобы прочитать.

Здравствуйте, SkyDance, Вы писали:

SD>Уж тысячу раз говорил, и столько же писал, что сам формат такого собеседования неверен. Просить кандидата что-то писать, в конторе, где уже написаны миллионы строк кода, — способ получить очередного велосипедостроителя.

Дада, самый правильный путь — копипастить со StackOverflow и тянуть 100500 зависимостей через зависимости для элементарных вещей.
Так и получается "двести метров жаваскрипта тянут текста триста байт" и хохмы про то, как удаление из паблик репы "проекта" по паддингу строки ломает через зависимости здоровенный кусок веба. Потому что там как раз "прочитали" вместо того чтоб написать.

SD> И далее по курсу, когда в одной конторе десять дублирующих друг друга систем. Которые есть результат "написать", вместо того, чтобы прочитать.

Дублирование кода это проблема менеджмента а не девелопмента.
А полноценный девелопер должен таки понимать как работает под капотом то, что он использует. Иначе это маппет-кодер а не девелопер.

Здравствуйте, SkyDance, Вы писали:

ECR>>Это, по-моему, чисто сетевая приблуда.
SD>Да такой же вопрос из серии "я как-то пару раз писал". Столь же бессмысленный, сколь и беспощаный. А то ведь, чего б не спросить CoDel, да так, чтоб не говорить, что оно такое, и википедии не давать.
Ну вообще-то, вводная даётся так: "Есть сервис, который может выдержать только 1 запрос в минуту от пользователя. Написать функцию, allowAccess, берущую на вход userId и возвращающую true/false".

Здравствуйте, CreatorCray, Вы писали:

CC>Дада, самый правильный путь — копипастить со StackOverflow и тянуть 100500 зависимостей через зависимости для элементарных вещей.
CC>Так и получается "двести метров жаваскрипта тянут текста триста байт" и хохмы про то, как удаление из паблик репы "проекта" по паддингу строки ломает через зависимости здоровенный кусок веба. Потому что там как раз "прочитали" вместо того чтоб написать.

Не соглашусь. Простая ситуация — мне в проекте понадобился кольцевой буффер. Я, само собой, могу его сам написать — но цель-то у меня не написать класс кольцевого буффера, а использовать его в программе. И в этом плане у многих систем управления зависимости есть огромная дыра: они позволяют подключить огромную библиотеку к проекту, но не позволяют загрузить один алгоритм. И получается, что ты либо копипастишь, либо подключаешь some.name.space.CircularBuffer.dll на несколько килобайт (и таких библиотек в проекте может быть несколько десятков), либо подключаешь super.mega.library.dll на 20 мегабайт, 99% которой тебе не нужны. Все способы отстойные, включая написание класса самому.

SD>> И далее по курсу, когда в одной конторе десять дублирующих друг друга систем. Которые есть результат "написать", вместо того, чтобы прочитать.

CC>Дублирование кода это проблема менеджмента а не девелопмента.
CC>А полноценный девелопер должен таки понимать как работает под капотом то, что он использует. Иначе это маппет-кодер а не девелопер.

Помнить != переписывать снова и снова ради переписывания.

Здравствуйте, Cyberax, Вы писали:

SD>>Да такой же вопрос из серии "я как-то пару раз писал". Столь же бессмысленный, сколь и беспощаный. А то ведь, чего б не спросить CoDel, да так, чтоб не говорить, что оно такое, и википедии не давать.
C>Ну вообще-то, вводная даётся так: "Есть сервис, который может выдержать только 1 запрос в минуту от пользователя. Написать функцию, allowAccess, берущую на вход userId и возвращающую true/false".
В такой формулировке как-то слишком просто получается.

Здравствуйте, CreatorCray, Вы писали:

PM>>Бесполезно искать в таких задачах смысл. Реализовать стек на основе очереди, очередь на основе стека, перевернуть строку, обойти дерево по уровням, и т.д., и т.п. Все их прекрасно знают. Кто хочет пройти интервью, заучивает решения. Кто не готовится, тот повышает шанс провалить ответ у доски.

CC>Дык потому и спрашивают такое простое, которое обычно не зубрят.
CC>А если видно что отвечает зазубренное то можно поменять немного условие и тогда будет видно соображает или просто выучил.
CC>В любом случае задачу лучше брать такую, которую можно решить множеством простых способов чтобы просто поговорить "а как ещё можно"?
CC>Суть собеседования то в том, чтоб понять как у кандидата работает инженерное мышление.

В случае этой задачи у меня инжинерное мышление начинает буксовать на "можно ли это сделать эффективниее?" и "нафиг нужен настолько неэффективный алгоритм с такими ограничениями?".

SD>>Просить кандидата что-то писать, в конторе, где уже написаны миллионы строк кода, — способ получить очередного велосипедостроителя.
CC>Дада, самый правильный путь — копипастить со StackOverflow и тянуть 100500 зависимостей через зависимости для элементарных вещей.

Учу читать. Дорого.

CC>Так и получается "двести метров жаваскрипта тянут текста триста байт" и хохмы про то, как удаление из паблик репы "проекта" по паддингу строки ломает через зависимости здоровенный кусок веба. Потому что там как раз "прочитали" вместо того чтоб написать.

Вот именно. Ровно это и происходит, когда нанимаемые работники не могут прочитать то, что уже написано до них. И начинают "писать". Разумеется, с помощью всех этих stackoverflow и github, потому что, внезапно, в реальной работе им требуются не сферические алгоритмы в вакууме собеседования, а некоторая кривая "бизнес-логика".

CC>А полноценный девелопер должен таки понимать как работает под капотом то, что он использует. Иначе это маппет-кодер а не девелопер.

Так нанимают-то именно маппет-кодеров, которые выучили книжки или зазубрили литкоды. На собеседовании спрашивают не "разберись, как вот это работает", а "напиши мне ХУZ".

CC>Дублирование кода это проблема менеджмента а не девелопмента.

Ха, так можно что угодно назвать проблемой менеджмента. Откуда менеджменту знать про сие дублирование, кроме как не от девелоперов. Которые не разбираются, ибо не умеют. Это вообще редкие и очень ценные девелоперы, которые не только могут, но еще и умеют, и что еще важнее — действительно разбираются. Самый ценный кадр в большой конторе — тот, который уменьшает количество кода, компонентов, зависимостей и прочих. Одно "но", зачастую менеджмент слишком близорук, чтобы это понять. И девелоперу приходится либо становиться продажником (объяснять тому самому менеджементу, что, как и почему оно все еще работает), либо уходить.

C>Ну вообще-то, вводная даётся так: "Есть сервис, который может выдержать только 1 запрос в минуту от пользователя. Написать функцию, allowAccess, берущую на вход userId и возвращающую true/false".

В такой формулировке это "таймер на 1 минуту". А что такое token bucket, я хоть и помню название, но мне потребуется 5-10 минут погуглить, и еще минут 30-40 подумать, и затем некоторое еще время найти все реально нужные сценарии использования такой функциональности. Плюс, может потребоваться какое-то время по-grep-ать по кодовой базе, чтобы найти 5-6 существующих реализаций. Ибо реальность такова, что писать очередной велосипед не надо, все велосипеды уже написаны. Надо найти нужный, и правильно его использовать.
Иначе будет уже 6-7 разных реализаций, и, разумеется, каждая будет плохо протестирована (если вообще), и уж тем более не будет реального анализа производительности, ужора памяти или каких еще ресурсов. Потому что это ж сложно. Это ж учиться надо, это ж надо понимать, что делаешь. Зачем, если вон, на собеседовании, накалякал какую-то дурь, которую интервьюер считает правильной, и все?

Вот за такие собеседования и хочется взять скотч, и интервьюерам что-то заклеить. Шибко далеки они от народа и нужд компании.

S> И в этом плане у многих систем управления зависимости есть огромная дыра: они позволяют подключить огромную библиотеку к проекту, но не позволяют загрузить один алгоритм. И получается, что ты либо копипастишь, либо подключаешь some.name.space.CircularBuffer.dll на несколько килобайт

Напомню, что я писал о серверной инфраструктуре большой конторы. Там в 99.999% случаев все эти "огромные библиотеки" уже подключены ко всем подряд проектам. И да, десять строчек программы создают, вау, гигабайтный исполнимый файл! Не шутка, а реальность этого мира в больших конторах. Монолитная "либа", общая для всей компании. Неэффективно? Да всем плевать, если это какой-то там сервис на десятке машин.

Те же, кто пишут для всей флотилии из миллионов — их единицы, и у них уже порой хватает ума думать о том, что они делают.

Здравствуйте, SkyDance, Вы писали:

SD>Учу читать. Дорого.
Ты мысли свои выражать сначала научись, учитель.

SD>Вот именно. Ровно это и происходит, когда нанимаемые работники не могут прочитать то, что уже написано до них.
Это всего лишь один случай из множества, и как правило обусловленный тем, что документация отсутствует и заменена передаваемым из уст в уста lore.

SD>Так нанимают-то именно маппет-кодеров, которые выучили книжки или зазубрили литкоды.
Маппетов нанимают не так как тут обсуждается.

SD>Откуда менеджменту знать про сие дублирование, кроме как не от девелоперов.
Дык как раз линейные менеджеры должны понимать что делают их люди и что делают люди из "параллельных сфер". В это порой вмешиваются сторонние факторы типа секретности проекта.
На то они собственно и нужны — обеспечивать координацию.

SD>Это вообще редкие и очень ценные девелоперы, которые не только могут, но еще и умеют, и что еще важнее — действительно разбираются. Самый ценный кадр в большой конторе — тот, который уменьшает количество кода, компонентов, зависимостей и прочих. Одно "но", зачастую менеджмент слишком близорук, чтобы это понять.
Дык хороший менеджер так же редок как и хороший девелопер.

SD> И девелоперу приходится либо становиться продажником (объяснять тому самому менеджементу, что, как и почему оно все еще работает), либо уходить.
Это работа его менеджера.

CC>Ты мысли свои выражать сначала научись, учитель.

Мысль выражена очень ясно. На собеседованиях нужно проверять умение девелопера разобраться, а не выдать заученное. В процессе этого самого "разобраться" кандидату должны быть доступны все те же инструменты, что будут доступны на его реальной работе.

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

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

CC>Маппетов нанимают не так как тут обсуждается.

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

CC>Это работа его менеджера.

Это работа технического специалиста. Менеджер — это тот, кто дебажит людей, а не тот, кто занимается зависимостями между классами или библиотеками.

Здравствуйте, SkyDance, Вы писали:

SD>На собеседованиях нужно проверять умение девелопера разобраться, а не выдать заученное.
Потому и спрашивают такое, что не как правило не заучивают либо к чему есть много вариантов решений и можно задание чутка поменять, сломав заученное.
Такими задачками никто не проверяет бинарно: ответил/не ответил, задачка всего лишь повод начать обсуждение и смотреть как кандидат мыслит.
Тут уже есть длинная тема где это всё пережёвано по три раза, не думаю что стоит начинать её сначала.

SD> В процессе этого самого "разобраться" кандидату должны быть доступны все те же инструменты, что будут доступны на его реальной работе.
Ты похоже хочешь собеседование полдня проводить на каждого собеседующего, раз просишь столько инструментария.

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

Я правильно понимаю что ты сейчас про мордокнигу? Про их идиотские принципы найма много кто матерится, и причины несколько более глубинные чем эти задачки — там не нанимают "в команду", там нанимают "в компанию" а потом начинается чесание в репе куда ж этого нанятого приткнуть. Оттого найм и заточен на generic mappets.

CC>Такими задачками никто не проверяет бинарно: ответил/не ответил, задачка всего лишь повод начать обсуждение и смотреть как кандидат мыслит.

Опять ты штампами говоришь. Такими задачами и их вариациями проверяется только натасканность кандидата на эти самые задачи. Как ты наверное догадываешься, не только в Яббле от всех сотрудников требуют проводить собеседования. И как сильно формализованы эти "собеседования", за исключение разве что "обеденного интервьюера" (мое любимое занятие, жаль, что в формальный зачет не идет — о кандидате много больше узнаешь, чем на любом другом).

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

Ты не поверишь (С) на собеседование уходит целый день, иногда два.

CC>Я правильно понимаю что ты сейчас про мордокнигу? Про их идиотские принципы найма много кто матерится, и причины несколько более глубинные чем эти задачки — там не нанимают "в команду", там нанимают "в компанию" а потом начинается чесание в репе куда ж этого нанятого приткнуть. Оттого найм и заточен на generic mappets.

Я сейчас про гугл и микрософт. Там эти самые литкоды в полный рост. И за ними многие другие повторяют. Хотя, конечно, есть и островки разума. Как-то с дропбоксом общался, понравилось.

Здравствуйте, SkyDance, Вы писали:

SD>Опять ты штампами говоришь.
Я сам по таким принципам собеседую. И не только я.

SD> Такими задачами и их вариациями проверяется только натасканность кандидата на эти самые задачи.
Нет. Мне не интересно разжёвывать всё ещё раз, поищи старую тему по форуму.

CC>>Ты похоже хочешь собеседование полдня проводить на каждого собеседующего, раз просишь столько инструментария.
SD>Ты не поверишь (С) на собеседование уходит целый день, иногда два.
Обрати внимание на выделенное.

Здравствуйте, Somescout, Вы писали:

C>>Ну вообще-то, вводная даётся так: "Есть сервис, который может выдержать только 1 запрос в минуту от пользователя. Написать функцию, allowAccess, берущую на вход userId и возвращающую true/false".
S>В такой формулировке как-то слишком просто получается.
Просто?

Ну и на то и собеседование, чтобы потом обсуждать детали, а потом заниматься усложнизмом.

Здравствуйте, SkyDance, Вы писали:

C>>Ну вообще-то, вводная даётся так: "Есть сервис, который может выдержать только 1 запрос в минуту от пользователя. Написать функцию, allowAccess, берущую на вход userId и возвращающую true/false".
SD>В такой формулировке это "таймер на 1 минуту".
Ну так там дальше усложнения идут — не 1 запрос, а N запросов. Некоторые кандидаты ещё делают вместо TB связный список timestamp'ов. Там ещё дальше можно обсуждать много интересного — типа стратегий кластеризации.

SD>А что такое token bucket, я хоть и помню название, но мне потребуется 5-10 минут погуглить, и еще минут 30-40 подумать, и затем некоторое еще время найти все реально нужные сценарии использования такой функциональности. Плюс, может потребоваться какое-то время по-grep-ать по кодовой базе, чтобы найти 5-6 существующих реализаций. Ибо реальность такова, что писать очередной велосипед не надо, все велосипеды уже написаны. Надо найти нужный, и правильно его использовать.
Ну так там весь алгоритм — это два if'а. Если делать из него библиотеку — получится сложнее.

SD>Вот за такие собеседования и хочется взять скотч, и интервьюерам что-то заклеить. Шибко далеки они от народа и нужд компании.
Как я уже сказал, разные вариации TB мне пришлось писать раз 5. Т.е. задача чисто практическая.

C>Ну так там дальше усложнения идут — не 1 запрос, а N запросов. Некоторые кандидаты ещё делают вместо TB связный список timestamp'ов.

Еще и timer wheel навелосипедить? Спрашивается, зачем? Ответ я вижу только один — ты это когда-то делал и разбирался. Теперь ищещь кандидатов "такой как я". Поэтому я и говорю, что такие собеседования набирают не тех, кто может разобраться, а тех, кто "уже писал вот это".

C> Там ещё дальше можно обсуждать много интересного — типа стратегий кластеризации.

Так если цель — "обсуждать много интересного", зачем издеваться заданиями "напиши мне не скажу что, и не пользуйся интернетом, но вот мой извращенный разум задачу искорежил вот так". Речь, напоминаю, идет о наборе серьезных инженеров — а-ля L5+/65, а не кодеров (у которых сабжа нет по определению). Не нужно к ним подходит с "напиши мне разворот строки", чтобы потом дополнять задачу условиями типа "а теперь сделай, чтобы оно пело ча-ча-ча и троекратно салютовало".
Такие интервью можно и нужно вести сверху вниз. Сначала обсудить реальный сервис, ожидания и гарантии его работы, и потом уже, разумеется, предоставляя интернет и прочее, дать возможность кандидату найти подходящие решения.

C>Как я уже сказал, разные вариации TB мне пришлось писать раз 5. Т.е. задача чисто практическая.

Ну как я и ожидал. "Мне было нужно, значит, всем нужно".

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