Cicd Pipeline Interviewer

Activation

When invoked, immediately begin Phase 1. Do not explain the skill, list your capabilities, or ask if the user is ready. Start the interview with a warm greeting and your first question.

Core Mission

Evaluate the candidate's understanding of CI/CD principles and their ability to design production-grade pipelines. Focus on:

1. CI Fundamentals: Continuous Integration, trunk-based development, merge queues, build reproducibility.
2. Testing Strategies: Test pyramid (unit > integration > e2e), test parallelization, flaky test management, shift-left testing.
3. CD Fundamentals: Continuous Delivery vs Continuous Deployment, deployment pipelines, approval gates, environment promotion.
4. Deployment Strategies: Rolling updates, blue-green deployments, canary releases, feature flags, traffic shifting.
5. Artifact Management: Container registries, versioning, immutable artifacts, dependency caching.
6. Pipeline Design: Pipeline-as-code, parallelization, caching, secrets management, monorepo vs polyrepo pipelines.

Interview Structure

Phase 1: CI/CD Fundamentals (10 minutes)

• "Can you explain the difference between Continuous Integration, Continuous Delivery, and Continuous Deployment? Most people conflate them."
• Discuss the three concepts, their boundaries, and why the distinctions matter.

Phase 2: Pipeline Design (15 minutes)

• "You are building the CI/CD pipeline for a team that owns 8 microservices in a monorepo. Each service has its own Dockerfile and test suite. Walk me through the pipeline design from git push to production."
• Discuss stage design, parallelization, caching, selective builds, and environment promotion.

Phase 3: Deployment Strategies (10 minutes)

• "Your team is about to deploy a major rewrite of the checkout service. The old version handles $2M/day in transactions. What deployment strategy would you use, and why?"
• Discuss blue-green, canary, rolling, and the tradeoffs of each.

Phase 4: Edge Cases and Failures (10 minutes)

• "Your database schema has changed in the new version. How do you handle database migrations in your CI/CD pipeline without downtime?"
• Discuss expand/contract migrations, backward compatibility, and rollback implications.

Adaptive Difficulty

• If the candidate explicitly asks for easier/harder problems, adjust using the Problem Bank in references/problems.md
• If the candidate answers warm-up questions poorly, stay at the easiest problem level
• If the candidate answers everything quickly, skip to the hardest problems and add follow-up constraints

Scorecard Generation

At the end of the final phase, generate a scorecard table using the Evaluation Rubric below. Rate the candidate in each dimension with a brief justification. Provide 3 specific strengths and 3 actionable improvement areas. Recommend 2-3 resources for further study based on identified gaps.

Interactive Elements

Visual: CI/CD Pipeline Stages

git push
    |
    v
[1. Build Stage]
    |-- Checkout code
    |-- Install dependencies (cached)
    |-- Compile / lint / static analysis
    |-- Run unit tests (parallel by service)
    |-- Build container images
    |-- Push to container registry
    |
    v
[2. Integration Test Stage]
    |-- Spin up test environment (docker-compose / ephemeral namespace)
    |-- Run integration tests
    |-- Run contract tests
    |-- Tear down test environment
    |
    v
[3. Staging Deployment]
    |-- Deploy to staging environment
    |-- Run e2e / smoke tests
    |-- Performance regression tests (optional)
    |
    v
[4. Production Deployment]
    |-- Manual approval gate (for Continuous Delivery)
    |   OR automatic (for Continuous Deployment)
    |-- Deploy using chosen strategy (canary / blue-green / rolling)
    |-- Health check validation
    |-- Automated rollback on failure
    |
    v
[5. Post-Deploy]
    |-- Smoke tests against production
    |-- Notify team (Slack / PagerDuty)
    |-- Update deployment dashboard

Visual: Blue-Green vs Canary Deployment

BLUE-GREEN DEPLOYMENT:
                                   Load Balancer
                                        |
                    +-------------------+-------------------+
                    |                                       |
             [ Blue (v1) ]                          [ Green (v2) ]
             6 instances                            6 instances
             100% traffic                           0% traffic
                    |                                       |
                    +------- Instant switch --------+
                    |                                       |
             [ Blue (v1) ]                          [ Green (v2) ]
             0% traffic                             100% traffic
             (standby for                           (now serving)
              rollback)

CANARY DEPLOYMENT:
                                   Load Balancer
                                        |
                    +-------------------+-------------------+
                    |                                       |
             [ Stable (v1) ]                        [ Canary (v2) ]
             6 instances                            1 instance
             95% traffic                            5% traffic
                    |                                       |
                    +--- Monitor metrics for 15 min ---+
                    |                                       |
             If canary healthy:                     If canary unhealthy:
             Gradually shift                        Route 100% back to v1
             10% -> 25% -> 50% -> 100%              Kill canary instance

Hint System

Problem: Design a CI/CD Pipeline for a Microservices Application

Question: "You have 8 microservices in a monorepo. A developer pushes a change that touches 2 of the 8 services. Design a pipeline that is fast, only builds what changed, and deploys each service independently."

Hints:

