Backend CV у 2026: годі писати стек, починай писати цифри

Відкрий поспіль десять Backend CV і побачиш одну й ту саму першу секцію: "Мови: Python, Go, Java, Rust, Node.js. Бази: PostgreSQL, MySQL, MongoDB, Redis, DynamoDB". Стіна іменників, з якої не зчитується нічого. Senior-інженер, який читає твоє CV, хоче зрозуміти одне: ти хоч раз рухав реальне число на реальній системі чи поки що тільки тегав себе тулзами у LinkedIn?

За чим насправді фільтрують hiring-менеджери

У 2026 цифри latency і throughput у твоїх пунктах важать більше за вибір мови. Коли я бачу "p99 80мс на 1200 RPS", я розумію, що людина запустила сервіс, дивилася в графік і знає, що показує цей графік. Коли я читаю "будував REST API", я не знаю взагалі нічого. Ринок давно переїхав з найму "по мовах" на найм "по системах". Якщо у тебе немає хоча б трьох пунктів з конкретним числом і одиницею (RPS, мс, %, $, GB), програєш кандидату, у якого їх п'ять.

Форма пункту, яка виграє щоразу

Ось зразок: "Спроєктував і запустив платіжний мікросервіс на Go з 1200 RPS і p99 80мс". Працює тому, що в одну фразу вкладено три речі: що зробив, у якому масштабі, з якою продуктивністю. А поруч у тому ж CV може бути ще один: "Оптимізував SQL у PostgreSQL, середній час відповіді API впав з 850мс до 120мс". Та сама форма, інша система, і вже виходить цілісна картина людини, яка міряє те, що робить, а не просто кодить.

Що додати у навички у 2026

• Distributed tracing (OpenTelemetry, Jaeger, Datadog APM)
• Async-меседжинг не тільки Kafka: NATS, RabbitMQ, SQS, EventBridge
• Observability-стек, який ти сам розгортав, а не просто "дивився у графіки"
• gRPC і Protocol Buffers, лише якщо ти їх реально запускав у проді
• Перемоги у cost-оптимізації (storage, egress, compute) з конкретним $ економії

ATS-пастка backend-розробника

У backend-розробників звичка писати все через слеші: "Python/Go/Java", "REST/GraphQL/gRPC". ATS погано розбирає слеші: інколи зчитує одне велике слово, інколи розриває довільно, і у підсумку три твої сильні навички перетворюються на одне слабке збігання. Просто пиши через кому: "Python, Go, Java". Те саме що було, але keyword density удвічі вища.

System design питання, яке відсіює mid від senior

"Спроєктуй скорочувач посилань на 100 мільйонів користувачів". Кандидат mid-рівня одразу починає малювати hash-функцію і key-value сховище. Senior спочатку ставить три питання: яке у нас співвідношення reads до writes, який очікуваний QPS, скільки взагалі тримати посилання. Уся пастка, почати малювати раніше, ніж зрозумієш задачу. Перші три хвилини витрать на уточнення. Один цей хід покаже твій рівень сильніше за будь-яку архітектурну схему, яку ти потім намалюєш.