Простые и стандартизованные бизнес-процессы имеются только в простых и стандартизованных бизнесах. Таких бизнесов с выручкой выше порога упрощенки я не знаю. Все процессы в них сложно подвести под какие-то стандарты.
Казалось бы ваш аргумент про относительно молодой бизнес может иметь место, но ведь и весь "большой" софт существует те же 30 лет. А многие (если быть честным - все) наши крупняки пользовались услугами западных консультантов, которые несут "лучшие практики".
Тем не менее стандартизация существует и нужна. Но не в автоматизации бизнес-процессов, а в методах управленческого учета.
Увеличивать прибыль можно как уменьшением затрат, так и увеличением выручки.
Выручка может увеличиваться за счет: увеличения количества клиентов (автоматизация маркетинга, повышение конверсии), за счет увеличения среднего чека (продажа большего количества товаров или услуг, допродажи), а также за счет увеличения пропускной способности конвейера от контакта до получения денег и отгрузки.
Кроме того, есть такая категория ПО как "управленческое", которое помогает более качественно принимать управленческие решения. Оно само по себе не влияет ни на какие финансовые характеристики компании, но помогает менеджерам меньше тратить и больше зарабатывать. Недавно был пример: внедрение системы прогнозирования платежей помогла понять что в конце года будет большой НДС и менеджеры побежали договариваться отправлять платежи контрагентам, чем сэкономили десятки миллионов налогов.
Это я все к чему: От софта обязательно должен быть экономический эффект. Но до внедрения просчитать его может быть невозможно.
У вас логическая ошибка в первом же предложении. Вы считаете что "алгоритмические собеседования как в гугле", которые по факту решение 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 и не сдохнуть".
Силовые: присед со своим весом, становая со своим весом, жать от груди свой вес. Остальное факультативно.
Простые и стандартизованные бизнес-процессы имеются только в простых и стандартизованных бизнесах. Таких бизнесов с выручкой выше порога упрощенки я не знаю. Все процессы в них сложно подвести под какие-то стандарты.
Казалось бы ваш аргумент про относительно молодой бизнес может иметь место, но ведь и весь "большой" софт существует те же 30 лет. А многие (если быть честным - все) наши крупняки пользовались услугами западных консультантов, которые несут "лучшие практики".
Тем не менее стандартизация существует и нужна. Но не в автоматизации бизнес-процессов, а в методах управленческого учета.
Увеличивать прибыль можно как уменьшением затрат, так и увеличением выручки.
Выручка может увеличиваться за счет: увеличения количества клиентов (автоматизация маркетинга, повышение конверсии), за счет увеличения среднего чека (продажа большего количества товаров или услуг, допродажи), а также за счет увеличения пропускной способности конвейера от контакта до получения денег и отгрузки.
Кроме того, есть такая категория ПО как "управленческое", которое помогает более качественно принимать управленческие решения. Оно само по себе не влияет ни на какие финансовые характеристики компании, но помогает менеджерам меньше тратить и больше зарабатывать. Недавно был пример: внедрение системы прогнозирования платежей помогла понять что в конце года будет большой НДС и менеджеры побежали договариваться отправлять платежи контрагентам, чем сэкономили десятки миллионов налогов.
Это я все к чему: От софта обязательно должен быть экономический эффект. Но до внедрения просчитать его может быть невозможно.
А еще все базы данных переносятся на один сервер в одну физическую базу
Чтобы ускорить сборку С++ нужны микросервисы?
Название статьи не соответствует содержанию.
Лучшие от худших судя по всему могут отличаться в 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 и не сдохнуть".
Силовые: присед со своим весом, становая со своим весом, жать от груди свой вес. Остальное факультативно.