Interview Q&A

spect Scrum Kanban Extreme Programming

(XP)

Framework

Type

Prescriptive, timeboxed

(Sprints)

Flow-based,

continuous delivery

Engineering-focused

gile methodology

Roles PO, Scrum Master, Dev

Team

No defined roles Coach, Developer,

Customer (on-site)

Work

Planning

Sprint Backlog (2–4

weeks)

Continuous pull

from board

Iterations, similar to

Sprints

Change

Policy

No changes during a

Sprint

Changes allowed

nytime

Change-resistant within

iteration

Focus Delivery + team

process

Visualizing flow and

limiting WIP

Code quality and

engineering discipline

Practices Daily Scrum, Sprint

Planning, Review,

Retro

Visual board, WIP

limits, Cycle Time

Pair programming, TDD,

CI/CD, Refactoring

Example:

support team may prefer Kanban for flexibility, while a product dev team building new

features might favor Scrum or XP for structure and code quality practices.

In Scrum, scope creep is managed by controlling what goes into a Sprint — not by

freezing the entire project.

How it’s handled:

• Sprint scope is locked once planning ends. No changes mid-Sprint without

discussion and agreement.

• Product Backlog remains flexible, so new ideas or requirements are added there

— not injected into the current Sprint.

• The Product Owner (PO) decides what gets prioritized for future Sprints.

Example:

If a stakeholder requests a new login method during the Sprint, the PO thanks them, adds it

to the Product Backlog, and it’s considered in the next planning session — not immediately

worked on.

Follow On:

Answer: Fibonacci scale: 1, 2, 3, 5, 8, etc. Focus on effort, complexity, and risk — not time.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Purpose:

Sprint Planning sets the direction for the upcoming Sprint. The team collaboratively decides

what can be delivered and how the work will be accomplished.

Key outcomes:

• A clear Sprint Goal.
• A selected set of Product Backlog Items (PBIs) for the Sprint.
• A high-level plan for delivering those items.

Real-World Example:

In a team building a customer support chatbot, the Product Owner presents the most

valuable backlog items. The team discusses capacity and agrees to focus on implementing

“Chatbot FAQ logic” and “User intent recognition.” These become the Sprint backlog.

Follow On:

Definition:

The Product Backlog is an ordered list of everything that might be needed in the product,

serving as the single source of work for the Scrum Team.

How to maintain it:

• Continuously refine items for clarity, detail, and priority.
• Regularly update it based on feedback, market changes, and stakeholder input.
• Collaborate with the team to ensure shared understanding.

Real-World Example:

For a streaming platform, the backlog might start with high-level features like “Watchlist” and

“User Reviews”. As sprints progress, these are broken down into more detailed items like

“Add to Watchlist Button” or “Review Moderation Rules”.

Scrum defines three key artifacts:

• Product Backlog – A prioritized list of everything that might be needed in the

product, maintained by the Product Owner.

• Sprint Backlog – A subset of the Product Backlog items selected for the current

Sprint, along with a plan for delivering them.

• Increment – The sum of all completed work that meets the Definition of Done at the

end of a Sprint.

Example:

If your product is an e-commerce website, the Product Backlog could include features like

"Add to Cart", "Payment Gateway", and "User Login". In the current Sprint, the Sprint

Backlog may include just “User Login” and “Add to Cart”. At the end of the Sprint, a working

login system is delivered as the Increment.

Answer: travel app team uses Value vs. Effort to prioritize. “In-app booking” has high value and moderate effort, while “Flight status tracking” has high effort and low impact — so the former gets scheduled first.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

login screen might be a 2-point story (simple, well understood). A feature with integrations

nd security considerations may be 8 points due to complexity and risk.

Pro Tip:

void estimating in hours — it introduces false precision. Focus on relative effort, not

duration.

Top challenges:

Follow On:

• Team alignment across multiple squads
• Coordination of dependencies
• Shared ownership of product vision
• Overhead from meetings multiplying with team size
• Consistent backlog management
• Resistance to organizational culture change

Example:

If 10 Scrum teams are working on the same e-commerce platform, ensuring consistent UI

standards and integrating features becomes increasingly difficult without coordination

frameworks like Scrum-of-Scrums or SAFe.

Effort is typically estimated using relative sizing methods:

✅ Story Points (most common)

✅ Planning Poker (a team-based game using consensus to estimate)

✅ T-shirt sizes (S, M, L, etc., for quick high-level sizing)

Story Points consider:

• Complexity
• Amount of work
• Risks or unknowns

Example:

A login screen might be a 2-point story (simple, well understood). A feature with integrations

and security considerations may be 8 points due to complexity and risk.

Pro Tip:

Avoid estimating in hours — it introduces false precision. Focus on relative effort, not

duration.

Team members independently assign story points, then discuss differences.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Techniques to prioritize:

• MoSCoW (Must, Should, Could, Won’t)
• Kano Model (Basic, Performance, Delighter)
• Value vs. Effort Matrix
• Weighted Shortest Job First (WSJF) in SAFe

Factors to consider:

• Customer value
• Business impact
• Risk reduction
• Dependencies

Follow On:

• Technical feasibility

Example:

A travel app team uses Value vs. Effort to prioritize. “In-app booking” has high value and

moderate effort, while “Flight status tracking” has high effort and low impact — so the former

gets scheduled first.

What didn’t?

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Purpose:

The Daily Scrum is a 15-minute timeboxed event for the Development Team to inspect

progress toward the Sprint Goal and adapt the plan.

Effective format (common but not mandatory):

• What did I do yesterday?
• What will I do today?
• Are there any blockers?

Best Practices:

Follow On:

• Same time, same place daily.
• Focus on progress toward the Sprint Goal.
• Keep it short and to the point.

Real-World Example:

During a mobile app Sprint, a developer mentions a deployment delay due to a

configuration issue. The Scrum Master takes note and helps resolve it after the meeting —

preventing a bottleneck.

Definition:

The Definition of Done is a shared understanding of what “done” means for a backlog item

or Increment. It ensures transparency and consistent quality.

Impact on quality:

• Prevents incomplete work from being marked as finished.
• Reduces rework by setting clear expectations.
• Ensures the Increment is potentially shippable.

Example DoD:

• Code is committed and peer-reviewed
• Unit tests are written and passed
• Integrated into CI/CD pipeline
• User story accepted by Product Owner
• No major bugs in QA

Real-World Example:

Without a DoD, a team may claim a feature is “done” even though it hasn’t been tested.

With a proper DoD, it won’t be considered complete until it’s fully tested, reviewed, and

accepted.

Follow On:

Sprint is a fixed-length (usually 1–4 weeks) timebox where a usable and potentially

shippable product increment is developed. The Sprint fosters focus, regular delivery, and

continuous improvement.

Example:

digital agency might run 2-week Sprints to deliver iterative updates to a client’s website.

fter each Sprint, the client gets a working piece — such as a new landing page — and

provides feedback that shapes the next Sprint.

S, M, L, XL — useful for high-level estimation.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Key enablers:

• Trust: Allow teams to own delivery without micromanagement.
• Clear goals: Provide vision, not step-by-step instructions.
• Cross-functionality: Ensure the team has all necessary skills.
• Scrum Master: Coaches the team, but doesn’t assign tasks.
• Encourage decision-making within the team.

Follow On:

Example:

Instead of telling the team who should build the new feature, let them decide who does what

based on skills and availability. The Scrum Master can step in only if the team is blocked.

Purpose:

To inspect the Increment and adapt the Product Backlog based on feedback. It’s a

collaborative working session, not a demo-only meeting.

Key components:

• Presentation of what was "Done" in the Sprint.
• Discussion on what went well and challenges faced.
• Stakeholder feedback on the Increment.
• Review of the market or business context.

Real-World Example:

The team presents a new analytics dashboard to stakeholders. Marketing suggests a

change in how data is grouped. The Product Owner logs this feedback into the Product

Backlog for future refinement.

SAFe (Scaled Agile Framework) builds on Scrum principles but provides structured

guidance for applying Agile at enterprise scale.

SAFe includes:

• Scrum at the team level
• Agile Release Trains (ARTs) to coordinate multiple teams
• Roles like Release Train Engineer (RTE), Product Management, Solution

Architect

• PI Planning instead of Sprint Planning for synchronization

Example:

A telecom company using SAFe may have 12 Scrum teams working in sync toward a

