Chapter 1
1. Define scalability in the context of a software organization.
Scalability is the ability of a software organization to increase output (features, quality, deployments) as the system, team, and users grow without a proportional increase in cost, complexity, or failure.
2. Give two resources in a software organization that must scale.
Human resources (teams, expertise, communication)
Technical resources (compute, codebase, infrastructure)
3. What is the Churn Rule and why does it scale well?
The Churn Rule says: If a change is cheap and reversible, it’s okay to let churn (frequent changes) happen rather than over-optimize upfront.
It scales well because it reduces coordination, avoids premature architecture decisions, and lets teams move independently.
4. Give an example of a policy that does not scale in large organizations.
A central approval board requiring every small code change to get clearance. It increases bottlenecks and slows throughput as teams grow.
5. Explain Time and Change in software engineering.
Time introduces change in requirements, environments, APIs, compilers, users, and teams. Scalable systems expect and accommodate change rather than assuming stability.
6. Differentiate between “It works” and “It is maintainable” in software engineering aspect.
It works: The software produces correct outputs today.
It is maintainable: The software can be modified, extended, debugged, and upgraded without high cost or fragility tomorrow.
7. Explain with an example a policy that does not scale and a policy that scales well in large organizations.
Non-scaling policy: Requiring architects to hand-approve every API design → creates bottlenecks.
Scaling policy: Having API linting tools + contract tests → decentralizes checks while keeping standards.
8. Why do compiler upgrades tend to be expensive in large codebases?
Because they require coordinated changes across many modules, teams, and build systems; old assumptions break; and testing overhead becomes large.
9. Mention two factors that improve codebase flexibility when performing upgrades.
Clear module boundaries/abstractions
Automated tests + CI pipelines that detect breakages early.
10. Why is expertise considered to scale better than asking every team to do the same task?
Expertise creates leverage: a small specialized team solves a shared problem once (e.g., security patches), instead of many teams reinventing it and multiplying cost.
11. State one human cost and one compute cost that can limit scalability.
Human cost: Communication/coordination overhead between teams
Compute cost: Build time or deployment time growing too large
12. Define scalability in the context of a software organization. Explain why human effort, compute resources, and the codebase itself need to scale.
Scalability is the organization’s ability to grow product output without linear growth in cost or failure.
Human effort must scale to avoid coordination bottlenecks; compute must scale to handle higher load; and the codebase must scale so many developers can change it without stepping on each other or breaking it.
If you want, I can convert this into shorter notes, more academic phrasing, or real industry examples. Also happy to push intellectually and critique assumptions if you want sparring mode.
Chapter 2
1. What does the term “Bus Factor” mean in software projects?
Bus Factor is the number of people who must disappear (e.g., “hit by a bus”) before a project becomes non-viable due to loss of knowledge.
Low bus factor = fragile project; high bus factor = knowledge shared.
2. Why are tight feedback loops important in software development?
Tight loops catch errors early, reduce rework, confirm assumptions while they’re still cheap, and accelerate learning → faster and more reliable delivery.
3. How does team collaboration improve the pace of progress in programming?
Collaboration spreads context, reduces silos, enables pairing/mentoring, speeds debugging, and increases the bus factor — all lowering bottlenecks in problem-solving.
4. What are the three pillars of social interaction in engineering teams?
Common framing: Communication, Coordination, and Cooperation.
(These support alignment, shared goals, and execution.)
5. Why is it important to balance uninterrupted focus with team accessibility in an office setup?
Focus enables deep work and architecture-quality decisions; accessibility enables knowledge flow and fast unblocking. Too much of either hurts progress: isolation slows collaboration; constant interruptions damage productivity.
Chapter 3
1. Define software engineering in terms of people and programs.
Software engineering is the discipline of coordinating people, processes, and programs to build and evolve software reliably over time. It’s as much about managing human coordination as it is about writing correct code.
2. What is tribal knowledge in a software engineering team?
Tribal knowledge is undocumented information, context, or tricks that only experienced members know. It makes teams fragile because progress depends on individuals rather than shared artifacts.
3. Explain the role of mentorship in promoting learning for new team members.
Mentorship accelerates onboarding by transferring context, standards, and reasoning patterns that aren’t written in docs. It raises the team’s bus factor and reduces the cost of mistakes made by newcomers.
4. Why is psychological safety important in large group interactions?
Psychological safety allows engineers to ask questions, challenge assumptions, surface risks, and admit uncertainty. Without it, information stays hidden, decisions degrade, and technical debt becomes social debt.
5. List two recommended patterns and two antipatterns of group interactions in software engineering teams.
Recommended patterns:
• Pairing / code reviews (shared context, fast feedback)
• Open RFCs / design docs for alignment without meetings
Antipatterns:
• Hero culture (single expert bottlenecks)
• Meeting-driven consensus without ownership (slow and unclear decisions)
Intellectual sparring note (brief, per your preference):
Chapter 4 (Diagrams)
Chapter 5
1. What is the primary responsibility of a Product Owner in a software development team?
To define and prioritize what should be built and why, aligning customer needs and business goals with the development backlog.
2. Name two key differences between an Engineering Manager and a Tech Lead.
Engineering Manager focuses on people, process, hiring, growth, and delivery.
Tech Lead focuses on technical direction, architecture, and code-level decisions.
3. What is the main goal of QA Engineers in a software development team?
QA aims to ensure the product meets quality standards by detecting defects early and validating correctness, usability, and reliability before release.
4. Define a T-shaped developer.
A T-shaped developer has deep expertise in a specific area (the vertical bar) and broad understanding across related domains (the horizontal bar), enabling better collaboration.
5. Give two ways an Engineering Manager can track team happiness.
Periodic 1:1 conversations / skip-levels for qualitative signals
Anonymous surveys or pulse checks for trends and sentiment.
Chapter 6
1. What does “Always Be Deciding” mean in leadership at scale?
It means leaders must keep decisions moving forward rather than stalling; indecision has cost, so progress is made through continuous, timely choices under uncertainty.
2. What are “blinders” in the context of team decision-making?
Blinders are implicit assumptions or constraints that limit the solution space (e.g., “we must do it this way”). Calling them out helps teams see alternatives.
3. Name the three steps for making decisions on ambiguous problems.
Typical framing:
Clarify the problem and the blinders
Explore realistic options and trade-offs
Decide and commit, while planning to adjust as feedback arrives
4. How does the airplane parable illustrate decision-making trade-offs?
It shows that when fuel (time/resources) is limited, choosing a direction beats debating endlessly; perfect information is less valuable than timely action.
5. Why should leaders frame decisions as iterative rather than final?
Iteration reduces fear of failure, shortens feedback loops, enables course corrections, and avoids the paralysis of trying to be perfect on the first attempt.
Chapter 9
Q1. Why is duplicate code discouraged?
Because it increases maintenance cost: every bug fix or change must be replicated, making the codebase harder to evolve.
Q2. What happens if reviewers request changes?
The author must make revisions before the code is approved and submitted; review creates feedback loops for quality and correctness.
Q3. Why code is considered a liability?
Because code must be maintained, tested, secured, and upgraded over time — even if it currently “works,” it incurs ongoing cost.
Q4. What problem occurs when a growing team continues giving everyone full access to the entire repository?
Coordination chaos and accidental breakages increase; no clear accountability exists for critical components.
Q5. What does “ownership” mean in Google’s codebase, and how is it different from possessing code?
Ownership means having review authority and responsibility for changes to a file, not personal possession; owners protect quality and continuity.
Q6. What information is stored in an OWNERS file?
It lists which people or groups are authorized to approve changes to the files in that directory.
Q7. How do OWNERS files help identify who is responsible for a particular code file?
By looking up the file’s directory and checking its OWNERS entry (or inherited entries), teams instantly know who can review and approve changes.
Q8. Why is it recommended to keep the list of owners in an OWNERS file small?
Smaller groups preserve accountability and shared context; large lists dilute responsibility and increase inconsistent decisions.
Q9. What responsibilities come with ownership rights in Google’s codebase?
Owners must ensure correctness, consistency, architectural soundness, security, and sustainable evolution of their components.
Q10. How is ownership inherited in Google’s hierarchical directory structure?
Directories inherit ownership from parent directories unless overridden by deeper OWNERS files, creating a tree of responsibility.
Q11. What is encouraged when team members join or leave regarding ownership?
Ownership should be transferred intentionally so responsibility stays current and the bus factor remains healthy.
Q12. How do OWNERS files support large-scale engineering practices at Google?
They distribute decision-making, reduce bottlenecks, clarify accountability, and allow thousands of developers to work safely in a shared repo.
Q13. Why has the ownership system been successful and scalable for Google over many years?
Because it balances local authority + global coordination, keeps accountability clear, and adapts as teams, code, and products grow.
SOFTWARE TESTING
1. A system accepts a password of length 6 to 12 characters. Using equivalence partitioning, identify valid and invalid partitions and give one test case for each.
Valid partition: length 6–12
Test case: "abc123" (length 6)
Invalid partition 1: length < 6
Test case: "a123" (length 4)
Invalid partition 2: length > 12
Test case: "abcdefghijklmn" (length 14)
2. A software system accepts an integer input representing the age of a user, which must be between 18 and 60 inclusive. Using equivalence partitioning, identify the valid and invalid partitions and suggest one test case from each partition.
Valid partition: 18–60 (inclusive)
Test case: 30
Invalid partition 1: < 18
Test case: 15
Invalid partition 2: > 60
Test case: 70
3. Define white-box testing and mention its main objective.
White-box testing evaluates the internal logic, control flow, and code structure of a program. Its main objective is to ensure all code paths, branches, and conditions behave correctly.
4. Explain branch coverage in white-box testing with one example.
Branch coverage ensures each decision point (e.g., if/else) executes both the true and false branches at least once.
Example: For if (x > 0) ... else ..., one test must make the condition true and another must make it false.
5. How test cases are generated using path coverage in white-box testing?
Path coverage identifies all independent execution paths through the control flow graph and generates test cases so that each distinct path is executed at least once.
6. Calculate the cyclomatic complexity of a program with 12 edges and 10 nodes, assuming a single connected component.
Formula: V = E − N + 2
So, V = 12 − 10 + 2 = 4
7. How does cyclomatic complexity help in determining the minimum number of test cases for a program?
Cyclomatic complexity gives the number of independent paths through a program. This number equals the minimum set of test cases required for full path coverage.
SOLID PRINCIPLE
1. Define the Open/Closed Principle with an example.
Open/Closed Principle: software entities should be open for extension but closed for modification.
Example: Adding new behaviors via subclasses or strategy plugins instead of altering existing class code.
2. What is the Liskov Substitution Principle in object-oriented design?
LSP states that objects of a subclass should be usable in place of their superclass without breaking correctness or expectations.
3. A Printer class does both printing and scanning. Which SOLID principle is violated? Explain briefly.
Violates Single Responsibility Principle (SRP) — the class has multiple unrelated responsibilities, reducing cohesion and increasing maintenance cost.
4. Class Bird has fly() method. A subclass Penguin overrides it but cannot fly. Which SOLID principle is violated?
Violates Liskov Substitution Principle — Penguin cannot safely substitute Bird since it breaks the behavioral assumption that all Birds can fly.
