Т-академия

Экзамены до 22 января. Курсы для фаст трека на стажировку. Податься одновременно и на стажировку и на академию нельзя, только если с фейков. Задания уже выложены тут. Разбор алгоритмов для аналитиков и бэкендеров будет только на нашем курсе по алгоритмам, на который скидка заканчивается уже сегодня.

Задача на сравнение чисел в джаве

    public static void main(String[] args) {
        Integer stupidNum1 = 127;
        Integer stupidNum2 = 127;
        Integer stupidNum3 = Integer.parseInt("127");
        Integer stupidNum4 = 128;
        Integer stupidNum5 = 128;
        Integer stupidNum6 = -129;
        Integer stupidNum7 = -129;

        System.out.println(stupidNum1 == stupidNum2);
        System.out.println(stupidNum1 == stupidNum3);
        System.out.println(stupidNum4 == stupidNum5);
        System.out.println(stupidNum6 == stupidNum7);
    }

Что будет выведено на экран при сравнении этих чисел?

Результат:
true
true
false
false

Объяснение:
В джаве значения в диапазоне от -128 до 127 включительно хранятся в Integer кэше.
Если инициализируется переменная со значением в указанном диапазоне, объект из кэша будет использован повторно => одна и та же ссылка на один и тот же объект.
Если значение не входит в диапазон, создаётся новый объект в куче, и при проверке на равенство через "==" сравниваться будут ссылки на разные объекты.
При создании значения через parseInt(): возвращается примитив int -> автоупаковка в Integer -> генерация вызова valueOf(), который проверяет, находится ли значение в диапазоне кэша, и либо возвращает кэшированный объект, либо создаёт новый объект типа Integer.

В общем, помните об этом, но сравнивайте числа через equals(), чтобы не заморачиваться.

@codeof_art

Задача на resize() хэшмапы в джаве

    public static void main(String[] args) {
        Map<Integer, String> internMap = new HashMap<>(5);

        internMap.put(1, "salary");
        internMap.put(2, "?");
        internMap.put(3, "thanks,");
        internMap.put(4, "I");
        internMap.put(5, "work");
        internMap.put(6, "for");
        internMap.put(7, "compote");

        System.out.println("key 1 = " + internMap.get(1));
        System.out.println("size = " + internMap.size());
    }

При добавлении какого элемента произойдёт resize()?

Результат:
Ресайз произойдёт при добавлении 7-ого элемента, все элементы перераспределятся, ёмкость хэшмапы увеличится с 8 до 16.

Объяснение:
При создании хэшмапы с параметром 5 ёмкость на самом деле = 8, так как приводится к ближайшей степени двойки.
Предельное количество элементов высчитывается именно от реальной ёмкости и в джаве по умолчанию равняется 75% от заполненности => 8 * 0,75 = 6. Ресайз произойдёт на 7 элементе, когда предельное количество станет превышено.
Для 7 элементов это не критично, но в условиях больших данных ресайзы необходимо избегать, так как они замедляют хэшмапу во время перераспределения бакетов.

Стандартный способ расчёта ёмкости, если мы в курсе предполагаемого количества элементов:

int expectedElements = 1000;
int safeCapacity = (int) Math.ceil(expectedElements / 0.75) + 1;
Map<K, V> anotherStupidMap = new HashMap<>(safeCapacity);

@codeof_art

Ментор+

Эта услуга для тех, кто хочет трудоустроиться уже сейчас без лишней головной боли и теории.

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

Что мы не обещаем
Мы не можем обещать нереальных или почти нереальных результатов как "оффер на 500 тыс (стажер)".
Мы не можем обещать попадание в конкретную компанию.

Как мы достигаем цели?

1. Легенда
Мы прорабатываем с вами легенду, которую вы должны выучить и озвучить на собеседовании: где работали, что делали и так далее. Составляем конкретно под вас резюме.

Если вам нужно проработать легенду и составить резюме, но вы хотите проходить собеседования полностью самостоятельно, то это отдельная услуга. Она стоит 15 тысяч рублей. Для записи: @vice22821.

2. Прохождение собеседований
Подбираем с вами вакансии, проходим с вами собеседования, сидя у вас на наушнике, проходим лайвкодинг с помощью удаленного доступа.

Если вам разово нужен специалист, который поможет на собеседовании: посидит на наушнике или пройдет лайвкодинг с удаленного доступа, то это отдельная услуга. Ориентировочная цена 10 тыс за пол часа собеса. Для записи: @vice22821

