Agile & Process
The word "Agile" in an interview almost never means a conversation about values — what is being probed is mechanics. How long a sprint lasts and who may cancel it. What a WIP limit physically forbids and how it exposes a bottleneck. How Continuous Delivery differs from Continuous Deployment. Why debt in code nobody touches can be left unpaid. The 2001 manifesto is four lines that by themselves prescribe nothing; everything executable lives in the two frameworks built on top of it, in the build pipeline, and in the discipline of tracking debt.
Python adds one property that changes the weight of every item. Python has no compile step — nothing stops a typo in a rarely imported module from reaching production and turning into a NameError under load. The missing compiler's job is taken over by CI: ruff and mypy catch exactly the class of error that never survives to a commit in compiled languages. For the same reason technical debt accumulates more quietly here — dead code and # type: ignore suppressions do not break the build and only surface during a refactor.
Three traps up front. CI is the practice of merging into a shared branch often, not a build server you bought. Kanban has no sprint — it has WIP limits and Cycle Time. Technical debt in Cunningham's original sense is a deliberate trade-off made to ship earlier, not a polite name for bad code.
Topic map
- Scrum and the Agile manifesto — the four manifesto values and the rigid Scrum frame: three accountabilities, five events, three artifacts and their timeboxes.
- Scrum vs Kanban — iteration versus continuous flow, the
WIPlimit as a mechanism, and whyvelocityandCycle Timemust never be swapped. - CI/CD — the pipeline — what CI actually does, the two different meanings of the CD acronym, and why pipeline stages are ordered the way they are.
- Technical debt — Cunningham's metaphor, principal versus interest, and Fowler's quadrant as a way to stop calling everything debt.
- Managing the debt — the three repayment strategies, prevention through a
Definition of Done, and measurable signals instead of gut feeling.
Common mistakes and traps
| Mistake | Consequence |
|---|---|
Believing sprint length is chosen to fit the amount of work | The length is fixed by definition; a floating sprint makes velocity meaningless and turns planning into haggling over a date |
Attributing two-week iterations to Kanban, or Cycle Time to Scrum | The metrics are swapped: Scrum measures velocity per iteration, Kanban measures how long an item takes to cross the board |
| Treating CI as a build server rather than a practice of frequent merging | Branches live for weeks, conflicts grow faster than the branch's age, and a green pipeline gives a false sense of being integrated |
| Confusing Continuous Delivery with Continuous Deployment | Interviewer and candidate discuss different processes; the manual gate before prod is a trait of Delivery, not Deployment |
| Assuming automated deployment lets you weaken the tests | The only human gate has been removed — it must be compensated by stronger tests, monitoring and fast rollback |
| Reducing technical debt to bad code | Deliberate debt and the notion of interest both disappear, and with them any basis for prioritizing repayment |
| Keeping debt tasks in a separate "later" tracker | They never compete with features for the team's capacity and never get done — a separate list is a way of not paying |
| Choosing a full rewrite as the default strategy | Years of fixed edge cases are thrown away and parity arrives late — the old system keeps moving ahead the whole time |
What interviews check
The process block opens the conversation and works as a quick calibration: has the candidate worked on a team, or only read about teams. At junior level three things are asked — what Scrum is (a framework of fixed-length iterations with a commitment to the Sprint Goal and delivery at the end), what the manifesto values (individuals, working software, collaboration, responding to change — with the mandatory caveat that the items on the right still have value), and what technical debt is. On the last one half the candidates answer "bad code", and the conversation turns into a review of that mistake: Cunningham's metaphor is about the future cost of a fast decision, paid as interest on every later change, and about a deliberate choice rather than sloppiness.
From middle level two questions reveal actual practice. The first is Scrum versus Kanban: a correct answer is built from the constraint (Scrum limits the time of an iteration, Kanban limits the amount of concurrent work), and from it follow the different metrics, the different attitude to reprioritization, and the choice of Kanban for support and ops where requests arrive unpredictably. The second is managing debt: the interviewer expects incremental refactoring with debt tasks in the shared backlog, a full rewrite as a last resort, conscious acceptance as a legitimate option, and prevention through MVP prototypes, versioned APIs and a clear Definition of Done. The senior question is almost always the same — what Continuous Deployment demands beyond an ordinary pipeline; here they check whether you understand that removing the manual gate is not a simplification but a transfer of responsibility to monitoring, fast rollback, feature flags and test coverage.