Summary of "СОБЕСЕДОВАНИЕ в ЯНДЕКС на frontend-разработчика. Этап 4: Проверка опыта во frontend"

Context

Video documents Stage 4 (“experience check”) of a Yandex frontend developer interview.
Duration: ~1 hour, focused on the candidate’s past projects, technical choices, development process, and short technical questions.
Interviewer answers questions about working at Yandex.

Current product: an internal portal for storing and generating regulatory and partner reports. The product automates an email-driven accountant workflow.
- Features: editing reports, configuring automations, sharing/adjusting and executing report flows.
Team composition:
- Small frontend team: 3 frontend developers (including an Expert).
- Product owner, analysts (2), testers (manual + automation), QA.
- No dedicated designers or DevOps in-team.

Frontend: React.
Data fetching/caching: request/cache library (similar to React Query / request caching).
Styling: design system / UI kit (Uikit); styled-components or scoped CSS (referred to as “ST comp”).
Forms/validation: form handling library (implied react-forms / react-hook-form).
Backend integration:
- OpenAPI (shared schema) in a separate repository; contract-first approach for microservice APIs.
- BFF (Backend-for-Frontend) pattern used to aggregate and optimize data from multiple microservices when necessary.
CI/CD and branching:
- Pipelines declared in files (editable by team members).
- Branching model: master and periodic release branches; releases ~every two weeks.
- CI runs tests and type checks; testers deploy to QA stands.
Feature flags used to avoid breaking changes when backend and frontend change out of sync.

QA uses a mix of manual and automated testing; developers and QA decide on coverage together.
Emphasis on meaningful test coverage (business logic, tricky validations) rather than 100% coverage.
Visual/screenshot tests are avoided or removed when fragile (no heavy pixel-perfect visual testing).
Common test issues: flaky tests and timeouts; switching test runners/implementations reduced timeout failures.

Request tracing:
- Trace IDs included in request headers (traceparent-like format, 16-byte IDs) to correlate frontend errors with backend traces.
Use traces and service-level graphs (response time, error rates) to locate slow or overloaded microservices.
Frontend/performance metrics are not always present but recommended:
- Suggested to track Lighthouse/PageSpeed metrics (LCP and others) per release.

Diagnose with browser DevTools
- Use Network panel to find slow or failed requests.
- Inspect which requests block rendering.
Use distributed tracing
- Find slow microservice calls via trace correlation.
Improve rendering / perceived speed
- Consider SSR or hybrid SSR + SPA to deliver initial HTML/skeleton.
- Use skeleton screens / placeholders while data loads.
- Defer non-critical scripts (async/defer) and code-split to avoid main-thread blocking.
Optimize data and requests
- Reduce unnecessary requests and push logic to the backend when appropriate.
- Aggregate calls via BFF to minimize chattiness.
- Optimize query patterns and backend endpoints.
Optimize static assets and build pipeline
- Optimize images: responsive images, appropriate formats and sizes per device.
- Compress fonts and static files; serve optimized images for mobile.
- Use caching and artifact registries to speed Docker/build pipelines (store packages to avoid repeated downloads).
Track metrics continuously
- Monitor Lighthouse/PageSpeed metrics and prevent regressions across releases.

Docker used for packaging frontend apps (example: embedding frontend as a plugin inside another app).
Pipeline knowledge is shared; the most experienced dev usually edits pipelines but anyone on the team can change them.
Test and type checks run in CI; testers deploy to QA stands.

Advertising platform:
- Built a selector that merged product models from multiple microservices.
- Created a BFF to aggregate and optimize calls, handle different entities and complex UI requirements.
- Launched under a feature flag and achieved strong user adoption.
Security console / plugin:
- Built a Docker image to deploy frontend as a plugin inside another app.
Backend tool (Go):
- Built a service to unify commands across many device types.
- Created a code-generation utility to auto-generate boilerplate and unit tests, reducing repetitive test-writing and improving coverage.

Requirements documented in Confluence; analysts draft feature specs, then developers join to design technical solutions and decompose work.
Grooming sessions with story point estimation; tasks split to fit sprints and to parallelize work.
Code reviews are collaborative and frequent; architectural and library decisions are discussed by the team.
Test ownership:
- Developers decide what to cover in automated tests.
- Testers write test cases and run manual/automated tests.
Conflict resolution:
- Example: code-review friction resolved via synchronous conversation and agreeing to tag “minor” comments for non-critical issues, improving PR throughput.

Candidate values teams where:
- People feel comfortable raising and solving problems.
- Work has visible business value.
- Product/lead communication about goals is clear.
Candidate is not actively searching but is considering offers and has a positive view of Yandex as offering varied opportunities.

Be ready to explain past projects, your role, the tech stack, and architecture decisions.
Be prepared to walk through debugging and performance investigations: network traces, tracing IDs, metrics, SSR vs SPA decisions, image optimization, and request reduction.
Show examples of initiatives (automation, code generation) and describe the impact (time saved, adoption, metrics).

Interviewer from Yandex (conducting the experience-check interview).
Candidate / Senior Frontend Developer (interviewee and video author), who describes projects, technical practices, and gives guidance.