In this article
Before you start
Why interviewers ask this
"What is Jenkins?" is a small question that shows whether a candidate has ever shipped code through an automated path or only heard the word. A strong answer prevents the next ten minutes of probing, because it already contains the vocabulary: pipeline, stage, agent, trigger, and it signals that the candidate has run one. The question also leads naturally into deployment strategies, Kubernetes and how a machine learning model reaches production, a topic of the machine learning operations (MLOps) hub.
A weak answer says "a CI tool" and stops. A strong answer says what runs, where it runs, what starts it and what happens when a stage fails.
Jenkins from first principles
In plain words
- Jenkins controller
- The Jenkins controller is the central Jenkins server. It holds the configuration and the plugins, schedules runs and administers the agents. A plugin is an add-on that gives Jenkins a feature.
- Jenkinsfile
- A Jenkinsfile is a text file that defines a Jenkins pipeline and is checked into source control with the code it builds. Because it is versioned like code, a change to the build is reviewed and can be reverted like any other change.
- Jenkins agent
- A Jenkins agent is a machine that runs the work a Jenkins controller hands it. It needs a Java installation and a network connection to the controller.
- Executor
- An executor is a slot on a Jenkins agent that runs a single task at a time. The number of executors on an agent sets how many tasks it can run concurrently, so an agent with two executors can work on two builds together.
Two terms in the first sentence need unpacking. Continuous integration (CI) means merging code changes into a shared repository often, with an automatic build and test on each change. Continuous delivery (CD) means keeping that code always ready to release, with the release steps automated.
Think of a restaurant kitchen. The pass, where orders arrive and are handed out, is the controller. The cooks at their stations are the agents. The recipe card pinned beside the stove is the Jenkinsfile: it says which steps happen, in which order, whoever is cooking.
The analogy breaks in one place. A kitchen has one fixed pass and a fixed set of cooks, but Jenkins agents can be added or removed as machines come and go, and one cook, an executor, handles one order at a time.
In one precise sentence, Jenkins turns a version-controlled list of stages into a run that a controller schedules and agents execute.
Step 1: The pipeline is a list of stages written as code
A Jenkins pipeline is an automated sequence of stages, such as build, test and deploy, that Jenkins runs in order. The Jenkins documentation says a Jenkinsfile contains the definition of a pipeline and is checked into source control, and that it connects phases rather than replacing build tools like Make or Maven.
A declarative pipeline, the newer syntax described on that page, wraps everything in a pipeline block with an agent and stages. The Jenkins Pipeline overview shows a three-stage example with stages named Build, Test and Deploy, each running shell commands. If one stage fails, the later stages do not run.
pipeline {
agent any
stages {
stage('Build') { steps { sh 'make' } }
stage('Test') { steps { sh 'make check' } }
stage('Deploy') { steps { sh 'make publish' } }
}
}Read the block from the outside in. pipeline is the whole definition. agent any says any available agent may run it. Each stage has a name and a list of steps, and here every step is a shell command that calls the project's own build tool. The block is a shortened form of the example on the Pipeline page,.
The input is the repository. The output is an ordered list of steps.
Step 2: A trigger starts the run
A trigger is the event that starts a pipeline run, and in a pipeline file the triggers directive lists them. The pipeline syntax reference says the triggers currently available in that directive are cron, pollSCM and upstream: a regular schedule, a regular check for new source changes, and the end of another job.
A code host can also notify Jenkins on a push, the pattern the webhook page explains. For repositories with many branches, a multibranch pipeline, as the multibranch page puts it, automatically discovers, manages and executes pipelines for branches that contain a Jenkinsfile.
The input is an event. The output is a queued run.
Step 3: Agents run the work and the controller coordinates
The controller schedules runs and agents execute them. The Jenkins agents page says the controller administers the agents and orchestrates their work, and that agents provide executors that perform work when the controller requests it.
The same page recommends setting the controller's own executor count to 0, to avoid resource contention. A heavy build can slow the scheduler for every team. There is a security reason too. The built-in node is the set of executors that run inside the controller process itself. The Controller Isolation page explains that builds on the built-in node have the same file-system access as the Jenkins process, so it is "highly advisable to not run any builds on the built-in node". Both reasons together are the answer to the follow-up above.
With agent any at the top of a pipeline, the Pipeline page says Jenkins allocates one executor and workspace for the entire pipeline. Stages run on separate agents only when a stage declares its own agent.
Capacity is simple arithmetic: three agents with two executors each give six concurrent tasks, an illustrative layout shown in the diagram below. The agent directive in a pipeline says where the whole pipeline, or one stage, will execute.
Step 4: Post actions decide what happens next
A post section holds steps that run after the stages finish, chosen by the outcome. The pipeline syntax reference lists conditions such as always, which runs regardless of the status, success, and failure, which runs only when the run has failed.
That is where a team puts notifications, cleanup and test-report publishing. A failed run is not an exception to the design; it is a normal outcome with its own steps, and a team that plans for it gets a message with the failing stage named instead of a silent red mark. For example, a failure step might notify the author of the commit, while an always step archives the test report whichever way the run ended. The input is a finished run and its status. The output is the cleanup and the message that tell people the result.
Step-by-step description
- Stages live in a Jenkinsfile in the repository.
- A schedule, a poll or an upstream job starts the run.
- The controller queues it and an agent runs it.
- Post actions run on success, failure or always.
- The Jenkinsfile holds the stages and lives in source control.
- The controller schedules runs and agents execute them.
- Post actions run after the stages, on success, on failure or always.
Text description of the diagram
- The controller has zero executors in this layout.
- Three agents with two executors each give six concurrent tasks.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
What is Jenkins, and how does it run a build?
Jenkins is an open source automation server for continuous integration and delivery. The pipeline lives in a Jenkinsfile in the repository, so the build is versioned and reviewed like code. A trigger, such as a schedule, a poll of the repository or another job finishing, queues a run on the controller, and the controller gives the run a free executor on an agent, one for the whole pipeline unless a stage names its own agent. I keep the controller at zero executors so a heavy build cannot starve the scheduler or read the controller's files. Post actions handle notification and cleanup whether the run succeeds or fails. The weakness to plan for is plugin and agent upkeep.
What makes it Staff-level is the last two moves: it states the design choice behind the controller and it names the operating cost instead of only describing features.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Correctness | "A CI tool" | Automation server that builds, tests and deploys | Adds pipeline as code, controller, agents and triggers |
| Depth | Names no parts | Explains Jenkinsfile and stages | Explains executors and why the controller runs none |
| Trade-offs | None | Mentions agents need upkeep | Weighs self-hosting against managed alternatives and names plugin risk |
| Communication | Jargon only | Defines each term once | Walks one commit from trigger to result |
| Follow-up readiness | Stalls on "why" | Handles triggers and failure | Handles scaling agents and multibranch builds |
Three variants of this question
What is a Jenkinsfile and where does it live?
A Jenkinsfile is a text file that defines a Jenkins pipeline and is checked into source control, usually at the root directory of the project. Keeping it there versions the build with the code it builds.
What is the difference between declarative and scripted pipelines?
Declarative pipelines use a structured pipeline block with required agent and stages directives and were added in Pipeline 2.5, while scripted pipelines use a node block and Groovy, which allows loops and try/catch. Choose declarative unless you need that freedom, a split the Jenkinsfile page describes.
What was Hudson, and how is it related to Jenkins?
Hudson was the project's earlier name. The Register reported in January 2011 that the community proposed renaming it Jenkins after Oracle's claim to the Hudson trademark, so older articles may say Hudson for the same lineage.
Common mistakes
- "Jenkins is a build tool like Maven" (wrong). Maven and Make compile and package code, while Jenkins orchestrates those tools in stages (right: say it is the orchestrator, as the Jenkinsfile page puts it, glue between phases).
- "The controller should also run the builds" (wrong). It can, but the documentation recommends zero executors on it, both to avoid resource contention and because builds on the built-in node can read the controller's files (right: let agents do the work).
- "A failed stage means the run is broken" (wrong). Later stages stop, and
poststeps still run on failure (right: describe the failure path). - "Jenkins only runs when someone clicks" (wrong). Triggers start runs on a schedule, a repository poll or an upstream job (right: name a trigger).
Follow-up questions
How does Jenkins know a commit happened?
It can poll: the pollSCM trigger checks for new source changes at a regular interval. A code host can also call Jenkins when a push happens, which avoids the delay of polling.
Why set the controller to zero executors?
There are two reasons. The agents page recommends 0 to avoid resource contention, so the scheduler stays responsive. The Controller Isolation page adds that builds on the built-in node have the same file-system access as the Jenkins process, so builds belong on agents.
Why do Jenkins plugins need upkeep?
The plugin management page calls plugins "the primary means of enhancing" Jenkins, and says they come "with their dependencies". It also says the Update Center installs only the latest release of a plugin, so a team has to keep up with updates and test them.
What happens when a stage fails?
The pipeline stops running later stages, and the post section can still run steps for the failure or always conditions, such as sending a notice and cleaning up.
Does Jenkins need Java?
Yes. The documentation says Jenkins can run on any machine with a Java Runtime Environment, and that agents require a Java installation and a network connection to the controller.
What is a multibranch pipeline?
A multibranch pipeline automatically creates and runs a pipeline for each branch that contains a Jenkinsfile, so a new feature branch gets the same checks without manual setup. Data teams use the same idea in a data engineering project.
- Jenkins is an open source automation server that runs build, test and deploy stages.
- The pipeline is a Jenkinsfile in the repository, so the build is versioned like code.
- A trigger starts a run, the controller queues it and an agent with a free executor runs it.
- Setting the controller to zero executors keeps the scheduler responsive.
- Post actions handle the outcome, including failure.
Sources
- Jenkins User Documentation — Jenkins project (page shows no date; read 2026-10-24), 24 Oct 2026
- Using a Jenkinsfile — Jenkins project (read 2026-10-24), 24 Oct 2026
- Pipeline Syntax (triggers, post, agent, stages) — Jenkins project (read 2026-10-24), 24 Oct 2026
- Using Jenkins agents — Jenkins project (read 2026-10-24), 24 Oct 2026
- Pipeline — Jenkins project (read 2026-10-24), 24 Oct 2026
- Controller Isolation — Jenkins project (read 2026-10-24), 24 Oct 2026
- Managing Plugins — Jenkins project (read 2026-10-24), 24 Oct 2026
- Branches and Pull Requests (multibranch Pipeline) — Jenkins project (read 2026-10-24), 24 Oct 2026
- Hudson renamed Jenkins — The Register, 11 Jan 2011
