Interview Q&A

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

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:

Aspect Scrum Kanban Extreme Programming

(XP)

Framework

Type

Prescriptive, timeboxed

(Sprints)

Flow-based,

continuous delivery

Engineering-focused

Agile 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

anytime

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:

A 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.

Review the concept and prepare a concise verbal explanation with a real project example.

A Scrum Team is composed of three primary roles:

• Product Owner – Responsible for maximizing the value of the product and

managing the Product Backlog.

• Scrum Master – Acts as a servant-leader, facilitating the Scrum process and

removing impediments.

• Development Team – A cross-functional group that builds the product increment

each Sprint.

Example:

In a software startup developing a new mobile app, the Product Owner gathers customer

needs and prioritizes them. The Scrum Master ensures daily stand-ups run smoothly and

helps remove blockers like server access issues. The Development Team (UI/UX designers,

front-end and back-end developers) work together to deliver usable features every two

weeks.

Follow On:

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.

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.

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.

• Team members independently assign story points, then discuss differences.

What didn’t?

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.

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.

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.

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.

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.

Review the concept and prepare a concise verbal explanation with a real project example.

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

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:

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:

A 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:

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

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

provides feedback that shapes the next Sprint.

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.

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:

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.

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.

Aspect 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

adding a new feature based on early user testing.

Purpose:

To reflect on the Sprint and identify process improvements for the next iteration.

Structure (commonly used):

Follow On:

Review the concept and prepare a concise verbal explanation with a real project example.

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.

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.

A 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:

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.

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%.

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.”

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.

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.

Aspect 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.

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.

A 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

account.”

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.

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.

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.

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 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 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:

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:

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.

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.

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.

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.

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.

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:

Alignment 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:

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:

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:

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:

Review the concept and prepare a concise verbal explanation with a real project example.

git cherry-pick <commit-hash>

git switch -c hotfix/save-work

git checkout -b feature/login abc1234

dashboard).

→ This prevents misuse.

Remove the secret from code:

git rm --cached path/to/file

git commit -m "Remove sensitive file"

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:

Review the concept and prepare a concise verbal explanation with a real project example.

git merge origin/main

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.

Follow:

Real-world example:

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

merge conflicts and allowed fast continuous deployment.

Review the concept and prepare a concise verbal explanation with a real project example.

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).

Follow:

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.

Follow:

Mark the conflicting sections in your file:

<<<<<<< HEAD

your current branch code

=======

incoming branch code

>>>>>>> feature/new-ui

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

Follow:

