Ну к примеру тревелайн , тинек , сбер , вб , все лучше чем Яша

Разработчик на Go в Еду Яндекс Москва, Питер, Екатеринбург, Новосбирск, Казань, Минск Формат: любой, в том числе гибрид или удаленка. Яндекс Еда — сервис доставки блюд из ресторанов и продуктов из магазинов. У нас миллионы заказов в месяц, с нами сотрудничают десятки тысяч заведений и более тысячи магазинов в 130 городах стран СНГ. Вместе с командой вам предстоит разрабатывать бэкенд приложения, которым пользуются сборщики заказов в подключённых к Еде магазинах, и его веб-админку, а в перспективе — более сложную систему, позволяющую нашим партнёрам в магазинах управлять продажей своих товаров в Еде. Какие задачи вас ждут – Разработка новых продуктовых сценариев – Поддержка и сопровождение работы сервиса Мы ждём, что вы – Разрабатывали на Go или готовы быстро и самостоятельно его освоить – Понимаете, как работают веб-сервисы – Разбираетесь в принципах работы с Unix и применяли их на практике – Умеете писать эффективный и понятный код, покрываете его тестами – Способны аргументировать решения и договариваться с коллегами – Не боитесь ответственности и предлагать идеи Что мы предлагаем – Работу в сильной команде, с которой можно расти – Сложные задачи для сервисов с миллионами пользователей – Возможность влиять на процесс и результат – Премии каждые полгода за эффективную работу – Компенсацию оплаты питания – Тренажёрный зал и дежурство врача в офисе – Расширенную программу ДМС, оплату 80% стоимости – ДМС для супругов и детей – Гибкий график Узнать подробнее и откликнуться или в лс к @MelnikovaK

что в вашем понимании алгодроч? написать проход по графу - это уже алгодроч ?

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

то есть, из всех, кто критикует Яшу, никто не работал и только слышали =) огонь! 👍

Разработчик на Go в Еду Яндекс Москва, Питер, Екатеринбург, Новосбирск, Казань, Минск Формат: любой, в том числе гибрид или удаленка. Яндекс Еда — сервис доставки блюд из ресторанов и продуктов из магазинов. У нас миллионы заказов в месяц, с нами сотрудничают десятки тысяч заведений и более тысячи магазинов в 130 городах стран СНГ. Вместе с командой вам предстоит разрабатывать бэкенд приложения, которым пользуются сборщики заказов в подключённых к Еде магазинах, и его веб-админку, а в перспективе — более сложную систему, позволяющую нашим партнёрам в магазинах управлять продажей своих товаров в Еде. Какие задачи вас ждут – Разработка новых продуктовых сценариев – Поддержка и сопровождение работы сервиса Мы ждём, что вы – Разрабатывали на Go или готовы быстро и самостоятельно его освоить – Понимаете, как работают веб-сервисы – Разбираетесь в принципах работы с Unix и применяли их на практике – Умеете писать эффективный и понятный код, покрываете его тестами – Способны аргументировать решения и договариваться с коллегами – Не боитесь ответственности и предлагать идеи Что мы предлагаем – Работу в сильной команде, с которой можно расти – Сложные задачи для сервисов с миллионами пользователей – Возможность влиять на процесс и результат – Премии каждые полгода за эффективную работу – Компенсацию оплаты питания – Тренажёрный зал и дежурство врача в офисе – Расширенную программу ДМС, оплату 80% стоимости – ДМС для супругов и детей – Гибкий график Узнать подробнее и откликнуться или в лс к @MelnikovaK

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

Поясню почему, дураков видно уже с собеса, а значит работать с ними не хочется.

