Топ компаний по WLB+зп, которые нанимают в Лондоне, для тех, кто имеет Java бэкграунд

Это расширенный топ, аналогичный Топ компаний, которые нанимают в Лондоне, для тех, кто ценит WLB при хорошей зп и имеет Java бэкграунд

Я убрал фильтры по нижней оценке по WLB и по нижней зп.
Рейтинг высчитывался по формуле: оценка по WLB + оценка по зп. Оценка по зп вычислялась так: зп Senior от 100 до 150 - 3, от 150 до 200 - 4, выше 200 - 5.

1) XTX Markets.
Оценка: 4,5 WLB: 4,3 ЗП: £260k
2) Jane Street
Оценка: 4,4 WLB: 4,2 ЗП: £263k
3) Two Sigma
Оценка: 4 WLB: 4,2 ЗП: £204k
4) DRW
Оценка: 4,3 WLB: 4,1 ЗП: £209k
5) Google DeepMind
Оценка: 4,2 WLB: 3,9 ЗП: £255k
6) The Trade Desk
Оценка: 3,9 WLB: 3,9 ЗП: £218k
7) OpenAI
Оценка: 4,4 WLB: 3,5 ЗП: £284k
8) Anthropic
Оценка: 4,5 WLB: 3,4 ЗП: £390k
9) Databricks
Оценка: 4 WLB: 3,4 ЗП: £300k
10) Google
Оценка: 4,4 WLB: 4,2 ЗП: £194k
11) Synthesia
Оценка: 4,5 WLB: 4,1 ЗП: £151k
12) Bloomberg
Оценка: 4 WLB: 4 ЗП: £150k
13) Meta
Оценка: 3,6 WLB: 2,9 ЗП: £219k
14) Apple
Оценка: 4,2 WLB: 3,7 ЗП: £158k
15) Revolut
Оценка: 4 WLB: 4 ЗП: £157k
16) Stripe
Оценка: 3,7 WLB: 4 ЗП: £189k
17) Spotify
Оценка: 3,9 WLB: 4,2 ЗП: £136k
18) Elastic
Оценка: 3,9 WLB: 4,1 ЗП: £128k
19) Expedia Group
Оценка: 3,8 WLB: 4 ЗП: £123k
20) Microsoft
Оценка: 4 WLB: 3,9 ЗП: £117k
21) Airbnb
Оценка: 4 WLB: 3,9 ЗП: £110k
22) Monzo
Оценка: 4 WLB: 3,9 ЗП: £138k
23) Starling Bank
Оценка: 3,5 WLB: 3 ЗП: £112k
24) Wise
Оценка: 3,7 WLB: 3,7 ЗП: £106k
25) Deliveroo
Оценка: 3,4 WLB: 3,4 ЗП: £122k
26) Checkout
Оценка: 4 WLB: 3,2 ЗП: £98k
27) Amazon
Оценка: 3,5 WLB: 3,1 ЗП: £115k
28) IBM
Оценка: 3,9 WLB: 4 ЗП: £71k
29) Goldman Sachs
Оценка: 3,7 WLB: 2,9 ЗП: £125k
30) Deutsche Bank
Оценка: 3,8 WLB: 3,9 ЗП: £89k
31) Palantir
Оценка: 3,7 WLB: 2,8 ЗП: £131k

Имеет ли смысл учиться в STEM-вузе (физмат, технический вуз) в 2026 в эпоху AI?

Мое мнение: Да, и даже более актуально, чем 10 лет назад.

Но при этом не стоит рассматривать обучение в физмат вузе как способ получения профессии и тем более как способ получения конкретных знаний.
Я закончил МФТИ. При этом ни в школе, ни в универе я не планировал становиться программистом. Тем более, когда я поступал, число программистов было не так много в странах СНГ. Эта индустрия только начала приходить к нам.

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

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