(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:

After 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.

Review the concept and prepare a concise verbal explanation with a real project example.

<<<<<<< HEAD

current branch code

=======

incoming branch code

>>>>>>> feature/contact-form

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

allows 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.

Follow:

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

a 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.

Follow:

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.

A distributed version control system (DVCS) for tracking changes in

source code during software development.

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 {

agent any

stages {

stage('Checkout') {

steps {

git branch: 'main', url:

Follow:

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

Follow:

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.

git config --global user.signingkey <key-id>

git config --global commit.gpgsign true

• Store tokens (like AWS_ACCESS_KEY, DOCKER_TOKEN) in

→ Settings > Secrets and variables > Actions

Access them in workflows:

env:

AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}

• 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).

Review the concept and prepare a concise verbal explanation with a real project example.

<<<<<<< HEAD

Your changes

=======

Incoming changes

>>>>>>> main

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 commit -S -m "fix: secure login flow"

Review the concept and prepare a concise verbal explanation with a real project example.

Review the concept and prepare a concise verbal explanation with a real project example.

Review the concept and prepare a concise verbal explanation with a real project example.

GitHub Actions tokens (GITHUB_TOKEN) should have minimal scopes:

permissions:

contents: read

deployments: write

packages: read

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.

Review the concept and prepare a concise verbal explanation with a real project example.

A system where every developer has a full copy of the repository,

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

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.

Alternatively, 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.

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.

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.

Automation tools:

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

Example using semantic-release:

Follow:

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

Follow:

Clean and optimize the repository:

git gc --aggressive

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:

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

git add .

git merge --continue # or git rebase --continue

Create a branch to restore it:

git checkout -b recovery-branch <commit-hash>

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

Working Directory (modified files), Staging Area (files marked for

next commit), Local Repository (committed files).

Review the concept and prepare a concise verbal explanation with a real project example.

Mark conflicts as resolved:

git add <filename>

git commit

Mask secrets automatically using:

run: echo "Deploying..." && echo "${{ secrets.AWS_SECRET_KEY }}"

• GitHub automatically redacts these values from logs.

Follow:

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).

Add the resolved file:

git add <file>

git commit # or continue the rebase

Review the concept and prepare a concise verbal explanation with a real project example.

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.

Follow:

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.

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.

Follow:

• Rebase: Like rewriting your story so it appears you followed the main storyline all

along.

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.

Review the concept and prepare a concise verbal explanation with a real project example.

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.

git remote add origin

git push --all origin

git push --tags origin

Review the concept and prepare a concise verbal explanation with a real project example.

• 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:

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

Follow:

Pros: Keeps shared code centralized.

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

git submodule update --init --recursive

Prune and repack:

git gc --prune=now --aggressive

• git filter-repo (preferred)

git filter-repo --path path/to/file --invert-paths

Follow:

git add .

git commit

git push

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

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.

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.

git push origin --force

Aspect 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.

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.

Follow:

• 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.

Follow:

Two developers edit the same line in README.md — one changes “version 1.0” to “1.1,”

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

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

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

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.

Follow:

To fix it:

Check what commit you’re on:

git status

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

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:

Follow:

Review the concept and prepare a concise verbal explanation with a real project example.

Review the concept and prepare a concise verbal explanation with a real project example.

When GitHub reports conflicts in a PR:

Fetch and switch to your branch locally:

git fetch origin

git checkout feature/new-ui

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.

A snapshot of your project at a specific point in time, including changes

and a message.

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.

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

git rebase origin/main

git push origin --force

On GitHub:

Collaboration & Workflow

• 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.

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.

On GitHub:

Security in CI/CD pipelines is crucial — you never want secrets hard-coded in code or

workflows.

Best practices:

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

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

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.

Follow:

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.

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:

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

previous changes with git stash pop.

(Duplicate of #4) A snapshot of your project at a specific point in

time, including changes and a message.

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

or pushing).

They live inside .git/hooks/.

Common examples:

Follow:

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

Example:

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

commit — ensuring consistency across all contributors.

If you accidentally committed to the wrong branch, you can move those commits cleanly.

Steps:

Switch to the correct branch:

git checkout correct-branch

Use git diff with two commit hashes:

git diff <commit1> <commit2>

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

Follow:

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.

Follow:

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:

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

clean.

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

and 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.

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

Settings → Branches → Branch protection rules.

Follow:

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.

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.

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)

and redeploy while investigating the issue.

Follow:

In CI/CD pipelines:

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

automatically.

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:

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

automatically in CI or periodically with these commands.

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

development.

To slim down a bloated repository:

Follow:

Remove large unnecessary files:

git filter-repo --path path/to/largefile --invert-paths

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

git checkout <branch-name> or git switch

<branch-name> - moves your HEAD pointer to another branch.

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.

• 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,

and then you use git commit -m "Fixed bug in homepage" to save those changes

to the repository.

Follow:

Aspect 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.

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.

Migrating involves preserving history, branches, and tags.

Steps (SVN example):

Install Git SVN:

git svn clone

• -trunk=trunk
• -branches=branches --tags=tags

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.

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:

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 follow:

• Branch-per-feature model – Each developer works on isolated branches.

Follow:

• 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:

At 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.

git merge <branch-name> - combines changes from one

branch into another.

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.

Manually editing files to combine conflicting changes, then

staging and committing them.

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:

Follow:

• 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

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

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).

Follow:

• 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

When you run a merge, Git:

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)

Follow:

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:

A healthy Git workflow = clear branches, clean commits, automated checks, and

collaborative reviews.

Real-World & Troubleshooting

Scenarios

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

Follow:

them into one commit:

👉 Add responsive navbar component

✅ Pro Tip:

A clean workflow often looks like this:

Rewrites commit history by moving a sequence of commits to a new

base commit, creating a linear history.

Uploads your local branch commits to a remote repository.

Downloads commits, files, and refs from a remote repository into your

local repository, but doesn't merge them.

git remote add <name> <url> - links a local repository to a

remote one (e.g., GitHub).

git clone <url> - creates a local copy of a remote repository.

A file (.gitignore) that tells Git which files or directories to

intentionally ignore from being tracked.

git status (summary), git diff (detailed changes).

