How I Spot a Copy-Pasted DevOps Engineer Project in Minutes

Interview Insights · DevOps Engineer

How I Spot a Copy-Pasted DevOps Engineer Project in Minutes

SECTION 01The Git history tells the first story

Before reading any code, I look at the commit history. Real projects grow in small steps: a first working build, a fix, a new stage, a broken deploy and a repair. Copied projects often arrive in one or two huge commits, sometimes with a message like 'initial commit' or 'final project', and nothing after that.

This is not proof on its own, because some people only learn Git late. But it shapes my questions. A one-commit project makes me ask much harder questions about how it was built. A history with real fixes gives me easy, honest openings such as 'tell me about this commit where you changed the health check'.

# Overview of the history
git log --oneline --graph --all | head -40

# Who committed and how much
git shortlog -sn

# When the work happened
git log --format='%ad %s' --date=short

# Size of each commit
git log --stat --oneline | head -60

# When a specific file changed
git log --follow --oneline -- Jenkinsfile

a91c2f0 Add rollback step using previous image tag
7d33e1b Fix health check path: /health -> /healthz
52b0a9e Cache npm dependencies to speed up CI
1f4c8d2 Move registry and region to variables
c0e7b55 Add Trivy image scan, fail on CRITICAL
8a2d6f1 Deploy to minikube with kubectl apply
3be91c4 Build and push Docker image in pipeline
0d5a7e3 Add Dockerfile for Node.js app

(Each commit is a step someone can talk about.)

The healthy history is a ready-made interview script. Every line is a question I can ask and a story the candidate can tell. If your history looks like this, you have already prepared half of your project discussion.

SECTION 02Configuration fingerprints that give copying away

The second check is the configuration itself: the Jenkinsfile or workflow YAML, Dockerfile, Kubernetes manifests and Terraform files. Tutorials leave fingerprints. The app is still called my-app or demo, the Docker Hub username belongs to the tutorial author, the region and account ID are hard-coded, and comments explain steps in the tutorial's own words.

The most worrying fingerprint is secrets in the repository. An access key or password committed to a public repo tells me the candidate has not thought about security, whether the project was copied or not.

# Leftover demo names and latest tags
grep -rnE 'demo|sample|my-app|:latest' --include='*.y*ml' --include='Dockerfile' .

# Hard-coded AWS account IDs (12 digits) and regions
grep -rnE '[0-9]{12}|us-east-1|ap-south-1' --include='*.tf' --include='*.y*ml' .

# Possible secrets
grep -rnE 'AKIA[0-9A-Z]{16}|password\s*[:=]' .

# Secrets ever committed (search all history)
git log -p | grep -nE 'AKIA[0-9A-Z]{16}' | head

pipeline {
  agent any
  environment {
    REGISTRY = "${env.REGISTRY_HOST}/orders"
    TAG      = "${env.GIT_COMMIT.take(7)}"
  }
  stages {
    stage('Test') {
      steps { sh 'npm ci && npm test' }
    }
    stage('Build') {
      steps { sh 'docker build -t $REGISTRY:$TAG .' }
    }
    stage('Push') {
      steps {
        withCredentials([usernamePassword(credentialsId: 'registry-creds',
            usernameVariable: 'U', passwordVariable: 'P')]) {
          sh 'echo "$P" | docker login $REGISTRY_HOST -u "$U" --password-stdin'
          sh 'docker push $REGISTRY:$TAG'
        }
      }
    }
  }
}

The adapted Jenkinsfile is not complex. It simply shows ownership: the registry comes from the environment, the tag is the short commit SHA and credentials come from Jenkins credentials rather than the file. These are the details I look for.

If you find an old secret in your history, rotating the key matters more than rewriting history. Once a key is public, assume it is compromised. Mentioning that you did this is a positive story, not a negative one.

SECTION 03The live questions that settle it

Even with clean history and adapted files, the interview itself is the final check. I ask questions that are easy for the builder and hard for the copier: change something small, explain why a line exists, describe what broke along the way. A builder answers from memory of doing it. A copier tries to reason from the file, and it shows.

In Uncodemy project reviews, we ask students these same questions before their interviews, so that any part of the project they cannot explain gets rebuilt and understood first.

Interviewer: Why does your Dockerfile copy package.json
before the rest of the code?

Candidate: That is the standard way.

Interviewer: What would happen if you copied everything
first?

Candidate: It would also work, I think.

(It would work, but every code change would invalidate
the dependency install layer. The candidate does not
know why the order matters.)

Interviewer: Why does your Dockerfile copy package.json
before the rest of the code?

Candidate: For layer caching. Docker reuses a layer if
its inputs have not changed. If package.json is copied
alone and npm ci runs next, that layer is reused until
dependencies change. Copying all code first would
rerun npm ci on every code change.

I noticed this because my early builds were slow, and
fixing the order made rebuilds much faster.

The builder's last sentence is the giveaway in a good way. It connects the line to a moment in the project's life. That is something a copier cannot produce.

SECTION 04Turning a tutorial project into your own

If your main project started as a tutorial, that is fine. Use these tabs to take it far enough beyond the tutorial that you can defend every part of it.

MAKE THE TUTORIAL YOURS (pick at least four)

[ ] Rename app, images and resources to your own
[ ] Move hard-coded values into variables
[ ] Tag images by commit SHA, not latest
[ ] Add a stage the tutorial did not have
    (image scan, lint, smoke test, rollback)
[ ] Deploy to a second environment
[ ] Replace stored keys with CI secrets or OIDC
[ ] Add monitoring or an alert
[ ] Write a README with decisions and problems

BREAK IT ON PURPOSE, THEN FIX IT

1. Push a failing unit test. Does the pipeline stop?
2. Use a wrong image tag. What does Kubernetes show?
3. Remove a required env variable. What happens?
4. Expire or remove the registry credential.
5. Fill the build agent's disk with old images.

Write down each error message and the fix.
These become your 'what broke?' answers.

README FOR AN OWNED PROJECT

## What it does (two lines)
## Architecture (your own diagram)
## Pipeline stages and why each exists
## How to run it
## Decisions and trade-offs
## Problems I hit and how I fixed them
## What I would improve next
## Credits
   Based on [tutorial name]; I added: ...

Crediting the tutorial is honest and makes
your additions stand out.

SECTION 05Habits that make every project clearly yours

Owning a project is mostly a set of habits during the build, not a clean-up at the end.

• Commit small and often — Each working step deserves its own commit with a message that explains what changed.
• Credit your sources — Saying a project started from a tutorial and listing what you added is honest and respected.
• Keep an error diary — Write down every error and fix while building; it becomes your best interview preparation.
• Remove secrets from day one — Use CI secrets or a secrets manager from the start, and rotate anything that was ever committed.
• Change one thing at a time — Small, deliberate changes teach you what each line does far better than pasting a full file.

SECTION 06Interview Q&A — DevOps project

SECTION 07Test yourself — DevOps project quiz

SECTION 08Frequently asked questions

SECTION 09Related reads