Очень часто на собеседованиях встречается небольшая задачка на SQL. Далеко не все и не всегда пишут SQL запросы на работе, на моем текущем проекте, например, вообще нет базы данных, а на предущем она была простая как 5 копеек.

Поэтому, перед собеседованием однозначно стоит вспомнить как пишутся простые запросы - SELECT, GROUP BY, HAVING.

Потренироваться можно на бесплатном тренажере:
https://sql-academy.org/ru/trainer

Также небольшой чек-лист для повторения по реляционкам:

1) Индексы, какие бывают, для чего нужны
2) Блокировки - оптимистичные, пессимистичные
3) Транзакции - для чего нужны, уровни изоляции

Как устроен процесс интервью в IT сейчас? 💻

Маленькие и средние компании обычно ищут разработчика сразу на конкретную позицию. Это значит, что процесс не особо формализован:

1) Скрининг с HR, общие вопросы по чеклисту.

2) Фит-интервью сразу с целевой командой, обычно собеседует лид и еще кто-то. Будет солянка, но в целом вопросы по опыту, технологиям, задачам, которые придется решать. Вопросы по алгоритмам и дизайну могут быть, а могут и не быть - зависит от компании и позиции.

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

Небольшая или средняя компания - неплохой вариант для старта, но расти там скорее всего не получится.

📌 Интереснее дело с наймом обстоит в крупных компаниях.

Собеседования часто идут в общий пул кандидатов:

1) Скрининг с HR - те же общие вопросы по чеклисту.

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

3) Фит с заинтересовавшейся командой: здесь мы общаемся с лидом, уточняем вопросы, что вообще придется делать на проекте (чек-лист обязательных вопросов - тема для отдельного поста).

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

🎯 Несколько хинтов, которые драматически повышают шансы на успешное интервью:

- Хорошее настроение - прийти на позитиве за несколько минут до начала, поздоровавшись - улыбнуться, небольшой смолл-толк - это плюс. 😊

- Ставить интервью на первую половину дня и НИКОГДА на вечер пятницы - после рабочего дня уже ничего никому не хочется, и в среднем оценка будет ниже.

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

Почему стоит идти работать в крупную компанию? 🏦

5 причин за:
1) Ты будешь работать с опытными коллегами, у которых есть чему поучиться
2) Ты узнаешь как строить высоконагруженные системы, мониторинг и алертинг для них, как это работает в реальной жизни
3) Ты увидишь как устроены процессы разработки у профессионалов, получишь качественный фидбек
4) Ты сможешь поучаствовать в создании сервисов для миллионов пользователей
5) Ты получишь неограниченный потенциал роста, который зависит только от амбиций

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

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

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

Я очень благодарен текущей работе, я узнал как действительно правильно разрабатывать системы (а не просто писать код). Узнал как выстраивать процессы работы нескольких команд для доставки ценности. И это на позиции разработчика. Поразительный уровень свободы.

Если у тебя есть возможность пойти работать в крупную компанию - это лучший шанс из возможных. 👍

#Java #собеседования #интервью #работа #поиск_работы #карьера #стажировка

Есть много рутинной работы, но нет денег? 💸
Купи клауд, а, нет, крути "карусель стажеров"! 🧑‍💻

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

Он успешно прошел скрининг и предварительное интервью

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

Краткие итоги:

Он с ребятами переписал небольшой легаси сервис с SOAP на REST бесплатно, и покрыл его тестами

Ментор был один на много человек и "очень занятой", отвечал пару раз в неделю

Он действительно получил опыт, а за него, сколько не плати, не переплатишь. И сказал что теперь никаких бесплатных стажировок, только ИС в штате😆

Но всегда есть следующий стажер, желающий получить ачивку "работал в крутой компании N".

#карьера

Джун или миддл: ну тут будет ошибка

Синьор: надо пробовать запустить и подебажить, чота падазрительна

Авторы JDK: т.к. это предпоследний элемент массива - тут корнер кейс, и в этом случае код отработает :D

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

