Ошибка	Последствие
Scrum без retrospective	Команда не учится; одни и те же проблемы повторяются
Daily превращён в статус-репорт менеджеру	Теряет смысл синхронизации внутри команды
Свой 80-страничный style guide	Никто не помнит; реальный стиль — кто что недавно дописал
Code review = «выглядит ок, LGTM»	Ревью бесполезен; баги попадают в main
Только negative review	Автор теряет мотивацию; пропускают и хорошие решения
Авторитарный ревьюер	Команда боится PR'ов, итерации замедляются
Сборка без `clang-format` в CI	Стиль расползается; на ревью спорят про пробелы
Игнор `clang-tidy` warnings	Накапливается технический долг и потенциальные баги

beginner

Process & Methodology

Agile methodologies (Scrum, Kanban), code conventions and style standards, and code review practices — the team practices expected of any engineer.

Process

Practice: 7 questions →

Contents

Detailed explanation

Process & Methodology

Most of development is not code — it's aligning with the team. Which style guide. Who reviews what. How work is planned. This is rarely the main block of an interview, but basic orientation is expected at any level.

Topic map

Agile methodologies — Scrum, Kanban, and where they differ.
Code conventions — code style, linters, formatters; why a single standard matters.
Code review — what to look for, how to give and receive feedback.

Agile methodologies

The Agile Manifesto (2001) lists four values: individuals over processes, working software over documentation, customer collaboration over contracts, responding to change over following a plan. Agile is not a methodology — it is the umbrella.

Scrum uses fixed iterations (sprints), usually two weeks. Artifacts: Product Backlog, Sprint Backlog, Increment. Roles: Product Owner, Scrum Master, Development Team. Ceremonies: Planning, Daily, Review, Retrospective. Fits products with a clear roadmap and regular delivery.

Kanban has no fixed iterations. A board with columns (To Do / In Progress / Done) and WIP limits. Tasks are pulled as capacity frees. Fits support, ops, and teams with unpredictable inbound flow.

Hybrid / Scrumban — in practice most teams mix. For example, sprints with WIP limits, or sprints without the full Scrum ceremony set.

⚠️ Scrum is not "daily standup and burndown chart." It is an empirical process with three pillars: transparency, inspection, adaptation. Teams that perform "scrum rituals" without reflection or adaptation are doing cargo cult.

Code conventions

Why a style standard:

Readability — code is written once and read hundreds of times. A uniform style lowers cognitive load.
Fewer holy wars — tabs vs spaces is decided once in .clang-format.
Automation — the linter catches bugs, the formatter places whitespace. Review time goes to logic, not indentation.

C++ de-facto standards:

.clang-format — code formatting. Base styles: LLVM, Google, Mozilla, WebKit, Microsoft.
clang-tidy — static analyzer that catches bugs and style issues. Checks from bugprone-* through modernize-*.
Google C++ Style Guide, Core Guidelines (Stroustrup/Sutter) — foundational documents.

⚠️ An in-house style is not automatically good. Do not write your own 80-page document — adopt Google or LLVM and customize 5–10 rules for the team.

Code review

Goals of a review:

Find bugs — especially those the compiler and tests missed (race conditions, ownership, UB).
Share knowledge — the author learns from comments; the reviewer learns from reading the code.
Sustain style and architecture — uniform code style and consistent patterns.

What to look for:

Correctness. Are edge cases considered? What about error handling? Memory leaks, races, dangling pointers?
Design. Is the abstraction right? Is existing code being duplicated?
Readability. Clear names? Are complex functions split? Do comments explain why, not what?
Tests. Is the new behavior covered? Are old tests still passing?
Performance. O(n²) where it should be O(n)? Extra allocations on a hot path?

How to give feedback:

Be specific: "std::move is unnecessary here, the argument is already an rvalue," not "this could be improved."
Justify: cite a guideline, a benchmark, or an incident.
Be respectful: critique the code, not the author. Distinguish "must fix" from "nit / suggestion."

How to receive it:

Do not defend the ego. A comment is not an attack.
Argue on the merits. If the reviewer is wrong, explain why with facts, not "that's how we do it."
Do not ignore nits. A thousand small inconsistencies add up to an inconsistent codebase.

Common traps

Mistake	Consequence
Scrum without retrospective	The team does not learn; the same problems recur
Daily turned into a status report to the manager	Loses its team-sync purpose
In-house 80-page style guide	No one remembers; the real style is "what was merged last"
Code review = "looks ok, LGTM"	Review is useless; bugs reach main
Only negative reviews	The author loses motivation; good ideas are missed
Authoritative reviewer	The team fears PRs, iteration slows down
No `clang-format` in CI	Style drifts; whitespace debates dominate review
Ignoring `clang-tidy` warnings	Technical debt and latent bugs accumulate

Interview relevance

Process questions are rarely the decisive block, but they are easy to fail. The interviewer wants to hear that:

You understand Scrum is about empirical process, not ceremonies.
You know the Scrum / Kanban distinction and when each fits.
You see code review as knowledge sharing, not "catch the junior's bug."
You can give a specific, calm review.

Typical wrong answer: "Scrum is daily standups, two-week sprints, and a burndown chart." Those are attributes, not the point. The point is short cycles with inspection and adaptation.

Popular question directions:

How does Scrum differ from Kanban? When do you pick each?
What do you do when a reviewer disagrees with you?
What do you look for when reading someone else's PR?
Why have a single style guide and clang-format in CI?
How do you give feedback — a concrete example?