(Duplicate of #18) git restore <file> (unstage/discard

working dir changes), git reset HEAD <file> (unstage).

git reset --soft/--mixed/--hard <commit> - moves HEAD

and optionally changes the staging area/working directory to a specified commit.

git revert <commit> - creates a new commit that undoes the

changes of a previous commit, preserving history.

git checkout <commit> -- <file> - restores a file to its state

at a specific commit.

Follow:

reset rewrites history; revert creates a new commit to undo

changes, preserving history.

Shows a log of where your HEAD and branch tips have been, useful for

recovering lost commits.

git cherry-pick <commit> - applies the changes introduced

by an existing commit from another branch onto your current branch.

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.

A permanent, immutable pointer to a specific commit, often used to mark

release points (e.g., v1.0).

A common collaboration model involving forking, branching, pull

requests, and code review.

The process of other developers examining source code to find bugs,

improve quality, and ensure best practices.

An automation platform that allows you to define custom workflows

to build, test, and deploy code directly from GitHub.

A request to merge changes from one branch (often from a fork) into

another, typically involving code review.

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.

Scripts that Git executes before or after events like commit, push, and

receive. Used for automation and enforcing policies.

Allows you to embed one Git repository inside another as a

subdirectory, maintaining separate histories.

When your HEAD pointer points directly to a commit instead of a

branch name, meaning you're not on any branch.

(Typo for "Interactive Rebase"?)

• Interactive Rebase: git rebase -i <commit> - allows you to squash,

reorder, edit, or drop commits during a rebase operation.

git bundle create <file.bundle> <ref> - packs Git refs and

objects into a single file for easy transfer without a network connection.

git blame <file> - shows who last modified each line of a file and

when.

git worktree add <path> <branch> - creates a new working

directory linked to your main repository, allowing you to work on multiple branches

simultaneously.

A Git repository that does not have a working directory, typically

used as a central remote repository (e.g., on a server).

Temporarily saves changes that are not ready to be committed,

allowing you to switch branches and come back to them later.

Combining multiple commits into a single, more meaningful

commit, typically done during an interactive rebase.

Follow:

The default name for the remote repository from which a project

was originally cloned.

A pointer to the current commit you are on in your local repository.

A configuration file that stores user-specific Git settings (e.g.,

username, email, aliases).

Shows changes between the staging area and the

last commit.

Displays the commit history of the current branch.

Allows you to interactively stage specific parts (hunks) of changes

within a file.

Shows the URLs of the remote repositories associated

with your local repo.

A command used to find the commit that introduced a bug by

performing a binary search on the commit history.

Checks the integrity of the Git file system.

Cleans up unnecessary files and optimizes the local repository.

A merge where the branch being merged can

simply be moved forward to the tip of the other branch without creating a new merge

commit.

A merge that involves the two branch tips and their

common ancestor to determine how to combine changes, potentially creating a new

merge commit.

Long Answers:

In tight sprints, I focus on business-critical items first—features that directly impact user

experience or revenue. I work with the Product Owner to re-evaluate what’s must-have vs.

nice-to-have. For example, in one sprint, we postponed UI polish and non-blocking

validations to future iterations so we could release core functionality on time. I also ensure

tasks are clearly scoped so there’s no time lost in ambiguity.

Yes, in one of my recent projects, we had to migrate a legacy monolithic .NET Framework

application to a microservices architecture using .NET Core and React. Midway, business

requirements changed drastically. I restructured the team into feature squads, held daily

syncs, and prioritized deliverables in bi-weekly sprints. Despite the shift, we delivered the

MVP on time. It was a test of agility, communication, and clear ownership.

I avoid jargon and focus on the impact. For example, when we chose to implement

server-side caching using Redis, I explained it to the product owner as “improving response

times for users and reducing load on our database.” I often use analogies or quick

visuals—like diagrams—to bridge the gap. If they understand the “why” behind a decision,

they’re usually fully supportive.

My biggest strength is translating complexity into clarity—both for my team and for

stakeholders. Whether it’s breaking down a complex backend refactor or explaining tech

trade-offs to non-technical clients, I help align everyone toward a common goal. I’ve found

that this bridges gaps, speeds up decision-making, and builds trust across teams.

We follow clean code principles—naming conventions, single-responsibility, DRY, and

SOLID—across both frontend and backend. In .NET Core, we enforce async programming

best practices, and in React, we use functional components and hooks with ESLint rules.

