Interview Q&A

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

Real-world example (ShopNest)

ShopNest’s team uses GitHub PRs with reviews and CI checks so broken builds never reach production unnoticed.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: <<<<<<< HEAD your code ======= incoming code >>>>>>> branch

Real-world example (ShopNest)

Feature work for “UPI payment” lives on feature/upi-payment. Open a PR to main; resolve conflicts before merge.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: My preferred strategy depends on the project type and team size: For large enterprise projects with planned releases → I prefer Git Flow.

Explain a bit more

Branches: main, develop, feature/*, release/*, hotfix/* Benefits: Organized release management, clear isolation of features and fixes. For agile teams or startups deploying multiple times a day → I prefer Trunk-Based Development. Developers work on short-lived feature branches and merge into main frequently (often daily). CI/CD pipelines ensure code is always deployable. Real-world example: At my last company, we used Trunk-Based Development for a SaaS platform — it reduced merge conflicts and allowed fast continuous deployment.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: 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 }}

Real-world example (ShopNest)

ShopNest’s team uses GitHub PRs with reviews and CI checks so broken builds never reach production unnoticed.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: git config --global user.signingkey <key-id> git config --global commit.gpgsign true

Real-world example (ShopNest)

ShopNest’s team uses GitHub PRs with reviews and CI checks so broken builds never reach production unnoticed.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: 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.

Explain a bit more

✅ 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: } } stage('Build') { steps { sh 'npm install' sh 'npm test' }

Example code

}
}
} ● Jenkins polls Git or listens for webhooks to trigger builds automatically. ✅ GitLab CI/CD GitLab CI is built-in — simply create .gitlab-ci.yml: stages: test deploy test: script: npm install npm test deploy: script: ./deploy.sh only: main Every push triggers this pipeline automatically. ✅ GitHub Actions GitHub has its own YAML-based workflows: name: Node CI on: [push, pull_request] jobs: build: runs-on: ubuntu-latest steps: uses: actions/checkout@v4 run: npm ci run: npm test It runs directly in GitHub without needing extra setup. Real-world example: Your team pushes code to GitHub → GitHub Actions automatically runs tests → Jenkins (or GitLab CI) deploys to a staging environment → Approval required for production deploy.

Real-world example (ShopNest)

ShopNest’s team uses GitHub PRs with reviews and CI checks so broken builds never reach production unnoticed.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: git cherry-pick <commit-hash>

Real-world example (ShopNest)

Prefer clear commits: fix(cart): prevent negative quantities instead of update.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: git switch -c hotfix/save-work

Real-world example (ShopNest)

ShopNest’s team uses GitHub PRs with reviews and CI checks so broken builds never reach production unnoticed.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: git checkout -b feature/login abc1234

Real-world example (ShopNest)

Feature work for “UPI payment” lives on feature/upi-payment. Open a PR to main; resolve conflicts before merge.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

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

Real-world example (ShopNest)

ShopNest’s team uses GitHub PRs with reviews and CI checks so broken builds never reach production unnoticed.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

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

Real-world example (ShopNest)

Prefer clear commits: fix(cart): prevent negative quantities instead of update.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: git merge origin/main

Real-world example (ShopNest)

Feature work for “UPI payment” lives on feature/upi-payment. Open a PR to main; resolve conflicts before merge.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: 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.

Explain a bit more

The -u flag links your local branch with the remote one so future pushes are easier (git push alone works after that). Real-world example: You create a local portfolio website and later decide to host it on GitHub. You connect your local repo to the remote one using git remote add origin so both stay in sync.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Mark the conflicting sections in your file: <<<<<<< HEAD your current branch code ======= incoming branch code >>>>>>> feature/new-ui

Real-world example (ShopNest)

Feature work for “UPI payment” lives on feature/upi-payment. Open a PR to main; resolve conflicts before merge.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: <<<<<<< HEAD current branch code ======= incoming branch code >>>>>>> feature/contact-form

Real-world example (ShopNest)

Feature work for “UPI payment” lives on feature/upi-payment. Open a PR to main; resolve conflicts before merge.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: git checkout wrong-branch git reset --hard HEAD~2

Real-world example (ShopNest)

Feature work for “UPI payment” lives on feature/upi-payment. Open a PR to main; resolve conflicts before merge.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

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

Example code

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

Real-world example (ShopNest)

ShopNest’s team uses GitHub PRs with reviews and CI checks so broken builds never reach production unnoticed.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: 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.

Explain a bit more

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.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

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

Real-world example (ShopNest)

ShopNest’s team uses GitHub PRs with reviews and CI checks so broken builds never reach production unnoticed.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

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

Real-world example (ShopNest)

ShopNest’s team uses GitHub PRs with reviews and CI checks so broken builds never reach production unnoticed.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

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

Real-world example (ShopNest)

Prefer clear commits: fix(cart): prevent negative quantities instead of update.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Alignment strategies: Define and communicate a clear Product Vision.

Explain a bit more

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:

Real-world example (ShopNest)

Agile for ShopNest means ship a thin checkout slice every sprint, get feedback, then improve—not a 6-month big-bang release.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Challenge How to Overcome Unclear roles Provide clear Scrum training; reinforce roles (PO, SM, Dev Team).

Explain a bit more

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:

Real-world example (ShopNest)

Agile for ShopNest means ship a thin checkout slice every sprint, get feedback, then improve—not a 6-month big-bang release.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Best practices: Rotate formats to keep things fresh.

Explain a bit more

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:

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: These values create a strong foundation for effective teamwork: Commitment – Teams commit to goals and deliverables.

Explain a bit more

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:

Real-world example (ShopNest)

Agile for ShopNest means ship a thin checkout slice every sprint, get feedback, then improve—not a 6-month big-bang release.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.