В мае я запустил курс, который постепенно подходит к своему завершению.

Недавно я спросил у ребят как дела, и вдруг узнал что кто-то уже трудоустроился! Курс прошел наполовину, а уже работает Java разработчиком! 🚀👍

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

Но для многих этот страх актуален, поэтому решил еще раз написать на эту тему.

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

Давайте представим, что может произойти, если попробовать преодолеть этот страх прямо сейчас?

1. Вы актуализируете свое резюме и выложите его везде где можно.
2. Поймете, что раз у вас нет откликов, значит что-то не так с привлекательностью резюме.
3. Обновите резюме
4. Получите приглашение на собес(ы)
5. Сходите на собес(ы)
6. Скорее всего вы провалите их
7. Поймете, что у вас пробелы в областях знаний X и Y
8. Подтяните то, чего вам не хватает
9. Сходите на собес(ы)
10. Получите оффер

Теперь давайте представим, что может произойти, если попробовать преодолеть этот страх чуть позже?

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

У вас также, скорее всего, не будет понимания, когда эта куча с названием "Все что нужно знать" закончится и вы будете учить все подряд неизвестное количество времени.

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

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

2. В конце концов вы решите попробовать пойти на собес и пройдете по все тем же 10 пунктам, перечисленным выше.

Что мы получим откладывая решение преодолеть страх собесов прямо сейчас? Мы получаем просто какое-то время "спокойствия" избегая встречи с этим стрессом.

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

Облегчить эту ношу можно по разному. Можно понять, что все интервьюеры когда-то были такими же соискателями. Можно понять, что как правило, все они с пониманием относятся к "незнанию ответов на вопросы". Никто не будет считать вас глупым. И провалив собеседование вы просто приобретете ключи к своему оферу (поймете что вам нужно подтянуть).

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

Я думаю нет, а вы как считаете?

Вчера с учеником проводили мок-собеседование по темам:

🦸‍♂️ SOLID
🎮Интерфейсы
🎮 Функциональные интерфейсы
🎮 Лямбды
🎮Stream API

Вот несколько (на мой взгляд) интересных вопросов на эту тему:

1. Можете привести пример того, как внедрение функциональных интерфейсов помогло сохранить обратную совместимость?

2. Часто говорят, что есть терминальные и промежуточные операции в стримах. Но есть еще ленивые и не ленивые операции, stateful и stateless операции. Можете рассказать о них?

3. Почему функциональный интерфейс может быть создан только с 1 абстрактным методом?

4. Приведите пример нарушения принципа LSP

5. Что такое Spliterator и связан ли он со Stream API, если да, то каким образом?

Накидайте своих ответов в коментах, а чуть погодя скину вам свои шпоры по этим темам 🖨

Привет, друзья!

Как обещал кидаю шпоры по темам из предыдущего поста, надеюсь будет полезно 🤗

👽 Примеры нарушения SOLID

👽 Вопросы по интерфейсам

👽 Вопросы по Stream API

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

Я сам себе обещал 10 постов за 2 недели.

Завтра две недели подойдут к концу и это мой второй пост 😀

Поделитесь, как вы мотивируете себя делать важные вещи?

Когда я учился на Java разработчика мне было сложно .

Сложна не сама Java, хотя она и не проста. А сложно долгое время находиться в состоянии неопределенности.

Сколько еще учиться? А получится ли у меня?

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

В самые трудные времена меня поддерживали чужие истории успеха.

Я думал раз у них получилось, то и я смогу.

Я смог.

Как смог и Никита , о котором я писал почти год назад, а недавно получил отзыв и от него 💪

Как сможет и любой человек, продолжительное время фокусирующий свои усилия на своей цели 🎯.

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

Как разбирать проблемы в коде?

Сегодня на курсе разбирал проблему с JS-скриптом, и вдруг понял, что при разборе практически любой проблемы я делаю одно и то же.

Представьте, вы кликаете на ссылку. Что происходит дальше?

1. Отправляется запрос на сервер. ⤵️
2. Выполняется код контроллера. ⤵️
3. Контроллер вызывает метод сервиса.⤵️
4. Сервис обращается к репозиторию.⤵️
5. Репозиторий формирует SQL-запрос в базу данных.⤵️
6. База возвращает данные обратно в репозиторий.⤵️
7. Репозиторий передаёт их сервису.⤵️
8. Сервис возвращает данные контроллеру.⤵️
9. Контроллер отправляет результат в веб-интерфейс.⤵️

Это как доставка посылки: вы забираете её из пункта выдачи и возвращаетесь домой.

Данные — это ваша "посылка", а маршрут — это выполнение кода программы.

Важно знать этот маршрут и контрольные точки, через которые проходят данные 🗺.

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