We also use code formatters (Prettier, EditorConfig) and have style guides documented

in our wiki. For every new module, we expect clear folder structure, separation of concerns,

and reusable components/services.

First, I quickly assess project status and critical tasks the lead was handling. I reassign

urgent responsibilities to senior team members and ramp up communication with the team.

Next, I engage with stakeholders immediately to set realistic expectations—maybe negotiate

a small deadline extension if possible. Meanwhile, I support the team with resources and

prioritize stabilization over new features to minimize risk.

I believe in setting clear expectations early. If a client wants something that's technically

risky or unrealistic within the timeframe—like real-time dashboards without backend

support—I break it down into what’s possible now, what’s risky, and what would need

extra time/resources.

I use visual aids like architecture diagrams or timelines to make it concrete. For example, I

once explained why moving to microservices in the middle of a release would delay delivery

by 4–6 weeks. Instead, we agreed on a phased approach. Transparency builds trust—even

if the answer is “not now.”

I start by understanding the business growth projections and expected user load.

Architecturally, I favor modularity—breaking the system into well-defined services or

components. For example, using microservices in .NET Core allows independent scaling.

On the frontend, reusable React components improve maintainability.

I also enforce clear API contracts and automate testing to ensure future changes don’t

break things. Documentation and knowledge sharing are key so the system is maintainable

even as teams grow or shift.

Technical skills matter, but I look for curiosity, problem-solving mindset, and

communication ability just as much. Can they learn new tools? Do they ask thoughtful

questions? Are they team players?

For example, when hiring, I value developers who can explain their thought process clearly

during whiteboard exercises and show how they’ve handled challenges in past projects.

I encourage a culture of shared learning. Every couple of weeks, we do “Tech Spotlights”

where team members present something new—like a tool they explored or a library they

used. We also have a shared Slack channel and Confluence board for articles, videos,

and cheat sheets.

On top of that, I push for Pluralsight or Udemy licenses, and during sprint retros, I ask

what tech skills people want to build, so we align learning with actual project needs.

I start by aligning with business goals—whether it's scalability, speed to market, or

maintainability. Then, I evaluate the tech stack, team skillsets, and existing

infrastructure. For example, in one project, I chose a microservices-based backend using

.NET Core with a React frontend. We used API gateways to separate concerns and ensure

scalability. I involve senior devs in early discussions, create a proof of concept if needed,

and always document the rationale for future reference.

Review the concept and prepare a concise verbal explanation with a real project example.

I believe in experimenting—but not at the cost of stability. If a tool looks promising, we

first try it in a non-critical module or POC. For example, when React Query came out, we

tested it in an internal admin panel before rolling it into client-facing apps.

Follow :

I also check community maturity, maintenance frequency, and compatibility with our stack

(.NET Core APIs, CI/CD, etc.). If all checks out, we schedule it into our backlog as a

technical spike and get team feedback post-implementation.

I bring stakeholders together early and clarify the core business goals. For instance, in one

project, marketing wanted a flashy UI with animations, but performance was a priority for

sales. I proposed a compromise—lazy-loading animations only after the first paint. We

documented priorities and aligned on a phased rollout. It’s about facilitating a conversation

and driving toward the common goal.

Yes, in one case, a client was unhappy because a feature didn’t behave the way they had

"imagined"—but it wasn’t documented that way in the specs. Instead of getting defensive, I

listened, acknowledged the gap, and proposed a fix with a quick turnaround.

Internally, I organized a requirements clarification checkpoint for future sprints. That

experience taught me the importance of confirming assumptions and using visual

mockups or user stories, even when time feels tight.

I'm currently focused on improving my delegation and coaching skills. Earlier in my

career, I had a tendency to take on critical tasks myself to ensure quality. Now, I’m learning

to trust the process, let others take ownership, and support them with the right tools and

feedback. It’s a shift from being the go-to problem solver to being an enabler of growth—and

it’s been rewarding.

I design for redundancy—using multiple instances behind load balancers, and designing

services to be stateless where possible. In .NET Core, this often means using resilient

patterns like circuit breakers and retries with Polly.

We also implement health checks and monitoring (Azure Monitor, Application Insights) to

detect issues early. For critical data, backups and failover strategies are baked in. The goal

is minimizing downtime and graceful degradation rather than “perfect uptime” which is often

unrealistic.

Follow :

Review the concept and prepare a concise verbal explanation with a real project example.

