Может кому-то это будет интересно, даст возможность лучше подготовиться; или наоборот кто-то примет решение не участвовать.

Коротко о себе: 41 год, senior software developer, стаж > 20 лет. Однако, как я понял, эти собесы все равно для всех одинаковые, так чтоб все написанное актуально и для молодежи.

Итак, угораздило меня согласиться на т. н. «Weekend Offer на позицию разработчика на Kotlin». Вообще‑то мне больше нравится Scala, и опыта по ней гораздо больше, но рекрутерша была сильно настойчива, и я решил обновить экспиренс, а возможно, и прибавку в деньгах. И вот что было дальше.

Большинство списков вопросов интервью по Spring Boot заставляют вас запоминать случайные детали из документации Spring Boot. Но запоминание — плохая замена истинному пониманию и уверенности в знании Spring Boot.

Поэтому сегодня мы собираемся применить другой подход. Вместо того, чтобы перечислять 50 вопросов по мелочам Spring Boot, мы сосредоточимся на 11, которые заставят вас задуматься и, таким образом, многому научиться на этом пути.
Вот они, в произвольном порядке.

Примечание: если вы сами проводите интервью по Spring Boot, возможно, вы захотите задать эти вопросы в открытом формате, ведущем к обсуждениям вместо того, чтобы ожидать ответов из учебников.

Этот небольшой список вопросов даст вам понимание самых важных концепций Spring, а так же поможет подготовится к собеседованию

Моя история проста как три копейки. В конце 2010-х, работая Java-разработчиком в Москве, я невольно попал под влияние голосов, утверждавших, что пора валить, что на Западе сытнее, спится слаще, солнце ярче и трава зеленее. В начале 2020-го я начал учить английский и к началу 2022-го имел все что нужно для переезда. Штаты и Канада меня не особо манили, юг Европы слишком жаркое для меня место, так что я искал на севере Европы и в Германии.

То, что в конечном итоге я оказался именно в Финляндии — чистая случайность. Мы переехали с женой и ребенком начального школьного возраста три года назад. За это время накопилось немало опыта, которым я сегодня поделюсь — как есть, без приукрашиваний, иллюзий и прочих розовых единорогов.

Александр Кушнарев работал на Kaspersky и «Яндекс» в России, а потом устроился в Wargaming на Кипре. За два года собрал много интересных наблюдений, которыми поделился с нами.

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

Написание собственного стека TCP/IP поначалу может показаться пугающей задачей. И в самом деле, за свой тридцатилетний срок жизни TCP впитал в себя множество спецификаций. Однако базовая спецификация остаётся относительно компактной1 — из важных частей в ней можно выделить парсинг заголовков TCP, машину состояний, отслеживание перегрузок и вычисление таймаута повторной передачи.

Самые распространённые протоколы слоя 2 и слоя 3, Ethernet и IP, скромны по сравнению с сложностью TCP. В этой серии статей мы реализуем минимальный стек TCP/IP пользовательского пространства для Linux.

Посты и код служат исключительно в образовательных целях, они позволят вам глубже изучить сетевое и системное программирование.

Когда-то я пытался завести ютуб канал и стать знаменитым, но оказалось что для этого нужна харизма, чувство юмора и четкая дикция, а не то что у меня.

Но все же мне удалось нафармить 3,5к подписчиков мучительными душными видео, которые совершенно не понятно зачем терпели мои зрители

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

Хотелось бы прокомментировать публикацию Ильи Кабанова в Медузе по поводу новых разработок в алгоритмах хеширования: "Optimal Bounds for Open Addressing Without Reordering" (Farach-Colton, Krapivin, and Kuszmaul, 2025) и последующую "The Bathroom Model: A Realistic Approach to Hash Table Algorithm Optimization" (Wang, 2025). И особенно кликбейтное: "в перспективе метод Крапивина и его коллег может ускорить многие процессы в интернете."

Я около 7 лет очень плотно занимался темой хеш-таблиц и написал много их вариантов: Koloboke, SmoothieMap, memory-mapped вариации.

Я потерял к теме интерес с выходом гугловской SwissTable (2018), и ее фейсбучного варианта F14, которые основаны на SIMD. Они проверяют загруженность ячеек и совпадения "тега" элемента сразу блоками по 8 соседних слотов. Поэтому на любых разумных загрузках таблиц (до 90%) - "цепочка проверки" очень редко превышает 1 (то есть, одну проверку 8-элементного блока).

В этих SIMD-based алгоритмах, ухищрения и теоретические по поводу "алгоритма шагания" просто не играют никакой роли -- алгоритм шагания можно сказать отсутствует, потому что если можно вставить элемент внутри 8-элементного блока, то это и стоит сделать.

Именно эти разработки, а не Крут и не статья Yao, которую "опровергли" новые работы, стали "практическим концом теории" хеш-таблиц, на мой взгляд.

SwissTable стали стандартным алгоритмом хеш-таблиц в Расте, и, буквально в этом месяце, в Golang 1.24.

В заключение, отвечая Илье Кабанову: к "ускорению интернета" эти теоретические алгоритмы не приведут :)

Сегодня я расскажу о стороннем приложении Apple Devices, но лишь потому, что оно проверяет версию ОС Windows и категорически не устанавливается в Windows 10 LTSC или IoT LTSC. Ну и, конечно, расскажу, как его победить.