🃏 Запрос — это JSON.
🃏 В контроллере данные преобразуются в объект DTO.
🃏 В сервисе — это уже сущность (Entity).
Понимание того, как выглядят данные на каждой контрольной точке, помогает быстро обнаружить место, где что-то идёт не так.

Итак, чтобы эффективно находить проблемы:

1. Поймите маршрут потока данных.
2. Определите ключевые контрольные точки.
3. Проверьте, как данные меняются на каждом этапе.

Следуя этому алгоритму, разбор любой проблемы становится намного проще.

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

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

Когда работа аналитиком в команде с разрабами, которые прям задрали со своими уточнениями по тз достала, и ты пошла в стюардессы, но проф-деформацию еще не проработала 🗿

Всем привет!

Вчера писал, что на технических интервью многие соискатели испытывают проблемы с mutable/immutable сущностями.


Один из вопросов который мы задаем такой:
🤔 Как сделать объект immutable?


Большинство ребят отвечают примерно так:
1. Сделать класс final
2. Все поля - final, задавать их через конструктор
3. Убрать сеттеры

С этим я согласен, но мало кто вспоминает про еще один пункт:

4. Для ссылочных типов в геттерах необходимо возвращать копии объектов.

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

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

Рассмотрим такой пример. Как вы думаете, что не так с этим классом? 🤔

@AllArgsConstructor
@Getter
class Demo {
    private List<String> names;
}

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

1. В конструкторе передается ссылка на объект списка и присваевается полю names.
А это значит, что если список, который передали в конструктор класса будет модифицирован, он изменится и в объекте demo.

2. В геттере возвращается ссылка на объект списка names.
А это значит, что данный список, могут модифицировать извне.

Это можно увидеть в коде ниже:

public static void main(String[] args) {
    final var names = new ArrayList<>(List.of("e1", "e2"));
    final var demo = new Demo(names);

    names.add("e3");

    // [e1, e2, e3]
    System.out.println(demo.getNames());

    final var newNames = demo.getNames();
    newNames.add("e4");

    // [e1, e2, e3, e4]
    System.out.println(demo.getNames());
}

Такое может привести к ошибкам в программе ⚠️
И это один из примеров того, почему immutable классы более безопасны.

Есть еще одна вещь, но она в большей степени на слуху.

У immutable объектов не изменится hashCode 3️⃣6️⃣0️⃣8️⃣8️⃣7️⃣1️⃣
Что делает их более предпочтительными для использования в Hash-коллекциях

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


Будьте внимательны при работе с mutable классами, они таят в себе скрытую угрозу 🔫

5 пет-проектов, которые реально помогли стать Java разработчиками

Если все время учить Java Core и ООП, и не браться за создание пет-проекта, то можно стать очень похожим на человека, который знает 100 техник соблазнения, но остается девственником 🫣.

Сегодня вы узнаете, с помощью каких проектов мои ученики удовлетворили влажные фантазии горячих HR специалистов и сказали своей карьерной невинности прощай ⚡

Погнали 🔜

1️⃣ Хранилище скриптов продаж.

Представьте себе страницу на которой можно делать всего две вещи:
1. Создавать и редактировать скрипты продаж
2. Скопировать скрипт продаж в буфер обмена

Добавьте сюда авторизацию, и получите пет-проект, который принес первое трудоустройство

2️⃣ Система заказа питания для школьников.

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

Проект, который реально внедрили в школу и который принес трудоустройство #2

3️⃣ Абонементы в качалку.
Система с веб-интерфейсом и ТГ-ботом для управления абонементами в качалке.
Вжух, и еще одна компания закрыла острую потребность в молодом и перспективном специалисте

4️⃣ Система для управления бронированием записей к барберу

Видели барберов, к которым можно записаться через ТГ бот?

Я тоже не видел, проект не вышел в прод)

Но это и не важно.
А знаете что важно?

Правильно - еще одна взбалмошная представительница касты HR осталась удовлетворена проделанной работой и закрытой дырой в кадровом ресурсе 😏

Когда твоя мечта сходу попасть в сбер, то выход один:

5️⃣ Система, которая рассчитывает премию для кредитных специалистов в банке.

По сути система, которая заменила бы excel файл, по которому производится расчет премии для банковских сотрудников.

Почему заменила бы? Потому что ребята продолжают использовать excel. Но это и не важно. Почему? Правильно, потому что это трудоустройство #5, прямо в сбер.

Так что если ты все еще учишь Java core, то:
1. Найди кого-то, кому нужно что-то
2. Сделай это что-то на Java за банку соленых огурцов
3. Теперь ты фрилансер
4. Найди ближайшую HR и скажи то, что видишь на картинке к посту
5. Профит, твоя жизнь никогда не будет прежней

PS В январе я запускаю второй поток своего курса по созданию пет-проекта на Spring, ставь 🔥если интересно узнать, какой проект мы будем делать