При этом не важно чему конкретно вы обучаетесь сейчас. Это может быть физика, математика, биотех, основы Computer Science или ML. Не стоит это рассматривать как вашу конечную специальность. Сейчас скорость изменений увеличивается и уже не работает получение одной специальности в вузе на всю жизнь. Но это позволит в нужном возрасте заложить нужный тип мышления и навыки эффективного самообразования.

Какой скилл имеет смысл освоить всем программистам в 2026?

Попробуйте агентную AI - разработку при помощи Claude Code.

Ресурсы, с чего начать:

1) Официальный курс от Anthropic: https://anthropic.skilljar.com/claude-code-in-action
2) Практическое видео от Бориса Черного (создатель Claude Code): Mastering Claude Code in 30 minutes
3) Официальная документация. Ссылка:
code.claude.com/docs

Робот, заменяет человека

Трансляция идёт уже третий день. Робот Helix-02 от компании Figure AI непрерывно работает на конвейере. Переворачивает посылки этикеткой вниз для последующего автоматического сканирования.

https://www.youtube.com/live/luU57hMhkak?si=qv9jkPg-INvkNB9J

Вышел трейлер документалки C++: The Documentary

Сам фильм выходит 4 июня 2026 года. Фильм спонсируется HRT (Hudson River Trading). Это топовая трейдинговая компания, специализирующаяся, в том числе, на high frequency трейдинге.


Сам трейлер:
https://youtu.be/NXwTRzywDSk?si=lmNOn_VyeXJTvDwj

Токенмаксинг

Ещё один свежий buzzword. Это когда сотрудники соревнуются в использовании AI-токенов, часто прибегая к бесполезному использованию AI ради самой метрики. Понятие возникло в Meta, но тренд распространился на многие компании, особенно на Amazon. Я работал в обеих компаниях.

Смотри также: Coffee Baging

Update по замене программистов при помощи AI

Заменяет ли AI программистов в 2026 году?
Краткий ответ: нет, но с нюансами.

С момента релиза ChatGPT прошло уже 3.5 года. За это время как сами модели так и тулы на основе этих моделей проделали большой путь.
Если в 2023 это был просто какой-то бесполезный прикол. То благодаря появлению CoT (Chain of Thought) и RLHF(Reinforcement Learning from Human Feedback) в 2024 стало понятно, что это как минимум может заменить собой поиск в интернете и Google Search под большой угрозой. Кроме того, для кода это стало заменять StackOverflow, Google поиск и автокомплиты в среде разработки.
В 2025 OpenAI со своим ChatGPT стало тормозить в развитии. Релиз ChatGPT 5.0 оказался разочарованием. Существенного прогресса по сравнению с предыдущей версией не было. Казалось, что хайп по AI начинает проходить. Круговые сделки между Oracle, Open AI, Microsoft раздували AI Bubble. И на сентябрь-октябрь 2025 казалось, что вот вот пузырь лопнет и хайп закончится.

Но тут вырвались сильно вперед Google Gemini и Anthropic Claude. А с релизом Claude Opus 4.6 в феврале 2026 года стало ясно, что автоматизация написания кода уже практически случилась.

Но, что важно, Claude Code + Opus >=4.6 могут помочь с написанием кода, но все еще не могут заменить программиста. Он все еще требует постановки задач, уточнения требований, ревью написанного кода. Кроме того, программист начиная с уровня Middle делает много чего другого, кроме написания кода. Это создание технической стратегии развития продукта, фичи, компоненты. Это создание и овнинг роудмапа. Это декомпозиция сложных задач и проектов. Это определение и устранение технических и организационных ботлнеков проектов. Это архитектура и дизайн продуктов и решений. Это обсуждение и согласование требований, технических решений. Это обнаружение и устранение конфликтов. Это написание и ревью кода. Это тестирование и мониторинг кода, фич и т.д. Это деплоймент и саппорт. Это документирование. Это менторинг и обучение. Это хайринг. И т.д.