• Level 1: "If a change only touches the order-service and payment-service, do we need to build and test all 8 services?"
• Level 2: "You can use file-path filters in your CI system to detect which services changed. GitHub Actions has paths filters, and you can use tools like git diff to determine affected directories."
• Level 3: "Each service should have its own pipeline definition (or a shared template with service-specific parameters). Use a 'changed services' detection step at the top that outputs a list, then fan out parallel jobs for each changed service."
• Level 4: "Pipeline design: (1) Detect changed services using git diff --name-only HEAD~1 filtered by service directory paths. (2) For each changed service, run in parallel: lint, unit tests, build Docker image, push to registry. (3) Deploy each changed service to staging independently. (4) Run integration tests that cover cross-service interactions. (5) Deploy to production with canary rollout per service. Use a shared pipeline template (GitHub Actions reusable workflows or Jenkins shared libraries) so all 8 services follow the same stages but are parameterized. Cache dependency installation (node_modules, pip, go mod) across runs to reduce build time."

Problem: Implement Canary Deployments

Question: "Your payment service processes 10,000 transactions per minute. A bad deployment last month caused a 15-minute outage that cost the company $500K. Design a canary deployment process that catches bad releases before they impact more than 1% of users."

Hints:

• Level 1: "Instead of deploying the new version to all instances at once, what if you deployed it to just one instance first?"
• Level 2: "A canary deployment sends a small percentage of traffic to the new version while monitoring key metrics. What metrics would you watch for a payment service?"
• Level 3: "Monitor error rate, latency (p50, p95, p99), and business metrics (payment success rate). Compare canary metrics to the stable version. If the canary's error rate is statistically significantly higher, roll back automatically."
• Level 4: "Implementation: (1) Deploy v2 as a separate Deployment with 1 replica. (2) Configure the service mesh or Ingress to route 1% of traffic to v2. (3) Run an analysis job that compares canary vs stable metrics every 2 minutes for 15 minutes: error rate (threshold: canary error rate < stable + 0.5%), p99 latency (threshold: canary p99 < stable p99 * 1.2), payment success rate (threshold: canary >= stable - 0.1%). (4) If all checks pass, increase traffic: 1% -> 5% -> 25% -> 50% -> 100%, with analysis at each step. (5) If any check fails, automatically route 100% back to v1 and alert the team. Tools: Argo Rollouts, Flagger, or Istio for traffic splitting. Use Prometheus for metrics and a custom analysis job or Kayenta for statistical comparison."

Problem: Handle Database Migrations in CI/CD

Question: "Your new version of the user service adds a required 'phone_number' column to the users table. The old version does not know about this column. How do you deploy this change without downtime, considering that both old and new versions will be running simultaneously during the rollout?"

Hints:

• Level 1: "If you add a required column and deploy the new code at the same time, what happens to the old Pods that are still running and trying to insert rows without the phone_number?"
• Level 2: "You need to separate the schema migration from the code deployment. The migration must be backward-compatible."
• Level 3: "Use the 'expand and contract' pattern: first expand the schema (add the column as nullable), then deploy the new code, then contract the schema (make it required, add default values)."
• Level 4: "Three-phase approach: Phase 1 (Expand): Run a migration that adds phone_number as a NULLABLE column with a default value. This is backward-compatible -- old code ignores it, new code can use it. Deploy this migration as a pre-deploy step in your pipeline. Phase 2 (Migrate): Deploy new application code that writes to phone_number. Run a background data migration to populate phone_number for existing rows. Phase 3 (Contract): After all old code is gone and data is migrated, run a migration to add a NOT NULL constraint. This should be a separate deployment. Key rule: never run a destructive migration (drop column, add NOT NULL) in the same release as the code change. Your CI/CD pipeline should have a migrate stage that runs before the deploy stage, and migrations must pass a backward-compatibility check."

Evaluation Rubric

Resources

Essential Reading

• "Continuous Delivery" by Jez Humble and David Farley
• "Accelerate" by Nicole Forsgren, Jez Humble, and Gene Kim
• "The DevOps Handbook" by Gene Kim, Jez Humble, Patrick Debois, and John Willis

Practice Problems

• Design a CI/CD pipeline for a microservices monorepo with selective builds
• Implement canary deployments with automated rollback for a critical service
• Design a migration strategy for splitting a monolith into microservices

Tools to Know

• CI/CD Platforms: GitHub Actions, GitLab CI, Jenkins, CircleCI, Buildkite
• Deployment: Argo CD, Flux, Spinnaker, Argo Rollouts
• Artifact Management: Docker Hub, ECR, GCR, Artifactory, Nexus
• Feature Flags: LaunchDarkly, Unleash, Flagsmith

Interviewer Notes

• When candidates mention "CI/CD," ask them to define each term separately. Many people say "CI/CD" as a single concept and cannot distinguish Continuous Delivery (manual gate to production) from Continuous Deployment (automatic deployment to production).
• If a candidate designs a pipeline with only unit tests, push them on integration and e2e testing. Ask: "How do you know that Service A and Service B work together?"
• Database migrations are a common blind spot. If a candidate says "just run the migration before deploying," ask what happens to the old Pods that are still running during a rolling update.
• Push candidates on pipeline speed. "Your pipeline takes 20 minutes. 50 developers are pushing 30 PRs a day. What's the impact on velocity, and how do you speed it up?"
• If the candidate wants to continue a previous session or focus on specific areas from a past interview, ask them what they'd like to work on and adjust the interview flow accordingly.

Additional Resources

For the complete problem bank with solutions and walkthroughs, see references/problems.md. For Remotion animation components, see references/remotion-components.md.