#Java #программирование

У меня есть в загашнике контент для пятничного шитпостинга. Свежие мысли из 2020, так скажем

Итак, поехали.

Самым имбалансным критерием оценки компании на мой взгляд ПО СЕЙ ДЕНЬ является толчек.

Да, именно он. Оценив чистоту, убранство, ассортимент гигиенических средств и приборов (крем для рук - базовый минимум?), а также
музыкальное сопровождение, можно сделать самые далеко идущие выводы о компании.

Мягкая и шелковитая бумага говорит о процветании, а приятный аромат о том, что компания очень ценит душевный покой своих сотрудников. 🍑

Футуристичный стиль кричит о креативном мышлении.

Это индикатор динамический. Как только вместо шелковистой бумаги начинает попадаться серая бумага из вторсырья - макрофинансовый отчет компании можно даже не открывать.

Лучше сходить в офис к конкурентам и проверить их фаянсового друга.

#карьера #шитпостинг

День без встреч. Бустим командные процессы (да и личные)

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

Краткие итоги обсудили на ретро:
0) Главное - никто не умер 😆
1) Появилось больше времени для концентрированной работы, без смены контекста и вечных обсуждений
2) Появился день когда можно работать по своему графику, а также сходить и порешать свои дела не парясь и никого не предупреждая
3) Leadtime задач статзначимо не изменился
4) Всем нравится, а это важно.

Эксперимент признан успешным. Попробовать однозначно стоит.

#опыт #it #процессы

Итак. Астрологи объявили неделю код-ревью. Напишу серию небольших постов о ревью, как его проводить на интервью и разбор реальной задачки.

Поехали. 🚀

Часть 1. Как проводить код-ревью на собеседовании? Чек-лист 📋

Подготовительные пункты:

- Ознакомиться с постановкой задачи, если она есть.

- Просмотреть структуру классов, их названия и контракты.

- Понять, какую задачу должен решать этот код.

Тайминги этого этапа 3-5 минут.

Приступаем к самому ревью:

- Ревью кода проводим построчно, от контроллеров к сервисам.

- По ходу ревью комментируем код — озвучиваем интервьюеру потенциальные проблемы с кодом и наш ход мысли.

- Когда находим проблему — править код не нужно, достаточно подсветить её и предложить решение.

Обычно достаточно подсветить 3–4 минорные проблемы и перейти к поиску мажорной.

Тайминги этого этапа тоже 3-5 минут.

Мажорная проблема всегда подразумевает детальную беседу — нужно раскрыть причины, предложить рефакторинг (2–3 способа).

Это 10-15 минут.

- Общие тайминги ревью кода обычно от 15 минут до получаса, нужно контролировать время, чтобы хватило на поиск и обсуждение мажорной проблемы.

- Важно. Критиковать авторов и код не нужно, важнее предложить хороший фикс.

- Основные проблемы обычно лежат на стыке приложения и БД или сторонних интеграций.

#Java #ревью #собеседования

Часть 2. Разбор слегка адаптированной задачи на ревью из одного зеленого банка.

Мы видим сервис, который обрабатывает пользователей. 🔍 Он умеет создавать список пользователей, а также выполнять некую логику после того, как пользователей создал.

Какие в коде есть проблемы? Начнём с минорных.

- Создание зависимостей через new, инжект через сеттеры (с объяснением, почему это плохо).

- Использование строкового типа для region.

- Нет аннотации Service.

Минорных пока достаточно, можно переходить к основным проблемам.

Часть 3. Критикал проблемы. 🧯

Критикал проблем тут несколько:

- Вызов транзакционного метода из метода внутри класса - это не сработает.

- Проблема потенциально большого количества пользователей на входе и их поштучное создание.

- Влияние сохранения одних пользователей на других: при ошибке сохранения одного не запишется весь пакет (откат всей транзакции).

- Вызов regionService поштучно для каждого пользователя - потенциально дорогая и неэффективная операция.

