Ну, я считаю, что моих общих знаний "а как вообще программировать" мне хватит чтобы пересесть за любой язык в разумное время (может быть, кроме функциональных), но как убедить в этом Яндекс? 😃

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

А дальше, внутри компании, расти можно только решая проблемы. И там тебе «умение программировать» уже сильно пригодится

Ну, я считаю, что моих общих знаний "а как вообще программировать" мне хватит чтобы пересесть за любой язык в разумное время (может быть, кроме функциональных), но как убедить в этом Яндекс? 😃

Да, я понимаю 😀 Жаль на работе негде это всё применить и попробовать, только в свое свободное время, а его как водится мало

В общем, мой совет проси рефер в этом чате, куча яндексойдов сидит. И го собеседоваться

У меня 1 задача выполненная на литкоде 🤣 Пока я даже не уверен что смогу ВЕРТАНУТЬ ДЕРЕВО. Может, через полгодика.

Да, за этим я здесь, спасибо!

Курс козули растёт 😃

Он ща работу ищет, так что пока что 0

О, скорость выгорания теперь в козулях измеряется, наконец то стандартизация

только козуля в дс сидит

В дс?

дефолт сити

в сбере вполне 😄

он уже был там, и у него уже опрос был, стоит ли идти опять в сбер))

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

А что с козулей то не так?)

А что с козулей то не так?)

Отлично! Бот не просит капчу у тех, кто пишет комменты!

Ты всё продолжаешь тестировать? 😃

Привет, подскажите, пожалуйста, при решении задачки на собесе стоит спрашивать нравится ли им мое решение и есть ли замечания или и так скажут если, что не так?

Еще может быть проблема, что сам собеседующий может не понять твоего решения, если ты ему объяснишь сразу что он сразу поймёт, это плюс огромный. Если через 5 минут поймёт, то это не плохо. Если вообще не поймёт и будет разбирать после собеса, тут уже 50% найм не найм

Всем привет! Скоро начинаем стрим, сегодня будем сериализовывать туда и обратно бинарные деревья. Подключайтесь! https://www.youtube.com/watch?v=nRBYVoWvPGc

Нормальная обложка!

Привет, подскажите, пожалуйста, при решении задачки на собесе стоит спрашивать нравится ли им мое решение и есть ли замечания или и так скажут если, что не так?

в сбере вполне 😄

А в сбере прям на руки такие зп ? Я думал там с учетом премий средняя за год такая получается

Зачем нужна секция «дизайн систем»? Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме. На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования. Чтобы не было такого, что сеть у нас всегда 100% надежная, latency не существует, а все зависимости (на самом деле написанные на коленке) работают как часы. Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил. Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет. То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет? Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными. И так далее, с интервьюером продолжаешь раскапывать задачу до дна.

Зачем нужна секция «дизайн систем»? Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме. На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования. Чтобы не было такого, что сеть у нас всегда 100% надежная, latency не существует, а все зависимости (на самом деле написанные на коленке) работают как часы. Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил. Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет. То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет? Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными. И так далее, с интервьюером продолжаешь раскапывать задачу до дна.

“сферических конец в вакууме” - страшно такое представить, особенно перед сном

ахаха, автозамена подвёла меня 😂

А посоветуйте, что почитать нубу про system design? Я знаю только репозиторий https://github.com/donnemartin/system-design-primer

Конечно, должно быть “сферический”

Кабанчика

Это про design data intensive application?

Зачем нужна секция «дизайн систем»? Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме. На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования. Чтобы не было такого, что сеть у нас всегда 100% надежная, latency не существует, а все зависимости (на самом деле написанные на коленке) работают как часы. Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил. Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет. То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет? Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными. И так далее, с интервьюером продолжаешь раскапывать задачу до дна.

А посоветуйте, что почитать нубу про system design? Я знаю только репозиторий https://github.com/donnemartin/system-design-primer

Зачем нужна секция «дизайн систем»? Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме. На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования. Чтобы не было такого, что сеть у нас всегда 100% надежная, latency не существует, а все зависимости (на самом деле написанные на коленке) работают как часы. Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил. Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет. То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет? Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными. И так далее, с интервьюером продолжаешь раскапывать задачу до дна.

можно ещё вот это https://vitkarpov.me/tags/system-design/ , но там по мелочи конечно я написал

Рекрутеры совсем

Зачем нужна секция «дизайн систем»? Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме. На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования. Чтобы не было такого, что сеть у нас всегда 100% надежная, latency не существует, а все зависимости (на самом деле написанные на коленке) работают как часы. Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил. Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет. То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет? Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными. И так далее, с интервьюером продолжаешь раскапывать задачу до дна.

А посоветуйте, что почитать нубу про system design? Я знаю только репозиторий https://github.com/donnemartin/system-design-primer

Зачем нужна секция «дизайн систем»? Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме. На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования. Чтобы не было такого, что сеть у нас всегда 100% надежная, latency не существует, а все зависимости (на самом деле написанные на коленке) работают как часы. Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил. Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет. То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет? Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными. И так далее, с интервьюером продолжаешь раскапывать задачу до дна.

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

это печаль.

Зачем нужна секция «дизайн систем»? Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме. На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования. Чтобы не было такого, что сеть у нас всегда 100% надежная, latency не существует, а все зависимости (на самом деле написанные на коленке) работают как часы. Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил. Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет. То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет? Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными. И так далее, с интервьюером продолжаешь раскапывать задачу до дна.

Кстати вопрос очень интересный, кабанчика читать лучше в оригинале, чтобы уметь оперировать терминами?

Зачем нужна секция «дизайн систем»? Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме. На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования. Чтобы не было такого, что сеть у нас всегда 100% надежная, latency не существует, а все зависимости (на самом деле написанные на коленке) работают как часы. Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил. Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет. То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет? Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными. И так далее, с интервьюером продолжаешь раскапывать задачу до дна.

решил купить электронную версию кабанчика. 35баксов для киндла, причем похоже не в нативном формате. обидненько.

Зачем нужна секция «дизайн систем»? Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме. На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования. Чтобы не было такого, что сеть у нас всегда 100% надежная, latency не существует, а все зависимости (на самом деле написанные на коленке) работают как часы. Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил. Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет. То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет? Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными. И так далее, с интервьюером продолжаешь раскапывать задачу до дна.

Зачем нужна секция «дизайн систем»? Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме. На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования. Чтобы не было такого, что сеть у нас всегда 100% надежная, latency не существует, а все зависимости (на самом деле написанные на коленке) работают как часы. Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил. Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет. То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет? Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными. И так далее, с интервьюером продолжаешь раскапывать задачу до дна.