Коли готових рішень немає: мислення розробника та зростання через виклик

У багатьох розробників існує внутрішній «перемикач»: «ось це я можу реалізувати» і «ось це варто взяти готовим». Це логічний і корисний підхід — не вигадувати велосипед там, де вже є надійні бібліотеки, фреймворки чи сервіси. Але інколи виникають завдання, для яких готового рішення просто немає. І тоді в одних настає ступор, а в інших — момент зростання.

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

Уявімо приклад. Розробник створює multi-tenant базу даних і для запитів використовує перевірену клієнтську бібліотеку. Проєкт розширюється, і тепер потрібно надати зовнішньому інструменту звітності доступ до даних конкретної компанії. Технічні обмеження роблять старий механізм підключення непридатним. Замість адаптації існуючого рішення, розробник додає новий механізм зі своїм кешем. У результаті з’являються два альтернативні способи підключення, два кеша, більше відкритих з’єднань, зайва складність.

Чому не використати загальний механізм підключення? Відповідь проста — готового універсального рішення немає. І саме в цей момент визначається «кураж» розробника, про який говорили родоначальники екстремального програмування. Це сміливість реалізувати нову цінність, навіть якщо доводиться йти невідомим шляхом.

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

Такі нестандартні задачі

Читати далі

Що таке RAG і в чому з ним проблема

RAG (Retrieval-Augmented Generation) — це сучасна архітектура, яка дозволяє генеративним моделям (на кшталт ChatGPT/LLM) користуватися вашою локальною базою знань. Інакше кажучи, ви можете завантажити свої документи і спілкуватися з ChatGPT, яка володітиме всіма наданими їй знаннями.

RAG поєднує дві складові: генеративну модель (LLM), яка “вміє красиво говорити”, і зовнішню базу знань, яка “знає, де що лежить”. Ідея проста: коли модель не має потрібної інформації, вона спершу робить запит до бази, знаходить релевантні фрагменти тексту (retrieval), а потім формує відповідь на їхній основі (generation).

Виглядає перспективно й корисно. Але в чому ж тоді проблема?

Сучасні RAG нагадують людину з поганою пам’яттю, яка шукає способи компенсувати свою ваду. Вона починає впорядковувати знання: все записує, все класифікує. Ось у цій шухляді — інформація про ліки, які я приймаю, у тій — комунальні платежі, а десь там — переписка з друзями. Але ця організація не вирішує головної проблеми. Бо незрозуміло, яка саме інформація взагалі є. Через недосконалу структуру даних людина може шукати відповідь не в тій шухляді — або просто не помітити потрібне.

Переходимо від метафори до технічної реальності:

1. Модель не “пам’ятає”, а лише “запитує”

LLM у RAG не має справжньої пам’яті: кожен запит обробляється незалежно від попередніх. У моделі немає відчуття контексту розмови, історії користувача чи стратегічної мети. Вона нічого не згадує — лише витягує уривки з індексу.

2. Пошук працює як сліпа інтуїція

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

Читати далі

Як ми розв’язали задачу, яка не мала технічного рішення

Ми в ІнтерЛінк створювали систему бронювання сервісів із можливістю миттєвої купівлі. На перший погляд, задача здавалася типовою. Проте з перших же спроб стало очевидно: стандартний підхід не спрацює.

Чому так складно просто «забронювати»

Щоб підтвердити замовлення, потрібно виконати послідовно декілька кроків:

  • перевірити, чи доступний сервіс на обране клієнтом вікно часу (3 секунди),
  • забронювати його у провайдера (5 секунд),
  • провести оплату на наш рахунок (5–10 секунд),
  • підтвердити бронювання у провайдера (ще 5 секунд).

У найкращому випадку — 18 секунд. У реальному світі — ближче до 25.

Коли ми завершили базову реалізацію, з’ясувалося: прискорити цей процес технічно неможливо. Ми перепробували варіанти оптимізації, розглядали зміну послідовності дій, але кожен альтернативний сценарій або створював фінансові ризики для нашої компанії (наприклад, оплачувати замовлення до бронювання), або ламав логіку бізнесу.