- Нет гарантии выполнения обновления region для каждого пользователя, а также сбой при обновлении повлияет на остальных.

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

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

Часть 4. Возможное Решение 🧠

Главный поинт в том, что не нужно решать ВСЕ проблемы, но нужно дать хорошую проработку хотя бы одной-двух.
Лучше акцентировать внимание на проблеме, которую ты сможешь лучше всего раскрыть.

Вопрос вызова транзакционного метода банальный, это отработает не так как ожидается, поскольку Spring использует прокси для реализации транзакций, можно предложить изменить структуру вызовов или self-injection для решения проблемы атомарного создания всего батча юзеров.

Но лучше пойти дальше и посмотреть на проблему производительности и надежности. На этом этапе можно дособрать требования по задаче. Есть ли потребность в батчевой обработке юзеров?

Если потребность есть - нужно копать в сторону батчевой вставки и конфигурировать hibernate. Если нагрузка очень большая - то подумать о том чтобы клеить всё в один INSERT (с отказом от hibernate здесь).

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

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

Обычно такой ответ уже удовлетворителен и на этом секция заканчивается.

С вами был Артем. Спасибо за внимание.

#Java #ревью #собеседование

Продолжаем тему ревью. Отличная шпаргалка, всё в одном, автору респект ❤️ Забираем в копилочку.

Предыдущая задача, которую разбирали, закрывает большую часть бинго. Но мне интересно было подобрать пример с if/else цепочками. Без спринга и прочего сахара.

На связи тот же "один зеленый банк", немного адаптированная задачка на рефакторинг.

class CodeProcessor {
    public void process(CodeType codeType) {
        if (codeType == CodeType.ONE) {
            sout("Handling ONE"); // и еще какая то сложная логика
        } else if // череда else-if
        ...
        else {
            sout("Handling Default Case"); // тут тоже
        }
    }
}

enum CodeType {
    ONE, TWO, THREE, OTHER
}

public class CodeProcessingApp {
    public static void main(String[] args) {
        var processor = new CodeProcessor();
        processor.process(CodeType.ONE);
    }
}

Первым предложением будет конечно поменять if/else на switch. Но основную проблему это не решает.

Если посмотреть детальнее - то CodeProcessor начинает брать на себя ответственность сразу за обработку всех типов кодов. Это нарушает SRP (и здравый смысл).

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

Обычно в такой ситуации стоит вспомнить отцов-основателей (банда четырех), и спросить себя, а что бы сделали они?

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

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

Хороший разбор паттернов очень простым языком можно найти вот тут:
https://refactoring.guru/ru/design-patterns/strategy

Ну а мы посмотрим на код:

interface Handler {
    void handle();
}

class OneHandler implements Handler {
    @Override public void handle() { 
        sout("Handling ONE"); // и еще какая то сложная логика
    }
}

class DefaultHandler implements Handler {
    @Override public void handle() { 
        sout("Handling Default Case"); // и еще сложная логика
    } 
}

class CodeProcessor {
    private final Map<CodeType, Handler> handlers = new EnumMap<>(CodeType.class);
    private final Handler defaultHandler = new DefaultHandler();

    public CodeProcessor() {
        handlers.put(CodeType.ONE, new OneHandler());
        // регистрируем обработчики здесь
    }

    public void process(CodeType codeType) {
        handlers.getOrDefault(codeType, defaultHandler).handle();
    }
}

Что мы здесь видим? Теперь CodeProcessor не знает ничего о деталях обработки каждого типа кода. Он просто делегирует эту работу соответствующему обработчику.

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

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

И намного красивее это начинает смотреться как только в проекте появляется DI контейнер, который может автоматически инжектить зависимости и регистрировать обработчики.

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

Пока все вайбкодят новые тасктрекеры, предлагаю поговорить о том, с чем вайбкод не справляется совсем 🌚

Mainteinability - это одна из важнейших вех в разработке.