Program Increment (PI) every 10 weeks, using shared roadmaps and synchronized planning

sessions.

Follow On:

utonomous?

Key enablers:

• Trust: Allow teams to own delivery without micromanagement.
• Clear goals: Provide vision, not step-by-step instructions.
• Cross-functionality: Ensure the team has all necessary skills.
• Scrum Master: Coaches the team, but doesn’t assign tasks.
• Encourage decision-making within the team.

Follow On:

Example:

Instead of telling the team who should build the new feature, let them decide who does what

based on skills and availability. The Scrum Master can step in only if the team is blocked.

rchitect

• PI Planning instead of Sprint Planning for synchronization

Example:

telecom company using SAFe may have 12 Scrum teams working in sync toward a

Program Increment (PI) every 10 weeks, using shared roadmaps and synchronized planning

sessions.

Follow On:

Scrum-of-Scrums (SoS) is a coordination mechanism where representatives from multiple

Scrum teams meet regularly to discuss progress, dependencies, and blockers.

Structure:

• Each team sends a delegate (often the Scrum Master or a dev lead).
• Frequency varies (e.g., 2–3 times/week).
• Focus is on cross-team coordination, not status reporting.

Example agenda:

• What has your team completed?
• What will your team work on next?
• Are there any blockers or dependencies?

Example:

In a bank's digital transformation project, five Scrum teams are building different modules of

the same app. SoS meetings align delivery and resolve integration issues early.

Answer: Purpose: To reflect on the Sprint and identify process improvements for the next iteration. Structure (commonly used): Follow On:

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Definition:

The Sprint Backlog is a subset of Product Backlog items the team commits to deliver in a

Sprint, plus a plan for how to achieve it.

How to manage it:

• Keep it visible and up to date (via a Scrum board or tool like Jira).
• Break down items into tasks during Sprint Planning.
• Update daily during stand-ups based on progress.
• Add tasks if necessary, but don’t change Sprint scope without discussion.

Example:

A team uses a Kanban board with “To Do”, “In Progress”, and “Done” columns. Every day,

they update task statuses so progress is clear and blockers are quickly identified.

Answer: login screen might be estimated as a 3-point story. A password reset flow involving emails nd error handling might be 5 points. Follow On:

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

The Product Owner:

• Continuously refines the Product Backlog — even during a Sprint.
• Works with stakeholders and the team to break down large items.
• Clarifies acceptance criteria.
• Re-prioritizes based on new insights.

Example:

Mid-Sprint, the PO learns from sales that customers are struggling with onboarding. They

update the backlog by splitting “User Onboarding Flow” into smaller, clearer stories for the

next Sprint.

spect Scrum Traditional (Waterfall)

Process Style Iterative and incremental Sequential and linear

Requirements Evolve over time Defined upfront

Follow On:

Team Involvement Cross-functional, collaborative Role-specific, hierarchical

Flexibility to Change High — welcomes changes Low — changes can be

costly

Delivery Frequent, every Sprint At the end of the project

Example:

In traditional construction, everything is planned before a brick is laid. In Scrum, like in

software development, teams build part of the system, get feedback, and adapt — like

dding a new feature based on early user testing.

Answer: team uses a Kanban board with “To Do”, “In Progress”, and “Done” columns. Every day, they update task statuses so progress is clear and blockers are quickly identified.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Preferred method:

Most agile teams favor Story Points with Planning Poker to foster team discussion and

build consensus.

Example:

A login screen might be estimated as a 3-point story. A password reset flow involving emails

and error handling might be 5 points.

Follow On:

Spotify’s model is not a framework but a cultural model inspired by Agile/Scrum, focusing

on autonomy, alignment, and innovation.

Key concepts:

• Squads = Scrum Teams
• Tribes = Collection of related Squads
• Chapters = Discipline-focused groups (e.g., QA Chapter)
• Guilds = Interest-based communities (e.g., DevOps Guild)

Follow On:

Emphasis on:

• Autonomy with accountability
• Servant leadership
• Agile mindsets over strict roles

Example:

Each Squad at Spotify decides its own tools and ways of working but is aligned on broader

goals and architecture via Tribes and Chapters.

Answer: Real-World Example: After noticing last-minute testing rushes, the team agrees to integrate testing into the daily workflow. Next Sprint, they try pairing QA early with devs, reducing defects by 30%.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Scrum fosters continuous improvement through:

• Sprint Retrospective – A dedicated meeting at the end of each Sprint to reflect on

what went well and what can be improved.

• Empowered Teams – Teams are encouraged to experiment and adapt their process.
• Transparency and Inspection – Constant review of progress and adaptation as

needed.

Example:

After noticing delays in code reviews, a team agrees in the Retrospective to set aside daily

time for peer reviews. In the next Sprint, turnaround time improves noticeably.

For small teams (3–5):

• Communication is simpler.
• Roles may overlap more (e.g., devs test their own work).

For larger teams (8+):

• Consider splitting into multiple Scrum Teams working on the same product, aligned

by a Scaled Scrum approach (e.g., Nexus, LeSS).

• Use communities of practice for specialized skill-sharing.

Follow On:

For varied skillsets:

• Promote cross-training to reduce silos.
• Use pair programming, knowledge sharing sessions, and code walkthroughs.

Example:

In a team with only one QA, developers start writing automated tests and review each

other’s code to balance the workload.

Answer: fter noticing last-minute testing rushes, the team agrees to integrate testing into the daily workflow. Next Sprint, they try pairing QA early with devs, reducing defects by 30%.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Purpose:

The Sprint Goal provides focus and alignment for the team. It serves as a shared

objective for the Sprint, guiding decisions and trade-offs.

Defining a good Sprint Goal:

• Collaboratively set during Sprint Planning.
• Clear, concise, and focused on outcome, not just output.
• Tied to business or customer value.

Example:

Instead of “build three reports,” a better Sprint Goal would be:

✅ “Enable users to access key sales insights through interactive reports.”

Answer: fter noticing delays in code reviews, a team agrees in the Retrospective to set aside daily time for peer reviews. In the next Sprint, turnaround time improves noticeably.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Product Increment is the sum of all work completed in the Sprint that meets the

Definition of Done.

Ways to measure:

• Functionality delivered (e.g. completed features)
• Business value delivered (e.g. increase in conversions)
• Quality metrics (e.g. defect rates, test coverage)
• Velocity (amount of work delivered compared to previous Sprints)

Example:

In a SaaS platform, the Sprint delivered “Export to CSV” and “Custom Reports”. These

features are measured by tracking how many users adopt them post-release and how much

support ticket volume drops.

Follow On:

Answer: team’s velocity drops — but it’s because they started writing more automated tests. The focus remains on sustainable delivery, not chasing numbers.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

spect Product Backlog Sprint Backlog

Follow On:

Owner Product Owner Development Team

Scope All desired features, bugs,

enhancements

Items selected for current Sprint

Timefram

Long-term, evolves continuously Short-term, Sprint-specific

Content Prioritized list of user

stories/features

Detailed tasks and plan for delivering

them

Example:

The Product Backlog includes “User Profile Page”, “Email Notifications”, “2FA Setup”. For

Sprint 4, the team selects “Email Notifications” and breaks it into tasks like “Create email

template”, “Setup backend service”, etc., forming the Sprint Backlog.

Meaningful metrics:

• Velocity (story points per Sprint): Trend, not target.
• Sprint Goal success: Did the team meet their goal?
• Lead Time / Cycle Time: Time from idea to delivery.
• Quality metrics: Bugs found, escaped defects.
• Team health: Engagement, collaboration, and satisfaction.

Caution: Avoid weaponizing metrics. They’re for continuous improvement, not judgment.

Example:

A team’s velocity drops — but it’s because they started writing more automated tests. The

focus remains on sustainable delivery, not chasing numbers.

Best practices:

• Identify and visualize dependencies during PI Planning or Sprint Planning.
• Use Dependency Boards or digital tools (e.g., Jira Advanced Roadmaps).
• Cross-team backlog refinement to surface risks early.
• Encourage cross-functional teams to reduce external dependencies.
• Establish Integration Sprints or teams, if needed.

Example:

In a large retail company, multiple teams need the same API updates. A shared backlog,

joint planning sessions, and dedicated integration owners reduce surprises.

well-formed backlog item (often a User Story) should be:

✅ INVEST:

• Independent – Can be developed separately
• Negotiable – Not a fixed contract
• Valuable – Delivers user or business value
• Estimable – Team can estimate its size
• Small – Can be completed within a Sprint
• Testable – Has clear acceptance criteria

Example:

Poor: “Fix bugs”

Better: “As a user, I want error messages when login fails, so I know why I can’t access my

ccount.”

Scrum embraces change by:

• Allowing the Product Backlog to be continuously refined and reprioritized.
• Keeping Sprints short, so changes can be incorporated in the next cycle.
• Fostering close communication between stakeholders and the team.

Follow On:

Example:

A product team building a CRM system receives new legal requirements for data handling.

Instead of derailing the project, the Product Owner updates the backlog, and the team

includes those changes in the next Sprint.

Answer: product team building a CRM system receives new legal requirements for data handling. Instead of derailing the project, the Product Owner updates the backlog, and the team includes those changes in the next Sprint.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Product Owner Team is a group of Product Owners (or PO + Product Managers) who

collaboratively manage a complex or large product backlog.

You need it when:

Follow On:

• The product is large or has multiple subcomponents.
• Multiple Scrum teams work on shared features or user journeys.
• Work spans multiple markets, compliance zones, or personas.

Structure:

• Chief Product Owner (overarching vision)
• POs for feature areas or team-specific backlogs
• Shared roadmap and prioritization process

Example:

For an enterprise SaaS platform with HR, Finance, and Compliance modules, each module

has a dedicated PO, coordinated by a Chief PO.

Purpose:

To keep the Product Backlog clean, prioritized, and well-understood by the team — ensuring

future Sprints run smoothly.

Best practices:

• Held once or twice per Sprint (not an official Scrum event, but crucial).
• Timebox to avoid fatigue (e.g., 1 hour per week).
• Break down large items (epics) into smaller, actionable stories.
• Clarify acceptance criteria and estimate effort.

Real-World Example:

Before Sprint Planning, the team refines a story called “Implement Dark Mode” by

discussing UI implications, dependencies, and edge cases. They split it into smaller tasks

like “UI toggle”, “Theme handler”, and “User preference saving”.

Definition:

A Product Owner Team is a group of Product Owners (or PO + Product Managers) who

collaboratively manage a complex or large product backlog.

You need it when:

Follow On:

• The product is large or has multiple subcomponents.
• Multiple Scrum teams work on shared features or user journeys.
• Work spans multiple markets, compliance zones, or personas.

Structure:

• Chief Product Owner (overarching vision)
• POs for feature areas or team-specific backlogs
• Shared roadmap and prioritization process

Example:

For an enterprise SaaS platform with HR, Finance, and Compliance modules, each module

has a dedicated PO, coordinated by a Chief PO.

User Story describes a feature from the end-user’s perspective. It answers: Who wants

it? What do they want? Why do they want it?

Template:

s a [type of user], I want [some goal], so that [some reason].

Best practices:

• Add Acceptance Criteria to clarify expectations.
• Keep it concise, focused, and testable.

Follow On:

Example:

s a shopper, I want to filter products by price range, so I can find items within

my budget.

cceptance Criteria:

• Price slider from $0–$500
• Real-time update of results
• Works on mobile and desktop

Best practices:

• Daily Scrum encourages daily alignment.

Follow On:

• Task ownership is flexible — any team member can pick tasks.
• Use shared goals (Sprint Goal) instead of individual targets.
• Foster a safe environment for asking questions and learning.
• Encourage pairing between devs, designers, testers, etc.

Example:

In a team building a healthcare dashboard, developers work closely with UX designers to

ensure usability and compliance, reviewing designs together before coding begins.

Definition:

A User Story describes a feature from the end-user’s perspective. It answers: Who wants

it? What do they want? Why do they want it?

Template:

As a [type of user], I want [some goal], so that [some reason].

Best practices:

• Add Acceptance Criteria to clarify expectations.
• Keep it concise, focused, and testable.

Follow On:

Example:

As a shopper, I want to filter products by price range, so I can find items within

my budget.

Acceptance Criteria:

• Price slider from $0–$500
• Real-time update of results
• Works on mobile and desktop

The Scrum Master facilitates, coaches, and removes obstacles. Unlike a traditional project

manager, they don’t assign tasks or manage timelines.

Scrum Master Project Manager

Facilitates Scrum practices Manages scope, schedule, and

budget

Focuses on team dynamics and

coaching

Focuses on deliverables and

deadlines

Servant leader Authority figure

Example:

If a developer is stuck due to a permissions issue, the Scrum Master will help resolve it. A

project manager might instead adjust timelines or escalate to keep the schedule on track.

Follow On:

Common pitfalls:

• Overcommitting based on optimism, not team capacity.
• No clear Sprint Goal, leading to scattered efforts.
• PO not prepared, causing delays or confusion.
• Ignoring team availability (e.g., vacations, holidays).
• Skipping task breakdown, leading to unclear work.

How to avoid:

• Come prepared with a refined backlog.
• Use velocity or past Sprint performance as a guide.
• Define a meaningful Sprint Goal.
• Factor in team availability.

Scrum is great wherever work is complex and iterative. Examples include:

• Marketing – Running campaigns in Sprints, delivering creative content.
• Education – Iteratively building course content or programs.
• Construction Design – Designing in phases, validating with stakeholders.
• Product Design – Developing prototypes and refining via feedback.

Real-World Example:

A university uses Scrum to develop an online learning program. In each Sprint, they deliver

lesson modules, gather student feedback, and adjust content and format accordingly.

Non-Functional Requirements (NFRs) like security, performance, and scalability are

treated as part of the Definition of Done (DoD) or explicitly captured in stories or tasks.

Approaches:

• Embed NFRs into acceptance criteria.
• Use technical enabler stories to address infrastructure or performance needs.
• Define NFR-related checklists in DoD.

Example:

For a fintech app, performance NFRs (e.g., “page load < 2 sec”) are part of every story's

DoD. Security is validated through automated scans in CI/CD.

Common estimation techniques:

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: university uses Scrum to develop an online learning program. In each Sprint, they deliver lesson modules, gather student feedback, and adjust content and format accordingly.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

pproaches:

• Embed NFRs into acceptance criteria.
• Use technical enabler stories to address infrastructure or performance needs.
• Define NFR-related checklists in DoD.

Example:

For a fintech app, performance NFRs (e.g., “page load < 2 sec”) are part of every story's

DoD. Security is validated through automated scans in CI/CD.

The Product Owner (PO) is the voice of the customer and is responsible for:

• Defining and prioritizing the Product Backlog.
• Maximizing value delivered by the team.
• Making trade-off decisions between features, cost, and time.

Example:

In a fintech app team, the PO decides that user onboarding is more critical than the referral

program, so it’s prioritized in the backlog. This ensures the team focuses on what's most

valuable for launch.

Follow On:

Answer: team working on a healthcare dashboard decides among themselves who takes on UI, backend, and testing tasks — without needing direction from a manager — and ensures the code is production-ready by Sprint’s end.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: fter a demo, a stakeholder suggests a visual improvement to a dashboard. The team doesn't implement it immediately but adds it to the backlog and addresses it in the next Sprint.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Follow On:

Ways to measure and manage technical debt:

• Code quality tools (SonarQube, CodeClimate)
• Automated test coverage
• Bug rates and frequency of rework
• Velocity trends — slowed delivery may indicate rising debt
• Team feedback in Retrospectives

Make it visible:

• Track known debt in the Product Backlog.
• Reserve capacity every Sprint to pay it down.

Example:

After frequent issues with legacy code, a team estimates and logs 5 technical debt stories,

prioritizing the worst ones during each Sprint.

Answer: fter frequent issues with legacy code, a team estimates and logs 5 technical debt stories, prioritizing the worst ones during each Sprint.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Tips to make Sprint Reviews impactful:

• Invite the right stakeholders (not just managers).
• Demonstrate working software, not just talk.
• Encourage interactive feedback — make it a conversation.
• Revisit progress toward the Product Goal.
• Align changes with business outcomes.

Follow On:

Real-World Example:

In a Sprint Review for a booking app, stakeholders suggested that date filters were

unintuitive. The team took this feedback and adjusted the UI in the next Sprint, improving

user satisfaction.

The Development Team is responsible for:

• Delivering a potentially shippable increment at the end of each Sprint.
• Self-organizing how they accomplish the work.
• Collaborating closely and maintaining quality.

Example:

