Video summary

Куда идти в IT в 2027: 6 направлений, где реально найти работу

Main summary

Key takeaways

Educational

Main ideas, concepts, and lessons

  • IT is diversifying, and “where to go next” needs a structured map

    • The speakers argue that the old IT hype bubble has passed: getting a job can feel harder, competition is higher, and new roles have emerged.
    • Since new professions/paths keep appearing, beginners need a clear comparison of directions by skills, market demand, entry difficulty, etc.—not guessing.

  • Web service as a unifying example

    • The webinar is built around a hypothetical food delivery product (a small local service that expands into a multi-city system).
    • This product is used to explain how roles work across the product lifecycle:
      • frontend → backend → QA → DevOps
      • plus changes related to AI.

  • Three “global” classical directions highlighted (then expanded)

    • Even though the title mentions “6 directions,” the subtitles mostly cover:
      • Frontend
      • Backend (Java/Python)
      • DevOps
      • Manual + Automated QA/Testing
      • then AI/LLM automation & “vibecoding/vipecoding” (AI-assisted coding)

Webinar structure & learning methodology (as described by the host)

Interactive format

Viewers are repeatedly prompted to:

  • participate in the chat
  • write personal background (1–4 scale + why they joined)
  • ask questions and provide feedback

Product-based walkthrough

  • Speakers choose a product scenario (food delivery) and explain:
    • what needs to be built
    • what specialists do
    • what tech/skills are typical for each direction

Starter packs + comparison tables

  • For each direction, organizers plan to provide (in chat) starter packs with:
    • required skills
    • example tasks
    • market vacancy quantity/difficulty
    • nuances of entering the profession
    • suggested next steps
  • They also promise:
    • comparative tables across directions
    • Q&A at the end

Question handling & logistics

  • A recording will be sent later.
  • Time is limited (“until 2:00”); unanswered questions may be handled later.

Direction 1: Frontend development (food delivery UI)

Main frontend screens / user-facing parts

  • Restaurant/catalog list
  • Basket/cart
  • Order tracking page (status updates, courier location)
  • User profile/order history
  • Payment methods management
  • Address management

Frontend definition

Frontend = the part of the service that the user interacts with directly in the browser/device (forms, buttons, UI logic).

Core technologies mentioned

  • HTML: page structure
  • CSS: styling/visual design
  • JavaScript / TypeScript: application logic (e.g., basket/cart behavior)
  • Frameworks/libraries: React or Vue
  • Styling tools: Tailwind CSS
  • Routing & rendering: Next.js (routing and service/site rendering)

“Pay button” flow concept (frontend → backend)

Clicking “Pay” triggers:

  • an API request to the backend
  • preliminary frontend processing (validation/packaging of data)

Direction 2: Backend development (Java and Python) using the food delivery workflow

Frontend vs backend responsibilities

  • Frontend: user interaction + sending requests
  • Backend:
    • processes requests
    • performs checks
    • communicates with external services (e.g., payment)
    • updates the database
    • triggers restaurant/courier logic

Pay workflow steps (backend perspective)

  1. API request arrives at the backend from the frontend
  2. Order verification: validate cart items/products
  3. Promo code validation: correctness + still valid (not drained/expired)
  4. Address validation: ensure within delivery service area
  5. Order total validation: ensure sum is correct
  6. Payment processing via payment service
    • backend calls external payment API
    • card payment may be skipped if already attached (edge concept)
  7. Payment outcome: success vs failure
  8. Status update logic
    • backend updates order status on payment success
    • discussed failure mode: money can be written off but order status might not update
      • due to technical issues/integration problems
  9. Trigger next business actions
    • if paid: mark order “ready for execution” and notify restaurant
    • assign courier, wait for restaurant pickup → user delivery

Backend language selection: Java vs Python (as presented)

  • How decisions are made in teams

    • team competencies
    • architecture needs
    • long-term maintenance plans
    • labor-market availability

  • Java

    • suited for large, long-lived, serious systems
    • common framework: Spring Boot
    • notes:
      • predictable under load
      • heavier learning curve due to Spring ecosystem breadth

  • Python

    • suited for MVP/prototypes and fast iteration
    • used more for AI/Data Science/Data Analytics and often in startups
    • still used in large systems, but frequently chosen for speed/flexibility