I believe in addressing conflicts early. Once, two developers disagreed on whether to use

Redux or Context API for state management. I had a quick one-on-one with both, then

brought them together to discuss pros/cons objectively. We agreed to prototype both

approaches and make a data-driven decision. It defused tension and built mutual respect.

I break down features into frontend, backend, integration, and testing efforts. Then, I

consider team members’ skillsets, dependencies (like API availability or third-party tools),

and risks. For example, a login module might seem simple, but if we’re implementing OAuth

or MFA, I factor in time for R&D, testing, and edge cases. I usually estimate in story points

first and then translate it to time with buffer built in.

Follow :

Code reviews are non-negotiable. No direct merges to the main branch—every PR goes

through at least one peer review. We use Azure DevOps/GitHub PRs with templates that

require description, screenshots (for UI), and test coverage info.

For quality checks, we integrate SonarQube or CodeQL for static code analysis and

enforce checks in our CI pipeline. I also encourage reviewers to look beyond syntax—check

for performance, scalability, and readability.

I ask questions about how candidates handle conflict, feedback, and collaboration. For

instance, “Tell me about a time you disagreed with a teammate—how did you resolve it?”

Their answers reveal how they operate in a team.

I also share our team values upfront—like transparency and continuous learning—and see

how candidates respond. It’s about ensuring mutual alignment rather than “fitting in” blindly.

I address this openly but without blame. In the next retrospective, I create a safe space for

the team to share challenges.

We then review the debt together, categorize it by impact, and plan how to tackle it

incrementally—either in future sprints or dedicated “debt paydown” cycles. I also work to

improve transparency so the team feels comfortable raising issues earlier.

We once had performance issues in a reporting module. I recommended switching from

real-time report generation to a scheduled batch process using Hangfire with .NET Core,

storing the results in a cache. This reduced report load time from ~20 seconds to under 2.

Business saw increased adoption of the feature and reduced support tickets. It wasn’t just a

technical fix—it directly improved user experience and saved cloud costs.

During a tough deadline crunch, the team was drained. I paused new work for a day and

organized a retrospective to listen to concerns. We adjusted sprint velocity, added buffer,

and celebrated small wins publicly. I also advocated for an extra day off post-release, which

really lifted morale.

Follow :

First, I don’t say "no" immediately—I say "let’s assess it." I evaluate:

• The impact on current scope and timeline
• Whether it’s critical or could be phased in later
• The technical implications (e.g., refactoring, re-testing)

Then I present options:

• “We can include this now, but we'll need to move Feature X to the next sprint.”
• “Or we can go live as planned and schedule this as a quick follow-up release.”

Follow :

This gives the client agency and visibility—and usually helps reach a compromise that

keeps the project on track.

Self-Awareness & Reflection – Interview Questions + Thoughtful

Review the concept and prepare a concise verbal explanation with a real project example.

One of the toughest decisions was halting a project halfway because we discovered

architectural flaws that would’ve created scaling issues. It was unpopular—we had already

invested weeks of effort—but I took it to leadership, explained the risks, and proposed a

re-architecture plan. It delayed the release but saved us from massive rework later. It taught

me that doing the right thing technically sometimes means pushing back, even when it’s

uncomfortable.

I love it when devs show initiative. I ask them to make a case—how it helps, potential risks,

and how it fits into our current architecture. Then we review as a team.

In one case, a developer wanted to use Tailwind CSS instead of our standard SCSS. We

reviewed the pros and cons, tested it in a feature branch, and agreed to adopt it for

greenfield projects. The key is balancing autonomy with technical alignment.

We design for testability from day one. For example, we follow dependency injection in

.NET Core and avoid tightly coupled code. In React, we separate logic into custom hooks or

services, making it easier to unit test.

We aim for meaningful unit tests (xUnit, Jest) and integration tests where needed. I also

encourage writing clear interfaces and modular components so code can evolve without

breaking everything. Maintainability is part of every code review discussion.

I set up a structured onboarding plan—covering codebase overview, development

environment setup, key contacts, and sprint goals.

Follow :

Pairing new hires with a mentor accelerates learning and builds relationships. Regular

check-ins in the first few weeks help address blockers. I encourage newcomers to start with

small, manageable tasks to build confidence before tackling complex features.

Bonus Scenario-Based Questions

I start by quickly upskilling—taking online courses, reading docs, and consulting with