Коли проблема не в швидкості, а в тиші

На етапі брейнштормів команда зробила важливе спостереження: користувачі рідко обурюються самою тривалістю процесу. Проблема — у відсутності зворотного зв’язку. Якщо система просто показує повідомлення типу “Booking is in progress…” і нічого більше не відбувається — користувач втрачає довіру. А отже — і покупку.

Це стало поворотним моментом. Ми переформулювали задачу: нам не потрібно пришвидшувати процес, якщо ми зможемо зробити його зрозумілим і передбачуваним.

Прозорість як інструмент довіри

Ми змінили інтерфейс і розбили процес на чіткі етапи з миттєвою зворотною реакцією:

  • Перевіряємо доступність часу — Ура, час доступний.
  • Бронюємо сервіс — Супер, бронь підтверджено.
  • Проводимо оплату — Чудово, гроші отримано.
  • Оформлюємо підтвердження — Готово, усе працює.

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

Що варто винести з цього кейсу

Користувачі не проти чекати — якщо

Читати далі

#Meeting room з Software Engineer: 10 років на проєкті – нудно чи захоплююче?

Коли проєкт – як ціле життя, в якому було і зростання, і стратегічні зміни. Ми раді, що є проєкти, які з нами вже багато років. Не менш цінуємо людей, що вже стільки років поспіль невтомно допомагають зростати таким проєктам. Сьогодні ми спілкуємося з такою людиною – нашим Software Engineer Олександром, який провів на ентерпрайз проєкті більшу частину своєї кар’єри. Приємного читання!

Розкажи як ти потрапив на роботу програмістом в ІнтерЛінк?

Після завершення університету я почав пошук роботи. Переглядаючи вакансії, я вирішив тримати фокус орієнтовано на Java, оскільки я вивчав це на одному з останніх курсів, та, порівняно з іншими високрівневими мовами, Java була мені найкомфортніша. Навіть не пам’ятаю як саме, але серед перших знайдених мною пропозицій була вакансія для початківців від ІнтерЛінк.

Це була моя перша співбесіда, тому я нервував, та мабуть трохи наївно сподівався, що підготовки за конспектами та матеріалами, що залишилися з універу, буде достатньо. Що ж, це був провал :). Але щось-таки я зміг продемонструвати достатньо, щоб отримати рекомендації як підвищити рівень своїх знань, і вже пізніше спробувати знову. Так і йшов надалі мій час за сторінками Thinking in Java.

Читати далі

#Meeting room: спілкуємось із Senior Software Engineer

Доброго зимового ранку, шановні читачі нашого блогу. Сьогодні у нашій #meeting room ми говоримо з нашим Senior Software Engineer Володимиром. Чи дійсно написання коду – це основна робота програміста та що найголовніше у командній роботі? Приємного читання!

Яке твоє найбільше усвідомлення за роки у сфері розробки?

Всі ми вміємо гарно виконувати свою роботу, наприклад – писати код або тестувати функціонал. Але не менш важливим є створення комфортної обстановки у команді та у спілкуванні із замовником. Саме взаєморозуміння у команді дозволяє створювати чудові продукти та ділитися навичками у команді.

Продолжить чтение

Читати далі

#Meeting room: спілкуємось із QA Lead

Ми продовжуємо знайомити вас із нашою командою. І сьогодні ділимося роздумами нашого QA Lead Романа про напрямок тестування та розвиток у цій професії. Приємного читання! 

Як ти прийшов у професію? Відразу хотів цього чи розуміння прийшло з часом?

Так вийшло, що я нічого не знав про тестування і починав працювати в першій IT-компанії як Technical Writer.
Згодом задач по розробці документації було не так багато, а у відділі тестування було багато задач та мені запропонували спробувати допомогти. Так я втягнувся і повністю став тестувальником.

Як зрозуміти, що тестування – це твоє? Які плюси та мінуси цієї професії?

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

