Хотя вероятно я и запросы sql не самые оптимальные написал

А, вы про отборочный тест

типа да... по приколу было поиграться... площадка тоже забавная, еще поигрался с ней

ну да, я тоже из интереса)

ты же в баду вроде?

ну а почему бы тестик не потыкать)

налажаешь, понизят грейд ;) или что там у вас ;)

лвлы не понижаются)

как даны в го - остаются до конца жизни)

Работаешь ты такой в баду, проходишь тестик, отправляешь результаты, а тебе приходит ответ "извините, но по плохим результатам вашего теста мы не можем пригласить вас на собеседование"

лал

ага, и еще от эйчара по башке, чтобы не баловался) ибо твой личный адрес уже засветился

найскейс)

ну в принципе если человек хочет в лондон из московской команды, а его не пускают, то почему бы и да ;)

не слышал о случаях, чтобы не пускали)

по крайней мере после прохождения испыталовки

удаленной?

эмм? удаленная испыталовка?

ну типа да, выделяют комнату со скайпом, вешают табличку "это лондон" ;)

лол)

скажи лучше, в чем подвох последнего вопроса теста... где sql с агрегацией ... если в лоб, там получается такой кривой запрос - агрегация на агрегации, подзапрос на подзапросе

угу. как-то можно нормально решить?

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

кстати, интересный вопрос. попробую узнать

джойн на себя с неравенством в ON?

но там агргация нужна все-равно...

чотя в ваще забыл о чем там речь... вроде вывести все отделы с максимальной суммой...

да, что-то типа. я уже тоже не помню

один подзапрос с агрегацией, что бы получить максимальную сумму и второй запрос с агрегацией, что бы вывести все записи совпадающие с этой максимальной суммой

помню только, что мне самому результат не оч понравился

ну я вообще не успел его, много на предыдущий писал.. но потом долго пытался найти, как такое решается... и что-то не нашлось

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

ну это онлайн задача... нужно запрос написать ;) рассуждения за кадром

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

ага… мне на собеседовании так и сказали сразу - «мы любим простые решения. они, как правило, работают»

проблема в том, что простота - это очень сложно....

простое решение !== первое приходящее в голову решение

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

потому что движок хакерранка как раз позволяет автоматом отсеять по этим 4 задачам

думаешь даже не глядят на решения?

да

там же тысячи наверняка писали

тогда логично бы текстовое последним ставить .... ;)

если ты тыкал движок, то понял, что кроме публичных кейсов там есть и приватные

да, это понятно

по которым уже проверяет правильность и оптимальность решения

про оптимальность вот не уверен ;)

а поставить третьим.. это правильное решение :)

там есть.. я в свое время на алгоритмы ради прикола решал.. некоторые мои неоптимальные заваливались по таймауту.

правда я SQL не решал. неинтересно же :)

не понятно, что мешало мне или кому-то еще, порешать все еще раз офлайн и заполнить тест второй раз под другим именем ;)

простое решение !== первое приходящее в голову решение

Просто решение это как правило унылое решение

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

Просто решение это как правило унылое решение

как раз нет, это решение "о... это же так просто, гениально, почему я сразу не догадался"

Как плюс - получаем несвязанность кода, можно в одном месте из 20 быстренько изменить поведение и не иметь проблем с обратной совместимостью

как раз нет, это решение "о... это же так просто, гениально, почему я сразу не догадался"

Ну нее :)

нет, копипастнуть 10 раз - это как раз "в лоб, первое пришедшее в голову"

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

А вот Игорь Сысоев рекомендовал при написании конфига nginx копипастить а не заморачиваться с инклюдами )

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

А вот Игорь Сысоев рекомендовал при написании конфига nginx копипастить а не заморачиваться с инклюдами )

не совсем так.. он советовал использовать внешние системы генерации из шаблонов

Ну копипаст - это не простое гениальное решение, у него есть и недостатки

а кто говорит, что копипаст простое решение... я так не считаю... это очевидное решение, а очевидное != простое

очевидное != простое != легкое != тривиальное != малозатратное

Ну вот сделать очереди на табличках mysql по твоему это решение очевидное или простое? =)

очевидное ;)

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

ERROR: S client not available

Ну есть же реббит

С роутингом, кластеризацией, репликацией сообщений

Вот это очевидное, но не простое

а простое решение, что-то из серии "а нахрена мне тут вообще очереди" ;)

Вот это очевидное, но не простое

смотря для кого. ктото ничего не знает кроме базы. он сразу в базе табличку сделает. тем более фреймворк позволяет(я про ларку)

ктото сразу в редисе сделает :) ибо он и так в проекте юзается

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

Как думаешь, ребята из баду знают хоть что-то кроме mysql?

Многие - да. Ребята из баду не только в баду работали или теперь работают.

ну насколько мне известно они mysql как key-value практически юзают.

как они только его не используют)

ну да :)

Ну есть же реббит

в моде кафка) хотя у них немного разная сфера применения, но частично пересекаются

Совсем как бы разная.

Все равно что сравнивать карьерный самосвал и пикап. Вроде и то - и дрое с открытым кузовом.

ну ты не забывай главного правила айти)

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

например, ML для сайта-визитки

JPEEEG! ONLY JPEG!

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

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

сложно что ли ;) блокчейн с одним инстансом, и правь что хочешь задним числом ;)

можно гит предложить ;)

а кто как кеши инвалидирует. и инвалидирует ли вообще(не зря же протухание придумали!)? просто интересно...

ну очевидно, что запросы страничные, с кучей записей, мало кто очищает или и такое бывает?

rm -rf /cache/ :)

эт неинтересно

я тут просто сижу.. ловлю эвенты, чищу нужные кеши...

мож чего не так делаю 7:)

да норм ;) когда сущности меняются редко и равномерно, полагаю... а если все разом и много - проще все сбросить ;)

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

тут то все ок :)