Describe using a pre-push Git hook for checks and its CI limitations.

WHAT THIS TESTS: This question checks whether you know the boundary between developer convenience and enforceable policy. Interviewers want to see that you understand Git hooks live in the local repository, are trivial to bypass, and therefore cannot replace server-side validation. They also want to hear the practical mechanics of wiring a script into the hook directory.

A GOOD ANSWER COVERS: First, the mechanics: you create an executable file named pre-push inside the .git/hooks directory of the repository. The script should run your linter or test suite, inspect the exit code, and exit with a non-zero code if any check fails so that Git aborts the push. Second, the scope: pre-push receives information about the remote and refs being pushed via standard input and arguments, so advanced scripts can limit checks to the commits actually being pushed rather than the whole codebase. Third, the limitations: client-side hooks are not copied when someone clones the repository, they can be bypassed entirely with the --no-verify flag, they depend on whatever toolchain versions the developer has installed locally, and they do not run for commits created through web interfaces or API calls. Fourth, the architectural stance: hooks are a safety net for the individual developer, but the canonical policy enforcement must live in server-side hooks or CI pipelines.

COMMON WRONG ANSWERS: Treating the pre-push hook as a security control or compliance gate. Claiming that hooks are shared through the repository automatically. Saying that --no-verify only skips commit hooks rather than push hooks. Suggesting that a failed hook can be fixed by amending the commit after push. Proposing to check the hook script into version control and expecting Git to run it from there without an explicit install step.

LIKELY FOLLOW-UPS: How would you distribute and update hooks across a large team if they are not cloned? What would you use instead of a client-side hook to guarantee tests run before merge? How do server-side hooks like pre-receive differ, and what are their trade-offs? Would you run the full test suite or a fast subset in a pre-push hook, and how do you keep feedback loops short?

ONE CONCRETE EXAMPLE: Imagine a Node.js project where npm test takes two minutes. You write a .git/hooks/pre-push shell script that runs npm run lint and npm test. If either fails, the script exits 1 and Git prints a message saying the push was rejected. You also add a Husky or similar framework to help teammates install the hook, but you still configure a GitHub Actions workflow that runs the same lint and test commands on every pull request because you know a developer can always push with --no-verify or might not have the hook installed at all.