🔥Фідбек по останньому мок інтервʼю - Node.js
Дякую за такий теплий фідбек - дуже цінно знати, що мок-інтерв’ю було корисним 🙌

Про наступні слоти напишу згодом

Ще раз дуже дякую за можливість пройти мок-співбесіду
Отримав конструктивний фідбек як щодо мого CV, так і щодо проходження співбесіди загалом
Завдяки цьому визначив для себе проблемні моменти в моєму позиціонуванні як кандидата та самопрезентації. Також отримав рекомендації щодо покращення CV, як зробити його більш бізнес-орієнтованим, на чому робити акценти та як оптимальніше подавати досвід.
Окремо визначили пріоритети щодо подальшого розвитку у контексті фулстак-експертизи та поглиблення технічних знань.
Однозначно, це був дуже класний та корисний досвід) тепер точно маю над чим працювати для мого подальшого розвитку як спеціаліста та перед проходженням реальних співбесід у найближчому майбутньому)

Фідбек по сьогоднішньому мок інтервʼю - Frontend
Дякую за такий теплий фідбек - дуже цінно знати, що мок-інтерв’ю було корисним 🙌

Про наступні слоти напишу згодом

Проходячи інтервʼю Олександр давав настанови по питання, по формулюванням відповідей, для себе виніс теми які треба під учити і опрацювати, дуже дякую за приділений час і сили 🙌, розібрав CV, проконсультував в питаннях пошуку роботи, як ментор я його рекомендую, хто боїться проходити ці тех співбесіди дуже рекомендую скористатись такою можливістю, безкоштовно підняти впевненість і чітко зрозуміти свої пробіли в інформації чи в тому як формулювати відповіді щоб можна було запрезентувати себе на всі 110% 😁

Що краще для MVP - SQL чи NoSQL?

Зазвичай це одне з найбільш дискусійних питань на старті будь-якого проєкту. Звісно, усе залежить від бізнесу, але давайте трохи узагальнимо й візьмемо середню картину. Для недосвідченого розробника на перший погляд NoSQL-бази даних часто здаються кращим вибором, адже вони виглядають зручнішими з точки зору гнучкості даних і зв’язків між ними.

На практиці все інакше. І навіть якщо спочатку здається, що зв’язків мало, з часом вони точно почнуть з’являтися, а ваші дані можуть перетворитися на хаос.

Один із яскравих прикладів - це зв’язка Serverless і DynamoDB. Буквально кілька років тому її активно просували майже в усі проєкти, аргументуючи це тим, що так дешевше. Насправді ж DynamoDB вимагає від розробників розуміння доволі складних концепцій, як-от Adjacency List чи Materialized Graph, з якими ніхто не хотів розбиратися 🗿🗿🗿

Тому такі проєкти часто трималися на різних костилях, а з часом їх поступово мігрували в умовний PostgreSQL або обкладали додатковими рішеннями для реалізації складних вибірок даних. Один із найпоширеніших варіантів - DynamoDB для запису + реплікація в Elasticsearch для вибірки.

У цілому NoSQL - це круте рішення, коли ви вже добре знаєте модель даних і у вас виникає потреба оптимізувати певні частини системи. Тоді має сенс мігрувати частину даних із реляційної моделі, щоб вирішити конкретний bottleneck.

Але починати проєкт зазвичай найзручніше з SQL, тому що це:
- чітка схема;
- зручні міграції даних;
- менше сміття в даних;
- цілісність даних.

Закінчив роботу над структурою першого курсу 🔥

У ньому розповім, як ефективно шукати роботу. Розглянемо основні теми, дотичні до цього процесу, які будуть відсортовані в порядку підготовки до отримання оферу.

Після того, як я його закінчу - він буде доступний на Udemy i також на сайті. Щоб не пропустити, ви можете підписатись на нотифікацію і отримати email, як тільки курс буде закінчений.

Тут можна детально ознайомитися з курсом і увімкнути нотифікацію:
https://devs-hive.tech/uk/courses/vid-cv-do-ofera

Як завантажувати файли?

Як на мене, організація завантаження файлів на бекенд - це доволі цікава тема, і її варто розкрити.

1️⃣ multipart/form-data
Старий дідівський підхід, яким чомусь і досі користуються в 2026. Клієнт надсилає файл прямо на бекенд. Він приймає його, обробляє і вже потім заливає кудись у сховище.