Данная статься не пропагандирует ни техники или продуктов Apple, ни замену устаревшего комбайна iTunes отдельными приложениями Apple, ни (упаси бог мне такое вам предлагать) использование продуктов Apple на Windows вместо Mac. Однако…

Еще полгода назад на Windows, наконец, появились приложения Apple Devices (Устройства Apple), Apple Music и Apple TV. На Mac они давно заменили мультимедиа комбайн iTunes, который стал неповоротлив, а для Windows несколько припозднились. Без комментариев. Причем, Apple выпуская новые приложения установила крайне непонятное требование, сборка ОС не ниже чем 19045 (в терминологии Microsoft, это Windows 10 22H2, смотри мою статью Все о версиях Windows 10 и как максимально продлить поддержку своей ОС / Хабр (habr.com)). Что крайне печально, так то, что версия долгосрочной ветви обслуживания Windows 10 Enterprise LTSC и Windows 10 IoT Enterprise LTSC максимально имеют версию 19044 (21H2) и, соответственно, установка на них приложения Apple Devices заблокирована. Рассмотрим же, как это починить. Кстати, этот же метод позволяет ставить современный Adobe Photoshop на LTSC издания, – он также проверяет именно версию ОС.

Я уже рассказывал в упомянутой выше статье, что те, кто хотят оставаться на Windows 10, наверняка должны задуматься именно об издании IoT Enterprise LTSC, так как оно одно будет поддерживаться и получать обновления аж до 13.01.2032. Обычные Профессиональные и Корпоративные издания «стухнут» уже через год – до 12.01.2025, а Enterprise LTSC будет получать свои обновления до 12.01.2027. Стало быть, разумный пользователь Windows 10 перешел на издание IoT Enterprise LTSC: кстати, и для Windows 11 это наилучшее издание, всем рекомендую почитать статью Windows 11 24H2 IoT Enterprise LTSC – что за зверь, и чем он хорош? / Хабр (habr.com). Впрочем, сегодня я анонсировал немного другую тему.

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

Дисклеймер: я не врач и не даю здесь рекомендаций. Названия лекарств привожу не для рекламы, а потому, что мне их выписывал доктор. Основная часть данных получена из личного опыта, консультаций с четырьмя докторами, медицинской литературы и ChatGPT 4o. Лично мои мнения помечены как «думаю, что...».

Итак, что произошло

Десятого декабря у меня был юбилей. Через три дня, в пятницу 13-го (я не верю в приметы) пошли с коллегами в ресторан отмечать событие. Было хорошее настроение и хороший коньяк. Через два часа захотелось в туалет. Струя оказалась тоненькой. Через 15 минут пошел еще раз – она стала еще тоньше, а в очередной поход через еще 15 минут исчезла вовсе. Я подумал, что пора прекращать пить и надо идти домой, ждать когда алкоголь выйдет из крови. Но дома лучше не стало, хотя отрезвел полностью. Я не спал  всю ночь, искал решение в интернете и пробовал что-нибудь сделать – ничто не помогало. Утром в девять я был в больнице, в очереди к урологу. Было уже страшно, что лопнет мочевой пузырь или откажут почки. Когда вошел в кабинет доктора, не смог даже самостоятельно лечь на кушетку из-за резкой боли внизу живота. Доктор быстро вставил мне катетер в уретру и я наконец понял, что такое настоящее счастье, когда услышал звук бурного потока мочи в рядом стоящий тазик.

Я хочу, чтобы вы задали себе один вопрос и честно на него ответили. Когда в последний раз вы получали настоящее удовольствие от программирования? Оглядываясь назад, я понимаю, что не испытывал подобных ощущений, наверное… уже лет десять. Удовольствия у меня не было ни от JavaScript, ни от Python, ни от Ruby или C — ни от чего. Когда я говорю «удовольствие» — я имею в виду ощущения человека, которого во время работы над неким проектом переполняет искренний восторг. Этот человек постоянно ловит себя на такой мысли: «Ох, ну какая ж круть. Поверить не могу, что моя безумная идея и правда сработала!».

Например, я писал маленькую игру-«рогалик». У меня была такая идея: «Готов поспорить, что у меня получиться воспользоваться этим вашим алгоритмом Дейкстры для соединения комнат при генерировании карты, сначала инвертируя карту, а потом его запуская. Вероятно, мне удастся прокопать отличнейшие туннели между комнатами». То было благословенное время, когда я пытался справиться с этой задачей, и при этом не чувствовал, что C++ мне мешает. Мне тогда удалось решить эту задачу, попутно многому научившись. Потом у меня появилась такая мысль: «Интересно, получится мне взять пользовательский интерфейс, сделанный на FTXUI, и просто напрямую его отрендерить в окно визуализации SFML?». Как и следовало ожидать, у меня всё отлично получилось. И хотя это было не так уж и сложно, я по ходу дела много узнал о том, как в C++ обрабатывается юникод. Ни одна из этих задач лёгкой не была, но все их, в принципе, можно было решить, и я не могу напридумывать себе достаточно много «подводных камней», которыми C++ мог бы помешать мне сделать то, что я хочу. Это — то, что я называю «удовольствием».

В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.

Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.

SRP не SRP

Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).