Здравствуйте, B0FEE664, Вы писали:
BFE>Ну если у вас 500 разных машинах и несколько сотен терабайт, то тогда, конечно, сортировку имеет смысл спрашивать.
Меня в Яндексе именно про это и спрашивали. Оказались очень довольны тем, что я знаю сортировку слиянием.
И таки да, у них несколько сотен террабайт текстовой информации.
Здравствуйте, CoderMonkey, Вы писали:
CM>Имел собеседование со "специалистом" из Гугла. На вопрос "какова лучшая сложность для алгоритмов сортировки", ответил ему, что O(n). Нет, говорит, это неправильно — должно быть O(n * log n). Правильно, говорю, именно O(n). Есть такой radix sort, у него сложность именно такая. В ответ — недоуменно-возмущенное молчание. Похоже, не поверил.
когда интервьируешся в компаниях из первой сотни, то давая сразу ответ, не важно какой, даже если думаешь правильный — ты провалил тест.
Потому что у них в рукаве козырный туз с подовохом, а ты расчитываешь на шестерку.
Если бы ты не поленился и посмотрел их курс как проходить интервью, то понял что должен задать встречных 3-4 вопроса, а потом только давать ответ.
Им не нужны работники, которым говорят — постройте нам самолет — разворачиваются, уходят и строять ракетный самолет, а им надо было винтовой.
Вы должны было спросить на каком обьеме памяти, что представляют из себя данные и т.д. и уже потом блистать ответом.
Здравствуйте, Lepsik, Вы писали:
L>Вы должны было спросить на каком обьеме памяти, что представляют из себя данные и т.д. и уже потом блистать ответом.
Вопрос то был вполне конкретный. Не "что быстрее" (где действительно может быть много вариантов), а "алгоритмическая сложность".
Здравствуйте, Lepsik, Вы писали:
L>Вы меня не услышали — нельзя давать ответ даже на как кажется очевидный вопрос — только после расспросов — это ключевое правило собеседования!
Да, возможно. Но как-то весь процесс становится всё более и более абсурдным.
Ритуалы, ритуалы....
Здравствуйте, mgu, Вы писали:
mgu>Лучшая сложность -- O(n^2). А O(n) -- это худшая сложность, зато лучшая производительность.
Ну, radix sort по сложности алгоритма примерно на том же уровне что merge или quicksort, ничуть не сложнее. А если брать всяческие их варианты с оптимизациями, то и проще.
CM>>Вопрос то был вполне конкретный. Не "что быстрее" (где действительно может быть много вариантов), а "алгоритмическая сложность".
L>Вы меня не услышали — нельзя давать ответ даже на как кажется очевидный вопрос — только после расспросов — это ключевое правило собеседования!
Почему? Вот я задал очевидный вопрос, и если кандидат задаёт встречных 4 вопроса, то у меня возникнут сомнения в его адекватности.
Здравствуйте, Тёмчик, Вы писали:
Тё>Почему? Вот я задал очевидный вопрос, и если кандидат задаёт встречных 4 вопроса, то у меня возникнут сомнения в его адекватности.
И это тоже. Как ни крути — кандидат всегда виноват окажется
H>Гуглу нужны программисты или специалисты по продаже себя?
Хаха, а как Вы сами думаете? Кто может быть нужен корпорации рекламщиков, торговцев приватными данными и задалбывателей нормальных людей распознаванием светофоров и витрин?
CM>Да, возможно. Но как-то весь процесс становится всё более и более абсурдным.
Ничуть. Все серьёзные высоконагруженные системы так и живут: алгоритмы и структуры данных донельзя узкозаточенные, подстроенные под множество противоречий и trade–off'ов. Или ты думаешь, что в солидных продуктах не парятся, и берут контейнеры и алгоритмы из стандартной библиотеки?
Здравствуйте, serj.e, Вы писали:
CM>>Да, возможно. Но как-то весь процесс становится всё более и более абсурдным. SE>Ничуть. Все серьёзные высоконагруженные системы так и живут: алгоритмы и структуры данных донельзя узкозаточенные, подстроенные под множество противоречий и trade–off'ов. Или ты думаешь, что в солидных продуктах не парятся, и берут контейнеры и алгоритмы из стандартной библиотеки?
Здравствуйте, serj.e, Вы писали:
SE>Ничуть. Все серьёзные высоконагруженные системы так и живут: алгоритмы и структуры данных донельзя узкозаточенные, подстроенные под множество противоречий и trade–off'ов. Или ты думаешь, что в солидных продуктах не парятся, и берут контейнеры и алгоритмы из стандартной библиотеки?
Вопрос в том — какой процент прогеров в том же Гугле действительно пишет такие алгоритмы и структуры, а какой — занимается обслуживающей работой, в которой за самопальные алгоритмы будут пороть розгами?
Здравствуйте, CoderMonkey, Вы писали:
CM>Имел собеседование со "специалистом" из Гугла. На вопрос "какова лучшая сложность для алгоритмов сортировки", ответил ему, что O(n). Нет, говорит, это неправильно — должно быть O(n * log n). Правильно, говорю, именно O(n). Есть такой radix sort, у него сложность именно такая. В ответ — недоуменно-возмущенное молчание. Похоже, не поверил. CM>Кажется, никакое продолжение мне не светит
Глубинная причина успеха гугля вовсе не в линейной сортировке.
Она заключается во внедрении SCRUM во все бизнес-процессы начиная с момента появления компании и по сей день.
L>Если бы ты не поленился и посмотрел их курс как проходить интервью, то понял что должен задать встречных 3-4 вопроса, а потом только давать ответ.
ну об этом надо тогда ясно предупреждать до экзамена-технического собеседования
а то мало ли кто там себе что мнит, и какое поветрие при приёме сейчас в моде
Властитель слабый и лукавый,
Плешивый щеголь, враг труда,
Нечаянно пригретый славой,
Над нами царствовал тогда.... (А.С. Пушкин ? )
