Ну да, я бы сказал что эти "архитектурные собесы" уже очень шаблонными стали - даже без книжек шардирование, кэш, очереди - ключевые моменты :) Тут и затык-то больше возник не в технической а в стратегической части архитектуры. И не уверен что на моей стороне.
В создании удобного и привычного инструмента частично и кроется магия
Где удобный и привычный, а где Яндекс?
Спасибо конечно за такое пространное восхваление очевидно сломанного процесса - но заметьте, в начале есть отсылка на статью автор которой позиционирует себя как "Chief of Engineering Staff" в этом самом Яндексе - и он сам же пишет о том как все было (и осталось) плохо.
и те кто не работал в яндексе встречали в других компаниях немало выходцев из него... в общем допускаю что яндекс большой и неоднородный и где-то найдутся и задачи поинтереснее и зарплаты повыше, но ситуации 2008-2011 годов видимо не повторится, когда яндекс джуниорские зарплаты мог предлагать на которые соблазнялись бы сеньоры а в смысле задач был непочатый край идей.
я подумал раз уж написали ту статью, наверное не зря, наверное большая работа проведена. но похоже работа по большей частью написанием статьи и косметическими мелочами по существующему процессу.
да, для топа из 1000 новостей это действительно пустяк. я об этом варианте подумал вскользь, но кажется в спешке именно просто сказал себе "я же не смогу найти в куче", не додумал мысль до конца :)
интервьюера я убедил что на одной куче можно сделать (после собеседования понял что обманул его, просто очень уверенно)
Абсолютно вас понимаю :) иногда тоже посылаю. Но Яндекс стучатся буквально раз в несколько месяцев, похоже не хранят инфу о собственных неудачных попытках. Так что иногда ввязываюсь, вот как сейчас, в их собеседования - больше, наверное, для поддержания тонуса. Иногда что-то новое можно узнать. Ну и задачки порой потом для своего сайта адаптирую.
Можно просуммировать :) Суммарно кажется чуть меньше двух рабочих дней.
Но я не считаю это совсем уж "выбрасыванием в урну". Можно что-то новое узнать, в чём-то потренироваться. К сожалению повседневная работа на текущем проекте тоже часто является очень неэффективным времяпрепровождением.
Любопытно, спасибо. Но как "краткое резюме" - для "исправления и модернизации" Claude был признан автором статьи бесполезным. Некоторая польза нашлась в генерации нагрузочного клиента и вспомогательных (текстовых) материалов.
По воспоминаниям лучше всего получались собеседования (и дальнейшее сотрудничество) в случаях когда на единственном интервью присутствовал руководитель отдела (или всея компании). Конечно фильтровать по 200 человек в день так не получится... ну для этого и нужно заниматься изобретательством по поиску и завлечению подходящих кандидатов (вместо того чтобы форвардить с уровня HR пачки резюме)...
у Яндекса самого на сайте например раньше (лет 10 назад) ещё был собственный "скриннинг", и это работало с грехом пополам, но явно уже никто не поддерживал и оно было на излёте
Были у них Яндекс-Алгоритм и Интернет-Математика соревнования - в общем тоже неплохие проекты чтобы через них завлекать.
А в результате имеем что имеем - вот эти низкоквалифицированные эйчары которые пытаются "брать числом".
Эта проблема не специфична для яндекса и не связана напрямую с разрастанием - когда я работал в одной гораздо меньшей (скандинавская Gelato всего около ~300 айтишников) конторе, там процесс был похожий устроен и как со смехом часто говорили - скорее всего сами интервьюеры друг у друга интервью с вероятностью 50% не прошли бы.
Но что касается Яндекса - я упоминал что собеседовался в него в разные времена :) и я бы отметил что на него сильно повлиял 2014 год - как "экономический провал" в связи с известными событиями, так и смерть Ильи Сегаловича, по-видимому.
тут опять же не буду спорить т.к. эти соображения зависят от пары вещей:
вариант 2 ввиду амортизации неприменим на практике
это разумеется зависит от размера кэша и времени обращения к нижележащему хранилищу - если речь о кэшировании веб-страниц, условно, то флаш кэша занимающий 5мс очевидно ничтожен по сравнению с запросами в интернет занимающими в десятки и сотни раз больше; но конечно в задачах где нам нужен гарантированно быстрый отклик это действительно неудобно (впрочем в таких задачах и LRU-стратегия под вопросом - как пишет википедия, кэш в процессорах ARM вообще на рандомную стратегию переделали ради простоты и скорости - и норм)
Ну и использование итерации по мапе в качестве семплирования — не очень хорошо.
всё правильно, тут всё таки демонстрационная реализация :) к сожалению устройство и возможности мэпы конкретно в Go делают её особенно неудобной для любого "продвинутого" применения так что для реального кэша, так что в идеале нужна самодельная реализация
Спасибо за комментарий :) приятно что тема, несмотря на "туманность" действительно даёт повод повыдумывать дополнительные варианты!
Минимальное и максимальное значение храним в отдельных переменных.
Да, это вполне неплохой вариант у которого однако есть нюанс - он будет давать хорошие варианты если элементы используются более-менее равномерно.
Мы же счетчик увеличиваем как на Put-ах так и на Get-ах - и вот представим если к какому-то элементу (или нескольким, небольшому числу) внезапно возникла пиковая нагрузка - за счет него счётчик увеличится, скажем, на несколько тысяч очень быстро. И когда мы попытаемся выбрать 20% от разницы между минимумом и максимумом - то в удаляемые попадут внезапно все элементы кроме этого опрошенного тысячу раз.
Ну, это необязательно катастрофа, просто нужно иметь в виду такую возможность.
Т.е. ваш вариант это тоже некая "эвристика" имеющая право на существование :)
Значение счетчика используем по модулю равному максимальному размеру словаря.
или просто проходя кэш при операции очередного удаления уменьшаем все счетчики на фиксированную величину (например, min).
А вакансии на Perl у вас есть? :) Мне небезынтересно! текущий профиль - Go, что тоже может быть полезно...
Любопытный опыт :) а live-coding это по языку было или какая-то специальная "секция"?
Ну да, я бы сказал что эти "архитектурные собесы" уже очень шаблонными стали - даже без книжек шардирование, кэш, очереди - ключевые моменты :) Тут и затык-то больше возник не в технической а в стратегической части архитектуры. И не уверен что на моей стороне.
Где удобный и привычный, а где Яндекс?
Спасибо конечно за такое пространное восхваление очевидно сломанного процесса - но заметьте, в начале есть отсылка на статью автор которой позиционирует себя как "Chief of Engineering Staff" в этом самом Яндексе - и он сам же пишет о том как все было (и осталось) плохо.
и те кто не работал в яндексе встречали в других компаниях немало выходцев из него... в общем допускаю что яндекс большой и неоднородный и где-то найдутся и задачи поинтереснее и зарплаты повыше, но ситуации 2008-2011 годов видимо не повторится, когда яндекс джуниорские зарплаты мог предлагать на которые соблазнялись бы сеньоры а в смысле задач был непочатый край идей.
отфильтровать хоть 99% можно
я только о том что им надо учиться делать это быстро
да, получается именно так
я подумал раз уж написали ту статью, наверное не зря, наверное большая работа проведена. но похоже работа по большей частью написанием статьи и косметическими мелочами по существующему процессу.
не спорить с интервьюерами, даже если на твой взгляд они тупят :)
да, для топа из 1000 новостей это действительно пустяк. я об этом варианте подумал вскользь, но кажется в спешке именно просто сказал себе "я же не смогу найти в куче", не додумал мысль до конца :)
интервьюера я убедил что на одной куче можно сделать (после собеседования понял что обманул его, просто очень уверенно)
спасибо что поделились :) это конечно покруче чем в моём случае
видимо не очень им нужны разработчики, тем более на автономный транспорт. в китае закупают всё, от роверов до колонок
Спасибо. Вы имеете в виду хранить одну кучу для топа и другую для всего остального?
Абсолютно вас понимаю :) иногда тоже посылаю. Но Яндекс стучатся буквально раз в несколько месяцев, похоже не хранят инфу о собственных неудачных попытках. Так что иногда ввязываюсь, вот как сейчас, в их собеседования - больше, наверное, для поддержания тонуса. Иногда что-то новое можно узнать. Ну и задачки порой потом для своего сайта адаптирую.
Можно просуммировать :) Суммарно кажется чуть меньше двух рабочих дней.
Но я не считаю это совсем уж "выбрасыванием в урну". Можно что-то новое узнать, в чём-то потренироваться. К сожалению повседневная работа на текущем проекте тоже часто является очень неэффективным времяпрепровождением.
Любопытно, спасибо. Но как "краткое резюме" - для "исправления и модернизации" Claude был признан автором статьи бесполезным. Некоторая польза нашлась в генерации нагрузочного клиента и вспомогательных (текстовых) материалов.
Ну, в этом наблюдении конечно есть смысл :)
По воспоминаниям лучше всего получались собеседования (и дальнейшее сотрудничество) в случаях когда на единственном интервью присутствовал руководитель отдела (или всея компании). Конечно фильтровать по 200 человек в день так не получится... ну для этого и нужно заниматься изобретательством по поиску и завлечению подходящих кандидатов (вместо того чтобы форвардить с уровня HR пачки резюме)...
дак ведь в статье про "обновление" автор (якобы глава-рекрутинга) сам пишет как это плохо и как нужно от этого безобразия уходить... :)
да, этот функционал явно сломан
впрочем я имел в виду более хитроумные способы - не помню, упомянул ли конкретно Telegram - там процесс на этаких мини-челленджах выстроен вроде
https://www.businessinsider.com/telegram-ceo-looks-for-best-engineers-2025-10
у Яндекса самого на сайте например раньше (лет 10 назад) ещё был собственный "скриннинг", и это работало с грехом пополам, но явно уже никто не поддерживал и оно было на излёте
Были у них Яндекс-Алгоритм и Интернет-Математика соревнования - в общем тоже неплохие проекты чтобы через них завлекать.
А в результате имеем что имеем - вот эти низкоквалифицированные эйчары которые пытаются "брать числом".
Эта проблема не специфична для яндекса и не связана напрямую с разрастанием - когда я работал в одной гораздо меньшей (скандинавская Gelato всего около ~300 айтишников) конторе, там процесс был похожий устроен и как со смехом часто говорили - скорее всего сами интервьюеры друг у друга интервью с вероятностью 50% не прошли бы.
Но что касается Яндекса - я упоминал что собеседовался в него в разные времена :) и я бы отметил что на него сильно повлиял 2014 год - как "экономический провал" в связи с известными событиями, так и смерть Ильи Сегаловича, по-видимому.
тут опять же не буду спорить т.к. эти соображения зависят от пары вещей:
это разумеется зависит от размера кэша и времени обращения к нижележащему хранилищу - если речь о кэшировании веб-страниц, условно, то флаш кэша занимающий 5мс очевидно ничтожен по сравнению с запросами в интернет занимающими в десятки и сотни раз больше; но конечно в задачах где нам нужен гарантированно быстрый отклик это действительно неудобно (впрочем в таких задачах и LRU-стратегия под вопросом - как пишет википедия, кэш в процессорах ARM вообще на рандомную стратегию переделали ради простоты и скорости - и норм)
всё правильно, тут всё таки демонстрационная реализация :) к сожалению устройство и возможности мэпы конкретно в Go делают её особенно неудобной для любого "продвинутого" применения так что для реального кэша, так что в идеале нужна самодельная реализация
Спасибо за комментарий :) приятно что тема, несмотря на "туманность" действительно даёт повод повыдумывать дополнительные варианты!
Да, это вполне неплохой вариант у которого однако есть нюанс - он будет давать хорошие варианты если элементы используются более-менее равномерно.
Мы же счетчик увеличиваем как на Put-ах так и на Get-ах - и вот представим если к какому-то элементу (или нескольким, небольшому числу) внезапно возникла пиковая нагрузка - за счет него счётчик увеличится, скажем, на несколько тысяч очень быстро. И когда мы попытаемся выбрать 20% от разницы между минимумом и максимумом - то в удаляемые попадут внезапно все элементы кроме этого опрошенного тысячу раз.
Ну, это необязательно катастрофа, просто нужно иметь в виду такую возможность.
Т.е. ваш вариант это тоже некая "эвристика" имеющая право на существование :)
или просто проходя кэш при операции очередного удаления уменьшаем все счетчики на фиксированную величину (например, min).