Why it matters

Technical interviews increasingly include a soft block — how you work in a team. Knowing Agile / Scrum / Kanban, code style, and code-review principles is basic hygiene, asked even of senior C++ developers.

Ошибка	Последствие
Scrum без retrospective	Команда не учится; одни и те же проблемы повторяются
Daily превращён в статус-репорт менеджеру	Теряет смысл синхронизации внутри команды
Свой 80-страничный style guide	Никто не помнит; реальный стиль — кто что недавно дописал
Code review = «выглядит ок, LGTM»	Ревью бесполезен; баги попадают в main
Только negative review	Автор теряет мотивацию; пропускают и хорошие решения
Авторитарный ревьюер	Команда боится PR'ов, итерации замедляются
Сборка без `clang-format` в CI	Стиль расползается; на ревью спорят про пробелы
Игнор `clang-tidy` warnings	Накапливается технический долг и потенциальные баги

beginner

Process & Methodology

Agile methodologies (Scrum, Kanban), code conventions and style standards, and code review practices — the team practices expected of any engineer.

Process

Practice: 7 questions →

Contents

Detailed explanation

Process & Methodology

Topic map

Agile methodologies — Scrum, Kanban, and where they differ.
Code conventions — code style, linters, formatters; why a single standard matters.
Code review — what to look for, how to give and receive feedback.

Agile methodologies

Kanban has no fixed iterations. A board with columns (To Do / In Progress / Done) and WIP limits. Tasks are pulled as capacity frees. Fits support, ops, and teams with unpredictable inbound flow.

Hybrid / Scrumban — in practice most teams mix. For example, sprints with WIP limits, or sprints without the full Scrum ceremony set.

Code conventions

Why a style standard:

Readability — code is written once and read hundreds of times. A uniform style lowers cognitive load.
Fewer holy wars — tabs vs spaces is decided once in .clang-format.
Automation — the linter catches bugs, the formatter places whitespace. Review time goes to logic, not indentation.

C++ de-facto standards:

.clang-format — code formatting. Base styles: LLVM, Google, Mozilla, WebKit, Microsoft.
clang-tidy — static analyzer that catches bugs and style issues. Checks from bugprone-* through modernize-*.
Google C++ Style Guide, Core Guidelines (Stroustrup/Sutter) — foundational documents.

⚠️ An in-house style is not automatically good. Do not write your own 80-page document — adopt Google or LLVM and customize 5–10 rules for the team.

Code review

Goals of a review:

Find bugs — especially those the compiler and tests missed (race conditions, ownership, UB).
Share knowledge — the author learns from comments; the reviewer learns from reading the code.
Sustain style and architecture — uniform code style and consistent patterns.

What to look for:

Correctness. Are edge cases considered? What about error handling? Memory leaks, races, dangling pointers?
Design. Is the abstraction right? Is existing code being duplicated?
Readability. Clear names? Are complex functions split? Do comments explain why, not what?
Tests. Is the new behavior covered? Are old tests still passing?
Performance. O(n²) where it should be O(n)? Extra allocations on a hot path?

How to give feedback:

Be specific: "std::move is unnecessary here, the argument is already an rvalue," not "this could be improved."
Justify: cite a guideline, a benchmark, or an incident.
Be respectful: critique the code, not the author. Distinguish "must fix" from "nit / suggestion."

How to receive it:

Do not defend the ego. A comment is not an attack.
Argue on the merits. If the reviewer is wrong, explain why with facts, not "that's how we do it."
Do not ignore nits. A thousand small inconsistencies add up to an inconsistent codebase.

Common traps

Mistake	Consequence
Scrum without retrospective	The team does not learn; the same problems recur
Daily turned into a status report to the manager	Loses its team-sync purpose
In-house 80-page style guide	No one remembers; the real style is "what was merged last"
Code review = "looks ok, LGTM"	Review is useless; bugs reach main
Only negative reviews	The author loses motivation; good ideas are missed
Authoritative reviewer	The team fears PRs, iteration slows down
No `clang-format` in CI	Style drifts; whitespace debates dominate review
Ignoring `clang-tidy` warnings	Technical debt and latent bugs accumulate

Interview relevance

Process questions are rarely the decisive block, but they are easy to fail. The interviewer wants to hear that:

You understand Scrum is about empirical process, not ceremonies.
You know the Scrum / Kanban distinction and when each fits.
You see code review as knowledge sharing, not "catch the junior's bug."
You can give a specific, calm review.

Typical wrong answer: "Scrum is daily standups, two-week sprints, and a burndown chart." Those are attributes, not the point. The point is short cycles with inspection and adaptation.

Popular question directions:

How does Scrum differ from Kanban? When do you pick each?
What do you do when a reviewer disagrees with you?
What do you look for when reading someone else's PR?
Why have a single style guide and clang-format in CI?
How do you give feedback — a concrete example?

Why it matters

Процесс и методологии

Процесс и методологии

Карта темы

Agile-методологии

Code conventions

Code review

Частые ошибки и ловушки

Значение для собеседований

Process & Methodology

Process & Methodology

Topic map

Agile methodologies

Code conventions

Code review

Common traps

Interview relevance

Процесс и методологии

Процесс и методологии

Карта темы

Agile-методологии

Code conventions

Code review

Частые ошибки и ловушки

Значение для собеседований

Process & Methodology

Process & Methodology

Topic map

Agile methodologies

Code conventions

Code review

Common traps

Interview relevance