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:

1. Find bugs — especially those the compiler and tests missed (race conditions, ownership, UB).
2. Share knowledge — the author learns from comments; the reviewer learns from reading the code.
3. 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

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:

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