Плюси:
- Простота реалізації, але тільки в PoC, MVP

Мінуси:
- Зайве навантаження на систему
- Складне масштабування
- Необхідність реалізації лімітів, ретраїв і таймаутів

2️⃣ Signed upload URL
Сучасний спосіб, який працює в усіх Cloud Providers (AWS, GCP…). Ідея в тому, що бекенд не займається завантаженням файлів напряму. Замість цього він генерує для клієнта тимчасовий signed URL, за яким файл можна завантажити одразу в Storage.

Плюси:
- Менше навантаження на бекенд
- Краща масштабованість
- Швидший upload
- Бекенд відповідає лише за авторизацію і правила доступу

Мінуси:
- Архітектурно складніше

Оновлення на сайті
Останнім часом, закидую все більше питань для інтервʼю. Тому хто зацікавлений в підготовці чи просто хоче глянути актуальні запитання в українських і ЄС компаніях, ловіть оновлення за останні дні:

Databases:
- Як працює CROSS JOIN?
- Як працює INNER JOIN?
- Як працює FULL JOIN?
- Що таке Triggers в базах даних?

🔥AI (новий топік, який актуальний для Backend/Full-stack напрямків):
- Поясни різницю між short-term i long-term memory
- Що таке Embeddings?
- Що таке Tokens в LLM?

🔗 - https://devs-hive.tech/uk/interview-qa

Результатом демократичних виборів, перша буде по Fullstack😁

Якщо ви думали, що з приходом AI вдасться ухилитися від вивчення Core, то ні - навпаки 😁

AI може пришвидшити роботу, підсилити вас і згенерувати код, але без розуміння того, що ви робите, далеко не заїдеш.

Якщо справа стосується SQL, то з мого досвіду АІ генерує доволі цікаві атракціони, які потрібно підчищати, оптимізовувати і часто переписувати. І я зараз не описую якісь специфічні кейси, а маю на увазі звичайну рутину де ви використовуєте ORM, QueryBuilder i інші абстракції.

І це з нормальними моделями по типу Opus 4.6, якщо увімкнути режим auto - ситуація стає ще гіршою.

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

SQLBolt - https://sqlbolt.com/

Хто пробував Opus 4.7, які враження?
В мене все частіше зʼявляється відчуття, що Anthropic перейняв найкращі практики в Apple. Коли перед виходом IPhone, вони починали уповільнювати старі моделі, щоб нова здавалась крутою, на фоні уповільнених😅🚬🚬

Лайфхак для тих хто використовує Cursor🔥
Відмініть підписку і вам запропонують знижку 50% на наступний місяць. Я перед зняттям коштів вибив собі таку акцію

*Те саме з ChatGPT😁

Для тих хто хоче розібратись в АІ
В цілому ресурсів багато, але головне правило - це не слухати інфоциган, які пробують продати свій гайд по Claude чи те як заробляти з n8n.

Ловіть один з крутих ресурсів по основам від Stanford - https://www.youtube.com/watch?v=Ub3GoFaUcds&list=PLoROMvodv4rOCXd21gf0CF4xr35yINeOy

Це звичайно не курси з instagram від різних АІ гуру, але теж дуже непогано. Головне запастись терпінням, бо деякі теми доволі складні і можуть спричинити підгорання нижче спини😁

Що почитати про PostgreSQL?
Так як AI перебрав на себе рутину, саме час прокачувати дійсно актуальні і важливі навички.

PostgreSQL це зараз стандарт і по відчуттям, найпоширеніша, в екосистемі Node.js база даних тому розуміння оптимізації і того як вона працює, це точно хороший плюс.

Дуже цікава книга, яка рефрешне різну теорію: індекси, алгоритми, OLTP/OLAP, DML, селективність, кешування….

Для мене особисто, найцікавіше було копнути Optimizer i розібратись з execution plans - як читати і оптимізовувати. Також ця книга позакривала багато гепів по теорії і дала краще розуміння того, як влаштовані сучасні бази даних.

Думаю книга підійде всім, хто хоче глибше розібратись в PostgreSQL.

Чи робити тестове?

Колись я вже робив відео про тестові завдання, але хочу продублювати свої думки в Telegram. Коли варто погоджуватися на тестове:

