Хотелось бы поделиться своим мнением по System Design и собеседовании.
Если вы не трогали и не погоняли как следует на тех или иных технологиях (Redis, Kafka, конкретный CDN, конкретные движки БД etc.) то вам скорее всего не пройти System Design Interview. Пройти какой-нибудь курс и прочитать пару книг и статей не достаточно. На практике нужно не просто знать какую задачу решает та или иная технология плюсы и минусы, а довольно хорошо разбираться в деталях и знать конкретные показетели производительности. Где, сколько и что можно сделать, и на каком оборудовании. При этом я лично считаю, что это не значит, что вы не сможете вытянуть нормальную архитектуру в боевых условиях. Т.е. не очень понятно как это помогает собеседующему выбрать более ценного кандидата. Это интервью сравнимо с решением задачек с leetcode.
На практике не так уж и много проектов, где, во-первых, это всё надо, а, во-вторых, ещё и сразу. Большинство не стартует что-то для миллионов пользователей или какой-то невероятной нагрузки, ни в уже существующем проекте, ни в новом. Всё вводится постепенно. При этом сначала бизнес ещё не знает, что именно ценно и нужно. Закинув сразу кучу технологий вы только добавите себе же работы по отладке, поддержке всяких проблемных случаев в архитектуре и логике, переделыванию, тестированию и дальнейшей поддержке. Даже просто запустите только через пол года первую бета версию, вместо того, чтобы что-то запустить через месяц, и потом ещё одну две версии в продакшене.
В тех же случаях, где реально надо сразу на миллионы, просто возьмут проверенных людей с других похожих проектов или вообще сами проекты перепрофилируют. Никто не будет собеседовать в духе https://github.com/donnemartin/system-design-primer.
Уверен, что WhatsApp, YouTube, Dropbox etc уже больше чем два раза переосмыслили и переписали места, которые реально требовали внимания. При этом спокойно могут работать на одном или паре инстансов того, что большинство будет пытаться "масштабировать" во время интервью. Они, конечно, могут написать об этом в блогах и рассказать на конференциях, но совсем не факт, что у вас будут те же самые проблемы, особенно в начале.
Но со временем я понял одну простую вещь: автоматика не должна быть заметной. Она не должна напоминать о себе, не должна требовать внимания, и тем более — не должна раздражать.
Золотые слова. Когда же производители всей бытовой техники дойдут до этого?
Приятно почитать такие истории. Молодцы. Есть, конечно, вопросы, типа зачем там kubernetes, но все эти детали просто меркнут с
А люди, как вы помните, стремятся минимизировать свою рабочую нагрузку. И есть искушение загнать одну пару на стенд, а потом проверять её несколько раз подряд, просто вручную забивая в систему новые номера. Старые типы стендов позволяют хитрить подобным образом, новые распознают подлог, но и здесь голь на выдумки хитра, операторы, подвешивая магниты и прочие не имеющие отношения к КП предметы, могут повлиять на данные диагностики
Что здесь вообще происходит, зачем и почему, в чем вообще смысл так себя вести, что потом с этими работниками стало? Это же не может быть какая-то глупость, звучит как какая-то диверсия.
Круто. Кстати, расскажите, пожалуйста, в деталях про thread safety, как какой поток/файл с какими параметрами открывается и как организована работа с ними. Например, приложение пишет одновременно в stdout и stderr, что будет при разных редиректах и почему.
Сроки - это стоимость. Вопрос в том, сколько будет стоить фича или можно это время потратить более продуктивно.
Решение: в общем случае договариваемся фиксированном времени (time box) на попытку или более точную оценку. А дальше смотрим. Говоришь, что попробую за день, получится быстрее приду и скажу, не получится, то к вечеру будет понятно почему, что изменилось, в зависимости от этого можно будет как-то оценить время, день, неделя, и т.п.
Да им надо наоборот возглавить. Не тратить время на интервью, hr и первые два тура должен проводить ИИ. Всё равно смысла в этих турах нет, только трата времени, особенно кандидатов.
Речь идёт о замене кабелей для передачи данных между серверами и составами. Стареющие хрупкие кабели представляют ещё большую проблему, чем дискеты.
Hitachi начнёт замену кабелей на новую систему связи, которая будет использовать Wi-Fi и сотовую связь для отслеживания поездов.
Ждём новости через 25 лет, что технологии устарели, но никак не могут заменить. Помехи в радиоэфире, такого Wi-Fi уже нет, переезжаем на хрупкие провода)))
Вот в Германии как раз 2g станции выключают, но не могут поскольку IoT (электросчетчики, сигнализации и т.п.) теперь надо скорее всего полностью менять, потому что уже никто не будет разбираться, как там GSM модем заменить.
In versions of Visual Studio before Visual Studio 2022 version 17.0, the maximum length of a string literal is 65,535 bytes. This limit applies to both narrow string literals and wide string literals. In Visual Studio 2022 version 17.0 and later, this restriction is lifted and string length is limited by available resources.
Вообще-то ЗП в большинстве случаев намного меньше, и всё очень сильно зависит от города и компании. Конечно, может в Гугле в Мюнхене, а ещё лучше в Цюрихе, вам могут "отвалить" астрономическую сумму, а в Берлине - спокойно в 2 раза меньше. В остальных городах где-то посередине.
Для общей картины glassdoor и stepstone в помощь. IT-шники частенько зарабатывают хорошо, но в целом разница по сравнению с другими профессиями не очень большая. За услуги придется платить столько же в час сколько у вас ЗП до налогов. Но там ещё хорошо насчитают помимо часов.
В Москве, скорее всего, действительно существенно намного выгоднее.
> Если у вас ПМы гробят разработку из за незнания и непонимания тех деталей означает, что у вас ПЛОХО организовано руководство и неправильная культура в компании.
Полностью согласен! К счастью, у «нас» такого нет, но все приведённое выше к сожалению живые примеры…
Крутая статья, и я рад, что у вас всё работает, но у меня впечатление, что всё определяется адекватностью и квалифицированностью конкретной группы людей, а структура просто подходит для этой конкретной группы. У вас это продуктовые менеджеры, а в другом месте это будут тимлиды, техлиды, кто-то вообще скажет QA или dev-ops и т.п.
Выше уже указывали на нестыковки, но все таки, если с тимлидами понятно, то что случилось с сеньорами и техлидами (в софтверных компаниях), которые упоминаются в тексте и на картинках? А что с архитекторами?
Что-то очень сомнительно, что крутые разработчики находят это лучше. Нет тайтла — нет причин платить им зарплату как тех лидам. Если у вас действительно так, то хорошо, но скорее всего в других местах все будут получать как middle или junior. Если у людей нет возможности роста у вас, то сначала будет демотивация, выгорание и т.п., что вредит всем, а потом они найдут рост сразу в ЗП и тайтле в другом месте.
> команда состоящая не из руководителей и подчинённых
В такой структуре скорее всего продакт менеджеры либо явные, либо неявные руководители. И тут можно почти без изменений переписать «Реальность: проблемы в работе продакт менеджера» и далее по тексту.
К примеру откуда возьмётся «доверие» со стороны технических людей, если ПМы гробят разработку, потому что они не только не знают техническую сторону предметной области, но и с другой планеты, где нет архитектуры, тестов, систем сборок, репозиториев, и т.д. Плюс добавим проблему коммуникации ПМ: " ПМ видит всю картину, а задача какого-то там разработчика закрывать таски".
«Пассивный контроль» — ПМ рассуждает так: «что-то метрики в джире слабоватые, и мои фичи медленно делаются. Нужно узнать, где проблема, а давайте ка соберем метрик побольше». Результат недоверие со стороны ПМ. В итоге недоверие обоих сторон и микроменеджмент.
«Независимость» — с ростом числа людей появляется политика, и конец независимости может прилететь откуда угодно.
Очень интересно! Календарь, конечно, лучше.
Оффтопик:
если перенести daily на 14:30, то у вас будет дольше блок времени в первую половину дня, что позволит работать над новыми категориями задач с утра, при этом не сильно пострадает «после обеда»
что означает «начало работы»
что думают о вашем календаре ваши коллеги и ваш начальник?
Возможно просто минимизируют attack surface.
К примеру, утёкший пароль даёт доступ сразу ко всему, а для каждого token'а, надаюсь можно ограничить доступ только к определённым данным и операциям.
Так же подозреваю, что многие использовали пароль везде, где можно, а теперь github подталкивает к использованию разных token'ов для каждого места. В итоге, если в одном месте что-то пошло не так, то не надо менять пароль (стоит ли все равно обновить все token'ы?..), а так же, надеюсь, что можно будет отследить все операции для конкретного token и выяснить, где дыра.
Ответ: первый шаг — покажете ваш personal development plan. А вообще по ссылке около странной формулировки о 34% все есть. Не поленюсь и тезисно сюда продублирую
обсудите с подчиненными развитие их карьеры, помогите разработать план. От себя добавлю, что как руководитель так же сделайте это возможным
создайте и развивайте культуру изучения нового. С точки срезния сотрудника, особенно ценными будут знания, которые помогут его карьере и вообще росту и развитию во всех направлениях
развивайте соих менеджеров. От себя в пользу этого пункта порекомендую почитать статьи, что люди уходят не с работы или из компании, а от менеджеров. Еще добавил бы, что можно и нанять. Почему-то все слышали байки про индийских программистов и их код, но не часто услышишь подобное про каких-то неадекватных и крайне непрофессиональных менеджеров, а ситуация в точности такая же
diversity and inclusion (не знаю как перевести :D) От себя добавлю, что на практике это не только и не столько про всяких маргиналов и меньшиства. Ни разу не видел такое на практике. Зато полно людей со стереотипами на базе национальных признаков, количества лет в какой-то опреденной компании, знакомства с кем-то, и прочая чушь. Сделате так, чтобы все были равны, вовлечены, и их мнения аргументированно и справедливо учитывались, и все будет ОК
Далее по ссылке в еще более вольной интерпретации
найдите людей, которые будут вдохновлять ваших сотрудников и коллег. Если бюджет позволяет то пригласите извне пообщаться (у меня был такой опыт, и мне этот подход кажется сомнительным), если нет — то дайте возможность обучиться у самого лучшего профессионала, который сейчас у вас работает
сделайте так, чтобы сотрудник поработал над чем-нибудь интересным для не-ё/-го
дайте возможность «рядовым» сотрудникам общаться с высшим руководством, чтобы сотрудники могли спокойно поделиться своими мыслями и переживаниями, и проникнуться целями компании, и как важен их отдел :D
Хочу поделиться небольшим опытом использования LOUDS в задаче нахождения всех строк из заранее заданного набора как подстрок входной строки. Т.е. к примеру, есть 100 000 небольших (3-50 символов) строк-фильтров, их надо компактно хранить и уметь быстро найти все такие строки, которые являются подстрокой тестируемой.
LOUDS действительно сильно помогает даже с накладными расходами, о которых через предложение. К примеру, реализация double array trie потребляла бы раз в 5 больше памяти. На самом деле я использовал Aho–Corasick. Для этого в trie параллельно с массивом битов использовал массивы для хранения данных. К примеру, по тем же смещениям, что и rank1 (c небольшой корректировкой), в еще одном массиве лежат символы (8 bits, типа ASCII (К сожалению, я дальше не исследовал, но мне кажется, что тут можно сделать поддержку UTF-8 с довольно приличными характеристиками, когда в других реализация размер алфавита довольно ограничен.)), а так же в еще одном массиве битов информация о том, является ли данный символ концом какой-либо строки.
Такой же трюк для структуры Aho–Corasick, суффиксные и конечные ссылки (терминология из вики) так же хранятся в массивах, плюс битовые массивы для индикации есть ли у этого узла соответствующая ссылка.
Как можно заметить коэффициент у О-большое уже не такой уж и маленький, как в статье.
Может легко оказаться, что если найти разумный подход с N-граммами, то выгоднее хранить извлеченные подстроки из строк словаря в хеш-таблице, а сами строки отдельно.
В любом случае придется анализировать природу данных и подкручивать тут и там.
Скорость работы при этом может оказаться сравнима, ну или, к примеру, достаточной для текущей бизнес задачи. Кстати, все упирается в select, где в моем случае скорее О(log(N)) (rank9 + бинарный поиск блока), чем O(log(log(N)), SIMD пока не использовали. Кстати, в случае с N-граммами можно относительно легко и дешево модифицировать сам словарь со строками.
К сожалению у меня не было возможности копать дальше, если у кого-то есть опыт, то было бы интересно услышать.
Сколько у вас обычно раундов комментирования в одном код-ревью?
Мы продолжаем отслеживать процесс код-ревью и решать все технические и даже психологические проблемы
Вот на последнем пункте можно поподробнее? К примеру, что вы делаете, когда люди завалены демотивирующими код-ревью? Демотивируют, потому что код, мягко говоря, «пахнет», а автор сопротивляется исправлять.
Как на счет изменения масштаба, смещения (сдвиг) и, возможно, поворота холста?
В онлайн редакторе не помешали бы всплывающие названия контролов, когда курсор над ними.
Хотелось бы поделиться своим мнением по System Design и собеседовании.
Если вы не трогали и не погоняли как следует на тех или иных технологиях (Redis, Kafka, конкретный CDN, конкретные движки БД etc.) то вам скорее всего не пройти System Design Interview. Пройти какой-нибудь курс и прочитать пару книг и статей не достаточно. На практике нужно не просто знать какую задачу решает та или иная технология плюсы и минусы, а довольно хорошо разбираться в деталях и знать конкретные показетели производительности. Где, сколько и что можно сделать, и на каком оборудовании. При этом я лично считаю, что это не значит, что вы не сможете вытянуть нормальную архитектуру в боевых условиях. Т.е. не очень понятно как это помогает собеседующему выбрать более ценного кандидата. Это интервью сравнимо с решением задачек с leetcode.
На практике не так уж и много проектов, где, во-первых, это всё надо, а, во-вторых, ещё и сразу. Большинство не стартует что-то для миллионов пользователей или какой-то невероятной нагрузки, ни в уже существующем проекте, ни в новом. Всё вводится постепенно. При этом сначала бизнес ещё не знает, что именно ценно и нужно. Закинув сразу кучу технологий вы только добавите себе же работы по отладке, поддержке всяких проблемных случаев в архитектуре и логике, переделыванию, тестированию и дальнейшей поддержке. Даже просто запустите только через пол года первую бета версию, вместо того, чтобы что-то запустить через месяц, и потом ещё одну две версии в продакшене.
В тех же случаях, где реально надо сразу на миллионы, просто возьмут проверенных людей с других похожих проектов или вообще сами проекты перепрофилируют. Никто не будет собеседовать в духе https://github.com/donnemartin/system-design-primer.
Уверен, что WhatsApp, YouTube, Dropbox etc уже больше чем два раза переосмыслили и переписали места, которые реально требовали внимания. При этом спокойно могут работать на одном или паре инстансов того, что большинство будет пытаться "масштабировать" во время интервью. Они, конечно, могут написать об этом в блогах и рассказать на конференциях, но совсем не факт, что у вас будут те же самые проблемы, особенно в начале.
Золотые слова. Когда же производители всей бытовой техники дойдут до этого?
Приятно почитать такие истории. Молодцы. Есть, конечно, вопросы, типа зачем там kubernetes, но все эти детали просто меркнут с
Что здесь вообще происходит, зачем и почему, в чем вообще смысл так себя вести, что потом с этими работниками стало? Это же не может быть какая-то глупость, звучит как какая-то диверсия.
Круто. Кстати, расскажите, пожалуйста, в деталях про thread safety, как какой поток/файл с какими параметрами открывается и как организована работа с ними. Например, приложение пишет одновременно в stdout и stderr, что будет при разных редиректах и почему.
Сроки - это стоимость. Вопрос в том, сколько будет стоить фича или можно это время потратить более продуктивно.
Решение: в общем случае договариваемся фиксированном времени (time box) на попытку или более точную оценку. А дальше смотрим. Говоришь, что попробую за день, получится быстрее приду и скажу, не получится, то к вечеру будет понятно почему, что изменилось, в зависимости от этого можно будет как-то оценить время, день, неделя, и т.п.
Да им надо наоборот возглавить. Не тратить время на интервью, hr и первые два тура должен проводить ИИ. Всё равно смысла в этих турах нет, только трата времени, особенно кандидатов.
<трольфэйс>
Все уже в целом готово (возможно, что придётся подложить пару своих патчей)
https://github.com/microsoft/vcpkg/tree/master/ports/openssl
Ждём новости через 25 лет, что технологии устарели, но никак не могут заменить. Помехи в радиоэфире, такого Wi-Fi уже нет, переезжаем на хрупкие провода)))
Вот в Германии как раз 2g станции выключают, но не могут поскольку IoT (электросчетчики, сигнализации и т.п.) теперь надо скорее всего полностью менять, потому что уже никто не будет разбираться, как там GSM модем заменить.
Вроде, тут нет проблем, объект будет удалён, когда закончится scope для __range.Невнимательно посмотрел, действительно баг.
Просто поделюсь хорошей новостью по поводу #embed, наконец-то в Visual C++ убрали ограничение на длину строки, правда пока все обновятся... https://learn.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#size-of-string-literals
И на всякий случай https://learn.microsoft.com/en-us/cpp/c-language/maximum-string-length?view=msvc-170
Вообще-то ЗП в большинстве случаев намного меньше, и всё очень сильно зависит от города и компании. Конечно, может в Гугле в Мюнхене, а ещё лучше в Цюрихе, вам могут "отвалить" астрономическую сумму, а в Берлине - спокойно в 2 раза меньше. В остальных городах где-то посередине.
Для общей картины glassdoor и stepstone в помощь. IT-шники частенько зарабатывают хорошо, но в целом разница по сравнению с другими профессиями не очень большая. За услуги придется платить столько же в час сколько у вас ЗП до налогов. Но там ещё хорошо насчитают помимо часов.
В Москве, скорее всего, действительно существенно намного выгоднее.
Полностью согласен! К счастью, у «нас» такого нет, но все приведённое выше к сожалению живые примеры…
Выше уже указывали на нестыковки, но все таки, если с тимлидами понятно, то что случилось с сеньорами и техлидами (в софтверных компаниях), которые упоминаются в тексте и на картинках? А что с архитекторами?
Что-то очень сомнительно, что крутые разработчики находят это лучше. Нет тайтла — нет причин платить им зарплату как тех лидам. Если у вас действительно так, то хорошо, но скорее всего в других местах все будут получать как middle или junior. Если у людей нет возможности роста у вас, то сначала будет демотивация, выгорание и т.п., что вредит всем, а потом они найдут рост сразу в ЗП и тайтле в другом месте.
> команда состоящая не из руководителей и подчинённых
В такой структуре скорее всего продакт менеджеры либо явные, либо неявные руководители. И тут можно почти без изменений переписать «Реальность: проблемы в работе продакт менеджера» и далее по тексту.
К примеру откуда возьмётся «доверие» со стороны технических людей, если ПМы гробят разработку, потому что они не только не знают техническую сторону предметной области, но и с другой планеты, где нет архитектуры, тестов, систем сборок, репозиториев, и т.д. Плюс добавим проблему коммуникации ПМ: " ПМ видит всю картину, а задача какого-то там разработчика закрывать таски".
«Пассивный контроль» — ПМ рассуждает так: «что-то метрики в джире слабоватые, и мои фичи медленно делаются. Нужно узнать, где проблема, а давайте ка соберем метрик побольше». Результат недоверие со стороны ПМ. В итоге недоверие обоих сторон и микроменеджмент.
«Независимость» — с ростом числа людей появляется политика, и конец независимости может прилететь откуда угодно.
Оффтопик:
К примеру, утёкший пароль даёт доступ сразу ко всему, а для каждого token'а, надаюсь можно ограничить доступ только к определённым данным и операциям.
Так же подозреваю, что многие использовали пароль везде, где можно, а теперь github подталкивает к использованию разных token'ов для каждого места. В итоге, если в одном месте что-то пошло не так, то не надо менять пароль (стоит ли все равно обновить все token'ы?..), а так же, надеюсь, что можно будет отследить все операции для конкретного token и выяснить, где дыра.
Далее по ссылке в еще более вольной интерпретации
- найдите людей, которые будут вдохновлять ваших сотрудников и коллег. Если бюджет позволяет то пригласите извне пообщаться (у меня был такой опыт, и мне этот подход кажется сомнительным), если нет — то дайте возможность обучиться у самого лучшего профессионала, который сейчас у вас работает
- сделайте так, чтобы сотрудник поработал над чем-нибудь интересным для не-ё/-го
- дайте возможность «рядовым» сотрудникам общаться с высшим руководством, чтобы сотрудники могли спокойно поделиться своими мыслями и переживаниями, и проникнуться целями компании, и как важен их отдел :D
- тимбилдинг и fun at work, только не из-под палки
и т.д.LOUDS действительно сильно помогает даже с накладными расходами, о которых через предложение. К примеру, реализация double array trie потребляла бы раз в 5 больше памяти. На самом деле я использовал Aho–Corasick. Для этого в trie параллельно с массивом битов использовал массивы для хранения данных. К примеру, по тем же смещениям, что и rank1 (c небольшой корректировкой), в еще одном массиве лежат символы (8 bits, типа ASCII (К сожалению, я дальше не исследовал, но мне кажется, что тут можно сделать поддержку UTF-8 с довольно приличными характеристиками, когда в других реализация размер алфавита довольно ограничен.)), а так же в еще одном массиве битов информация о том, является ли данный символ концом какой-либо строки.
Такой же трюк для структуры Aho–Corasick, суффиксные и конечные ссылки (терминология из вики) так же хранятся в массивах, плюс битовые массивы для индикации есть ли у этого узла соответствующая ссылка.
Как можно заметить коэффициент у О-большое уже не такой уж и маленький, как в статье.
Может легко оказаться, что если найти разумный подход с N-граммами, то выгоднее хранить извлеченные подстроки из строк словаря в хеш-таблице, а сами строки отдельно.
В любом случае придется анализировать природу данных и подкручивать тут и там.
Скорость работы при этом может оказаться сравнима, ну или, к примеру, достаточной для текущей бизнес задачи. Кстати, все упирается в select, где в моем случае скорее О(log(N)) (rank9 + бинарный поиск блока), чем O(log(log(N)), SIMD пока не использовали. Кстати, в случае с N-граммами можно относительно легко и дешево модифицировать сам словарь со строками.
К сожалению у меня не было возможности копать дальше, если у кого-то есть опыт, то было бы интересно услышать.
PS. спасибо за статью!
Вот на последнем пункте можно поподробнее? К примеру, что вы делаете, когда люди завалены демотивирующими код-ревью? Демотивируют, потому что код, мягко говоря, «пахнет», а автор сопротивляется исправлять.
В онлайн редакторе не помешали бы всплывающие названия контролов, когда курсор над ними.