A team working on a healthcare dashboard decides among themselves who takes on UI,

backend, and testing tasks — without needing direction from a manager — and ensures the

code is production-ready by Sprint’s end.

Epics:

• Large, high-level features or initiatives that are too big for a single Sprint.
• Broken down into User Stories for implementation.

Relationship:

Epic → Multiple User Stories → Tasks (optional)

Example:

Epic: “User Account Management”

User Stories:

• As a user, I want to register with email.
• As a user, I want to log in with my credentials.
• As a user, I want to reset my password.

Each of these stories can be completed in a separate Sprint and delivered incrementally.

During the Sprint:

• Feedback is captured but doesn’t change the current Sprint scope.
• Product Owner logs feedback in the Product Backlog.
• Team might discuss it in refinement sessions or plan to act on it in the next Sprint.

Follow On:

During Sprint Review:

• Stakeholders review the Increment.
• Discuss what’s useful, missing, or needs improvement.
• PO adjusts priorities accordingly.

Example:

After a demo, a stakeholder suggests a visual improvement to a dashboard. The team

doesn't implement it immediately but adds it to the backlog and addresses it in the next

Sprint.

lignment strategies:

• Define and communicate a clear Product Vision.
• Use Sprint Goals that tie directly to business outcomes.
• Conduct Sprint Reviews with real stakeholders to validate direction.
• Use OKRs (Objectives & Key Results) at a program or portfolio level.
• Empower POs to make value-driven decisions, not just task prioritization.

Example:

If the business goal is to increase user retention, Sprint Goals focus on improving

Follow On:

onboarding UX and reducing churn. Sprint Reviews showcase progress toward these

objectives.

Follow On:

Burndown Chart is a visual tool that shows the remaining work in a Sprint or project

over time.

Purpose:

• Helps teams monitor progress toward completing the Sprint backlog.
• Enables early identification of scope creep or falling behind.

Follow On:

How to use:

• X-axis: Days in Sprint
• Y-axis: Remaining effort (usually in story points or hours)
• Ideal line vs. actual line

Example:

Midway through a Sprint, a team sees the burndown flatlining (no work is getting “done”).

This prompts a conversation — they discover a blocker in API access and address it before

the Sprint is derailed.

Scrum Implementation & Best

Practices:

Challenge How to Overcome

Unclear roles Provide clear Scrum training; reinforce roles (PO, SM, Dev

Team).

Lack of stakeholder

engagement

Involve them in Sprint Reviews, show working software

regularly.

Poor backlog refinement Schedule regular grooming sessions with the PO and

team.

Unrealistic expectations Educate stakeholders on sustainable pace and team

velocity.

Team silos Promote cross-skilling and shared ownership of work.

Skipping retrospectives Prioritize continuous improvement by making retros

engaging and action-focused.

Micromanagement Empower teams to self-organize; educate managers on

agile leadership.

Follow On:

Advanced Scrum & Scaling:

Definition:

A Burndown Chart is a visual tool that shows the remaining work in a Sprint or project

over time.

Purpose:

• Helps teams monitor progress toward completing the Sprint backlog.
• Enables early identification of scope creep or falling behind.

Follow On:

How to use:

• X-axis: Days in Sprint
• Y-axis: Remaining effort (usually in story points or hours)
• Ideal line vs. actual line

Example:

Midway through a Sprint, a team sees the burndown flatlining (no work is getting “done”).

This prompts a conversation — they discover a blocker in API access and address it before

the Sprint is derailed.

Scrum Implementation & Best

Practices:

team felt retrospectives were repetitive. The Scrum Master tried a “Team Radar” activity to

visualize team health across areas like collaboration and quality. This revealed deeper

issues and sparked more meaningful discussions.

Scrum Artifacts:

These values create a strong foundation for effective teamwork:

• Commitment – Teams commit to goals and deliverables.
• Courage – Members speak up about challenges and take initiative.
• Focus – Everyone stays aligned on Sprint goals.
• Openness – Honest communication about progress and problems.
• Respect – Valuing everyone's contribution fosters trust.

Example:

In a high-pressure release, a developer admits they’re falling behind. Instead of assigning

blame, the team rallies to support — pair programming to stay on track. That’s Scrum values

in action.

Follow On:

Scrum Ceremonies:

Best practices:

• Rotate formats to keep things fresh.
• Foster psychological safety — no blaming.
• Use data and facts (velocity, defect rates) to ground discussions.
• Focus on 1-2 action items, not a wish list.
• Follow up — review actions in the next Retrospective.

Popular formats:

• Start / Stop / Continue
• Mad / Sad / Glad
• 4Ls (Liked, Learned, Lacked, Longed for)

Real-World Example:

A team felt retrospectives were repetitive. The Scrum Master tried a “Team Radar” activity to

visualize team health across areas like collaboration and quality. This revealed deeper

issues and sparked more meaningful discussions.

Scrum Artifacts:

A Git tag marks specific points in a repository’s history — usually to label release versions

(like v1.0, v2.1, etc.). It’s like a snapshot that says, “this commit is stable and ready to

release.”

Types of tags:

• Lightweight tag: just a name for a commit.
• Annotated tag: includes metadata like the tagger’s name, date, and message.

Commands:

git tag -a v1.0 -m "Version 1.0 release"

git push origin v1.0

Real-world example:

fter testing your project, you tag the commit representing your first release with v1.0. This

helps other developers or CI/CD pipelines identify which version is live.

Answer: &lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD current branch code ======= incoming branch code &gt;&gt;&gt;&gt;&gt;&gt;&gt; feature/contact-form

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

A branch in Git is like a separate line of development — a parallel universe for your code. It

llows you to work on new features, bug fixes, or experiments without affecting the main

codebase (usually called the main or master branch).

Why branches are useful:

They make collaboration easier by keeping each developer’s work isolated until it’s ready to

be merged back.

Real-world example:

Imagine your company website is live, but you need to add a “dark mode” feature. Instead

of editing the main code directly (which might break the live site), you create a new branch

called feature/dark-mode to work independently. Once it’s done and tested, you merge it

back into main.

Git is a distributed version control system (VCS) that allows multiple developers to work on

project without overwriting each other's work. It's designed to be fast, flexible, and

scalable, allowing developers to track changes in code and collaborate with ease.

In contrast, SVN (Subversion) is a centralized version control system. This means that SVN

has one central repository, and developers check out code to work locally. Git, on the other

hand, allows every developer to have their own full local repository, including the project’s

history. This makes Git faster and more reliable, especially in distributed teams.

Real-World Example:

If you were working on a website project with a team, using Git allows each developer to

clone the repository, make changes locally, and push their changes without disrupting others.

In SVN, the code is pulled from the central server, and only one developer can commit

changes at a time.

Answer: Mark the conflicting sections in your file: &lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD your current branch code ======= incoming branch code &gt;&gt;&gt;&gt;&gt;&gt;&gt; feature/new-ui

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

After initializing a Git repo locally (git init), you can connect it to a remote repository

(like one on GitHub) using:

git remote add origin

Then push your code:

git push -u origin main

Explanation:

• origin is just a nickname for the remote URL.
• The -u flag links your local branch with the remote one so future pushes are easier

(git push alone works after that).

Real-world example:

You create a local portfolio website and later decide to host it on GitHub. You connect your

local repo to the remote one using git remote add origin so both stay in sync.

git merge origin/main

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Accidentally pushing secrets (API keys, passwords, tokens) is serious — even if you delete them, they may still exist in commit history. Steps to fix it:

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: dashboard). → This prevents misuse. Remove the secret from code: git rm --cached path/to/file git commit -m "Remove sensitive file"

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git checkout -b feature/login abc1234

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git switch -c hotfix/save-work

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git cherry-pick &lt;commit-hash&gt;

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Integration means connecting your Git repository to your CI/CD system so every

push, pull request, or tag triggers an automated build, test, and deploy pipeline.

✅ Jenkins Integration

• Install the Git plugin in Jenkins.

Create a new pipeline job and link it to your Git repository:

pipeline {

gent any

stages {

stage('Checkout') {

steps {

git branch: 'main', url:

}
}

stage('Build') {

steps {

sh 'npm install'

sh 'npm test'

}
}
}
}

• ● Jenkins polls Git or listens for webhooks to trigger builds automatically.

✅ GitLab CI/CD

GitLab CI is built-in — simply create .gitlab-ci.yml:

stages:

• test
• deploy

test:

script:

• npm install
• npm test

deploy:

script:

• ./deploy.sh

only:

• main

Every push triggers this pipeline automatically.

✅ GitHub Actions

GitHub has its own YAML-based workflows:

name: Node CI

on: [push, pull_request]

jobs:

build:

runs-on: ubuntu-latest

steps:

• uses: actions/checkout@v4
• run: npm ci
• run: npm test

It runs directly in GitHub without needing extra setup.

Real-world example:

Your team pushes code to GitHub → GitHub Actions automatically runs tests →

Jenkins (or GitLab CI) deploys to a staging environment → Approval required for

production deploy.

Answer: git config --global user.signingkey &lt;key-id&gt; git config --global commit.gpgsign true

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Store tokens (like AWS_ACCESS_KEY, DOCKER_TOKEN) in → Settings &gt; Secrets and variables &gt; Actions Access them in workflows: env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: ccess them in workflows: env: WS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: &lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD your code ======= incoming code &gt;&gt;&gt;&gt;&gt;&gt;&gt; branch

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

My preferred strategy depends on the project type and team size:

• For large enterprise projects with planned releases → I prefer Git Flow.
• Branches: main, develop, feature/*, release/*, hotfix/*
• Benefits: Organized release management, clear isolation of features and

fixes.

• For agile teams or startups deploying multiple times a day → I prefer Trunk-Based

Development.

• Developers work on short-lived feature branches and merge into main

frequently (often daily).

• CI/CD pipelines ensure code is always deployable.

Real-world example:

t my last company, we used Trunk-Based Development for a SaaS platform — it reduced

merge conflicts and allowed fast continuous deployment.

source code during software development.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: A distributed version control system (DVCS) for tracking changes in source code during software development.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: You deleted feature/payment after merging, but QA needs it again — you can restore it from git reflog.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: &lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD Your changes ======= Incoming changes &gt;&gt;&gt;&gt;&gt;&gt;&gt; main

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Example: You checked out an old commit for debugging: git checkout a1b2c3d Then made edits and committed — but forgot to make a new branch. Create one before switching back, or you’ll lose that work.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Large binary files (like images, videos, or data models) bloat Git repositories since Git

stores every version.

To handle them efficiently, I use Git LFS (Large File Storage).

Setup:

git lfs install

git lfs track "*.psd"

git add .gitattributes

git commit -m "Track Photoshop files with Git LFS"

Explanation:

Git LFS replaces large files with lightweight text pointers inside Git, while the actual binary

files are stored on a separate LFS server.

Example:

If a game project has large texture files, Git LFS prevents the repo from becoming gigabytes

in size, improving clone and fetch performance.

git add . git merge --continue # or git rebase --continue

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

• origin – The main remote repository you cloned or own.
• upstream – Usually refers to the original repository that your fork came from.

Example:

If you fork a popular open-source project:

• Your fork on GitHub = origin
• The original repo (the one you forked from) = upstream

Commands to set both:

git remote add origin

git remote add upstream

Why it matters:

This setup lets you pull new changes from the main project (upstream) while pushing your

changes to your fork (origin).

Answer: GitHub Actions tokens (GITHUB_TOKEN) should have minimal scopes: permissions: contents: read deployments: write packages: read

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: A system where every developer has a full copy of the repository, including its entire history, allowing for offline work and decentralized collaboration.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git checkout wrong-branch git reset --hard HEAD~2

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git commit -S -m "fix: secure login flow"

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Semantic Versioning (SemVer) follows the format:

MAJOR.MINOR.PATCH

Example: v2.3.1

It’s based on changes — breaking changes bump MAJOR, new features bump

MINOR, and bug fixes bump PATCH.

utomation tools:

• semantic-release (Node.js)
• GitVersion (for .NET)
• release-please (Google’s tool for GitHub Actions)

Example using semantic-release:

npm install semantic-release @semantic-release/git

@semantic-release/github -D

Create a .releaserc.json:

{

"branches": ["main"],

"plugins": [

"@semantic-release/commit-analyzer",

"@semantic-release/release-notes-generator",

"@semantic-release/changelog",

"@semantic-release/github",

"@semantic-release/git"

}

What it does:

• Reads commit messages (feat:, fix:, breaking:)
• Calculates next version automatically
• Creates a Git tag (e.g., v1.2.0)
• Updates CHANGELOG.md
• Publishes release notes to GitHub

Example output:

chore(release): 1.3.0

• feat: add dark mode toggle
• fix: resolve login error

Clean and optimize the repository: git gc --aggressive

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: including its entire history, allowing for offline work and decentralized collaboration.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Create a branch to restore it: git checkout -b recovery-branch &lt;commit-hash&gt;

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

If you deleted a branch accidentally but haven’t run garbage collection yet, it can be

recovered using the commit log.

Steps:

Find the last commit of that branch:

git reflog

Example output:

bc1234 refs/heads/feature/login: commit: Add login validation

If a commit has been pushed to a shared branch, the safest way is to revert it — not

remove it.

git revert <commit-hash>

This creates a new commit that undoes the changes from the old one, without rewriting

history.

Example:

If you pushed a buggy commit that broke the login page, git revert creates a new

commit that removes those buggy changes while keeping the history intact.

⚠ Avoid git reset on shared branches because it rewrites history — it can

mess up others’ work.

You can create and switch to a new branch using:

git checkout -b feature/login-page

This creates a branch named feature/login-page and switches you to it immediately.

lternatively, you can do it in two steps:

git branch feature/login-page

git checkout feature/login-page

Real-world example:

If your team assigns you to build a login page, you can create a branch

feature/login-page to isolate your changes from the main code.

Git is the tool used to track changes in your code locally (on your computer), whereas

GitHub is a platform that hosts Git repositories online, enabling collaboration and sharing.

GitHub allows teams to work on Git-based projects in a central location, review code, and

manage issues and pull requests.

Real-World Example:

You use Git to make changes to your website’s code locally. Once you're happy with your

changes, you push them to GitHub so your team can see and review the updates. GitHub is

essentially a cloud service that works on top of Git.

Answer: Mask secrets automatically using: run: echo "Deploying..." &amp;&amp; echo "${{ secrets.AWS_SECRET_KEY }}" GitHub automatically redacts these values from logs.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git add . git commit git push

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: A force push can rewrite history and make commits disappear from the remote branch — but they’re often recoverable. Steps: Run git reflog locally to view all commit references: git reflog show origin/main

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

A Git submodule is a repository inside another repository — useful for including shared

components or libraries.

Example:

You have multiple microservices that share a common authentication library. Instead of

duplicating it, you include it as a submodule:

git submodule add

libs/auth

Pros: Keeps shared code centralized.

Cons: Requires careful syncing; new contributors must initialize submodules using:

git submodule update --init --recursive

Forking is when you create your own copy of someone else’s GitHub repository.

You do this directly on GitHub by clicking the “Fork” button on the top right of the repository

page.

Example:

You want to contribute to a public project like freeCodeCamp. You click Fork, creating your

own version under your account. You can modify it freely and then make pull requests to the

original project.

Command-line analogy:

Forking is like cloning, but on the GitHub server level — it gives you your own remote

repository to push to.

dd the resolved file: git add &lt;file&gt; git commit # or continue the rebase

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Mark conflicts as resolved: git add &lt;filename&gt; git commit

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Prune and repack: git gc --prune=now --aggressive

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

rea, Repository)

• Working Directory: This is where you make changes to the files. It's your local

workspace where you're actively editing code.

• Staging Area (Index): This is like a holding area where you prepare files before

committing them to the repository. You can choose which changes to add here.

• Repository: This is where Git stores the project’s history (commits). It's the

permanent record of your project's evolution.

Real-World Example:

When you're editing code, it starts in the working directory. After editing, you "stage" your

changes (using git add), which moves them to the staging area. Once you're ready to

save your changes permanently, you commit them to the repository using git commit.

You’ll see a green “Verified” badge on signed commits.

Why it matters:

• Verifies authorship for open-source contributions.
• Helps in regulated environments (e.g., fintech, healthcare).
• Prevents supply chain attacks via spoofed commits.

Real-world example:

In a security-conscious org, all commits to the main branch are required to be

GPG-signed — GitHub enforces this with branch protection rules.

• Working Directory: This is where you make changes to the files. It's your local

workspace where you're actively editing code.

• Staging Area (Index): This is like a holding area where you prepare files before

committing them to the repository. You can choose which changes to add here.

• Repository: This is where Git stores the project’s history (commits). It's the

permanent record of your project's evolution.

Real-World Example:

When you're editing code, it starts in the working directory. After editing, you "stage" your

changes (using git add), which moves them to the staging area. Once you're ready to

save your changes permanently, you commit them to the repository using git commit.

Follow:

Answer: Signed commits ensure authenticity — they’re cryptographically verified with a GPG or SSH key, proving the commit really came from you and wasn’t tampered with. Setup: Generate a GPG key: gpg --full-generate-key

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Comman

Description Safe for shared

repos?

git revert Creates a new commit that undoes changes from a

previous commit

✅ Yes

git reset Moves the branch pointer back to a previous commit,

potentially removing commits

❌ No (rewrites

history)

Example:

If you realize a commit caused an error:

• git revert will make a new commit that undoes it.
• git reset will erase it as if it never happened (good for local cleanup).

git remote add origin git push --all origin git push --tags origin

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Both commands integrate changes from one branch into another, but they work differently:

• git merge combines the histories of two branches, creating a new “merge commit.”
• git rebase rewrites history by placing your branch’s commits on top of another

branch, making it look like you developed your changes sequentially.

Real-world analogy:

• Merge: Like combining two storylines into one — you keep both histories.
• Rebase: Like rewriting your story so it appears you followed the main storyline all

long.

Example:

If your feature branch has diverged from main, merging will keep both timelines, while

rebasing will make it look like your branch was based on the latest main version all along.

Answer: Signed commits ensure authenticity — they’re cryptographically verified with a GPG or SSH key, proving the commit really came from you and wasn’t tampered with. Setup: Generate a GPG key: gpg --full-generate-key

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

next commit), Local Repository (committed files).

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Working Directory (modified files), Staging Area (files marked for next commit), Local Repository (committed files).

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git filter-repo (preferred) git filter-repo --path path/to/file --invert-paths

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Conventional Commits define a standard format for commit messages, such as:

feat: add new user registration flow

fix: correct login validation

chore: update dependencies

To enforce this automatically, use commitlint with husky:

Setup:

npm install --save-dev @commitlint/{config-conventional,cli} husky

Create a commitlint.config.js:

module.exports = { extends: ['@commitlint/config-conventional'] };

Then add a Git hook:

npx husky install

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit

"$1"'

Now every commit is checked — bad messages are rejected.

Example:

✅ feat: add password reset feature

❌ Added new password reset → ❌ rejected

Why this matters:

• Enables automatic changelog and versioning.
• Keeps Git history consistent.
• Works well with tools like semantic-release.

Answer: A snapshot of your project at a specific point in time, including changes and a message.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Conventional Commits define a standard format for commit messages, such as:

feat: add new user registration flow

fix: correct login validation

chore: update dependencies

To enforce this automatically, use commitlint with husky:

Setup:

npm install --save-dev @commitlint/{config-conventional,cli} husky

Create a commitlint.config.js:

module.exports = { extends: ['@commitlint/config-conventional'] };

Then add a Git hook:

npx husky install

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit

"$1"'

Now every commit is checked — bad messages are rejected.

Example:

✅ feat: add password reset feature

❌ Added new password reset → ❌ rejected

Why this matters:

• Enables automatic changelog and versioning.
• Keeps Git history consistent.
• Works well with tools like semantic-release.

Follow:

A commit in Git is a snapshot of your project at a specific point in time. It records all the

changes you've made to the files and saves them to the repository. Every commit has a

unique ID, and it's like a save point in a video game—if something breaks, you can go back

to any commit.

Real-World Example:

Let’s say you fixed a bug on the homepage of your app. After completing the fix, you commit

the changes to the repository. Later, if the fix causes an issue, you can roll back to the

previous commit.

• Instead of long-lived access keys, use federated identity:

■ AWS/GCP trusts GitHub’s identity token.

■ Short-lived credentials are issued dynamically.

Example for AWS:

permissions:

id-token: write

contents: read

Real-world example:

In one project, we replaced static AWS keys with OIDC-based auth in GitHub Actions

— no more long-lived tokens, and access was automatically scoped per workflow.

nother to “v2.0.” Git will stop and ask you to pick which to keep.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Example:

Before approving a PR for a new payment API, I check:

• Code readability and naming consistency
• Proper test coverage
• Security considerations (e.g., no API keys in code)

Bonus:

I sometimes use Suggested Changes in GitHub comments to make small fixes easier for

contributors.

git push origin --force

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: A detached HEAD means Git’s HEAD points to a specific commit instead of a branch — commits made now won’t belong to any branch. To fix it: Check what commit you’re on: git status

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

A Pull Request is a request to merge your changes from one branch or fork into another

repository or branch — typically to propose new code, bug fixes, or improvements.

Example:

You fixed a typo or added a feature in your fork of a project. You create a PR asking the

original maintainers to “pull” your changes into their main branch.

PRs enable:

• Code review
• Automated testing
• Discussion before merging

Answer: When migrating a legacy product from SVN, I ran the migration on a weekend, verified history integrity with the team, and locked SVN after the Git migration was complete.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Follow:

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Example: If you merge feature/login into main, Git finds the last point they shared code, applies your login branch changes, and creates a new commit that connects both histories. Intermediate / Advanced Git Concepts

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Example: If your teammate accidentally ran git push origin main --force, you can still restore your lost commits using your local reflog if you had pulled the branch before the overwrite.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

spect Merging Rebasing

History Keeps all commits, including merge

commits

Creates a linear, cleaner history

Safety Safe for shared/public branches Risky for shared branches (rewrites

history)

Use

Case

When collaboration is ongoing When you want a clean, linear history

before merging

Real-world example:

Before merging a feature into main, many teams rebase it to make the commit history

cleaner. But during teamwork, merging is safer because it doesn’t rewrite other people’s

work.

Reset

Type

What It Does Example Scenario

• -soft Moves HEAD to a previous commit

but keeps your changes staged

You committed too early and just

want to edit the message or add

more changes.

• -mixed

(default)

Moves HEAD and unstages files but

keeps your changes in the working

directory

You want to redo your git add

selections.

• -hard Completely resets everything —

deletes all local changes

You want to discard all work and

return to a clean state.

Example:

git reset --soft HEAD~1 # undo last commit, keep staged

git reset --mixed HEAD~1 # undo last commit, unstage files

git reset --hard HEAD~1 # undo last commit and delete changes

Answer: When GitHub reports conflicts in a PR: Fetch and switch to your branch locally: git fetch origin git checkout feature/new-ui

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: nother changes the same header), Git won’t know which to keep — you decide manually.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

A fast-forward merge happens when the target branch has not diverged — meaning, there

re no new commits on main since you branched off. Git simply moves the branch pointer

forward to include all your new commits, without creating a new merge commit.

Example:

If main has not changed since you created your feature/navbar branch, merging it back

will simply “fast-forward” main to the latest commit.

git merge feature/navbar

No merge commit — just a pointer move.

git init - creates a new Git repository in the current directory.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git stash temporarily saves your uncommitted changes so you can work on something

else without committing unfinished work.

Example:

You’re fixing a login bug but suddenly need to switch branches to fix a production issue.

Instead of committing half-done code, you run:

git stash

git checkout main

Later, you can come back and reapply your stashed work.

• git fetch: It retrieves changes from a remote repository but does not apply them to

your working directory. You can think of it as checking for updates without actually

installing them.

• git pull: This does two things: it fetches the latest changes and then merges them

into your current branch. It's like fetching updates and immediately applying them.

Real-World Example:

If you're working on a project with teammates, git fetch allows you to see what changes

have been made without affecting your code. git pull, on the other hand, will update your

local copy and merge those changes with your work, which can sometimes result in merge

conflicts.

git push origin --force

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Collaboration &amp; Workflow

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: ctions? Security in CI/CD pipelines is crucial — you never want secrets hard-coded in code or workflows. Best practices:

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

On GitHub:

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Real-world example: If you’re a team lead, you review a PR for a new feature, check coding standards, ensure tests pass, and approve it before merging into main.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Security in CI/CD pipelines is crucial — you never want secrets hard-coded in code or workflows. Best practices:

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

On GitHub:

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git stash temporarily saves your uncommitted changes so you can work on something

else without committing unfinished work.

Example:

You’re fixing a login bug but suddenly need to switch branches to fix a production issue.

Instead of committing half-done code, you run:

git stash

git checkout main

Later, you can come back and reapply your stashed work.

Answer: When branches diverge, Git can’t automatically merge them — it needs your help. Steps: Pull the latest changes and rebase or merge: git fetch origin git merge origin/main or git rebase origin/main

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Merge conflicts occur when two branches modify the same part of a file differently. To resolve: Run the merge command: git merge feature/contact-form

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

GitHub Actions is GitHub’s built-in Continuous Integration/Continuous Deployment

(CI/CD) platform.

It lets you automate tasks — like running tests, building code, or deploying apps — every

time code is pushed or a PR is opened.

Example:

You can create a workflow file .github/workflows/test.yml:

name: Run Tests

on: [push, pull_request]

jobs:

test:

runs-on: ubuntu-latest

steps:

• uses: actions/checkout@v4
• name: Install dependencies

run: npm install

• name: Run tests

run: npm test

Whenever code is pushed, GitHub automatically runs your tests — ensuring quality before

merging.

To create a new Git repository, navigate to your project directory and use the command:

git init

This initializes an empty Git repository in that directory. Now you can start tracking changes

in your project.

Real-World Example:

Imagine you're starting a new website project on your computer. You open your terminal, go

to your project folder, and type git init. This sets up the Git repository, and you can start

tracking your changes immediately.

Git hooks are scripts that run automatically when specific Git events occur (like committing

or pushing).

They live inside .git/hooks/.

Common examples:

pre-commit: Run linting or unit tests before a commit

# .git/hooks/pre-commit

npm run lint || exit 1

• pre-push: Prevent pushes to main

if [ "$(git rev-parse --abbrev-ref HEAD)" == "main" ]; then

echo "You can't push directly to main!"

exit 1

fi

• Example:

In a team, we set a pre-commit hook to check code formatting with ESLint before any

commit — ensuring consistency across all contributors.

time, including changes and a message.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: If you accidentally committed to the wrong branch, you can move those commits cleanly. Steps: Switch to the correct branch: git checkout correct-branch

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

To bring back your stashed work:

git stash apply # reapplies the most recent stash

git stash pop # reapplies AND deletes the stash

git stash list # shows all stashes

git stash show -p # shows what changes are in a stash

Real-world example:

fter resolving the production issue, you return to your feature branch and restore your

previous changes with git stash pop.

Answer: (Duplicate of #4) A snapshot of your project at a specific point in time, including changes and a message.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Example: You pushed .env with a production API key. Even after deletion, it’s still in the Git history — so you must clean and rotate keys right away.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Old branches can clutter your repo. You can clean them locally and remotely.

Commands:

To delete merged branches locally:

git branch --merged main | grep -v "main" | xargs git branch -d

• To prune deleted remote branches:

git fetch --prune

• Example:

fter several months, your repo has 50 old feature branches. You can prune them

utomatically in CI or periodically with these commands.

You can enforce reviews and branch protection rules in repository settings under

Settings → Branches → Branch protection rules.

You can require:

• Pull requests before merging
• At least one approval
• Passing CI checks (e.g., GitHub Actions)
• No direct pushes to main

Example:

Your team sets a rule that all PRs must be reviewed by at least one other developer and

must pass automated tests before merging.

There are several safe rollback methods:

Option 1 — Revert to a previous tag (recommended):

git revert <commit-hash>

git push origin main

This creates a new commit that undoes the bad release.

Option 2 — Deploy a stable tag:

git checkout v1.2.3

git push origin main --force

Example:

If version v2.0 introduced a bug in the payment flow, I revert to v1.9.1 (the last stable tag)

nd redeploy while investigating the issue.

In CI/CD pipelines:

We often have a ROLLBACK_TAG variable that can deploy a known safe version

utomatically.

Use git diff with two commit hashes:

git diff <commit1> <commit2>

This shows line-by-line changes between the two commits.

Example:

If you want to compare how your project changed between version 1.0 and version 1.1:

git diff v1.0 v1.1

You’ll see added, removed, and modified lines across files.

Locally:

git branch -d feature/old-branch

• (-D for force delete if it’s not merged)

Remotely:

git push origin --delete feature/old-branch

• Real-world example:

fter merging your feature branch into main, you can safely delete it to keep your repository

clean.

A lightweight, movable pointer to a commit, allowing for parallel development.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

To clone an existing repository, you use the git clone command followed by the URL of

the remote repository:

git clone

This command creates a copy of the repository on your local machine, including all its files

nd history.

Real-World Example:

If you're joining an open-source project on GitHub, you can clone the repository to your

machine by running the git clone command. This gives you access to the full codebase

to start contributing.

A detached HEAD occurs when Git’s HEAD (which points to your current branch) points to a

specific commit instead of a branch. This means you’re not working on any branch — any

new commits made in this state are “orphaned” unless you create a branch from them.

Example:

If you check out an old commit directly:

git checkout a1b2c3d

You’re in a detached HEAD state.

If you make changes here and don’t create a new branch, you could lose them later.

Fix:

Create a new branch to save your work:

git checkout -b hotfix/rollback-test

spect GitHub Flow Git Flow

Purpose Simple branching model for

continuous delivery

Structured model for release

management

Branche

Only main and short-lived feature

branches

Multiple: main, develop, feature,

release, hotfix

Workflow Create branch → Commit → Pull

Request → Merge → Deploy

Feature branches merge into develop,

then release/hotfix merges into main

Use Case SaaS projects, frequent deploys Complex products with scheduled

releases

Example:

• GitHub Flow → Used by startups deploying updates daily.
• Git Flow → Used by large software teams (e.g., enterprise apps) with versioned

releases.

Answer: git checkout &lt;branch-name&gt; or git switch &lt;branch-name&gt; - moves your HEAD pointer to another branch.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

A detached HEAD happens when Git’s HEAD (your current position) points to a specific

commit instead of a branch. If you make new commits in this state, they won’t belong to any

branch — you could lose them if you switch branches.

How to fix it:

If you accidentally commit in a detached HEAD state:

git switch -c temp-branch

This creates a new branch from your current state so your commits aren’t lost.

Example:

You checked out an old commit to test something:

git checkout a1b2c3d

If you make changes, create a branch to save them before switching back.

Answer: To slim down a bloated repository: Remove large unnecessary files: git filter-repo --path path/to/largefile --invert-paths

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

• git add: This command stages changes, telling Git which modifications you want to

include in the next commit. It doesn't save the changes to the repository yet, just

prepares them.

• git commit: This actually saves the changes to the repository, creating a new entry

in your project’s history.

Real-World Example:

You’ve edited a few files in your project. First, you use git add . to stage all changes,

nd then you use git commit -m "Fixed bug in homepage" to save those changes

to the repository.

In CI/CD, I automate version tagging to keep releases consistent and traceable.

Example pipeline step (GitHub Actions):

• name: Tag release

run: |

VERSION=$(node -p "require('./package.json').version")

git tag -a "v$VERSION" -m "Release version $VERSION"

git push origin "v$VERSION"

Versioning style:

I use Semantic Versioning (SemVer) → MAJOR.MINOR.PATCH

Example: v2.1.4

• Major = breaking changes
• Minor = new features
• Patch = bug fixes

This helps CI/CD pipelines automatically trigger deployments for new versions.

&lt;branch-name&gt; - moves your HEAD pointer to another branch.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

A protected branch (like main) restricts direct commits or merges unless specific rules are

met.

You can configure:

• Require pull request reviews
• Require status checks (tests) to pass
• Restrict who can push
• Prevent force pushes or deletions

Example:

You protect the main branch to ensure developers can only merge code through PRs that

have passed CI checks and received approval — preventing accidental overwrites.

Answer: When two branches modify the same part of a file, Git can’t automatically decide which version to keep — this creates a conflict. Git will:

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Migrating involves preserving history, branches, and tags. Steps (SVN example): Install Git SVN: git svn clone -trunk=trunk -branches=branches --tags=tags

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git cherry-pick lets you apply a specific commit from one branch to another, without

merging the entire branch.

Example:

Imagine you fixed a typo in the develop branch but need that same fix in main

immediately. Instead of merging all of develop, you can just cherry-pick that commit:

git cherry-pick 1a2b3c4

Real-world use case:

Useful when you want to apply a hotfix or small bug fix without merging unrelated feature

work.

Key practices I

• Branch-per-feature model – Each developer works on isolated branches.
• Pull Requests (PRs) for merging into main.
• Code reviews + CI tests required before merging.
• Protected branches prevent direct commits.
• Communication – Sync via Slack, GitHub Discussions, or standups to avoid

conflicts.

Example:

t a fintech startup, 8 engineers worked on a single monorepo. We used short-lived

branches and daily merges, with GitHub Actions running automatic tests for every PR — this

reduced integration headaches.

A protected branch (like main) restricts direct commits or merges unless specific rules are

met.

You can configure:

• Require pull request reviews
• Require status checks (tests) to pass
• Restrict who can push
• Prevent force pushes or deletions

Example:

You protect the main branch to ensure developers can only merge code through PRs that

have passed CI checks and received approval — preventing accidental overwrites.

git merge &lt;branch-name&gt; - combines changes from one branch into another.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

The .gitignore file tells Git which files or directories it should ignore when tracking

changes. This is useful for files that aren’t necessary in the repository, like log files, compiled

binaries, or local configuration files.

Real-World Example:

If you're working on a Node.js project, you likely don’t want to track the node_modules/

directory, since it can be recreated by running npm install. You can add

node_modules/ to your .gitignore file to ensure that Git doesn't track those files.

git cherry-pick lets you apply a specific commit from one branch to another, without

merging the entire branch.

Example:

Imagine you fixed a typo in the develop branch but need that same fix in main

immediately. Instead of merging all of develop, you can just cherry-pick that commit:

git cherry-pick 1a2b3c4

Real-world use case:

Useful when you want to apply a hotfix or small bug fix without merging unrelated feature

work.

I believe in a clean, meaningful Git history that tells the story of the project clearly.

Here’s how I maintain it:

• Use atomic commits (each commit = one logical change)

Write clear commit messages:

feat: add user profile API

fix: correct typo in dashboard title

chore: update dependencies

• ● Use rebase before merge to remove noisy commits (fix typo, debug print)
• Squash commits in PRs before merging
• Avoid committing generated or temporary files (use .gitignore)
• Tag meaningful releases (v1.0.0, v1.1.0-beta)

Example:

When reviewing history later, I can quickly find “where” and “why” a change was made — no

messy “temp commit” or “final fix” messages.

✅ In short:

healthy Git workflow = clear branches, clean commits, automated checks, and

collaborative reviews.

Real-World & Troubleshooting

Scenarios

Answer: Manually editing files to combine conflicting changes, then staging and committing them.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

When you run a merge, Git:

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

You can view the commit history by using the command:

git log

This shows a list of commits, with each commit’s hash, author, date, and message.

Real-World Example:

Imagine you're trying to figure out when a bug was introduced to your code. By running git

log, you can see all previous commits, helping you pinpoint the changes that might have

caused the issue.

Branching & Merging

Squashing combines multiple small commits into one clean commit before merging —

keeping history tidy.

Options:

• On GitHub:

When merging a PR, select “Squash and merge.”

On local machine:

git rebase -i HEAD~3

Change extra commits from pick → squash and then push with:

git push -f

• Real-world example:

If your PR has 10 commits like “fix typo,” “oops forgot semicolon,” and “final fix,” you squash

them into one commit:

👉 Add responsive navbar component

✅ Pro Tip:

clean workflow often looks like this:

You can interactively rebase to edit, squash, or reorder commits using:

git rebase -i HEAD~3

This opens an editor showing the last 3 commits:

pick 1a2b3c Fix typo in footer

pick 4d5e6f Add login API

pick 7g8h9i Update UI color scheme

You can change:

• pick → edit to modify a commit
• pick → squash to combine commits
• pick → reword to change the message

Real-world example:

Before merging your feature branch, you may use git rebase -i to combine small “fix

typo” or “debug print” commits into a clean, single commit.

⚠ Don’t rewrite history on shared branches that others are using — it can

cause conflicts and confusion.

GitHub & Remote Repository

Management

I treat Git as the single source of truth for builds and deployments.

My approach:

• Each merge to main triggers CI/CD pipelines (GitHub Actions, Jenkins, or GitLab

CI).

• Pipelines:
• Run tests, lint, and security scans.
• Tag builds automatically (e.g., v1.2.3).
• Deploy to staging/production environments.

Best practices:

• Use semantic versioning in tags (v1.0.0).
• Store environment configs securely (never in Git).
• Require PR reviews and passing checks before merge.
• Deploy directly from tagged commits, not branches.

Example:

In a microservices project, each push to main triggered automated Docker builds.

Tagging a commit with v2.3.1 automatically deployed that version to production —

ensuring traceability and rollback capability.

✅ In summary:

The key to mastering Git isn’t just knowing commands — it’s knowing how to

recover, clean, and automate safely.

Bonus / DevOps Integration

Answer: Rewrites commit history by moving a sequence of commits to a new base commit, creating a linear history.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

base commit, creating a linear history.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Uploads your local branch commits to a remote repository.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

local repository, but doesn't merge them.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Downloads commits, files, and refs from a remote repository into your local repository, but doesn't merge them.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: git remote add &lt;name&gt; &lt;url&gt; - links a local repository to a remote one (e.g., GitHub).

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git clone &lt;url&gt; - creates a local copy of a remote repository.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

intentionally ignore from being tracked.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: A file (.gitignore) that tells Git which files or directories to intentionally ignore from being tracked.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git status (summary), git diff (detailed changes).

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git reset HEAD &lt;file&gt; (unstage).

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

working dir changes), git reset HEAD &lt;file&gt; (unstage).

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: (Duplicate of #18) git restore &lt;file&gt; (unstage/discard working dir changes), git reset HEAD &lt;file&gt; (unstage).

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: git reset --soft/--mixed/--hard &lt;commit&gt; - moves HEAD and optionally changes the staging area/working directory to a specified commit.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

nd optionally changes the staging area/working directory to a specified commit.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: git revert &lt;commit&gt; - creates a new commit that undoes the changes of a previous commit, preserving history.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

changes of a previous commit, preserving history.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: git checkout &lt;commit&gt; -- &lt;file&gt; - restores a file to its state at a specific commit. Follow:

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: reset rewrites history; revert creates a new commit to undo changes, preserving history.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Shows a log of where your HEAD and branch tips have been, useful for recovering lost commits.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

by an existing commit from another branch onto your current branch.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: git cherry-pick &lt;commit&gt; - applies the changes introduced by an existing commit from another branch onto your current branch.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Forking creates a copy of an entire repository (often on a remote server); branching creates a lightweight, isolated line of development within a single repository.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: remote server); branching creates a lightweight, isolated line of development within a single repository.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: A permanent, immutable pointer to a specific commit, often used to mark release points (e.g., v1.0).

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: A common collaboration model involving forking, branching, pull requests, and code review.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: The process of other developers examining source code to find bugs, improve quality, and ensure best practices.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

improve quality, and ensure best practices.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: An automation platform that allows you to define custom workflows to build, test, and deploy code directly from GitHub.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

to build, test, and deploy code directly from GitHub.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

nother, typically involving code review.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: A request to merge changes from one branch (often from a fork) into another, typically involving code review.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: the main repository, storing pointers in Git while files are on a remote server.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Git Large File Storage - a Git extension for versioning large files outside the main repository, storing pointers in Git while files are on a remote server.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

receive. Used for automation and enforcing policies.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Scripts that Git executes before or after events like commit, push, and receive. Used for automation and enforcing policies.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Allows you to embed one Git repository inside another as a subdirectory, maintaining separate histories.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

subdirectory, maintaining separate histories.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: When your HEAD pointer points directly to a commit instead of a branch name, meaning you're not on any branch.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

branch name, meaning you're not on any branch.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: (Typo for "Interactive Rebase"?) Interactive Rebase: git rebase -i &lt;commit&gt; - allows you to squash, reorder, edit, or drop commits during a rebase operation.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Interactive Rebase: git rebase -i &lt;commit&gt; - allows you to squash, reorder, edit, or drop commits during a rebase operation.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

objects into a single file for easy transfer without a network connection.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: git bundle create &lt;file.bundle&gt; &lt;ref&gt; - packs Git refs and objects into a single file for easy transfer without a network connection.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

git blame &lt;file&gt; - shows who last modified each line of a file and when.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: git worktree add &lt;path&gt; &lt;branch&gt; - creates a new working directory linked to your main repository, allowing you to work on multiple branches simultaneously.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.