Поэтому на данный момент AI может повысить вашу производительность в плане написания кода. При этом он все равно требует от вас усилий даже в написании кода. Если его не контролировать, то качество кода просядет и потребуется много переделок в будущем.
Можно рассматривать текущее состояние AI для программиста как наличие круиз контроля в вашем автомобиле или ранние версии автопилота в самолете. Даже современные продвинутые автопилоты не заменили живых пилотов. Наоборот, число пилотов выросло в разы по сравнению с временами, когда пилотировали чисто вручную.

Что по AI-собеседованиям?
Во многих компаниях сейчас стали заменять один из стандартных leetcode-style кодинг раундов на AI-coding. В том числе и в Мете. Раунд длится 60 минут вместо 45 минут. При этом задача одна, вместо двух. Но в ней несколько под-заданий. Например, пофиксить баг, реализовать функционал, написать тесты. У вас уже будет какое количество написанного кода до вас. А также могут быть файлы с данными. Обычно, это файл с тестами, файл с данными и пару файлов с кодом. При этом вам разрешают пользоваться строенным LLM в среду разработки, в которой вас будут собеседовать. Формулировка задач при этом более практичная, чем стандартные leetcode задачи. Но по факту, это не просто API с бойлерплейт кодом и перекладываением джейсонов. С чем в реальности работает программист на работе. Это все равно так или иначе задача на использование структур данных и алгоритмов. Кроме того, просто переадресовывать вопросы интервьюера LLM и копировать код не получиться. Придется разбираться с постановкой задачи, существующим кодом, алгоритмами и структурами данных. LLM просто может вас ускорить и помочь ускорить процесс написания кода.

Что будет в будущем?
Если экономика использования AI для кодирования сойдется, то написание кода будет существенно автоматизировано. Пока даже с этим есть проблемы. Например, Uber недавно израсходовал годовой бюджет на Claude Code за 4 месяца. Microsoft также перешли на свой AI, в том числе потому, что Claude Code дорогой. Но если по деньгам будет все ок. То кодирование с помощью AI станет новой нормой. Но при этом до замены программистов все еще далеко. AI просто существенно повлияет на профессию. При этом уметь программировать, знать особенности языка программирования, структуры данных, алгоритмы все еще будет необходимо. Что будет через 2-5 лет сказать очень сложно. Все очень быстро меняется.

Смотри также:
LLM vs программисты

Uber COO Андрю Макдональд про AI

Uber израсходовал годовой бюджет на AI за несколько месяцев. При этом COO Uber в интервью рассказал, что пока сложно установить связь между реальным увеличением производительности (увеличение числа заде́ливеренных фич или рост выручки) и использованием AI. То есть использование AI растёт, расходы на AI растут, но нет увеличения выхлопа от этого. По крайней мере, пока сложно установить связь между расходами на AI и ростом производительности.

https://youtube.com/shorts/GZFCSyjunZI?si=eDi4fcd3RV3PELrC

Вышла документалка про создание C++

Трейлер: https://youtu.be/NXwTRzywDSk?si=3aEmsgWoZXUjA2Hk

Документалка: https://youtu.be/lI7tMxzSJ7w?si=aSSf8X7ZWxZpH_CY

На том же канале много других прикольных документалок

1) IntelliJ IDEA. Про создание, возможно, лучшей среды разработки для Java.

Трейлер

Фильм

2) Spring. Про создание одного из самых популярных фреймворком для Java.

Трейлер

Фильм

3) Java. Про создание языка программирования Java. Пока только трейлер. Фильм должен выйти летом этого года.

Трейлер.

Exit стратегия ранних инвесторов в Open AI, Anthropic и Space X заключается в использовании пенсионных накоплений американцев

Такая дискуссия разворачивается в преддверии самых масштабных IPO в истории. В этом году на IPO выходят SpaceX, OpenAI и Anthropic. Ранние инвесторы вкладывали колоссальные деньги в эти компании по астрономическим оценкам. Все три компании глубоко убыточные. Revenue (доход) измеряется десятками миллиардов долларов в год. При этом оценка капитализации в триллионах долларов.
Выход на IPO — это один из вариантов вернуть инвестиции и заработать на них.

Но что необычного сейчас происходит?