experts. I leverage the knowledge of the team or bring in specialists if needed.

I focus on applying my core leadership skills: clear communication, setting goals, and

managing risks. I emphasize collaboration, encouraging the team to share knowledge and

flag risks early while I learn the new stack alongside them.

Follow :

Follow :

I break the problem down and research similar use cases. I’ll reach out to peers, consult

Follow :

internal documentation or communities like Stack Overflow or Microsoft Docs. In one case,

we weren’t sure whether to use SignalR or polling for a real-time notification feature. I built

small POCs, ran performance tests, and presented findings to the team. We made a

data-driven choice—SignalR worked best for our needs.

I treat technical debt like any other risk—track it transparently in our backlog or issue

tracker. I encourage the team to prioritize it alongside new features during sprint planning.

In one project, we scheduled “debt sprints” every few months to pay down accumulated

issues. I also promote writing code with future maintainers in mind, using automated tests

and code reviews to prevent new debt.

Hiring & Building Teams

Yes, extensively. I’ve worked in Scrum teams where we follow 2-week sprints, with

grooming, planning, daily standups, reviews, and retrospectives. I often act as a tech lead

or senior developer, helping refine tickets, breaking down tech tasks, and mentoring

others. I also collaborate closely with the Scrum Master and Product Owner to raise blockers

early and keep delivery smooth.

We work as a tight-knit Agile squad. I involve QA from the story grooming stage so they can

prepare test cases in parallel. For DevOps, I make sure deployment configurations (like

CI/CD pipelines in Azure DevOps) are documented and changes communicated ahead of

releases. With PMs, I ensure regular updates via standups and Jira dashboards, and I

proactively flag risks so they can adjust timelines.

If it checks most boxes, I propose a trial with clear success metrics—like reduced dev

time or better performance—and revisit after feedback.

Client Communication & Expectation Management – Interview Questions

+ Sample Answers

I look at it from four angles:

We set up logging (using Serilog, Application Insights) and performance monitoring

(New Relic, Azure Monitor) as part of the release checklist. We track key metrics like API

response times, error rates, and resource usage.

Follow :

I set up alerts for critical failures or performance degradation, and we review logs

regularly—especially after major deployments. I also encourage the team to proactively run

load testing (using tools like k6 or Apache JMeter) before release when performance is

critical.

Yes, in one project, we were halfway through building a custom authentication module when

the client opted to integrate with Azure AD B2C instead. It required re-architecting parts of

our user management system. I paused all related development, reassigned tasks

temporarily, and set up a focused spike to integrate the new flow. Within a week, we

resumed with a clear path forward. The key was quick realignment and clear stakeholder

communication.

We use tools like Jira or Azure DevOps to track progress via boards and burndown charts.

I also monitor pull request activity, blockers, and actual work completed vs. planned.

Mid-sprint, I check in with the team on progress—not just status updates, but how confident

they feel about completing their tasks. If needed, I adjust scope or involve additional support

early to avoid last-minute surprises.

I pair them with mid-senior developers for code reviews and involve them in architectural

discussions early. I also give them manageable but slightly challenging tasks so they learn

by doing. Weekly one-on-ones help me track their growth and unblock any learning barriers.

I keep it constructive and specific. Instead of saying “This is wrong,” I say, “This LINQ query

could be optimized to reduce DB calls—here’s an example.” I also highlight what’s done well,

so the person doesn’t feel discouraged. And if the issue is conceptual—like

misunderstanding of async/await—I suggest a quick huddle or pair-programming session.

One of my most successful projects was leading the modernization of a legacy .NET

monolith into a microservices architecture with React as the frontend. We reduced page

load times by 70%, improved deployment cycles from weeks to hours, and got great

feedback from both users and stakeholders.

What made it successful wasn’t just the technical delivery—it was the collaboration across

teams, the way we handled uncertainty, and how we got buy-in at every level. It reinforced

my belief that great software is built by great communication and clear ownership, not

just good code.

Scalability, Architecture, and Performance

For task tracking, we use Jira or Azure DevOps Boards. For code and PR management,

it's Git with GitHub/GitLab or Azure Repos. We use Slack or Microsoft Teams for

communication, and Confluence for documentation. For CI/CD, Azure DevOps Pipelines

or GitHub Actions. I also like using Miro for whiteboarding during planning or architecture

discussions.

In one sprint, the frontend dev assumed an API would return detailed user info, but the

