Jenkins interviews focus on Pipeline as Code and the controller/agent architecture that's powered CI/CD for over a decade.
Jenkins is an open-source automation server that orchestrates the build, test, and deployment stages of the software delivery lifecycle. In a CI/CD context it's the engine that watches for code changes, usually via a webhook from GitHub or GitLab, and then automatically compiles the code, runs the test suite, and pushes the artifact toward staging or production. It's written in Java, ships with its own web UI, and its real power comes from its plugin ecosystem rather than built-in features. Because it's self-hosted, teams get full control over the build environment, but that also means you're on the hook for maintaining and scaling it yourself, unlike hosted offerings like GitHub Actions. Most companies use it as the central hub that ties together source control, artifact repositories, and deployment targets like Kubernetes or AWS.
Both are ways of writing a `Jenkinsfile`, but they differ in syntax and flexibility. Declarative pipeline uses a fixed, structured format that starts with a `pipeline` block and enforces sections like `agent`, `stages`, and `post`, which makes it easier to read, validate, and lint before it even runs. Scripted pipeline is essentially raw Groovy wrapped in a `node` block, giving you full programmatic control with loops, conditionals, and try/catch logic, but at the cost of readability and a steeper learning curve. In practice, most teams default to declarative for its guardrails and only drop into scripted blocks, using the `script` step, when they need something declarative can't express cleanly. Both ultimately compile down to the same Groovy-based pipeline engine under the hood.
A Jenkinsfile is a text file, usually checked into the root of your repository, that defines your entire build pipeline as code rather than through manual point-and-click job configuration in the Jenkins UI. Because it lives in version control alongside the application code, every change to the pipeline gets reviewed, diffed, and rolled back the same way as any other code change, which you just can't do with a freestyle job's UI-based config. It also means the pipeline definition travels with the branch, so a feature branch can safely experiment with a different build process without touching the main pipeline. Jenkins reads the Jenkinsfile at runtime, either from SCM directly or via a multibranch pipeline job, so there's no drift between what's documented and what's actually running. This is really the foundation of treating your CI/CD process itself as a versioned, testable artifact.
A freestyle job is Jenkins' original job type, configured entirely through the web UI with build steps, triggers, and post-build actions set as form fields, and its state lives only in Jenkins' internal config XML. A pipeline job, by contrast, is driven by a Jenkinsfile written in Groovy-based DSL, so the entire build logic is code that's portable, versionable, and reviewable. Freestyle jobs are quick to set up for simple, single-step tasks but don't scale well once you need multi-stage logic, conditional branching, or parallel execution, since chaining them requires plugins like the old "Build Pipeline" plugin or upstream and downstream triggers. Pipeline jobs natively support stages, parallelism, retries, and shared libraries, which is why nearly every modern Jenkins setup uses pipelines instead. The main reason freestyle jobs still show up is legacy projects or very simple utility jobs where a Jenkinsfile would be overkill.
Jenkins runs in a distributed model where the controller, historically called the master, handles scheduling builds, serving the web UI, and storing configuration and job history, but doesn't necessarily execute the actual build work itself. Agents, previously called slaves, are separate machines or containers that register with the controller and actually run the build steps, which lets you distribute load across different environments, say a Windows agent for .NET builds and a Linux agent for containerized services. Agents connect back to the controller over JNLP or SSH, and you can label them so pipelines target specific hardware or toolchains using syntax like `agent { label 'docker' }`. This separation is what lets Jenkins scale horizontally, since you just add more agents rather than overloading a single node, and it's also what enables ephemeral agents spun up on demand through plugins like the Kubernetes plugin. Keeping heavy builds off the controller is a best practice because an overloaded controller can degrade the whole system's responsiveness.
Jenkins core is intentionally minimal, it just gives you a scheduler, a UI, and an execution engine, and almost everything else, from Git integration to Slack notifications to Docker support, comes from plugins. There are well over a thousand plugins in the official update center, covering source control integrations, cloud providers, credential stores, static analysis tools, and pipeline steps, which is why Jenkins can slot into almost any tech stack. The tradeoff is that plugin quality and maintenance vary widely, some are actively maintained by CloudBees or the community while others are stale, and version compatibility issues between plugins are a common source of Jenkins upgrade pain. Because of that, most teams pin plugin versions and test upgrades in a staging Jenkins instance before rolling them out to production. The Plugin Manager UI lets you install, update, and see dependency chains, but keeping a large plugin footprint healthy is genuinely one of the bigger operational burdens of running Jenkins at scale.
The most common and recommended way is a webhook, where GitHub, GitLab, or Bitbucket pings Jenkins the moment a push or pull request happens, so the build kicks off within seconds and Jenkins doesn't waste cycles checking for changes that aren't there. The older alternative is SCM polling, configured with a cron-like expression such as `H/5 * * * *`, where Jenkins periodically checks the repository for new commits itself; it works without exposing Jenkins to the internet but adds latency and unnecessary load. You can also trigger builds on a pure schedule using the `cron` trigger, which is common for nightly regression suites or periodic cleanup jobs unrelated to code changes. Beyond that, builds can be triggered manually, chained from upstream jobs finishing successfully, or fired via the REST API or CLI, which is handy for integrating Jenkins with external tooling. In practice, most production setups favor webhooks for speed and use polling only when the network topology makes webhooks impractical.
A stage represents a logical, visually distinct segment of your pipeline, like `Build`, `Test`, or `Deploy`, and Jenkins renders each one as its own block in the pipeline visualization, which makes it easy to see at a glance where a build failed. A step is the actual unit of work inside a stage, things like `sh 'mvn test'`, `checkout scm`, or `archiveArtifacts`, and a stage can contain any number of steps executed sequentially. This structure exists purely for organization and observability, Jenkins doesn't require you to use stages, but without them you'd lose the clean visual breakdown in the classic UI and Blue Ocean. Stages can also carry their own `agent`, `when` conditions, and `post` blocks, so you can run a specific stage only on certain branches or route it to a different agent label. Grouping steps into well-named stages is really a readability and debugging convenience more than a functional requirement.
You use the `parallel` block, either at the stage level or within a stage, and give it a map of named branches, each containing its own sequence of steps, and Jenkins executes all of them concurrently across available agents or executors. It's most commonly used for things like running unit tests across multiple language versions simultaneously, or building and testing on Linux and Windows agents at the same time, which cuts overall pipeline duration significantly compared to running everything sequentially. You can also set `failFast: true` so that if one parallel branch fails, Jenkins immediately aborts the others instead of waiting for them to finish. One thing to watch for is executor availability, if you request more parallel branches than you have free executors across your agents, some branches will just queue and wait, which can silently negate the speed benefit. Parallel stages also show up as separate lanes in Blue Ocean, which makes diagnosing which specific branch failed much easier than scrolling through a single combined log.
Jenkins has a built-in Credentials plugin that stores secrets, usernames and passwords, SSH keys, secret text, and certificates, in an encrypted store on the controller, scoped either globally or to a specific folder or job. Pipelines reference credentials by ID rather than embedding actual secret values, typically through the `withCredentials` step or the `credentials()` helper in an environment block, so the secret value never appears in the Jenkinsfile or in version control. Jenkins also automatically masks credential values in the console log output, replacing them with asterisks, to reduce the risk of accidental leakage during a build. For larger organizations, Jenkins can integrate with external secret managers like HashiCorp Vault or AWS Secrets Manager through plugins, which is generally preferred over relying solely on Jenkins' internal store since it centralizes secret rotation and auditing. Scoping credentials tightly, like binding them to a specific folder instead of making everything global, is one of the more overlooked but important security practices in a multi-team Jenkins instance.
Blue Ocean is a plugin and reimagined UI for Jenkins that visualizes pipelines as a clean, graphical flow of stages rather than the dense, text-heavy layout of the classic Jenkins interface. It's particularly useful for pipelines with parallel stages, since it renders concurrent branches as visually distinct lanes, making it much easier to spot exactly which parallel step failed without digging through interleaved logs. Blue Ocean also includes a visual pipeline editor that can generate a Jenkinsfile through a drag-and-drop interface, which lowers the barrier for people less comfortable writing Groovy by hand. That said, it's worth noting that Blue Ocean's active development has largely stalled as CloudBees shifted focus elsewhere, so while it's still usable and included in many Jenkins installs, it's not receiving the investment it once did. Many teams still use it purely as a better read-only dashboard even if they write and edit Jenkinsfiles the traditional way.
The `archiveArtifacts` step lets you capture files produced during a build, like compiled binaries, test reports, or packaged applications, and store them alongside that specific build record in Jenkins so they're downloadable from the build's page later. You typically call it with a glob pattern, something like `archiveArtifacts artifacts: 'target/*.jar', fingerprint: true`, and the fingerprint option lets Jenkins track that exact file across downstream jobs, which is useful for tracing which build's artifact actually got deployed. For anything beyond short-term storage, teams usually push artifacts to a dedicated repository like Nexus, Artifactory, or an S3 bucket instead, since Jenkins' own artifact storage isn't meant to be a long-term or highly available artifact repository and can bloat disk usage on the controller over time. Jenkins also supports the `stash` and `unstash` steps for passing files between stages within the same pipeline run, which is different from archiving since stashed files don't persist after the build finishes. Getting artifact retention policies right, using job or build discarders, matters too, otherwise archived artifacts can quietly consume a lot of disk space over months of builds.
The biggest difference is hosting model: Jenkins is self-managed, so you own the infrastructure, scaling, security patching, and plugin maintenance, whereas GitHub Actions and GitLab CI are largely SaaS-first with managed runners, so there's far less operational overhead to get started. Jenkins' pipeline syntax, whether declarative or scripted Groovy, is also more verbose and has a steeper learning curve compared to the YAML-based configs of GitHub Actions and GitLab CI, though YAML has its own limitations around expressing complex conditional logic. Where Jenkins still wins is flexibility and ecosystem breadth, its plugin library and ability to run literally anywhere, on-prem, air-gapped networks, custom hardware, make it a better fit for complex enterprise environments with legacy systems or strict compliance requirements. GitHub Actions and GitLab CI, on the other hand, tend to have tighter native integration with their respective platforms' pull requests, issues, and container registries, which reduces the glue code you'd otherwise need to write in Jenkins. In practice, the choice often comes down to whether you're already living in GitHub or GitLab's ecosystem and want convenience, versus needing Jenkins' openness and control for a more complex or hybrid infrastructure.
A Shared Library is a separate, version-controlled repository of reusable Groovy code, custom steps, classes, and pipeline logic, that any Jenkinsfile across your organization can import with a single line like `@Library('my-shared-lib') _` at the top. It solves the problem of duplicated pipeline logic across dozens or hundreds of repositories, since instead of copy-pasting the same deployment or notification steps into every Jenkinsfile, you centralize that logic once and every team just calls a shared function like `deployToKubernetes(namespace: 'staging')`. Shared libraries follow a specific folder convention, `vars` for globally accessible pipeline steps and `src` for more structured Groovy classes, and Jenkins loads them dynamically at pipeline runtime. They can be configured globally by an admin, trusted and available to all pipelines, or loaded on-demand per pipeline, which gives security teams a way to control what code untrusted pipelines can execute. This is really the mechanism that lets platform or DevOps teams enforce consistent build and deployment standards across an entire organization without policing every individual Jenkinsfile.
A node is any machine, whether the controller itself or an agent, that's registered with Jenkins and capable of running build work. An executor is a slot within a node, essentially a worker thread, that can run one build step at a time, and a single node can be configured with multiple executors to run several jobs or pipeline stages concurrently on the same machine. If a node has two executors and three jobs try to run on it simultaneously, the third simply queues until an executor frees up. Setting a node's executor count too high risks jobs competing for the same CPU, memory, and disk I/O and slowing each other down, while too few executors leaves capacity idle even when jobs are queued waiting. In practice, the controller is usually configured with zero or very few executors so it stays free to schedule and serve the UI, pushing actual build execution out to dedicated agents.