Крупные индексы, вроде Nasdaq, Russell 1000, S&P 500, изменили правила включения компаний специально под эти 3 компании. Они сократили время включения до недель и даже дней, вместо месяцев или даже года. Кроме того, S&P 500 исключил правило, что для включения компании в индекс нужно, чтобы компания была прибыльной.

То есть,

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

Но как это связано с пенсиями в США?

В США существенная часть пенсий поступает от так называемых инвестиционных счетов 401(k). Работник может откладывать часть своего дохода на специальный инвестиционный счёт. Например, 5%. Часто работодатель может добавить столько же. То есть вы можете откладывать 10% своего дохода на инвестиционный счёт. Причём вы откладываете процент дохода до уплаты налогов. То есть то, что вы туда откладываете, идёт в обход уплаты налогов.
И когда вы перечисляете туда деньги, вы можете выбрать индексы, в которые вы инвестируете. Снять деньги со счёта до достижения пенсионного возраста очень сложно, и придётся платить штраф за это.

Теперь получается так, что эти компании насильно и по практически изначальной цене включают в индексы, и следовательно, это частично оплачивается из пенсионных накоплений американцев.

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

Это вызвало широкие обсуждения в последнее время. И S&P 500 уже отказался от упрощенных правил для этих трех компаний. Но Nasdaq и Russell 1000 — нет.

Более того, под соусом SpaceX нам продают ракеты, но в реальности туда включили X.AI (создатель Grok), который является глубоко убыточным AI-бизнесом.

Всё это, совместно с разговорами про токенмаксинг и бесполезными расходами на AI (не видна польза от внедрения AI, видны только астрономические расходы), снова поднимает тему про AI Bubble.

Почему самые высоконагруженные веб приложения мира это не всегда микросервисы?

Многие компании, которые разрабатывают самые высоконагруженные приложения, с миллиардами запросов в секунду, используют монолиты и монорепы. Ярким примером является Facebook и Instagram. В бэкенде это монолиты. Конечно, у них есть большое число других компонент, которые вынесены в отдельные сервисы, но основной backend, который принимает и обрабатывает запросы от фронтенда (веба или мобильного приложения), содержит бизнес логику - это монолит.

Backend Facebook изначально был написан на PHP в 2004 году. Далее его плавно мигрировали на собственный язык hacklang и собственную виртуальную машину hhvm. При этом он остался, по большей части, колоссального размера монолитом.
Аналогично, Instagram написан на python (django). Основная часть все еще остается монолитом.

Оба сервиса имеют миллиарды пользователей и обрабатывают невероятное число запросов в секунду. При этом они обладают колоссальной отказоустойчивостью и скорость разработки сервисов огромная. Время от того, как вы запушили комит до деплоя в prod проходит несколько часов.

Более того, весь код этих приложений находится в монорепе и используется trunk-based development. Т.е. все изменения сразу делаются в основной ветке разработки.

Почему так? Какие это дает преимущества?

Монорепа:
1) Проблема версионирования API решается на уровне компилятора. Если вы меняете какое-то API, то вы не сможете запушить это изменение в trunk до тех пор, пока не измените все call site (все места, где это API вызывается). Вам не позволит компилятор, ваш код просто не скомпилируется. Если у вас множество репозиториев, то изменение API в одном месте не блокирует вас запушить это изменение. Вы создадите новую версию вашего API. Всем клиентам нужно про это узнать, и делать процесс миграции на новую версию. Нужно менять код, зависимости и т.д. Очень часто это приводит к багам в проде. Когда клиент ожидает одного поведения или семантики API, а в проде уже задеплоена другая версия.
2) Полностью решается проблема dependency hell. Проблемы зависимостей на разные версии одной и той же библиотеки со стороны разных зависимостей вашего модуля. Круговые зависимости и т.д. Тут все решается автоматически на уровне компилятора.
3) Легкий поиск по коду. У вас весь код под рукой. Если он проиндексирован можно легко найти любой интересующий вас код.

