lifeofjuniordev

🏞️ Сочи

⚖️ Недавно в Грузии приняли закон, по которому IT-специалисты обязаны получать ВНЖ.
Для этого нужно достать пару выписок, и так как электронные документы тут не принимают, пришлось скататься в Россию.

Ближайший город - Сочи.

В самом городе делать особо нечего, только набережная красивая.

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

Самое прикольное место - Роза Хутор, выглядит красиво и современно, даже в пасмурную погоду тут вайбово, потому что стиль напоминает Амстердам.
Нижние вершины закрыты туманом, а на самом высоком пике уже лежат большие сугробы и идёт снегопад ❄️

👨‍💻 Джуниор

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

Исходя из этого, я выбрал такой стек:
— TypeScript — тут без вариантов. Хотелось бы писать на Go или Rust, но они совсем не подходили.

— Bun — бандлер + пакетный менеджер. Быстрый, модный, минималистичный. Идеально.

— Snabbdom — маленькое модульное виртуальное DOM-дерево. Его, например, использует Lichess — огромная шахматная платформа, которую в основном поддерживает один разработчик-минималист. Я мог бы обойтись и без виртуального дерева, но на будущее решил взять.

— Pico CSS — здесь я как раз хотел немного магии. Красивый UI делать самому долго, а Pico отлично подошёл как готовое drop-in решение.

— VSCode — взял с минимумом плагинов. В отличие от тяжёлой IntelliJ IDEA, которая ломается от переименования папки, здесь всё было под контролем. Более того, проект я собирал не через VSCode, а только через терминал.

Такой стек максимально сократил количество абстракций. Если что-то ломалось — проблема была точно в моём коде, а не в нюансах работы библиотек.

🤖 И, конечно, главный инструмент — GitHub Copilot.
Сначала я боялся, что если он будет писать код за меня, я ничего не пойму. Но благодаря минималистичному стеку и простой задаче, код оставался прозрачным. В итоге копайлот написал процентов 30–40.

🎯 Главный вывод — чем проще инструменты и быстрее запуск, тем лучше. И даже проваленный проект даёт хороший опыт.

(часть 2)

👨‍💻 Джуниор

Я решил попробовать сделать расширение.

Моя идея была простой: расширение, которое скачивает все картинки с сайта в один клик.
По запросу images downloader в выдаче было всего два расширения, и одно вообще не работало. В Google Trends запрос выглядел перспективно.

🔥 Так как фронт я писать особо не умею, целью было просто прокачаться в разработке. Монетизацию и прочие штуки я тогда не учитывал.
Весь процесс — от идеи до загрузки в Chrome Store — занял около 4 месяцев. Я долго выбирал инструменты, разбирался с ними и параллельно был загружен другими делами.

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

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

(часть 1, часть 3)

👨‍💻 Джуниор

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

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

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

🚀 План такой
— Делаем только расширения для Chrome. Гугл сам проверяет и продвигает расширения в своём магазине, а значит, доверие к ним выше, чем к сайтам. Соответственно, в выдаче они тоже появляются чаще.
К тому же конкуренция ниже: расширений ~110k, а мобильных приложений в Google Play уже под 2kk.

— Берём существующее расширение с >10k пользователей и выделяем из него только одну функцию. Главное — чтобы она была простой и понятной, но реально нужной. Если аналогов с одной функцией уже хватает — пробуем улучшить UX: меньше кликов, удобные настройки по умолчанию и т.п.

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

— Дальше думаем, какой поисковый запрос пользователь введёт. Например, функция — скриншот всей страницы, тогда запрос будет "Full page screenshot". Проверяем в Google Trends и сравниваем с запросами "ad blocker" (мегапопулярный) и "site blocker" (среднепопулярный). Наш запрос должен быть хотя бы на уровне site blocker.

— Пишем быстро, без перфекционизма и чистого кода. Возможно, проект завтра выкинем. Если взлетит — потом отрефакторим.

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

— Запускаем. Если зашло — дорабатываем, если нет — ищем новую идею.

🙌 Более подробно про схему "Короче, капитан" они рассказывают на интенсиве.

(часть 2)

👨‍💻 Джуниор

🚀 Как я решаю сложные задачи

Для меня самое важное — полностью понять задачу ещё до того, как начать её выполнять.

Звучит банально, но под полным пониманием я имею в виду прям ПОЛНОЕ: не только суть, но и все технические детали, вплоть до того, какой код и где нужно написать.

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

💡 Почему это работает:
1️⃣ Это помогает точнее оценить время выполнения.
2️⃣ Легче расставлять приоритеты. Если застрял на мелочи — видишь общую картину и не утонешь в деталях.
3️⃣ Быстрее формулируются вопросы. Особенно важно, когда коллеги в другой таймзоне и доступны не всегда. Чем чётче и быстрее задаёшь вопросы, тем быстрее получаешь ответы.

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

👨‍💻 Джуниор

🤑 Собеседование на 100к€

Меня иногда зовут на собесы и я хожу ради опыта. Недавно позвали в Revolut - современный европейский банк с офисами в Дубае, Испании и Польше.

Расскажу как проходит собеседование к ним.

🗣️ Первый этап (как и везде) - скрининг, на котором hr рассказывает о компании.
В революте все строго с технологиями.
 - Нет спринга, с 21 года используется свой минималистичный DI-фрйемворк.
 - Только джава. Все остальные языки для бэка запрещены, даже котлин.
 - Револют - большая компания (~10к сотрудников) и эти правила распространяются на все команды. 
Для сравнения, в моей компании на ~1к человек есть и джава и котлин и c# и спринг и другие штуки.

Про опыт спрашивают о работе с многопоточкой, шардингом, репликацией и изоляцией в распределенных системах, TDD и DDD.
Задают пару простых вопросов о разных видах блокировок.

Ну и самое интересное - зп. Я попросил 85к€ - 100к€ в год до налогов и они согласились (жаль что не прошел🥲).

👨‍💻 Второй этап - лайв кодинг
Обычно на этом этапе решают алгоритмы, но в революте нужно сделать бизнес-задачу - либо load-balancer, либо url-shrotener.
Сами по себе эти задачи легкие, но тх нужно сделать в три этапа, на каждом этапе требования усложняются и код приходится переписывать, на каждом этапе решение нужно покрывать тестами, желательно по TDD, времени дается всего 45 минут.

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

⏭️ Следующие этапы - обсуждение технических тем, system design, собеседование с командой, но до них я к сожалению не дошел

👨‍💻 Джуниор