Backend “starter pack” general skills (language-independent)

  • HTTP basics
  • REST API design/usage
  • SQL for databases
  • Git version control
  • Testing basics + writing tests
  • Algorithms / processing structured data
  • Logging & debugging
  • Security and secrets management
  • Asynchronicity (handling many simultaneous requests)

Backend-specific tech listed

Java

  • Java Core (syntax + collections)
  • OOP
  • Spring / Spring Boot
  • Maven or Gradle
  • JVM concepts (memory/performance monitoring)

Python

  • Python Core
  • Typing
  • Virtual environments
  • Frameworks: Django and FastAPI
  • Testing: Pytest (mentioned as “Pest” in subtitles)
  • Packaging/build tools: pip / Poetry

Big point about AI in development (“will it replace developers?”)

The speakers argue AI/LLMs increasingly automate:

  • boilerplate code (e.g., CRUD patterns)
  • parts of debugging (log analysis)
  • test generation (with caution about “show testing”)

Conclusion: developers aren’t “replaced,” but shift toward:

  • architecting
  • supervising correctness
  • integrating AI output into real systems

“Full-stack” trend question (frontend+backend blending)

The speaker agrees full-stack is increasingly common:

  • fewer hires needed when teams use assistants/automation to complete cross-domain tasks

Direction 3: DevOps engineering (scaling & deployment)

When DevOps is needed (story-based trigger)

As the delivery service grows to:

  • many cities
  • tens/hundreds of orders per hour
  • frequent updates/promotions

A DevOps engineer is introduced for:

  • fast deployments
  • scaling
  • logs/alerts
  • quick incident response

Starter pack for DevOps (skills/tools listed)

  • Linux administration
  • Docker and containerization concepts
  • Cloud deployment: AWS, Google Cloud, Yandex Cloud
  • Networking basics
  • Monitoring: Prometheus + Grafana
  • Logging systems
  • Kubernetes (advanced level mentioned)

DevOps goals

  • Deploy changes quickly
  • Detect problems before users suffer
  • Handle load without timeouts

“DevOps now + AI-first pipeline” (how they describe change)

Instead of writing code “on the fly”:

  • write a detailed technical specification
  • have AI generate code
  • AI runs tests + adjusts output
  • developer reviews and then merges to production

Direction 4: Testing / QA (manual + automated, with AI assistance)

Main test scenario (food delivery)

Restaurant → Basket → Promo code → Payment → Delivery

Example: payment test cases (categories listed)

  • Successful payment
  • Negative cases:
    • incorrect card data
    • insufficient funds
    • network/payment interruptions
    • money written off but order status not updated
  • Focus: payment is business-critical/risky, so it’s heavily tested

Promo code test categories

  • Valid code → correct discount/application
  • Invalid/negative cases:
    • discount miscalculation
    • amount below threshold
    • expired promo codes/rules
    • service logic errors

Address and delivery test categories

  • Address within service zone vs outside zone
  • Delivery cost correctness
  • Wrong/changed delivery cost cases
  • Delivery calculation and external dependencies

Automation strategy (guidance-style)

  • Not everything must be automated
    • automate only stable, critical, repeatable cases
  • Rough split:
    • 70–80% automated tests for risky/stable parts
    • 20–30% manual for changing/UX/complex explorations

Examples:

  • Successful payment: automate (stable)
  • Network loss: manual (situational)
  • New promo code/changing promo rules: manual (automation maintenance burden)
  • Delivery calculation: more manual due to external dependencies
  • UI/UX checks: manual

Manual testing tools mentioned

  • Postman
  • Swagger
  • Charles Proxy
  • SQL (at least for basic table/connection work)
  • Figma (design/layout references)
  • Confluence
  • QA/test documentation systems (QAS mentioned)
  • TestRail
  • Grafana/log tools, and reading backend logs

Automated testing approach

Need:

  • programming language knowledge
  • framework knowledge
  • Git workflow (commit/merge)

Tooling mentioned for automation stack:

  • Selenide / Selenium WebDriver
  • mobile testing mentioned (Play for mobile; Android/iOS split implied)

