Сап, аноны,
Надо взять за правило отписываться тут, т.к. собирать мысли вместе дело хорошее, а писать в стол я просто не могу.
Расстановка сил: я хуй, но не оп, компания в ЕС, у меня зарплата процентов на 30% больше, чем они могут предложить. Но я так устал на текущем месте, что даже может и согласился бы, т.к. если подсчитать по часам то получится та же ставка.

1 этап Codility - пустяк, решил за 1/3 от данного на задачи времени, но одна из задач получила только 70%, т.к. я забыл подумать об оптимизации. Очень уж хотелось нажать Submit и забыть.
2 этап HR - её разговор со мной вполне устроил, достаточно мило поговорили.
3 этап индус - внезапно, тоже норм, у меня с ними обычно проблемы, т.к. вообще не понимаю их акцент (как и британский), очень много на этом завалил собеседований. Индус просил доделать тест на Codility и дал еще пару задач в том же стиле, прошло норм. В отличие от Гуглов, Амозонов и Фейсбуков он не ожидал долгих и нудных расспросов про условия задачи. Наверное, поэтому и был успех.
4 этап - провальный. Мужик, который в компании с самого начала, к команде, куда я прохожу интервью он отношения не имеет. Задание не задание, а какой-то мало вменяемый диалог. "Давайте поиграем в игру, я буду вам описывать ситуацию, задавать вопрос, вы будете отвечать, и с учетом Ваших ответов мы будем продолжать".
Далее он рисует трехзвенную архитектуру, слой логики у него состоял из 3-х серверов (по 16GB RAM), которые он назвал микросервисами. Сказал, что на каждом сервере крутится TomCat. БД - PostgreSQL. Приложение - интернет магазин, работает в AWS. Тут надо упомянуть, что Java EE и Томкат ничего общего с будущей позицией не имеют.
Следует вопрос: "Вы замечаете, что запросы начинают обрабатываться медленно и приложение неработоспособно, скажите, какой элемент архитектуры Вы будете проверять первым?". Такая постановка вопроса меня несколько ошарашила.
Окей, начинаю. Чтобы решать проблему быстро, будем использовать инструменты, которые помогут максимально быстро локализовать проблему.
Сначала пойду в БД и загляну в pg_stat_activity, если что-то не так с запросами или самой БД, то мы это сразу увидим. Он меня прерывает, говорит, с БД все хорошо. Окей, раз с БД все хорошо, тогда по JMX соединяемся с Томкатами и смотрим, что происходит с JVM, можем собрать немного sampling-данных, если по нагрузке CPU это не очевидно.
Он меня прерывает и говорит, что вопрос стоял не так и что я должен указать, какой элемент архитектуры с наибольшей вероятность окажется точкой отказа. Я отвечаю, что вообще вопрос поставлен некорректно, никогда нельзя судить о точке отказа без локализации проблемы, что "угадывание" - не самый лучший способ решения.
Он продолжает, окей, проблема на фронт-Томкате, там же jsp и статика отдается, сервер страдает от IO. Далее идет мой с ним диалог о том, что "Минуту, а как оно может от этого страдать?". Ведь даже если сам Tomcat не кеширует отдаваемую статику, то это сделает Linux через Page cache. У нас в магазине статики так много? "Да, у вас jpeg-и по 15МБ".
Далее идет диалог о том, что JPEG пережать, залить на CDN, он описывает следующую проблему, ставим балансировщики, ставим сессионный сервер, управляем сессиями и т.д. Диалог вроде бы наладился. Вроде даже закончили нормально.

Сегодня я получаю сообщение от рекрутера: "Вам дали case study, Вы не согласились с процессом и компания не может продолжать".
Ощущение, что меня просто накормили говном. Вроде бы и выводы хочется какие-то сделать. Написал рекрутеру. Ок, наверное, я плохо понял интервьюера, похоже, моих вербальных и English навыков недостаточно. В ответ получаю, нет у Вас с английским все нормально.