Video summary
СОБЕСЕДОВАНИЕ в ЯНДЕКС на frontend-разработчика. Этап 4: Проверка опыта во frontend
Main summary
Key takeaways
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.
Product & project descriptions
- 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.
Tech stack & architecture
- 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.
Testing practices
- 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.
Monitoring, tracing & observability
- 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.
Performance debugging & optimization (actionable steps)
- 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.
CI / build / deployment notes
- 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.
Examples / case studies
- 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.
Team & process practices
- 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.
Career & cultural notes
- 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.
Practical tips for interviewees / viewers
- 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).
Main speakers / sources
- Interviewer from Yandex (conducting the experience-check interview).
- Candidate / Senior Frontend Developer (interviewee and video author), who describes projects, technical practices, and gives guidance.
Rate this summary
Your feedback will help improve summaries.
Improve this summary
Reprocess with a stronger model when the summary feels incomplete or inaccurate.
Translate summary in another language
Ask questions to this video
Chat for follow-up questions, clarifications, and source-backed answers.