Jenkins Fundamentals
Fast recall
Quick revision
Core answer
Whether you understand Jenkins as a self-hosted pipeline orchestrator with a master/agent model and a plugin ecosystem, and can name what it costs (ops, plugin sprawl) vs. managed CI.
Listing Jenkins plugins you've used without explaining the controller/agent model, the Jenkinsfile-as-pipeline, or the maintenance burden of self-hosting.
Frame Jenkins as a self-hosted pipeline orchestrator (controller + agents, Jenkinsfile-as-code, plugin ecosystem), name the trade-off against managed CI (full control vs. you operate it), and acknowledge the plugin-sprawl maintenance burden.
Interview-ready guide
Interview answer
Jenkins is an open-source automation server that orchestrates CI/CD pipelines — build, test, deploy — and it exists because before managed CI like GitHub Actions, teams needed a self-hosted, scriptable engine to run their release process on every commit.
The model is a controller that manages scheduling and config plus agents that run the steps, which enables parallel execution. The modern form is pipeline as code — a Jenkinsfile checked into the repo, so the pipeline is versioned with the source and reviewable.
The trade-off I'm honest about is control versus maintenance: self-hosting gives you full control — custom agents, on-prem networks, any plugin — but you bear the operations burden of upgrading the controller, managing plugin compatibility, and patching security holes. The plugin ecosystem is both Jenkins' power and its fragility; plugins enable any integration but need governance.
So for teams with on-prem constraints or heavy customization needs Jenkins still makes sense; for greenfield projects, managed CI often wins because it removes the ops burden.
Jenkins Fundamentals
Direct Answer
Jenkins is an open-source automation server that orchestrates pipelines — build, test, scan, deploy — across languages and platforms via a plugin ecosystem and a declarative Jenkinsfile. It exists because, before managed CI (GitHub Actions, GitLab CI), teams needed a self-hosted, scriptable engine to run their release process on every commit, and Jenkins filled that with extreme extensibility: a plugin exists for almost any tool, and pipelines are code (Jenkinsfile) checked into the repo. It remains the workhorse in many enterprises precisely because it's self-hosted and endlessly customizable.
Common Mistakes & Pitfalls
Listing Jenkins plugins you've used without explaining the controller/agent model, the Jenkinsfile-as-pipeline, or the maintenance burden of self-hosting.
Check your understanding
Answer these without looking back at the article.
- What is the difference between the Jenkins controller and an agent, and how does it enable parallel pipelines?
- What does 'pipeline as code' mean with a Jenkinsfile, and why is it better than freestyle jobs?
- What is the maintenance burden of self-hosting Jenkins, and how does it compare to managed CI?
- Why is the plugin ecosystem both Jenkins' strength and its fragility?
- When would you choose Jenkins over GitHub Actions, and when would you not?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.