3. Теоретические занятия
Теоретические занятия в ментор+ не входят, ментор+ для тех, кому нужно трудоустройство. Если вам нужны знания, вам подойдут курсы.

Если у вас непростая ситуация и требуется консультация специалиста, то это отдельная услуга. Она стоит 8 тыс в час. Для записи: @vice22821.

Если вам нужно мок собеседование, то это отдельная услуга. Она стоит 8 тыс в час. Для записи @vice22821.

Как записаться
Написать @vice22821 со своим запросом. Мы обсудим насколько ваша цель достижима, сколько на это потребуется времени и готовы ли мы взяться за ваш заказ. Если вас все устроит, то начнем работать.

Оплата ментор +
Залог составляет 30 тыс. Уже после получения оффера нужно внести 1 месячную зарплату после вычета налогов.

Что если не получится
Если не получилось получить оффер по нашей вине (после собеседований в 5 компаний у вас нет оффера) в установленные сроки, то мы возвращаем вам залог.

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

Ответы на часто задаваемые вопросы

1. Сколько в среднем вся работа займет времени?
Если с вашей стороны нет задержек (например, уехали в отпуск), то максим 6 месяцев. Обычно удается получить оффер за 3 месяца.

2. Есть ли сопровождение на испытательном сроке?
Не входит в ментор+, отдельная услуга и обсуждается индивидуально.

В новом ролике обсудим современное рабство: стоит ли идти в айти галеры ради первого опыта работы на примере Астона! Осторожно, факты вас шокируют! Смотрим! Смотрим!

https://www.youtube.com/watch?v=y7QwkvxSzbc

Товарищи, Поступашкам нужны контент мейкеры. Если вы творческая личность, интересующейся бэкендом, дата сайнс, аналитикой, алгоритмами и так далее, вам нравится писать посты/ придумывать идеи для контента, то обязательно пишите @vice22821. Оплата сдельная, ориентировочно за один пост от 2 тыс до 15 тыс рублей.

Обязательно делитесь с ребятами, которым это может быть интересно.

ИИ ВСЕХ ЗАМЕНИТ! ЧТО ДЕЛАТЬ?

По результатам нашего опроса, 50% считает, что первые с рынка уйдут бэкендеры. Ещё 39% голосуют за аналитиков, а ML-специалисты пока чувствуют себя увереннее всех — за них отдали всего 11%.

Но кто на самом деле находится под угрозой?

В эту субботу в 19:00 устроим дебаты про ИИ. Преподаватели наших направлений по ML, аналитике и backend попробуют доказать, почему именно их профессия переживёт развитие нейросетей, а работа коллег изменится первой.

Обсудим:
— какие задачи ИИ уже забирает у специалистов;
— где нейросети пока не могут заменить человека;
— какие навыки скоро станут бесполезными;
— чему учиться сейчас, чтобы не остаться без работы через пару лет.

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

Ну а ведущий эфира - легендарный Михаил Абрамович 😎

📅 Суббота, 19:00
🔗 Ссылка будет за 2 часа до эфира и в нашем боте @Postupashkianalitycsbot

System Design

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

Начнём разбор задачек с фронта, и вот почему. На просторах интернета я часто натыкался на разборы систем дизайна по бэкенду - там уже всё разобрано вдоль и поперёк. А по фронту совсем тухло. Особенно мало такого контента на русском - за рубежом эта тема в ходу давно, и вот за последние года три-четыре все чаще проводят собесы такого формата и у нас. Так что дыру затыкаем в первую очередь там, но бэк тоже разберём, задачки уже в очереди. Но давайте поговорим для начала вообще как проходит эта секция для всех направлений.

Что такое систем-дизайн вообще
Это секция, где тебе дают намеренно расплывчатую задачу — "спроектируй ленту новостей/сервис для хранения сообщений пользователей в мессенджере" - и оценивают не финальную картинку, а то, как ты к ней пришёл. Правильного ответа здесь не существует, есть обоснованный выбор под ограничения. Поэтому если ты не задал ни одного уточняющего вопроса и сразу побежал рисовать - ты уже валишь секцию, каким бы красивым ни вышло решение.

В целом структура данного собеса одинаковая и для фронта, и для бэка, ниже кратко разберем её.

