Articles
TeamCity Interview Questions: Build Chains, Artifact Dependencies, and Reproducibility
Practice TeamCity interview questions with snapshot vs artifact dependencies, wrong-package timelines, build reuse, clean checkout, and reproducibility checks.
The Compile, Test, and Deploy builds are all green, but production runs a package that Test never inspected. An artifact dependency can select a newer successful build even though Test validated an earlier package.
Answer TeamCity interview questions by explaining execution order, source-revision selection, and artifact identity as separate contracts. This guide uses a compile-test-deploy mismatch, a dependency review matrix, and a reproducibility evidence ledger. The core question is not merely whether stages ran in order: it is whether the final stage consumed the output that the intended tests validated.
Start with Design a Dependency-Aware CI/CD Pipeline. After drawing its graph, annotate which edges synchronize source revisions and which edges transfer files. Those annotations reveal whether Test and Deploy can select different packages despite running in the intended order.
What should you clarify about the TeamCity setup?
Ask five questions before choosing a dependency setting:
- Are the stages classic build configurations, newer pipeline jobs, or separate pipelines?
- Which upstream stages must finish before each downstream stage starts?
- Which source roots and revisions must be synchronized?
- Which exact upstream build supplies each downloaded artifact?
- Which inputs and outputs must be recorded to reproduce or audit the result?
Official fact: JetBrains describes a build chain as a dependency graph, with dependencies declared in downstream objects pointing to upstream ones. Classic build configurations and newer pipelines can participate, but their configuration representation differs. See the TeamCity build-chain documentation.
Scope and evidence: This guide's worked configuration cases use classic build configurations. Current linked documentation is TeamCity On-Premises 2026.2 documentation; check the installed edition and version before translating settings into UI or DSL. Official product facts are labeled. The exercises and diagnostic proposals are original reasoning, with no independently verified employer-specific candidate report or claimed interview frequency.
A job dependency inside one newer pipeline is not automatically the same configuration surface as a snapshot dependency between classic configurations. Naming the object type prevents a correct concept from turning into an incorrect configuration instruction.
What does a snapshot dependency guarantee?
Official fact: JetBrains' chain-dependency guide explains that snapshot dependencies govern execution order and source-revision synchronization. The synchronization setting can be disabled, and build reuse depends on suitability. Snapshot dependencies do not transfer artifact files.
Original review exercise: Compile builds the application. Test must inspect Compile's output, and Deploy must use the package that Test validated. In classic configurations, Test declares its upstream dependency on Compile; Deploy declares its upstream dependency on Test. That graph establishes the scheduling relationships you intend to review.
If source synchronization is enforced along those edges, a newer commit arriving while the chain runs should not silently turn Test into a test of the newest sources under the exercise's synchronized source roots. Still, the source snapshot does not prove that Test opened the correct package.
Ask what each stage actually executes. If Test compiles a new package locally rather than downloading Compile's package, it may validate a different output even with the same source revision. Different toolchains, dependency resolutions, or environment values can change that output.
Now introduce separate deployment scripts. It can be legitimate to deploy a previously validated application package using a newer deployment-script revision. Explain the independent revision groups deliberately, keep the application artifact fixed, and record both revisions. Do not disable synchronization casually on one edge without reviewing the rest of the graph's revision constraints.
What does an artifact dependency guarantee?
Official fact: JetBrains' artifact-dependency guide describes downloading files from a selected build before the downstream build starts. Artifact dependencies alone do not enforce execution order or source synchronization. Pairing a snapshot dependency with Build from the same chain ties file selection to the intended chain member.
Original dependency matrix: Separate the property you need from the mechanism that supplies it:
| Required property | Mechanism to review | What it does not prove alone |
|---|---|---|
| Compile finishes before Test | Snapshot dependency | Test receives Compile's package |
| Stages share the intended sources | Enforced revision synchronization | Identical toolchains or output bytes |
| Test downloads a package | Artifact dependency and file rules | Package came from this chain |
| Package comes from the selected chain member | Same-chain artifact source plus matching dependency | The test actually exercised that package |
| Deploy uses the validated bytes | Explicit artifact provenance and digest checks | Full runtime correctness |
The artifact source is part of the answer. “Latest successful” and “Build from the same chain” are different selectors. A floating selector can supply a valid package from a different build ID; compare that ID with the one Test actually used.
Review the published source path, download destination, and path opened by the test command separately. For a simple exercise, Compile publishes app.zip, and Test downloads it with a required rule such as:
app.zip=>incoming
Confirm that the source artifact exists and that Test opens incoming/app.zip. Review destination cleanup if older files might remain. Making a required package optional can let the build continue without the input it was supposed to validate.
Why can a green chain deploy an untested package?
Original timeline exercise: Two Compile runs produce different packages. The first belongs to the release chain; the second is a later successful build.
| Time | Event | Identity to retain |
|---|---|---|
| 10:00 | Compile #210 builds application revision A | Package digest H-A |
| 10:04 | Test #88 validates #210's package | Tested digest H-A |
| 10:05 | Compile #211 builds revision B in another run | Package digest H-B |
| 10:06 | Deploy selects “latest successful” Compile output | It may receive #211 and H-B |
Deploy can report success while shipping H-B, a package that Test #88 never validated. The diagnosis requires the actual artifact provider build ID, not only a green Test status or the name app.zip.
A stronger configuration proposal identifies the relevant same-chain Compile build, adds the appropriate artifact dependency, and verifies that Test and Deploy record the same digest. If Deploy depends transitively on Compile through Test, inspect the actual chain and artifact provider rather than assuming a stage name establishes membership.
An alternate design lets a packaging stage republish a validated package with a manifest that records its origin. Then Deploy consumes that explicit release artifact. The manifest must accompany the actual bytes; a label saying “tested” is insufficient if the republished package changed.
Do not repair this by rebuilding the application in Deploy. Rebuilding creates another output to validate and can change dependency or environment inputs. In this exercise, promotion of the already-tested package is the intended contract.
Is reusing an upstream build the same as a build-cache hit?
Official fact: The chain-dependency documentation lists suitability requirements for reusing a build, including its source snapshot, branch compatibility, configuration settings, customized parameters, and dependency suitability. “Do not run new build if there is a suitable one” is a chain-level reuse decision.
Original distinction: Reusing Compile #210 means the chain points to an existing build result instead of executing another Compile run. A compiler or package-manager cache hit happens inside an executing build step. Both can save work, but their evidence and invalidation rules differ.
If a candidate says, “The source did not change, so reuse is always safe,” introduce a build-configuration change or customized parameter. Ask whether that result is still suitable according to TeamCity's rules. Then introduce an unrecorded external dependency: even a product-defined suitable build does not prove that every input to a historical result was hermetic.
JetBrains' chain-monitoring guide explains where reused build results and artifact dependencies are visible. In an interview, ask for the chain's actual dependency build IDs and reuse indicators before assuming that an upstream stage reran.
What does clean checkout fail to guarantee?
Official fact: Clean checkout deletes the build checkout directory's contents and refetches sources. Its scope is that checkout directory, not every dependency cache, external service, tool installation, or machine setting.
Original reproducibility exercise: The same application commit runs once with compiler version X and once with compiler version Y. A clean checkout in both runs does not reconcile the compiler difference. Likewise, a dependency declared with a floating version can resolve differently while the repository revision remains identical.
Build a provenance ledger with fields that answer the intended investigation:
| Evidence field | Question it answers |
|---|---|
| Application revisions for all relevant source roots | Which source snapshot was built? |
| TeamCity configuration/settings revision | Which orchestration and runner settings applied? |
| Dependency lockfile and resolved versions | Which external packages were selected? |
| Compiler/runtime/container image identity | Which toolchain executed? |
| Relevant parameters and environment values | Which behavior-changing inputs were supplied? |
| Upstream provider build ID and artifact digest | Which output was tested and deployed? |
JetBrains documents versioned project settings, including XML and Kotlin representations. Use the settings revision as one recorded input; storing settings in Git does not automatically pin every toolchain or dependency used by the build.
Separate byte reproducibility from functional equivalence. Two archives can contain identical application files but differ in timestamps or packaging metadata. Decide whether the requirement is identical bytes, identical extracted contents, or equivalent behavior before using a digest mismatch as the final diagnosis.
How should a failed test affect downstream stages?
Official fact: Chain-dependency settings define downstream behavior when an upstream dependency fails or cannot start. Available behaviors include cancellation and running with or without a dependency problem. The run-build-chains guide also describes retries and promotion of an existing build.
Original gate exercise: TestLinux and TestWindows both depend on Compile. Release depends on both test configurations. If TestWindows fails, what should Release do? State the release policy first, then inspect both dependency edges' failure behavior. A graph with both edges can still undermine the gate if its configured behavior permits an unacceptable release path.
A retry is a new attempt, not proof that the original failure was harmless. Retain the failure evidence and the revision/artifact identities used by the replacement attempt. If the tested input changes during a retry, describe it as testing a different candidate package.
For promotion, inspect the selected upstream build and the downstream artifact selector together. Promotion should preserve the intended package in this exercise; a floating selector can defeat that intention even when the promoted build's identity is visible.
How would you diagnose a missing or unexpected artifact?
Official fact: TeamCity's build-artifact guide describes publication rules and where a finished build's artifacts can be inspected. A file created on an agent is not automatically a published artifact just because a later stage needs it.
Original diagnostic order: Verify the upstream build ID and status, inspect its published artifact list, compare the downstream source selector, then inspect the download rule and destination. Finally confirm the command's working directory and the path it actually opens.
That order separates “not produced,” “not published,” “wrong provider,” “not downloaded,” and “downloaded but not used.” Capture the earliest failing boundary before changing several settings. For a stale-file case, check whether an old destination package satisfied the script even though the intended download was absent.
Give a reviewable dependency answer
A strong answer names the graph, synchronized source roots, artifact provider, and verification evidence. For the opening mismatch, it explains why a floating artifact selector can defeat an otherwise correctly ordered chain, then proposes same-chain selection and digest readback.
Practice Design a Dependency-Aware CI/CD Pipeline with one additional constraint: Deploy must consume the exact package that Test validated. Review the provider build ID and tested/deployed digests until the graph and actual artifact readbacks support that constraint.