Разработчик на Go в Еду Яндекс Москва, Питер, Екатеринбург, Новосбирск, Казань, Минск Формат: любой, в том числе гибрид или удаленка. Яндекс Еда — сервис доставки блюд из ресторанов и продуктов из магазинов. У нас миллионы заказов в месяц, с нами сотрудничают десятки тысяч заведений и более тысячи магазинов в 130 городах стран СНГ. Вместе с командой вам предстоит разрабатывать бэкенд приложения, которым пользуются сборщики заказов в подключённых к Еде магазинах, и его веб-админку, а в перспективе — более сложную систему, позволяющую нашим партнёрам в магазинах управлять продажей своих товаров в Еде. Какие задачи вас ждут – Разработка новых продуктовых сценариев – Поддержка и сопровождение работы сервиса Мы ждём, что вы – Разрабатывали на Go или готовы быстро и самостоятельно его освоить – Понимаете, как работают веб-сервисы – Разбираетесь в принципах работы с Unix и применяли их на практике – Умеете писать эффективный и понятный код, покрываете его тестами – Способны аргументировать решения и договариваться с коллегами – Не боитесь ответственности и предлагать идеи Что мы предлагаем – Работу в сильной команде, с которой можно расти – Сложные задачи для сервисов с миллионами пользователей – Возможность влиять на процесс и результат – Премии каждые полгода за эффективную работу – Компенсацию оплаты питания – Тренажёрный зал и дежурство врача в офисе – Расширенную программу ДМС, оплату 80% стоимости – ДМС для супругов и детей – Гибкий график Узнать подробнее и откликнуться или в лс к @MelnikovaK

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

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

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

Вот признак хотите, если думать что одну технологию типа k8s нужно пихать всегда и везде, это плохо...

это разного рода задачи. одно дело - написать бизнес фичи (CRUD или что-то из базы просто достать и отдать). другое дело - написать statefull систему, которая еще и что-то хранить должна у себя и с правильной обработкой. в 1ом - алгоритмы не нужны, там все просто. во 2ом - нужно понимание алгоритмов

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

Может у них на проекте микромодули, организованные swarm, зачем ему знать k8s?

Алгоритмы такого уровня уж очень редко бывают нужны, тем более СТАЖЁРАМ. А если необходимо разработать принять какое-то сложное архитектурное решение по продукту, не думаю, что хорошей идеей будет принимать его в одиночку за полчаса)

почему большинство не используют swarm? =) при том, что у них геораспределение микромодулей имеется. тут само собой разумеется использование k8s или аналогов. swarm такое может, но огрехов больше, чем профита

почему большинство не используют swarm? =) при том, что у них геораспределение микромодулей имеется. тут само собой разумеется использование k8s или аналогов. swarm такое может, но огрехов больше, чем профита

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

Не надо в IT смотреть на большинство, если большинство использует молоток, а мне нужно саморез закрутить, я возму шуруповерт. В IT многообразие инструментов. Использовать нужно что лучше подходит а не что использует большинство. А то будет яндекс.

Не надо в IT смотреть на большинство, если большинство использует молоток, а мне нужно саморез закрутить, я возму шуруповерт. В IT многообразие инструментов. Использовать нужно что лучше подходит а не что использует большинство. А то будет яндекс.

правильно, поэтому пишите на хаскеле

Хорошая аналогия, но мне кажется тут больше подходит история про паровой двигатель и ДВС, конечно если ты работаешь на пароходе пытаться поставить туда ДВС так себе идея. Но если ты хочешь развиваться и идти в ногу со временем то нужно искать работу с ДВС, или ещё дальше с электромоторами)

правильно, поэтому пишите на хаскеле

если он тебе идеально подходит как инструмент, то на здоровье

правильно, поэтому пишите на хаскеле

где и кто? ДОПЛАЧУ!)

это разного рода задачи. одно дело - написать бизнес фичи (CRUD или что-то из базы просто достать и отдать). другое дело - написать statefull систему, которая еще и что-то хранить должна у себя и с правильной обработкой. в 1ом - алгоритмы не нужны, там все просто. во 2ом - нужно понимание алгоритмов

