Здравствуйте, Олег К., Вы писали:

S>>И да, я сам хоть уже 10 лет не кодирую, но даже ночью готов рассказать quick/radix и т.п. sort, пересказать алгоритмы построения/нормализации/обхода деревьев, алгоритмы поиска, десяток основных паттернов и прочее что въелось мне в мозг так, что похоже уже никогда не забудется.

ОК>Звиздеть не мешки ворочать. Пока что единственное мерило умения это работающий код.

Это слишком дорогая техника, проверять работающим кодом вместо собеседоания.

Здравствуйте, Тёмчик, Вы писали:

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

А проверять есть или нет уже у нас копия наверно предложишь с помощью хеш таблицы?)

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

SA>Ты — не архитектор, и даже не программист, ты не сталкивался и не представляешь, как правильно проектируются сложные системы, и ЧТО может породить какой-нибудь великий знаток квиксортов. Живой пример — Ангуляр 1, который зачинали аутисты-олимпиадники противоестественным способом, в итоге получился мертворожденный кадавр, пожравший миллионы человеко-часов сотен тысяч прикладных разработчиков.
SA>Более того, кадавр вышел настолько ужасен, что даже самому Гуглу пришлось принять меры.

Ангуляр1 очень быстро вытеснил другие фремворки. И писали его ни разу не знатоки алгоритмов.

Здравствуйте, Тёмчик, Вы писали:

AK>>Я не архитектор, но Скиену частично перечитываю примерно раз в два года. Освежить память. Хорошо помогает в решении повседневных задач. Надо ещё Кормена купить.
Тё>Раз в 2 года открываешь сезон хождений по собеседованиям?

AK>>Вчера вот просили написать реализации очереди используя массив и используя стэк.
Тё>Правда интересно, как (и главное зачем) эффективно зафигачить FIFO через LIFO.

Стандартный ход для языков, где односвязный список — главная структура (LISP, Erlang...)

Тё> Очередь с приоритетом через стек не просили?

А в чём проблема? Читайте вот эту книгу, там есть всё и больше

Здравствуйте, Олег К., Вы писали:

ОК>Рано или поздно тебя отинтервьюирует такой же, хм, спец как и ты. Либо в силу своей глупости либо просто умышленно.
И? Что такое ужасное случится, чтобы этим запугивать? Они найдут общий язык и побеседуют к взаимному удовольствию.

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

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

I>>>Что ты хочешь шеллом проверить, умение писать вложенные циклы на массиве? Это примерно первый месяц первого курса программирования.

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

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

I>Важный вопрос — понимание последовательностей. Но его как раз проще проверить отдельно, а не кусками кода.

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

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

N>Стандартный ход для языков, где односвязный список — главная структура (LISP, Erlang...)
Лисп про возврат функцию как переменную, эрланг про пересылку сообщений между агентами. При чем тут односвязный список?

Тё>> Очередь с приоритетом через стек не просили?

N>А в чём проблема? Читайте вот эту книгу, там есть всё и больше

N>Image: okasaki_chisto_funkcionalnye_struktury_dannyh.jpg
Много букв. Можно вкратце, как и зачем?

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

_>А проверять есть или нет уже у нас копия наверно предложишь с помощью хеш таблицы?)

Стандартная хэш функция строки- соль, сдвиг, xor по символу.

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

I>Ангуляр1 очень быстро вытеснил другие фремворки.

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

I>И писали его ни разу не знатоки алгоритмов.

А кто? Простые аутисты с функциональным недостатком способности к синтезу и анализу? Очень странно. Как правило, такие альтернативно одаренные личности прекрасно знают алгоритмы. Это вершина того, что они способны запомнить и осознать.

Здравствуйте, Тёмчик, Вы писали:

Тё>Стандартная хэш функция строки- соль, сдвиг, xor по символу.

Валяй, сыпь свою соль.
Заодно, раз пошла такая пьянка, расскажи (и по)чему равен оптимальный fill factor.

Здравствуйте, Тёмчик, Вы писали:

Тё>Здравствуйте, netch80, Вы писали:

N>>Стандартный ход для языков, где односвязный список — главная структура (LISP, Erlang...)
Тё>Лисп про возврат функцию как переменную, эрланг про пересылку сообщений между агентами. При чем тут односвязный список?

На это могу только зафейспалмиться и посоветовать изучить матчасть. Потому что твоё знание обоих на уровне "слышал звон".

Тё>>> Очередь с приоритетом через стек не просили?
N>>А в чём проблема? Читайте вот эту книгу, там есть всё и больше
N>>Image: okasaki_chisto_funkcionalnye_struktury_dannyh.jpg
Тё>Много букв. Можно вкратце, как и зачем?

Вкратце — там, где основная структура — список, и изменяемые структуры нежелательны, для хорошей производительности нужно работать с данными особым образом. Как правило, разные мапы / словари / таблицы / etc. строятся из деревьев на списках, с сохранением существенной части этого дерева (пусть и в перетасованном виде) при любом изменении.

Здравствуйте, Тёмчик, Вы писали:

AK>>Я не архитектор, но Скиену частично перечитываю примерно раз в два года. Освежить память. Хорошо помогает в решении повседневных задач. Надо ещё Кормена купить.
Тё>Раз в 2 года открываешь сезон хождений по собеседованиям?