В Амазоне отдельные репы. Там целая наука работы с зависимостями. Есть свои тулы, концепции и т.д. Там есть тул brazil, понятие version set и много всего другого. Это постоянно приводит к затыкам с зависимостями, багам в проде из-за версионирования. Часто пуш сторонней библиотеки может заблокировать ваш CI/CD пайплайн, т.к. у вас поломались зависимости.

Монолиты:
1) Высокая производительность. В микросервисах вызов функции происходит по сети, что работает за миллисекунды. В монолитах вызов происходит в рамках одного процесса и работает за наносекунды.
2) Нет проблемы версионирования API в проде. Это решается на уровне компилятора. Это типичная проблема микросервиисов.
3) Легко тестировать. Вы можете протестировать все e2e. В микросервисах часто очень сложно или не возможно протестировать приложение e2e. Вы можете протестировать свою компоненту, но не весь функционал в целом. Особенно, если у вас под 100 тысяч микросервисов, как в условном Amazon.

Trunk-based development:
1) Отсутствие Merge-Hell. Если вы разрабатываете крупную фичу в отдельной ветке, ее потом сложно мержить в trunk. Мелкие и частые изменения предотвращают тяжелые конфликты вмерживания.
2) Можно сделать реальный и быстрый CI/CD. В Мета любое изменение вмерживается, компилируется, тестируется и деплоится в прод за несколько часов. Не нужно делать долгие, сложные и редкие релизы.

Какие есть с этим проблемы и как их решили в Facebook/Instagram?
1) Производительность системы контроля версий. Если у вас очень много кода в одном репозитории как в Meta (миллионы файлов, десятки, если не сотни миллионов строк), то система контроля версий может на справиться по производительности. Поэтому Мета сделала свою систему контроля версий на основе Mercury (git не справляется с такими масштабами).
2) Feature Flags. Из-за trunk-based development у вас деплоится множество функционала в промежуточном состоянии. Для этого вам нужно иметь возможность ее включать и выключать в проде, проводить тестирование в проде и т.д. Для этого вам нужно активно использовать feature flags.
3) Привязка к одному языку программирования. Это неустранимая особенность. Приходится писать на том языке, на котором написан монолит.
4) Влияние проблем в одной фиче на другую/независимое масштабирование. Если одна функциональность стала работать плохо (потреблять много памяти, бросать ошибки, потреблять много процессорного времени и т.д.), то это может повлиять на работоспособность другого функционала, т.к. весь функционал живет на одном и том же сервере (т.к. это монолит). Это решено на уровне виртуальной машины/контейнера приложений. В Python у вас создается несколько отдельных процессов. Которые способны обрабатывать запросы независимо друг от друга. Число процессов зависит от числа ядер процессора. Процессы не шарят между собой память. Их можно независимо друг от друга мониторить, убивать и перезапускать. В hacklang и hhvm процесс один, но имеет множество потоков, которые имеют изолированную память, которую можно независимо друг от друга ограничивать. Потоки более легковесные, чем отдельные процессы. Но при этом они не шарят память между собой. В Java такое реализовать не получится. Там также один процесс и отдельные потоки на каждый запрос. Но потоки используют одну и туже память (Java Heap).
5) Проблемы с ownership кода. Из-за того, что весь код в одной большой куче, сложно разграничивать кто отвечает за тот или иной код. В Meta эта проблема решена плохо. Тут есть и плюсы и минусы. С одной стороны вы не ограничиваетесь кодом своей команды и можете при необходимости изменить любой код. Но важно, чтобы те, кто отвечает за этот код как минимум проревьюили это изменение. В Meta с этой целью к каждому файлу добавляется специальная аннотация/тег - какая команда владеет этим кодом. И при его изменении, автоматически в код ревью добавляются люди из нужной команды.
6) Сложно засетапить CI/CD. Нужно, чтобы компиляция на такой большой базе кода работала быстро, а также тесты прогонялись быстро. Для этого вычисляется дельта, и прогоняется только подмножество тестов, на которые может повлиять ваше изменение.