У вас логическая ошибка в первом же предложении. Вы считаете что "алгоритмические собеседования как в гугле", которые по факту решение leetcode задач уровня medium-hard на время в стрессовой ситуации, как-то проверяют знание алгоритмов. Это не так, единственное что проверяют такие собеседования - сколько человек тренировался решать leetcode задачи на время. Это не знания, а навык, причем весьма специфический, практически не востребованный в коммерческой разработке.
Этот навык довольно слабо коррелирует с производительностью, так как высокая производительность в разработке ПО достигается тем, что люди не делают того, чего делать не надо. Не пишут сложный общий алгоритм, когда достаточно реализации частного случая, не делают навороченную архитектуру, когда достаточно написать все в одной функции, используют готовые библиотеки вместо написания своего кода в конце концов. Это все никак не связано с решением leetcode задач на время.
Более того, нет никаких исследований, что умение быстро решать leetcode задачи на время как-то коррелирует с производительностью. Я честно искал и не нашел.
Вы все правильно пишите, про преимущества таких собеседований, что сложно считерить, надо готовиться, обеспечивает однозначную оценку кандидата. Но проблема в другом - это собеседование не проверяет нужных навыков.
Если вы фаанг или хотя бы яндекс, то к вам могут стоять очереди хоямячков, готовых забесплатно поработать ради строчки в резюме. Но если у вас компания поменьше, то найти хотя бы 10 подходящих кандидатов по другим критериям, кроме знания алгоритмов будет уже проблемой.
Что касается задач, то как в фаангах, так и в рогах-и-копытах примерно одинаковое соотношения задач нетривиальной обработки данных и банальных перекладываний json. И вероятность что натренировавшись решать 100500 задач с литкода в секунду вы не будете заниматься скучной фигней - крайне мала.
Альтернативы всегда существуют.
Обычное собеседование с разбором кейсов: "как бы вы решили [такую] задачу". Желательно кейсы практические из встречающихся на практике. Тут и знания фрейморков, и алгоритмов, и умение фокусироваться на задаче итд
Чтение кода и поиск багов. Несмотря на банальность такая работа встречается в практической разработке гораздо чаще, чем реализация каких-то алгоритмов.
Тестовое задание, близкое к тому, чем придется заниматься, желательно с ограничением времени, которое сам кандидат назначит. Это идеальная проверка, но к сожалению многие кандидаты откажутся решать.
Эти варианты не взаимоисключающие, а взаимодополняющие. Если у вас поток кандидатов большой, а отобрать надо мало, то можно применить все три, а если поток маленький, то провести только обычное собеседование.
Алгоритмическое собеседование как в Яндекс\Гугл\ГдеТоЕще не нужно. Нет никаких доказательств что оно как-то влияет на продуктивность сотрудников и вообще как-то помогает.
А само знание алгоритмов очень нужно, помогает не писать говнокод. Алгоритмов которые надо знать и понимать не очень много: массивы, списки, сортировка, бинарный поиск, кучи, деревья, хэш-таблицы, "динамическое программирование". Обычно это изучается первые полгода на курсе программирования, а при самостоятельном изучении заботать за пару ндель можно.
Что касается функции долга: если 2 посетителя заказали по три семейных комбо, а третий посетитель только колу, тогда при распределенной работе множество людей будут готовить компоненты семейного комбо, а для третьего посетителя один человек нальет колу и он уйдёт.
Предположим сборщик один. В текущем виде от соберет сначала первый крупный заказ, потом второй, а потом только отдаст вам колу.
Если будет действовать по моему алгоритму, то после первого крупного заказа появится "долг" в размере Х, а кола гарантированно будет иметь вес меньше Х (если нет, то неправильно функцию долга подобрали). И вы сразу после обработки крупного заказа её получите.
А если оценивать вес заказа, тогда семейное комбо будет весомее с точки зрения бизнеса, чем посетитель заказавший колу. Однако распределение ресурсов позволяет максимально быстро удовлетворить потребности всех посетителей.
В том то и прикол, что не будет. Самые большие прибыли рестораны быстрого питания делают на напитках. Там наценка на себестоимость выше 100%. В вот кухня сильно дороже.
Если вы не отдаете быстро заказы только с напитками, а заставляете людей ждать, то скорее всего теряете деньги, так как некоторые просто ждать не будут и пойдут в другом месте купят. А большой заказ человек легко подождет лишние пару минут.
Так вот сборка заказов и есть узкое место. Каждый сборщик может конечно взять любое количество заказов, но берет обычно один. Если количество крупных заказов перед вами будет больше количества сборщиков, то вы кофе свой не скоро получите, хотя казалось бы.
Что касается кода из статьи, то автор не учел, что когда у всех клиентов будет меньшее 100 транзакций в заказе, то второй инстанс будет отдыхать. Или наоборот, все элементы в очереди окажутся чуть больше порога. Этот алгоритм хоть и "справедливый", но нифига не эффективный.
Непонятно при чем тут микросервисы и .NET, если задача из теории массового обслуживания.
Кстати вполне практическое приложение: я заехал в мак вкусно-и-точка взять кофе. Но в ресторане было много заказов и кофе я дожидался минут 15. Хотя сама операция наливания кофе занимает от силы минуту, но передо мной было много "семейных" заказов, которые не умещались на один поднос.
Очевидно в маке (буду так называть) используется обычная FIFO очередь. Без потери общности можно считать, что обработчик очереди тоже один. Чтобы улучшить обслуживание они могли бы каждому заказу назначать некоторый вес Wi. В случае мака это время приготовления (они могут вычислить), а в случае топикстартера - количество транзакций в запросе.
Далее надо ввести функцию долгаD(w), такую что D(Wi) < Wi. Для примера D(w) = 0.5 * w
После обработки каждого заказа считать значениедолгаd = (d - Wi + D(Wi)) max 0.
Следующим заказом брать первым из очереди у которого Wi <= d, или первый из очереди если под условие ни один не подходит, в начале обработки d = 0
Если обработчиков очереди больше одного, то параметр долга должен быть общий на всех.
Все конечно хорошо, но 215 кг в приседе и 25+% жира в организме (судя по фото) никаким "здоровьем" и продлением жизни не пахнут. Есть даже исследование с довольно сильной корреляцией продолжительности жизни с соотношением размера пузика и плеч.
Для здоровья надо:
Отказаться от алкоголя и курения, лучше совсем отказаться, если не получается со всем, то минимизировать.
Много двигаться, чем больше тем лучше. Не в ущерб работе, семье, сну конечно же. Средний офисный (или удаленный) работник может ходить по 10к шагов в день и иметь активное хобби по выходным.
Здоровый сон, тут все понятно
Нормальный процент жира (15% для мужика), если у вас сильно больше, то надо менять пищевые привычки (и чем раньше, тем лучше)
Выносливость на уровне "пробежать километр за 4-00 и не сдохнуть".
Силовые: присед со своим весом, становая со своим весом, жать от груди свой вес. Остальное факультативно.
Довольно странно сравнивать заводы в СССР и ИТ-шников сейчас. Сравните тогда нынешнее положение работников на заводе со временами СССР.
Кроме того надо понимать какие времена сравниваем - позднего СССР, времен Андропова и Горбачева или СССР на пике развития - после войны.
Но суть капитализма не во времени в пути на работу, а в том что расходы на поддержание бренного тела работника в трудоспособном состоянии перекладываются на самого работника. Поэтому работник, который меньше времени и денег на это тратит, оказывается выгоднее капиталисту. Несмотря на все высокопарные заявления руководителей крупных компаний о заботе о работниках, выбор всегда будет в пользу условного Миши.
Поэтому единственный вариант поддержания и развития человеческого капитала в масштабах страны или отрасли - социализм, то есть отъем часть прибыли капиталистов и распределение её в пользу работников.
Название статьи не соответствует содержанию.
Лучшие от худших судя по всему могут отличаться в 10 и более раз. Но даже на одной и той же выборки лучшими оказывались разные в разных задачах.
Нужна третья статья: %COMPANYNAME% - не FAANG, тогда цикл станет полным
На литкоде любое решение пройдет. На алгоритмической секции собеседования решение должно быть асимптотически оптимальным.
У вас логическая ошибка в первом же предложении. Вы считаете что "алгоритмические собеседования как в гугле", которые по факту решение leetcode задач уровня medium-hard на время в стрессовой ситуации, как-то проверяют знание алгоритмов. Это не так, единственное что проверяют такие собеседования - сколько человек тренировался решать leetcode задачи на время. Это не знания, а навык, причем весьма специфический, практически не востребованный в коммерческой разработке.
Этот навык довольно слабо коррелирует с производительностью, так как высокая производительность в разработке ПО достигается тем, что люди не делают того, чего делать не надо. Не пишут сложный общий алгоритм, когда достаточно реализации частного случая, не делают навороченную архитектуру, когда достаточно написать все в одной функции, используют готовые библиотеки вместо написания своего кода в конце концов. Это все никак не связано с решением leetcode задач на время.
Более того, нет никаких исследований, что умение быстро решать leetcode задачи на время как-то коррелирует с производительностью. Я честно искал и не нашел.
Вы все правильно пишите, про преимущества таких собеседований, что сложно считерить, надо готовиться, обеспечивает однозначную оценку кандидата. Но проблема в другом - это собеседование не проверяет нужных навыков.
Если вы фаанг или хотя бы яндекс, то к вам могут стоять очереди хоямячков, готовых забесплатно поработать ради строчки в резюме. Но если у вас компания поменьше, то найти хотя бы 10 подходящих кандидатов по другим критериям, кроме знания алгоритмов будет уже проблемой.
Что касается задач, то как в фаангах, так и в рогах-и-копытах примерно одинаковое соотношения задач нетривиальной обработки данных и банальных перекладываний json. И вероятность что натренировавшись решать 100500 задач с литкода в секунду вы не будете заниматься скучной фигней - крайне мала.
Альтернативы всегда существуют.
Обычное собеседование с разбором кейсов: "как бы вы решили [такую] задачу". Желательно кейсы практические из встречающихся на практике. Тут и знания фрейморков, и алгоритмов, и умение фокусироваться на задаче итд
Чтение кода и поиск багов. Несмотря на банальность такая работа встречается в практической разработке гораздо чаще, чем реализация каких-то алгоритмов.
Тестовое задание, близкое к тому, чем придется заниматься, желательно с ограничением времени, которое сам кандидат назначит. Это идеальная проверка, но к сожалению многие кандидаты откажутся решать.
Эти варианты не взаимоисключающие, а взаимодополняющие. Если у вас поток кандидатов большой, а отобрать надо мало, то можно применить все три, а если поток маленький, то провести только обычное собеседование.
Подмена понятий.
Алгоритмическое собеседование как в Яндекс\Гугл\ГдеТоЕще не нужно. Нет никаких доказательств что оно как-то влияет на продуктивность сотрудников и вообще как-то помогает.
А само знание алгоритмов очень нужно, помогает не писать говнокод. Алгоритмов которые надо знать и понимать не очень много: массивы, списки, сортировка, бинарный поиск, кучи, деревья, хэш-таблицы, "динамическое программирование". Обычно это изучается первые полгода на курсе программирования, а при самостоятельном изучении заботать за пару ндель можно.
Теперь уже и API аналитики проектируют? Программисты не могут?
Когда начнут классы создавать и за ООП холиварить?
Почему не использует? Вы заранее знаете что у вас все инстансы на одной физической машине развернуты? Масштабировать не собираетесь?
Решение чтобы добавлять и удалять инстансы от нагрузки уже придумано до вас - Kubernetes называется.
Неверно формулу записал, надо было так:
d = ((d - Wi) max 0) + D(Wi)Спасибо.
Предположим сборщик один. В текущем виде от соберет сначала первый крупный заказ, потом второй, а потом только отдаст вам колу.
Если будет действовать по моему алгоритму, то после первого крупного заказа появится "долг" в размере Х, а кола гарантированно будет иметь вес меньше Х (если нет, то неправильно функцию долга подобрали). И вы сразу после обработки крупного заказа её получите.
В том то и прикол, что не будет. Самые большие прибыли рестораны быстрого питания делают на напитках. Там наценка на себестоимость выше 100%. В вот кухня сильно дороже.
Если вы не отдаете быстро заказы только с напитками, а заставляете людей ждать, то скорее всего теряете деньги, так как некоторые просто ждать не будут и пойдут в другом месте купят. А большой заказ человек легко подождет лишние пару минут.
Так вот сборка заказов и есть узкое место. Каждый сборщик может конечно взять любое количество заказов, но берет обычно один. Если количество крупных заказов перед вами будет больше количества сборщиков, то вы кофе свой не скоро получите, хотя казалось бы.
Что касается кода из статьи, то автор не учел, что когда у всех клиентов будет меньшее 100 транзакций в заказе, то второй инстанс будет отдыхать. Или наоборот, все элементы в очереди окажутся чуть больше порога. Этот алгоритм хоть и "справедливый", но нифига не эффективный.
Непонятно при чем тут микросервисы и .NET, если задача из теории массового обслуживания.
Кстати вполне практическое приложение: я заехал в
маквкусно-и-точка взять кофе. Но в ресторане было много заказов и кофе я дожидался минут 15. Хотя сама операция наливания кофе занимает от силы минуту, но передо мной было много "семейных" заказов, которые не умещались на один поднос.Очевидно в маке (буду так называть) используется обычная FIFO очередь. Без потери общности можно считать, что обработчик очереди тоже один. Чтобы улучшить обслуживание они могли бы каждому заказу назначать некоторый вес
Wi. В случае мака это время приготовления (они могут вычислить), а в случае топикстартера - количество транзакций в запросе.Далее надо ввести функцию долга
D(w), такую чтоD(Wi) < Wi. Для примераD(w) = 0.5 * wПосле обработки каждого заказа считать значение долга
d = (d - Wi + D(Wi)) max 0.Следующим заказом брать первым из очереди у которого
Wi <= d, или первый из очереди если под условие ни один не подходит, в начале обработкиd = 0Если обработчиков очереди больше одного, то параметр долга должен быть общий на всех.
Какая постная фигня.
"Лучше быть здоровым и богатым, чем не быть". Спасибо, кэп.
Я чето не понял как вы перешли от задачи семантической валидации JSON к сорс генераторам. Не притянуло ли за уши?
И зачем вам эти рекорды? Доплачивают за них?
Для получения мастера спорта по пауэрлифтинг не обязательно разжиратся, там норматив от весовой категории зависит.
Все конечно хорошо, но 215 кг в приседе и 25+% жира в организме (судя по фото) никаким "здоровьем" и продлением жизни не пахнут. Есть даже исследование с довольно сильной корреляцией продолжительности жизни с соотношением размера пузика и плеч.
Для здоровья надо:
Отказаться от алкоголя и курения, лучше совсем отказаться, если не получается со всем, то минимизировать.
Много двигаться, чем больше тем лучше. Не в ущерб работе, семье, сну конечно же. Средний офисный (или удаленный) работник может ходить по 10к шагов в день и иметь активное хобби по выходным.
Здоровый сон, тут все понятно
Нормальный процент жира (15% для мужика), если у вас сильно больше, то надо менять пищевые привычки (и чем раньше, тем лучше)
Выносливость на уровне "пробежать километр за 4-00 и не сдохнуть".
Силовые: присед со своим весом, становая со своим весом, жать от груди свой вес. Остальное факультативно.
Если анализ гитхаба и другого опенсорса говорит, что ничего не сломается от такого изменения, то ничего страшного.
На собеседовании: систем дизайн, архитектура, алгоритмы.
На практике: перекладывание json и сборка страничек из готовых реакт компонентов.
ИМХО все эти вопросы на собеседовании нужны чтобы делать вид, что компания на уровне Гугла или фейсбука.
Довольно странно сравнивать заводы в СССР и ИТ-шников сейчас. Сравните тогда нынешнее положение работников на заводе со временами СССР.
Кроме того надо понимать какие времена сравниваем - позднего СССР, времен Андропова и Горбачева или СССР на пике развития - после войны.
Но суть капитализма не во времени в пути на работу, а в том что расходы на поддержание бренного тела работника в трудоспособном состоянии перекладываются на самого работника. Поэтому работник, который меньше времени и денег на это тратит, оказывается выгоднее капиталисту. Несмотря на все высокопарные заявления руководителей крупных компаний о заботе о работниках, выбор всегда будет в пользу условного Миши.
Поэтому единственный вариант поддержания и развития человеческого капитала в масштабах страны или отрасли - социализм, то есть отъем часть прибыли капиталистов и распределение её в пользу работников.
Добро пожаловать в капитализм