И как связаны "поддерживаемость" с собеседованиями?

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

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

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

И какие открытые вопросы в первую очередь стоит прорабатывать перед собеседованием. 😇

С чего начинается maintanability? 💬

1. Шаг номер один. Статический анализ. На любом проекте больше чем тыща строк кода возникает потребность в контроле стиля и формата. Сюда же относятся более продвинутые инструменты типа sonarqube. Весь этот хоровод называется словом quality gate.
Чуть детальнее по ссылке:
https://t.me/java_interview_tips/40

2. Тестовый контур и процессы тестирования. Сюда входит понимание пирамиды тестирования, опыт развертывания и поддержки тестовой инфраструктуры на проекте, метрик качества. Слова для поиска - testcontainers, jacoco, junit, mockito, wiremock, allure.

3. Здоровье сервиса. Отвечает на вопрос - как понять что сервис жив и выполняет свои функции. Ключевики - Actuator, Prometheus, Micrometer. Grafana для визуализации.

4. Логирование и трассировка, ELK - обычных разработчиков касается по касательной, достаточно общего представления.

5. Документация - автодоки, причесаный сваггер, gitlab pages.

6. CI, простая поставка ценности, пайплайны.

Пункт номер один. Code smells не пройдут! Как вы следите за качеством кода?

Для чего на проекте, в котором больше чем один разработчик - нужен кодстайл, какие-то правила, quality gate и прочие сложные процессы?

Эти процессы позволяют решить две проблемы:
1) Споры между разработчиками "как лучше и как правильно"
2) Сделать качество кода хотя бы немного "измеримым"

При этом наличие жесткого код-стайла в команде существенно экономит общее время на ревью.

Вместо споров как лучше - правила фиксируются один раз и позволяют фокусироваться только на логике

Обычно для реализации используется checkstyle или detekt с набором ваших правил

Пример таких правил - максимальный размер строки или метода, или количество return

На собеседованиях это обычно встречается под соусом вопросов "а как вы следите за качеством вашего кода? А кроме ревью?"

Пункт номер 2. Любимая всеми нами пирамида Хеопса. Но на моем проекте отвалился нос с юнитами.

Что же хотят услышать коварные люди, когда спрашивают "как ты относишься к юнитам"?

Ответ что ты их терпеть не можешь - это отличный ответ умного человека. Особенно если потом объяснить, где проходит граница применимости и что покрытие юнитами в 80% это ужас ужасный - такой код проще сжечь чем отрефакторить.

Еще пример комплексных вопросов:

1) Приведи пример реализации всех слоев тестирования из твоего проекта, что, зачем, почему? (ожидается детальный рассказ)

2) Как дружите тестирование и CI, сколько занимает прогон тестов, и почему интеграционники бывают такими долгими? Как с этим боретесь?

3) Почему интеграционники с моками это нечестные тесты? Что тестируете руками?

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

Завершающий пост на тему тестирования 👀

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

В этих условиях у разработчика всего 3 союзника - он сам, llm и тесты.

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

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

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

Тестируй свой код прежде чем пушить в прод, аве! 🙏

Фундамент комфорта и лучшая сегодня галка в резюме - observability на проекте 🎯

Что обычно понимают под этим словом?

Простыми словами - это процессы, которые позволяют легко и быстро понять, что на проекте что-то идет не так. Для этого команде нужен работающий 24/7 мониторинг ее услуг.

Как это касается разработчиков?

Именно разработчик обычно принимает решение, что нужно собирать метрики, и какие. Именно разработчик пушит внедрение инструментов трассировки в проект. И автоматизирует работу алертов.

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

Когда эти вещи внедряются сверху - то они делаются для галочки и ничего не мониторят.

Поэтому кандидатов часто спрашивают один простой но глубокий вопрос - как именно на текущем проекте у вас устроен observability?

Симулировать хороший ответ на него сложно. И даже для мидла уже важно самому принимать решение, а что же именно мониторить? И главное - как?