AI assistance in QA (Claude mentioned):

  • AI generates test cases/checklists from requirements
  • AI helps analyze logs to locate issues faster
  • AI drafts reports and supporting artifacts
  • AI speeds documentation and research tasks

Career guidance inside QA

  • Trend: companies want automation-capable QA
  • Advice:
    • enter QA via manual first, then move into automation
  • Hiring dynamics:
    • more demand for manual than automation positions for juniors
    • automation testers are still in shorter supply

Resume targeting advice (for QA too)

  • Tailor your resume to each vacancy’s requirements (recruiters/HR may filter aggressively).

Direction 5: LLM/AI automation and “vipe/vibecoding” (AI-assisted work & coding)

Three layers of usage presented

  1. Business automation (bots for support, knowledge base help, notifications, document processing)
  2. AI as a coding assistant (coding agents, test generation, integration)
  3. “Wipe coding / vibecoding”: rapid creation of prototypes using LLM prompts

What business typically wants to automate (examples)

  • Knowledge base + bot for simple support questions
  • Improve internal info:
    • organize/transcribe conversations
    • highlight important parts
  • Generate additional data and automate follow-up actions
  • Add notifications and routine processes

Caution: don’t replace “first-line support” blindly

The speaker explicitly calls replacing first-line support a bad decision.

  • AI should act more like “zero support line” / triage/help, not fully remove support roles.

Vibecoding: what it is (as described)

Best for cases where:

  • results don’t need unique, hand-crafted perfection
  • speed and low effort matter
  • you need a cheap prototype quickly (landing pages, dashboards, converting Excel to UI, simple scripts)

Framed as:

  • a skill/role leaning toward automation/scripting and rapid prototyping
  • often suited to freelancers more than in-house “headhunter” roles (as claimed)

“AI automation engineers / LLM integration roles” vacancy growth

  • Subtitles indicate inconsistent/unstandardized job titles (unclear keywords)
  • Related vacancy keywords exist (AI engineer, LLM automation engineer, prompt/LLM engineer, etc.)
  • Predicted growth as the market matures

Security/architecture concerns (LLM in real systems)

LLM usage should be layered and protected:

  • data anonymization
  • protection from injection attacks
  • controlled extraction of relevant info
  • use of tools (search/database/RAG/system prompt context)
  • response verification layers
  • NDA handling:
    • avoid sending confidential info to third-party models
    • local models reduce risk

“Trust but don’t trust fully”:

  • verify output; don’t blindly rely on coding agents.

Direction 6 (implied in discussion): Career and market navigation (Hexlet context)

Job search tactics and internships

  • For top companies:
    • use referrals
    • apply to internships (trainee positions)
    • note strong intern pipelines at leading universities (e.g., MSU, HSE, SPbU)

Ageism discussion

Age bias is framed as mostly related to:

  • which languages/tech are popular among certain age groups
  • older candidates being pushed toward “systems languages” (C/C++/Rust/Haskell mentioned)

Main claim:

  • if you pass interviews and show interest/competence, age shouldn’t block entry.

“Experience boosting / lying on resumes” (strong stance against)

  • Hexlet does not recommend inflating experience:
    • it may work short-term
    • but can fail in interviews or become harder after hiring

Pet projects: helpful but not a guarantee

  • Pet projects can:
    • demonstrate practical thinking
    • explain stack choices
    • enable deeper discussion
  • But they’re not a universal solution:
    • screening bottlenecks exist (not all candidates reach hiring managers).

Speakers / sources featured (identified from subtitles)

  • Kirill Dediko — event producer; organizer/host (Hexlet)
  • Valentin Ipchuk — backend/development speaker (ex-engineer at fintech startup “Shioda”)
  • Anya — testing/QA speaker (works at “Kata Insurance Company”; previously manual tester and QA automation for web app using WebDriver enhancements/Selenide)
  • Rustam Varkhanov — AI/LLM automation speaker; senior engineer/programmer integration department in Finam; also a Hexlet teacher for an “LM” course
  • (Other named expert panelists mentioned):
    • E Anna Klimacheva — speaker (testing directions implied; cameras turned on)
    • Rustam Varkhanov — already above
    • Valentin Ipchuk — already above

Original video