Не.. В этом плане у меня как-то по-другому получается. Последнее время интересные предложения поступают по рекоммендациям коллег, а не от рекрутеров. Поэтому собеседование получается одно. А алгоритмы освежаю из чисто практических соображений. Я не перечитываю книгу целиком, я перечитываю несколько глав из того что соприкасается с моими текущими задачами. Помогает привести мысли в порядок.
То же самое и с книгами по архитектуре приложений.

AK>>Вчера вот просили написать реализации очереди используя массив и используя стэк.
Тё>Правда интересно, как (и главное зачем) эффективно зафигачить FIFO через LIFO.

Про "эффективно" тут трудно говорить, а сама по себе задача известная и подробно разобрана в "Cracking the coding interview".
Берём два стэка и при необходимости меняем порядок элементов, перекидывая из одного стэка в другой.

Тё>Очередь с приоритетом через стек не просили?

Не, такого не просили.

Здравствуйте, Тёмчик, Вы писали:

Тё>Аморально ли проверять знание алгоритмов, если на рассматриваемую позицию человек не будет их писать?
Тё>...

Мораль — это традиции принятые в обществе, так сказать, нормы поведения.
Если в обществе принято пожимать руку при приветствии, то, например, китайского архитектора не пустят строить римские соборы и наоборот, несмотря на то, что рукопожатия и поклоны со сложенными ладонями вряд ли будут применяться непосредственно при строительстве.
Хорош или плох (правилен или неправилен) результат тоже будет оцениваться нормами принятыми в обществе.
Прикинь что было бы, если бы твой любимый поисковик написали бы те, кто не умеет сортировать канализационные люки? Думаю у тебя сразу бы отпали бы вопросы про аморальность вопросов на собеседовании.

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

I>>Ангуляр1 очень быстро вытеснил другие фремворки.
SA>А знаешь, почему? А совсем не благодаря его качеству.
SA>Просто потому что разного рода погонщики кодеров с недостатком кислорода в левом полушарии дружным гуртом ринулись за Гуглом, погоняя перед собой ораву своих подопечных.

Это целая конспирологичесая теория. Ну, может, набор эмоций. Ангуляр это вообще говоря механика древняя как весь UI, простая, как автоматы Мили и Мура Потому и стала популярной. До Ангуляра в моде было не столько решать проблемы, сколько исправлять JS, бровзер и тд. Всё это давно никому не надо.
Сейчас в вебе вагоны полу-программистов которые на Ангуляре обгоняют функционалистов-реактивщиков, объезжают на кривых. Пока реактивисты хвастаются классным кодом и стройной концепцией, полу-программисты на Ангуляре собирают бюджет и выкатывают продакшн. Как то так

Жизнь такая — уродцы вроде JS и Ангуляр срывают джекпот. Так было всегда.

SA>И теперь эти сотни тысяч в глубокой, глубочайшей жопе — потому что Гугл выкинул и их, и всю их работу, и весь Ангуляр один, полтора и прочее гугно на помоечку.

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

Фронтенд безо всякого гугла устроен так, что его проще переписать независимо от фремворка или его отсутствия. Через год-два появляется новая концепция сайтов, которая напрочь ломает старую. Проще сломать и выбросить или просто пилить новую морду рядом.
Гугл собственно учел эту особенность, и потому пошел на риск с отказом от обратной совместимости.

I>>И писали его ни разу не знатоки алгоритмов.

SA>А кто?

Покажи, где там алгоритмические чудеса ?

Здравствуйте, Олег К., Вы писали:

I>>Сообщение даже с запикаными матами вообще говоря оскорбительное. Фактически — насилие. Ты точно уверен, что kaa.python не имеет права защитится от такого насилия ?

ОК>Насилие? Ты еще к психоаналитику ему посоветуй сходить.

Именно. Оскорбление == насилие.

Здравствуйте, Тёмчик, Вы писали:


Тё>иметь высокоуровневое видение продукта,каким он будет

это задача менеджера

Тё> какие фреймворки использовать.

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

Здравствуйте, Олег К., Вы писали:

ОК>>>Это ты сейчас в википедию заглянул?
G>>Нет
ОК>Я не верю тебе но допустим ты хранишь столько хлама у себя в голове.
Вот потому архитектов и надо драть по алгоритмам, чтобы понять кто реально опыт имеет, а кто просто занимается написанием бумажек с квадратиками и стрелочками.

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

Тё>>иметь высокоуровневое видение продукта,каким он будет

S>это задача менеджера

Не только менеджера, но и архитектора. Без глобального видения продукта архитектор никому не нужен.

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

Архитектор не бывший, а действующий программист.

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


S>>это задача менеджера

I>Не только менеджера, но и архитектора. Без глобального видения продукта архитектор никому не нужен.

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


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

I>Архитектор не бывший, а действующий программист.

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

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

I>>Не только менеджера, но и архитектора. Без глобального видения продукта архитектор никому не нужен.

S>Архитектору глобальное видение ни к чему. Понимать рынок, как позиционировать продукт, как им будут пользоваться люди -- задача менеджера продукта.
S>Задача архитектора -- решение технических проблем в целом.

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


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

Архитект не пишет тз и задачи может не ставить. У него более другие задачи, вот, например https://www.sei.cmu.edu/architecture/research/previousresearch/duties.cfm