90 вопросов на собеседование автоматизатора: что спрашивают в 2026 | AQA за 60 дней #18

Main ideas, concepts, and lessons

• Purpose of the video: AQA/automation job interview prep (2026) focused on what interviewers actually evaluate for automation QA/automation engineer roles.

• Reality check about market roles:

  • “Automation engineer” roles can vary by team: sometimes you do mostly manual testing; sometimes automation is only a small part of the job.
  • Even when a vacancy says automation, the work may be closer to manual QA with occasional automated tests.
  • Therefore, always clarify expectations with the hiring team, including:
    • the proportion of automation vs. manual work
    • who writes what
    • how responsibilities are divided

• Core requirement across roles: Regardless of the exact title, QA fundamentals are mandatory, especially:

  • Test design (described as the hardest part of QA)
  • Client-server and basic system understanding
  • Knowing what to automate vs. not to automate

• Skills interviewers test (most common pattern):

  • Ability to reason (engineering thinking), not just memorize answers
  • Basic coding/syntax (sometimes not required, depending on the vacancy)
  • Ability to understand and review code written by others
  • Practical knowledge of CI/CD test execution: running tests, duration, coverage
  • UI automation specifics, especially locators, when UI automation is involved

• Interview process structure:

  • Job search → HR screening → technical interview (may include code) → sometimes multiple extra stages; final can vary by company/team

• Algorithms and coding tasks:

  • Algorithms are not always tested; when they are, they’re generally basic
  • Many companies instead ask code comprehension questions (e.g., locators, API behavior, simple transformations)
  • Recommendation: practice easy LeetCode problems for 2–3 weeks to ramp up fast

• How to perform during live coding / problem solving:

  • Never stay silent: think out loud, explain reasoning, ask clarifying questions
  • Interviewers can provide hints; correctness often depends on your reasoning process
  • Use tools if allowed, but the emphasis is on “show your thinking,” not “hide behind automation”

• How to answer technical questions effectively:

  • Avoid shallow answers—expand with:
    • Thesis (short direct answer)
    • a real-life example
    • reasoning
    • mention alternatives/limitations to show versatility
  • Example emphasis: explain why a specific framework (e.g., Playwright) was chosen and what outcomes you achieved; also demonstrate knowledge of alternatives (Selenium, Cypress, etc.)

• Behavioral / communication advice:

  • Interviewers are human: both technical and communication signals matter
  • Don’t argue aggressively; if they’re wrong, stay calm and restate the context
  • Aim for a relaxed “vibe,” not only correctness
  • Be ready for questions like:
    • “What is your achievement personally?”
    • “What was team vs you?”

• What to ask the employer (very important):

  • Asking questions signals interest and reduces uncertainty after onboarding
  • Recommended questions include:
    • automation proportion
    • process
    • infrastructure
    • scenario assignment
    • expectations for your first months

• Portfolio/interview practice tool shown:

  • A “cat Boris” bot exists in the chat to simulate interview Q&A and give feedback
  • It’s meant to help practice questions and improve answers

---

Methodologies / instruction lists

1) How to prepare for interviews (high-level workflow)

• Build understanding of:
  • QA fundamentals and test design
  • system basics (including client-server overview)
  • CI/CD test execution concepts (what runs, how long, coverage)
  • UI automation essentials if applicable (especially locators)
  • “what to automate vs not” decisions
• Practice typical interview tasks:
  • code reading / explaining
  • simple coding exercises (when required)
  • algorithm basics (only if applicable)
• Prepare communication and stories:
  • explain your personal contribution
  • prepare one failure and one success story, plus lessons learned
  • rehearse project stories in a structured format: context → what you did → results
• Practice responding:
  • speak with reasoning
  • expand answers with examples and technical details
  • avoid silence during live problem solving

2) “What to automate vs not” (decision framework)

• Automate first scenarios that are:
  • high business risk if broken
  • frequently repeated
  • stable enough not to constantly break and require heavy maintenance
  • critical for production value (e.g., core user journeys like registration/booking, “smoke” type checks)
• Regression strategy guidance:
  • Start with smoke tests (fast, triggered often, catches breakage after releases/changes)
  • Full regression is typically larger/slow to fully automate; approach it in phases:
    • cover the most critical things first (to catch issues in each PR)
    • expand gradually (“piece by piece”)
    • use analytics to prioritize what’s exercised most often
• Avoid automating tests that are:
  • too unstable / frequently changing without stable requirements
  • costly to maintain compared to the value they add

3) How to answer typical interview questions (answer structure)

Use a consistent formula:

• Thesis / direct answer (short)
• Example from your experience
• Reasoning (why that approach)
• Show awareness of tools/alternatives and limitations
  • e.g., when asked about locators or a framework, mention when/why alternatives differ

4) How to handle live coding / LeetCode-style sessions

• If you don’t know immediately:
  • reason out loud
  • ask clarifying questions (make the interviewer explain expectations)
• During coding:
  • never write code in silence
  • explain your plan, data structures, and logic as you go
• If you go wrong:
  • continue reasoning and correct direction rather than freezing
  • keep communication open so the interviewer can guide you

5) Prepare project stories (“tomato” example template)

Describe the project as a complete product/system (not “a bunch of tests”):

• what it is
• which platforms/use cases it supports
• what you did (manual vs automation vs architecture/infrastructure)
• how you improved things (coverage %, CI/CD integration, reduced release time, etc.)
• add one memorable case:
  • a conflict/bug you resolved, or
  • a “hard moment” showing problem-solving

6) “Personal contribution” clarification (common interview trap)

Be explicit about:

• what you personally implemented
• what you adapted from course/material/team
• what part was generated or already present

Avoid framing team work as purely individual. Be ready for follow-ups like:

• “What exactly did you do?”
• “What was ready-made vs your contribution?”
• “Who handled the rest?”

7) Prepare “achievements + failures” for 100% usefulness

Prepare:

• 1 achievement story (with measurable impact)
• 1 hard problem / failure story (what broke, what you did)
• 1 lesson / correction story (what you changed afterward)

Keep them rehearsed so you can reuse them quickly.

---

Speakers / sources featured (identified from subtitles)

• Main speaker (presenter/coach): Timur
• Interactive bot: “Boris” (the cat/bot shown in chat for simulated interview feedback)

• Referenced persons (not interviewed directly; mentioned as chat participants/recipients):

  • Alexey
  • Vika
  • Vladislav
  • Airat
  • Lena
  • Tahir
  • Valentin
  • Kostya
  • Love
  • Timur (also mentioned among certificate recipients)
  • Nastya
  • Sultan

• No other explicit external sources/organizations are clearly named in the subtitles, beyond general references to tools/terms like CI/CD, APIs, locators, Playwright/Selenium/Cypress, and LeetCode.