1. Main difference between programming and software engineering
Programming is the act of writing code to solve a specific problem.
Software engineering is the systematic, disciplined, and scalable approach to designing, building, testing, deploying, and maintaining software.
👉 In short: Programming = writing code.
Software Engineering = managing the entire lifecycle of software.
---
2. What does “Hyrum’s Law” state?
Hyrum’s Law:
> “With enough users of an API, all observable behaviors of your system will eventually be depended upon, whether you documented them or not.”
Meaning: even small or unintended behaviors will become dependencies, making changes risky.
---
3. Two reasons long-term projects need continuous upgrades
1. Changing requirements: business, user needs, and laws evolve over time.
2. Technological updates: libraries, languages, security patches, and platforms change.
---
4. What is meant by “Shifting Left” in software development?
“Shift Left” means moving testing, quality checks, security reviews, and feedback earlier in the development cycle.
Goal: catch issues early → reduce cost, time, and failures.
---
5. What are trade-offs in engineering decisions?
Trade-offs mean choosing one advantage at the cost of another.
Example: Choosing faster performance may increase memory usage.
Engineers must balance speed, cost, complexity, reliability, etc.
---
6. Two challenges faced by software engineers when working in teams
1. Communication gaps – misunderstandings about requirements or tasks.
2. Integration conflicts – merging code from multiple people causes bugs or version issues.
---
7. How does knowledge sharing benefit teams?
Knowledge sharing:
Reduces dependency on any single developer
Improves team speed and problem-solving
Helps onboard new members faster
Promotes consistency in coding practices
---
8. Define the role of a team lead
A team lead:
Guides team technically
Distributes tasks
Ensures coordination and code quality
Supports junior developers
Communicates with management
Removes obstacles that block development
---
9. Why should team members admit mistakes openly?
Builds trust and psychological safety
Prevents small issues from becoming major failures
Encourages learning culture
Helps team fix problems quickly instead of hiding them
---
10. How does knowledge sharing benefit teams?
(Same as Q7 — you can repeat or summarize)
Knowledge sharing improves collaboration, resilience, productivity, and reduces risks.
---
11. Why a low Bus Factor is dangerous (with example)
Bus Factor = number of people who must leave (or be unavailable) to stall a project.
Low bus factor (1 or 2) → very risky.
Example:
If one developer knows all about the billing system and leaves the company, no one can fix bugs or make updates. The entire service may break during a payment outage.
Real-life example:
A company’s only DevOps engineer left suddenly → deployment pipelines stopped working for days.
---
12. Why is feedback culture important in software teams?
Feedback culture:
Improves performance and code quality
Encourages continuous growth
Helps catch mistakes earlier
Builds trust and healthy communication
Prevents recurring errors
---
13. What does “equity” mean in software engineering teams and why is it important?
Equity = providing fair opportunities by giving people the support and resources they uniquely need, rather than treating everyone identically.
Importance:
Creates inclusive work environments
Reduces bias in promotions and hiring
Improves diversity → leads to better problem solving
Ensures all team members can contribute effectively
---
14. Why blind hiring promotes equity?
Blind hiring hides identifying information such as:
Name
Gender
School
Age
Race
Photo
This prevents unconscious bias from affecting hiring decisions. Candidates are judged purely on skill, not personal background.
---
15. Main reason Google’s image recognition system made serious classification mistakes
The system was trained on biased and incomplete data, meaning certain groups were underrepresented in the training dataset.
Because of this, the model produced incorrect and harmful classifications.
---
16. Who discovered the mistakes? Why internal testing failed?
The mistakes were discovered by users, not Google employees.
Internal testing failed because:
Google used non-representative test data
Lack of diversity in testing groups
They didn’t consider all real-world edge cases
---
17. Explain “haunting graveyards” in code and why they are haunted
Haunting graveyards = old, abandoned, or unused parts of the codebase that everyone is afraid to delete.
They are “haunted” because:
Nobody knows what depends on them
Documentation is missing
Removing them might break something critical
The original developers have left
---
18. Short note on Tribal Knowledge
Tribal knowledge = important project information that lives only in people's heads and is not documented.
Problems caused:
New developers struggle
If key people leave, knowledge is lost
Makes project risky (low bus factor)
---
19. Explain “Googleness” in Software Development
Googleness refers to qualities Google expects from developers:
Innovation and curiosity
Working well in teams
Taking ownership
Being data-driven
Empathy and respect for users
Strong problem-solving and learning mentality
---
20. Low bus factor is a red flag — explain with real-life example
Red flag: a project collapses if 1–2 key people leave.
Example:
In 2014, the Left-Pad NPM package was unpublished by its single maintainer.
Thousands of JavaScript projects broke because they depended on one person maintaining one tiny piece of code.
This shows how dangerous low bus factor is in software ecosystems.