1️⃣ Це цікавий для вас продукт (не галера), прямий контракт і рейт вище ринку;
2️⃣ У вас немає фінансової подушки хоча б на кілька місяців, тож потрібно швидко знайти роботу;

В усіх інших випадках можна спокійно слати на*уй, коли вам пропонують тестове 😁

2000 підписників на YouTube 🍾🎉
Оскільки аудиторія каналу зростає, поділюся деякими змінами, які планую саме для YouTube-каналу:

1️⃣ Будуть стріми
Подій і новин, які варті уваги, доволі багато, і думаю, було б цікаво обговорювати їх наживо.

2️⃣ Трохи зміниться фокус відео
З’явиться декілька нових форматів, які, обіцяю, будуть дуже цікавими.

3️⃣ Технічний контент — всьо? 😱
Він теж буде, але без туторіалів. Більший нахил буде в архітектуру, системний дизайн і огляд різних технологій, підходів і тд. А от сухі навчальні відео перекочують у курси на Udemy, сайт і частково Telegram.

Оновлення для прихильників найбільш переоціненої ORM в історії

- Додали Prisma Bootstrap. Я навіть не знаю, кому це може бути корисно, але най буде.
- Також є оновлення в Prisma Studio. Може зайти тим, у кого немає грошей на TablePlus або хто не знає, як запустити PGAdmin у контейнері.
- Окремо виділю, додавання АІ в Prisma Studio. Тут реально буде корисно для тих, хто готовий злити весь prod dataset 😁

Що не додали?
- Query Builder як не було, так і нема тому для складних запитів доведеться писати raw SQL або використовувати криві мапінги, які пропунує Prisma.
- Triggers, Stored Procedures, Materialized Views - тут все стабільно (їх теж не додали) 😑

Кому цікаво почитати детальніше, зробити це можна тут

Ілюзія ефективності АІ 😱

Сьогодні хочу поділитися своїми спостереженнями щодо використання AI. Він справді добре автоматизує рутину й дозволяє зосередитися на важливіших речах, але зі складними задачами є нюанси.

Зазвичай, на такі задачі найбільше впливає бізнес, який часто сам не розуміє, як усе має працювати. Через це вимоги змінюються частіше, ніж релізи нових JS-фреймворків.

У таких випадках AI створює ілюзію швидкості, бо за день-два генерує першу версію. Але що більше змін, то більше технічного боргу й втрати контексту в розробника. А це веде до того, що будь-які нові зміни можуть ламати вже наявний workflow.
Фактично, це проблеми, з якими стикалися всі, хто працював із legacy-системами. Але зазвичай, перехід у такий стан відбувається після місяців або років розробки, або після передачі системи на аутсорс в Індію 😁

У випадку з AI цей процес прискорюється: система чи окремі її компоненти дуже швидко переходять у стан legacy. З моїх спостережень, якби розробник не перекладав таку задачу повністю на AI, а використовував його як утиліту для контрольованої й точкової генерації коду, наприклад для створення сервісів, сутностей чи міграцій, то в short-term це було б трохи повільніше, ніж повна генерація через AI.

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

Це ще раз доводить тезу: AI - це просто інструмент, який допомагає вирішувати задачі, але не вирішує фундаментальних проблем у розробці ПЗ.

Найкращий інструмент, для залежностей в ваших тестах🔥

Один із важливих плюсів АІ в розробці - це можливість швидше і ефективніше покривати код тестами. Якщо з unit-тестами все зрозуміло: залежності можна замокати, ізолювати окремий модуль і перевірити його поведінку, то з інтеграційними та e2e-тестами все складніше.

Такі тести мають перевіряти, як система поводиться в умовах, максимально наближених до реального середовища і залежності у вигляді бази даних, кешу і т.д., мають відображати реальну поведінку.

На даний момент найкраще, з чим я зіштовхувався для керування залежностями, - це Testcontainers. Замість того, щоб страждати з розгортанням контейнерів вручну, просто встановлюєте його як npm-пакет і одразу починаєте використовувати.

Наприклад вам потрібно протестувати код, який використовує ElasticSearch:

npm install @testcontainers/elasticsearch --save-dev

const container = await new ElasticsearchContainer("elasticsearch:7.17.7").start();

📎 - https://testcontainers.com/

Сьогодні зарелізили Node.js 26.0.0 (Current)

З важливого - Temporal API тепер активне по замовчуванню🔥

Детальніше можна почитати тут