1.7Interview Depth Check

Question 1

Prompt: Your team is migrating from a monolith on Jenkins to microservices on GitHub. The CTO wants everything moved in one sprint. How do you push back, and what migration plan do you propose?

What a strong answer should cover:

• Risk of a big-bang migration: broken pipelines block all teams simultaneously
• Phased approach: migrate one service at a time, starting with the least critical
• Parallel running period where both systems coexist
• Secret migration strategy and audit trail
• Team training and documentation before cutover

Example answer:

• "I would propose a phased migration starting with a non-critical service to validate our GitHub Actions patterns. During the first phase, both Jenkins and GitHub Actions run in parallel so we have a fallback. I would migrate secrets through the platform's encrypted stores with an audit log, never through code. Each migrated service gets a one-week soak period before we decommission its Jenkins job. This approach limits blast radius and gives the team time to build confidence with the new platform."

Question 2

Prompt: You discover that your CI pipeline runs for 35 minutes on every push, and developers have started merging without waiting for results. The test suite itself is sound. What do you do?

What a strong answer should cover:

• Diagnosis: identify which stages are slow (install, test, deploy)
• Pipeline staging: move expensive tests to PR/merge triggers, keep fast tests on push
• Caching: dependencies, browser binaries, Docker layers
• Parallelization: sharding, matrix strategies
• Cultural fix: making the pipeline fast enough that developers trust it again

Example answer:

• "First I would profile each pipeline stage to find the bottleneck. Then I would restructure triggers so only lint and unit tests run on every push -- targeting under 3 minutes. Integration and browser tests move to PR events. I would add dependency caching and test sharding to cut wall-clock time further. The goal is to make the fast-feedback loop fast enough that developers naturally wait for it, restoring trust in the pipeline as a safety net rather than a bottleneck."

Question 3

Prompt: A junior engineer asks why you need both CI and CD -- why not just deploy every commit directly? How do you explain the difference and the risks?

What a strong answer should cover:

• CI validates code correctness; CD ensures deployability; Continuous Deployment automates the release
• The maturity ladder: CI is table stakes, CD requires a reliable test suite, Continuous Deployment requires exceptional test coverage and monitoring
• Risk without CI: broken code reaches production because nobody validated it
• Risk of premature Continuous Deployment: insufficient test coverage means bugs auto-deploy

Example answer:

• "CI is about proving the code works -- every merge triggers automated validation. CD extends that by ensuring the artifact is always deployable, but a human still decides when to release. Continuous Deployment removes that human step entirely. The risk of jumping straight to Continuous Deployment is that your test suite becomes your only safety net -- if coverage is thin, bugs auto-deploy to users. I recommend teams earn Continuous Deployment by first building a mature CI practice, then graduating to CD, and only adopting full Continuous Deployment when their test suite and monitoring give them genuine confidence."