Читати далі

#Meeting room: спілкуємось із Project Manager

Професія РМ – багатогранна та захоплююча. Як врахувати інтереси всіх сторін, переключатися між різними задачами та проєктами, управляти своїм часом та при цьому не втрачати натхнення та знаходити час для власних проєктів? Сьогодні ми запитали у нашої енергійної Олени Кондратової.  

Чим тебе зацікавила професія РМ?

У школі мене називали завгоспом. Коли була можливість взяти на себе відповідальність – я завжди брала і намагалася довести поставлену задачу до кінця. Через 10 років виявила, що професія менеджера – це саме про це. Я вступила на факультет математики і інформатики, де майже усі кодили і були програмерами. Але я відчувала, що мені більше подобається комунікація, планування і структуризація. Випадково я дізналася, що програмерами має хтось керувати або слідкувати за процесом, іншими словами. Зрозуміла, що це якраз для мене, так я стала PMом :).

Що найбільше тобі подобається у роботі

Читати далі

#Meeting room: спілкуємось із Software Engineer

Коли потрібно десь взяти сили та натхнення, ми надихаємося нашою драйовою та відкритою до викликів командою. Ділимося цим натхнення з вами! У сьогоднішньому інтервью трохи рефлексії від нашого досвідченого розробника Владислава. 

Розкажи про свій шлях в компанії

Напевно почну із порівняння себе зі сліпим кошенятком, яке потрапило на інтернатуру, маючи невеликий досвід декількох лабораторок з універу. Тут я познайомився з чудовим ментором Олександром Котовим, який став для мене та інших інтернів як “котяча мама”, котра підштовхує свою дитину в правильному напрямку. Після закінчення інтернатури, для мене відкрився величезний світ IT. До цього моменту я встиг побувати на дуже різноманітних проектах. Одні були великі, з великою командою, інші маленькі, навіть доводилось працювати самому. Всі ці проєкти обʼєднувала одна невідʼємна річ – це класні люди. Тімліди, техліди, QA, менеджери, та навіть замовники – всі вони зробили значний внесок у формування мене як професіонала, за що я безмежно вдячний кожному. Зараз же команда вже формується навколо мене, і я стараюсь передавати той досвід, якого

Читати далі

#Meeting room: спілкуємось з РМ – Написання ефективного Escalation Email

Несподівані виклики у проектах, це не рідкість, навіть з ретельним плануванням. Проте, те, як ви комунікуєте та ескалюєте ці проблеми, може зіграти ключову роль у їх ефективному вирішенні. Нижче ви знайдете детальний гайд по тому, як написати ефективний лист-ескалацію (escalation email). За допомогою цього гайду, ви зможете ескалювати вирішення проблеми нагору, до стейкхолдерів, керівництва та зацікавлених сторін, щоб подолати “затор” та разом знайти вихід з ситуації.

Дотримуйтесь дружнього тону

Ввічлива та дружня комунікація є важливою у складних ситуаціях. Пам’ятайте, що ефективна комунікація сприяє співпраці та розумінню. Ставтеся до зацікавлених сторін так як очікуєте, щоб ставилися до вас.

Поясніть проблему

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

Читати далі

#Meeting room: спілкуємось з Team Lead

П’ятниця – прекрасний день для знайомств. Тому сьогодні ми знову представляємо читачам нашого колегу. Цього разу це досвідчений інженер, тімлід та наш запальний спікер-мотиватор технічних івентів ІнтерЛінку – Владіслав Козленко. Владіславу вдається не лише вирішувати будь-які проєктні задачі та робити наших замовників щасливішими, а й самому насолоджуватися своєю справою та навіть знаходити час на домашніх улюбленців :). 

Ділимося вайбом та натхненням в інтервью нижче.

Що найбільше надихає тебе у роботі?

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

Які твої найбільші інсайти за час роботи Software Engineer-ом?

Найбільшим моїм відкриттям колись давно став JavaScript. Це був швейцарський ніж, який я взяв до

Читати далі