по языку, я тогда писал на котлине и выбрал его, проходил в яндекс 360, для удаленки нужен был сеньор грейд, решил попробовать
первая секция была лайф кодинг как раз, дали задачу бизнесовую - есть клиент и его корзина, у каждого клиента свой процент скидки, нужно оформить заказ, на правильную сумму и в ответе отдать userName + orderSum. И тут как в архитектурных секциях нужно задать миллион вопросов, чтобы понять, что именно хотят) все проверки на отрицательные чиста и т.д выдумываешь сам и покрываешь тестами, в своей иде, обычные юнит тесты. На самом деле секция прикольная, особенно идея с тестами, ее я прошел успешно и получил хороший фидбэк следующим этапов были алгоритмы, решив 2 задачки на котлине с собеседующим, который даже не видел этот язык получил ответ, что немного было неправильно и я сказал, ну и ладно) Через месяц позвали на собес в ОТП банк и прошел туда, где работаю по сей день) Всего 2 человеческих этапа, собес на 1:30 часа и созвон с руководителем и командой, где спрашивали, что я буду делать в экстренной ситуации и тд) Ну и предложили там больше, чем в яндексе))
Проходил собес в Яндекс в июне, live coding был в моей иде, даже попросили настроить проект для тестов и задача считалась решенной тольк тогда, когда были написаны тесты(как сказали на интервью, тесты, которые считаю нужными), а вот алгосы были в блокноте(в их приложении для кодинга) причем я писал на котлине, а мой код смотрел ревьювер на GO, который просто смотрел, как я пишу код, сказав, что котлин в глаза не видел))))
Есть carrier-threads(настоящий поток ОС), в котором может быть много виртуальных потоков. Виртуальные потоки не держат стек в памяти ОС, их стек хранится в куче и выделяется динамически.
На уровне JVM есть планировщик виртуальных потоков. Он управляет тем, какой виртуальный поток монтировать на какой carrier-thread. Планировщик использует FIFO-очередь (First-In-First-Out) для ожидания выполнения задач на carrier-thread. Также же еще весь сок в том, что виртуальные потоки полностью совместимы со старым апи, то есть как раз и экзекуторы, симафоры и т.д)
Спасибо за комментарий, рад, что вам понравилась статья)
Да, дублирование возможно, но это не баг кода, а ограничение стандартного outbox-подхода без Kafka transactions. Понятно, что такое может случится и мы действительно пошлем сообщение 2 раза. Я писал, что показал самую дефолтную реализацию. Но про питание и OOM можно много где написать, что нет защиты. Но как часто у вас были такие примеры, что выдернули шнур? OOM можно стабилизировать кол-вом записей, которые мы достаем. Есть еще практика выделять шедулеры или консюмеры в отдельные инстансы, чтобы они работали независимо.
Как по мне подход к решению проблем, которые вы описали это больше комплексный подход всего проекта, а не конкретного стартера)
Все собесы разные, у меня был такой, бывают, конечно, собесы гораздо сложнее.
Зачастую все основные вопросы и понимание у собеседуего приходит на систем дизайне, как по мне, там и доп вопросы и почему так и зачем, вот там и раскрывается человек)
Примерно 0 в моей практике)) обычно ты приходишь и за тебя уже все настроено, а именно выбор GC стоит очень редко, обычно дефолтный покрывает все, что нужно, за редким исключением
там в этом был смысл) видимо без ТЗ разработать и продумать проверки и камни
Либо там плохо с аналитикой, либо очень странная и ненужная секция
по языку, я тогда писал на котлине и выбрал его, проходил в яндекс 360, для удаленки нужен был сеньор грейд, решил попробовать
первая секция была лайф кодинг как раз, дали задачу бизнесовую - есть клиент и его корзина, у каждого клиента свой процент скидки, нужно оформить заказ, на правильную сумму и в ответе отдать userName + orderSum. И тут как в архитектурных секциях нужно задать миллион вопросов, чтобы понять, что именно хотят) все проверки на отрицательные чиста и т.д выдумываешь сам и покрываешь тестами, в своей иде, обычные юнит тесты.
На самом деле секция прикольная, особенно идея с тестами, ее я прошел успешно и получил хороший фидбэк
следующим этапов были алгоритмы, решив 2 задачки на котлине с собеседующим, который даже не видел этот язык получил ответ, что немного было неправильно и я сказал, ну и ладно)
Через месяц позвали на собес в ОТП банк и прошел туда, где работаю по сей день)
Всего 2 человеческих этапа, собес на 1:30 часа и созвон с руководителем и командой, где спрашивали, что я буду делать в экстренной ситуации и тд) Ну и предложили там больше, чем в яндексе))
Проходил собес в Яндекс в июне, live coding был в моей иде, даже попросили настроить проект для тестов и задача считалась решенной тольк тогда, когда были написаны тесты(как сказали на интервью, тесты, которые считаю нужными), а вот алгосы были в блокноте(в их приложении для кодинга) причем я писал на котлине, а мой код смотрел ревьювер на GO, который просто смотрел, как я пишу код, сказав, что котлин в глаза не видел))))
От Яндекса остались не очень впечатления)
Привет, рад, что вам понравилось)
LookUp правильный и гарантированный способ получать новый prototype каждый раз)
/
Рад, что вам понравилось)
Если я не ошибаюсь основная причина, почему их назвали виртуальными потоками: обеспечить полную совместимость с существующим API потоков в Java)
Есть carrier-threads(настоящий поток ОС), в котором может быть много виртуальных потоков.
Виртуальные потоки не держат стек в памяти ОС, их стек хранится в куче и выделяется динамически.
На уровне JVM есть планировщик виртуальных потоков. Он управляет тем, какой виртуальный поток монтировать на какой carrier-thread.
Планировщик использует FIFO-очередь (First-In-First-Out) для ожидания выполнения задач на carrier-thread.
Также же еще весь сок в том, что виртуальные потоки полностью совместимы со старым апи, то есть как раз и экзекуторы, симафоры и т.д)
Спасибо за комментарий, рад, что вам понравилась статья)
Да, дублирование возможно, но это не баг кода, а ограничение стандартного outbox-подхода без Kafka transactions. Понятно, что такое может случится и мы действительно пошлем сообщение 2 раза. Я писал, что показал самую дефолтную реализацию.
Но про питание и OOM можно много где написать, что нет защиты. Но как часто у вас были такие примеры, что выдернули шнур?
OOM можно стабилизировать кол-вом записей, которые мы достаем. Есть еще практика выделять шедулеры или консюмеры в отдельные инстансы, чтобы они работали независимо.
Как по мне подход к решению проблем, которые вы описали это больше комплексный подход всего проекта, а не конкретного стартера)
Спасибо за комментарий)
Раньше бывало по 2 собеса в день, сейчас же, из-за ситуации на рынке, такое редкость)
А у нас всегда называли так, у всех свое, видимо))
Что-то я не могу найти где это в статье, вроде и прошелся еще раз))
Возможно вы и правы, спасибо вам за комментарий)
Ваше мнение
Если будут одинаковые имена, то группировка по айди не даст 1 запись, а несколько, по каждому клиенту)
Мне доказывать нечего, да и не нужно, я просто делюсь своим опытом))
Вам же спасибо, что следите за мной, мне очень приятно)))
Все собесы разные, у меня был такой, бывают, конечно, собесы гораздо сложнее.
Зачастую все основные вопросы и понимание у собеседуего приходит на систем дизайне, как по мне, там и доп вопросы и почему так и зачем, вот там и раскрывается человек)
Я же рассказал свой реальный опыт)
У меня в профиле есть разбор целого собеса)
Но сейчас рынок очень тухлый, зовут редко куда-то (
Это была опечатка, спасибо большое, так да, там count
Спасибо, да, вы правы, я не совсем корректно выразился, спасибо)
Примерно 0 в моей практике)) обычно ты приходишь и за тебя уже все настроено, а именно выбор GC стоит очень редко, обычно дефолтный покрывает все, что нужно, за редким исключением
Профайлер вообще имба, выручал не один раз))