Собираем требования. Задаём вопросы. Что за продукт, кто пользователи, какие ключевые сценарии, какие ограничения. Делим на функциональные требования (что система должна уметь) и нефункциональные (скорость, надёжность, доступность, безопасность). Половина хорошего ответа на собесе - это правильно заданные вопросы в первые несколько минут, но тут главное не задать слишком много вопросов, иначе можно себя закопать легко, тут важно не распыляться.

Затем рисуем верхнеуровневую архитектуру. Крупные блоки и как между ними течёт поток данных. Пока без деталей реализации - только скелет. Продумываем данные и состояние. Что где хранится и в каком виде. Определяем контракты. Как части системы общаются друг с другом: формат запросов и ответов, как приходят ошибки.
Углубляемся и оптимизируем. Узкие места, пограничные кейсы, отказы. Именно здесь джун превращается в мидла на глазах у интервьюера.

Что спрашивают у бэкендеров
Главный вопрос, на который ты весь час отвечаешь: выдержит ли твое решение миллион пользователей и не потеряем ли мы данные, если что-то упадёт.

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

Что по фронту
Тут же начинаем с одного пользователя, а затем масштабируемся. Также стоит учитывать, что у юзеров может быть плохой инет, древний браузер и кирпич вместо телефона. Это тоже сильное влияет на итоговое решение. Что стоит обсудить на этой секции: контракт API, стратегия рендеринга (CSR / SSR / SSG, гидрация), работа с состоянием. Дальше - производительность (размер бандла, ленивая загрузка, и прочие вещи), UX-состояния, доступность и локализация. И только потом выбор методологии под проект и уже совсем в конце сами компоненты.

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

Что общего
И там, и там проверяют одно и то же: умеешь ли ты работать в условиях неопределённости, видишь ли компромиссы и можешь ли объяснить, почему выбрал именно это. Формулировка уровня «я взял такой подход из-за ограничения X, но если бы было условие Y — выбрал бы Z» показывает в тебе инженера.

Что дальше по плану - разборы конкретных задач с реальных собесов, примерно раз в неделю. Надеюсь, зайдёт и вы поддержите новую рубрику!

Подписывайтесь на канал и вступайте в чатик, товарищи, так вы не пропустите новый контент!

Подписаться: @codeof_art

System Design: frontend

Разберём реальную задачку, её дали мне на собес в Яндекс Поиск. Пользователь вбивает в поиск «2+2», в выдаче нужно показать блок-калькулятор с уже посчитанным ответом, отрисовка серверная. Как реализуешь?

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

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

Дальше поток простой. Бэк поиска понимает, что запрос - это выражение, парсит его и считает на сервере, отдаёт готовый HTML с уже проставленным ответом. Юзер видит «4» до того, как загрузился хоть один килобайт нашего JS. Вот, собственно, ради этого здесь и нужен SSR. Потом виджет гидрируется и становится кликабельным, и с этого момента все вычисления живут на клиенте - бегать на сервер за каждым нажатием кнопки нельзя, это верный способ завалить секцию.

Состояние приезжает с сервера и обязательно сериализуется в разметку, а не пересчитывается заново на клиенте, иначе поймаешь hydration mismatch и блок мигнёт при перерисовке. После гидрации стейт полностью локальный, виджет автономен. Контракт с бэком выдачи выглядит примерно как выражение, его нормализованный вид и результат, причём результат передаём строкой, а не числом - иначе можем потерять точность. И ошибки проговариваем отдельно: невалидное выражение, деление на ноль и переполнение это три разных состояния, а не одно «что-то пошло не так».

Теперь возвращаемся к тому вопросу про клики. Ответ на него такой: подавляющее большинство вбили «2+2», увидели «4» и ушли, они никогда не нажмут ни одной кнопки. Так зачем мы им грузим и гидрируем интерактивный калькулятор? Гидрируем лениво, по первому взаимодействию - клику, наведению. До этого на странице лежит статичный HTML, который стоит ноль. Если это сказать на собесе, то это большой плюсик для тебя, ответ явно не джуна.