это разного рода задачи. одно дело - написать бизнес фичи (CRUD или что-то из базы просто достать и отдать). другое дело - написать statefull систему, которая еще и что-то хранить должна у себя и с правильной обработкой. в 1ом - алгоритмы не нужны, там все просто. во 2ом - нужно понимание алгоритмов

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

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

То что нужно во втором случае, придет например от чтения кабанчика, от проекта с тразакциями и т.п., но точно не с литкода.

То что нужно во втором случае, придет например от чтения кабанчика, от проекта с тразакциями и т.п., но точно не с литкода.

Литкод - это просто неумение и/или нежелание готовиться к собеседованию со стороны нанимающего.

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

В IT иногда хорошо платят за легаси или решение проблем. Как щас Гошнику легче вкатится с опытом древнего PHP, потому что возмут перепиливать старое...

Все так, пока Легаси не закроется, и человек не окажется на рынке с невостребованными скиллами

И вот он задрочил код до страшного состояния скорости, а потом результат работы этого кода прошел через 10 микросервисов, с 10 сетевыми рукопожатиями и т.п и все тупит. А код от задроченности стал некрасивым и не читабельным. :)

странное у вас мировоззрение. как по вашему гугл работает или дискорд (вроде по нему как-то писали статью про рекомендовательную систему)? ой да, там наверное жесткий боевой код, не требующий алгодрочева... =(

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

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

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

то есть вообще нет смысла сидеть на литкоде?

я с вами не согласен =) решал литкод, периодически решаю и буду решать. лично мне это помогает в профессии. тот же кабанчик, который упоминали, строится (неожиданно) на алгодрочеве! базы, которые новые и придумывают - алгодрочево. индексы к векторным базам - вообще песня алгодрочева =)

я с вами не согласен =) решал литкод, периодически решаю и буду решать. лично мне это помогает в профессии. тот же кабанчик, который упоминали, строится (неожиданно) на алгодрочеве! базы, которые новые и придумывают - алгодрочево. индексы к векторным базам - вообще песня алгодрочева =)

то есть вообще нет смысла сидеть на литкоде?

и часто вы придумываете новые базы?)

это не жесткий, а легаси. не путайте )

Так кто-же запрещает то, решайте если вам нравится. Если свою базу пишите, наверно тоже пригодится.

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

Не, легоси, это если кто код задрочил до выигрывания 3 тактов на библиотеке 10 летней давности, а с библиотекой 5 летней давности оно тупит или сломалось из за этого. А жесткий когда писал нормально, читаемо, и все работает с любой версией библиотеки.

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

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

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

Если говорить полностью про stateless систему/приложение, то это будет условный сервис аутентификации, который будет проверять jwt токены не используя БД и прочие вещи и возвращать пользователю ответ о том, что токен валиден или нет. Если он лезет в базу для проверки того, чтобы проверить инфу по этому токену (вообще любую), то это уже по сути stateless

Придется ему в редис по сесии смотреть, и скорее всего в базу по рефреш токену. :)

В большинстве случаев работа с БД это уже statefull, т.к. ты можешь что-то с этими данными сделать и выдать пользователю историю, статистику и т.д. stateless подразумевает, что отдельный запрос пользователя никак не будет связан с предыдущими и ты эти данные не хранишь. Statefull не подразделяется на то, где ты хранишь данные в памяти, на диске или в БД, если ты какие-то данные сохраняешь на сервере, то это определению statefull, а не stateless(мб кроме пары исключений)

Понимаю авторов мапы в Go, что специально сделали отсутствие порядка в выдачи. Иначе обязательно бы нашелся алгодрочер чтоб по индексу работать. :)

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

А данные он берет из базы, stateless и statefull не определяются тем, где конкретно ты хранишь данные, они определяется что ты хранишь/не хранишь их состояние. О того, что ты кеш перенес из локальной мапы в редис, сервис не становится stateless