backend only returned IDs. This wasn't caught until QA testing. I took responsibility, set up a

post-mortem, and realized our story grooming didn’t align both sides. Since then, I made API

contract documentation mandatory before dev starts. A quick 10-minute API sync is now part

of our sprint kickoff.

I assess the risk and cost of the debt. If it’s minor (like a code smell in a non-critical

module), I log it as tech debt in Jira and schedule it post-release. But if it's something like

skipping unit tests for a new payment flow—I push back, because the long-term risk is too

high. I always try to make tech debt visible to stakeholders, so they understand the trade-offs

being made.

We hold bi-weekly tech huddles where developers present something they’ve worked on or

explored—like optimizing LINQ queries or using React Hooks effectively. We also maintain

internal Confluence pages with code standards, deployment steps, and troubleshooting

guides.

DevOps is a core enabler, not a separate team’s job. I advocate for full-stack developers to

understand and participate in CI/CD processes.

We use Azure DevOps Pipelines or GitHub Actions to automate builds, run unit tests, lint

checks, and deploy to dev/staging environments. We also use infrastructure-as-code (like

Bicep or ARM templates) for consistent environment provisioning.

CI/CD shortens feedback loops, catches issues early, and reduces manual errors. It’s tightly

integrated with how we deliver full-stack features end-to-end.

Innovation & Learning – Interview Questions + Sample Answers

In one project, the client kept requesting UI tweaks and additional filters post-sprint

planning. I set up a meeting with the Product Owner and stakeholders, explained the impact

on delivery, and proposed bundling the extra items into a separate sprint labeled "UX

Enhancements." By formally defining scope boundaries and being transparent about impact,

we avoided derailing the main release.

Transparency is key. I break down the scope and highlight trade-offs. For example, in a

recent feature delivery, we dropped multilingual support for the initial release to meet the

deadline but kept it in the backlog with a commitment date. I inform stakeholders early rather

than at the last minute, and I always propose options—not just problems.

In one project, I decided to build a custom grid component in React instead of using a

third-party library like AG Grid or Material Table. We thought we’d save licensing costs, but

maintaining it became a huge time sink—handling sorting, filtering, edge cases. In hindsight,

the cost of development far outweighed the license. Lesson learned: Don’t reinvent the

wheel when a reliable tool exists—and always consider long-term maintenance when

making build vs. buy decisions.

Process, Quality & Best Practices – Interview Questions + Real-World

Follow :

One of our devs consistently missed deadlines and pushed buggy code. I first checked if he

was overloaded or facing personal challenges. Turned out, he was unfamiliar with async

programming in .NET Core. I arranged for peer mentoring and gave him smaller modules to

rebuild confidence. Within two months, his performance noticeably improved.

I never start development on vague requirements. I request a quick sync with the

stakeholder or BA to clarify the business goal. If things are still evolving, I build with feature

toggles or keep the architecture flexible (e.g., config-driven logic or modular components). I

also document assumptions clearly in Jira or Confluence, so if changes come later, we know

what to revisit.

Decision-Making & Problem Solving –

Interview Questions + Sample

I keep 1:1s regular and informal. It’s not just about work—I ask how things are going in

general, what’s frustrating them, and what support they need. I also use this time to discuss

career goals, training needs, and any feedback they have for me. The goal is to build trust

and spot small issues before they become big problems.

Project & Delivery Management –

Interview Questions + Sample

Yes, a senior dev was brilliant technically but often disregarded team input. I gave him

ownership of a critical module but made it clear that collaboration and documentation were

non-negotiable. I also encouraged him to present in sprint reviews to get him more visibility

and accountability. Over time, he became more team-aligned.

I categorize tasks into frontend, backend, and integration. Based on strengths, I delegate

accordingly. For example, a React expert handles UI components, while someone stronger

in .NET Core handles APIs. For end-to-end features, I assign pairing so both get

cross-functional exposure.

Follow :

Clear role definitions help. But in cases where roles overlap—say, a backend dev also

tweaking UI—I clarify ownership during sprint planning. If overlap continues, I document

boundaries and rotate tasks so everyone stays aligned and feels involved without stepping

on toes.

I follow a servant leadership style. I see my role as enabling the team—clearing blockers,

listening actively, and letting them shine. I trust the team to own their work, but I’m always

there if they need support or direction.

Communication & Collaboration –

Interview Questions + Sample