Дальше добираем очки от интервьюера. Гидрируем независимо от остальной выдачи, чтобы наш виджет не утащил за собой SERP. Никакого eval ни на сервере, ни на клиенте - выражение пришло от пользователя, это недоверенный ввод, нужен нормальный парсер. Про eval интервьюер спросит почти наверняка, а если не спросит, скажи сам, +реп. Результат детерминирован, «2+2» всегда даёт «4», значит блок прекрасно кэшируется. Ну и резервируем высоту блока, чтобы выдача не прыгала, делаем настоящие кнопки вместо дивов с onclick и вешаем aria-live на результат, чтобы скринридер его озвучил. Сразу видно, что человек думает о доступности, тоже +реп гарантирован.

Если коротко, проверяют здесь одно: понимаешь ли ты разницу между «отрендерить» и «сделать интерактивным», и умеешь ли не платить за интерактивность там, где она девяноста пяти процентам людей не нужна.

Подписывайтесь на канал и вступайте в чатик, товарищи, так вы не пропустите новый контент!

Подписаться: @codeof_art

Уточнил у кандидата работал ли он со скоринговыми моделями как "Ясасу Бибу" и "Цист Яна". Ответ убил.

https://youtube.com/shorts/ccNWpP5grzg

System Design: backend

Обещали разобрать бэк - делаем. Задачка с собеса в Сбере: нужно передавать файлы большого размера. Через мессенджер не выйдет, упрёмся в лимиты, значит либо торрент, либо поднимать свой сервер, либо что-то ещё. Как спроектируешь?

Стоит начать не идти в лоб решать, а задать парочку вопросов, например я начал бы с такого: отправитель и получатель должны быть онлайн одновременно? Ну и попутно выясняем размер файлов, один получатель или тысячи качают одно и то же, сколько файл живёт и не корпоративная ли это сеть - потому что в корпоративной сети половина P2P просто не взлетит.

Дальше развилка, ради которой задачу и дают. Можно пойти в P2P, когда файл льётся напрямую между участниками, а мы храним только метаданные. Мы не платим за хранение и за исходящий трафик, и чем популярнее файл, тем быстрее раздача, потому что получатели сами становятся источниками. Но обе стороны обязаны быть онлайн одновременно, придётся возиться с NAT и фаерволами, а фолбэк на релей - это уже снова наш сервер и наш трафик. Можно пойти централизованно: отправитель залил, получатель забрал когда захотел, никто никого не ждёт, но мы платим за хранение и, главное, за исходящий трафик, который тут и будет основной статьёй расходов. А в проде почти всегда получается гибрид, где метаданные, авторизация и сигналинг идут через наш сервер, а данные - напрямую между клиентами, где это возможно. Вот эту мысль и надо озвучить: выбор определяется требованиями.

Что бы ты ни выбрал, файл целиком одним куском не гоняем никогда, режем на чанки. Отсюда сразу берётся возобновляемость - оборвалась сеть на N гб, дослали недостающие куски, а не начали всё сначала. Берётся параллельность, потому что несколько чанков льются одновременно и утилизируют канал. Берётся дельта-передача: правка внутри десятигигабайтного видео превращается из десяти гигабайт трафика в пару десятков мегабайт. Считаем хеш каждого чанка — и получаем дедупликацию, когда один и тот же файл, залитый сотней людей, лежит в единственном экземпляре, и заодно контроль целостности, когда битый кусок видно сразу и перекачивается только он.

По хранению главное не смешивать вещи в кучу. В базе лежит запись о файле и ссылки на чанки, сами чанки - в объектном хранилище. И клиент заливает и качает напрямую туда по подписанной ссылке с ограниченным сроком жизни, минуя наши приложения, потому что если ты пропустишь пятьдесят гигабайт через свой бэкенд, ты его положишь. Наш сервис только выдаёт ссылку и пишет метаданные, а раздача идёт через CDN с поддержкой range-запросов, чтобы качалка умела докачивать.

И главное, что стоит понимать про эту задачу. Интервьюеру в общем-то всё равно, что ты в итоге выбрал - торрент, свой сервер или гибрид. Ему важно, назовёшь ли ты условие, при котором выбрал бы другое. Пока ты рассуждаешь "раздача на тысячи получателей — значит P2P окупается, а тут передача один на один и получатель офлайн - значит хранилище", ты проходишь секцию. Как только не рассматриваешь другое решение при других вводных, а стоишь на одном и том же, то это сильно режет твои шансы на успешное прохождение собеса.

Подписывайтесь на канал и вступайте в чатик, товарищи, так вы не пропустите новый контент!

Подписаться: @codeof_art

C какими айтишницами стоит строить отношения, а какие - ред флаг? В новом ролике разобрал все бигтехи по фактам: Яндекс, ВК, Т-банк, Озон, Сбер. Смотрим! Смотрим! И не говорите потом, что не предупреждал!

https://www.youtube.com/shorts/d_lUVE5oo7A

System Design: backend

Как и обещал — задачка с бэковой секции Яндекса. На system design там реально дают «спроектируй ленту новостей, как в Твиттере/ВК, где новостные посты выдаются на основе подписок на авторов»: человек подписан на кучу людей, открывает приложение и видит их посты, свежие сверху. Погнали.

Базовая идея — идти от базы: на открытии ленты делаем SELECT * FROM posts WHERE author IN (на кого подписан) ORDER BY time LIMIT 50. В деве летает. Но в продовой бд так не прокатит: у юзера тысяча подписок, у каждого тысячи постов, и так одновременно долбят миллионы людей. Лента открывается на каждый заход — чтение это самый горячий путь, и вот на нём база и ляжет. Дальше обсудим, какое примерное решение от тебя ждут на собесе.

Уточняем детали
Сначала уточни границы: сколько подписок у среднего юзера, сколько постов в день, какая задержка ок. Но главный вопрос один: есть ли у нас звёзды — аккаунты на миллионы подписчиков? Звучит как продуктовая мелочь, а на деле именно он разворачивает всю архитектуру — сейчас увидишь как.

Попробуем зайти от обратного
Ключевая идея, ради которой задача и придумана: не собирай ленту в момент, когда её открыли. Собери заранее. Когда автор публикует пост, мы разносим (fan-out) его по заранее посчитанным лентам всех подписчиков — кладём в «инбокс» каждого. Тогда открыть ленту — дешёвое чтение готового списка, без тяжёлого запроса по всем подпискам. Смысл манёвра: дорогую работу мы перенесли с частого чтения на редкую запись. Пост пишут один раз, а ленту с ним открывают тысячи раз — вот пусть будет тяжело один раз на записи, а не тысячу раз на чтении.

Возвращаемся к звёздам
А теперь тот самый вопрос. Fan-out на записи прекрасен — пока блогер с 40 миллионами подписчиков не нажмёт «опубликовать». Один пост превращается в 40 миллионов записей, разом, всплеском. Одна звезда убивает всю схему. Поэтому — гибрид. Обычные аккаунты разносим по подписчикам на записи. А посты звёзд не разносим: их мало, зато подписчиков тьма. Их подтягиваем в момент чтения и подмешиваем в готовую ленту. Разложил систему на два пути ровно из-за вопроса про звёзд — это ответ уже не ниже мидла.

В целом вся задача это пример из «Designing Data-Intensive Applications» Клеппманна, первая глава там ровно про ленту Твиттера. Готовишься к систем дизайну — тогда стоит ознакомиться с этой книжкой, не пожалеешь.

Где запнуться можно
Всё вытекает из мысли «работаем на записи». Забыл — провалился. Разнос — асинхронный, через очередь. Автор нажал «опубликовать» — его запрос не ждёт, пока пост доедет до десятков тысяч лент: кинули задачу в брокер, ответили сразу, подписчики увидят через секунду. Тут ок eventual consistency — лента не банковский баланс. В инбоксы кладём не посты, а их id. Хранить полный текст в ленте у каждого из тысяч подписчиков — копия одного и того же миллион раз. Держим ссылки, сам пост подтягиваем при чтении. Не разноси мёртвым душам: если юзер не заходил полгода, гонять его ленту на каждый пост подписок — жечь ресурсы впустую. Соберём на чтении, если вернётся. И идемпотентность: разнос будет ретраиться при сбоях, один и тот же пост не должен лечь в ленту дважды.

На что нацелена задача по итогу
Проверяют этой задачей одно: видишь ли ты, где в системе на самом деле тяжело. Наивный SELECT по подпискам — «лента как страница в базе», его напишет и джун. А инженер замечает, что ленту открывают в тысячи раз чаще, чем пишут пост, и переносит всю тяжесть туда, где она случается редко — на запись. Дальше это само тянет за собой и очередь, и гибрид под звёзд, и хранение по ссылкам: весь дизайн — следствие одного решения, считать ленту заранее, а не на лету. Дожал эту мысль — секция твоя.

Подписаться: @codeof_art
Вступить в чатик: @code_of_art