Git, APIs & SQL Interview Questions

Git is the version-control software itself, running locally on your machine, tracking changes to files over time -- GitHub is a hosted service for storing Git repositories remotely and adding collaboration features (pull requests, issues, code review) on top of Git.

`git add` stages changes -- marking specific file changes to be included in the next commit; `git commit` actually records those staged changes as a new permanent snapshot in the repository's history, with a message describing the change.

It lets you selectively choose exactly which changes go into the next commit, even if you've modified several unrelated files -- enabling focused, logically-grouped commits instead of one giant commit mixing unrelated changes together.

A commit is a snapshot of the entire repository's file tree at a point in time, plus metadata (author, timestamp, message) and a reference to its parent commit(s) -- the chain of parent references is what forms the project's history.

It shows which files are staged, unstaged, or untracked in the current working directory -- checking it before committing prevents accidentally committing unintended files (like a debug log) or missing files you meant to include.

It lists file/directory patterns that Git should never track or stage, even if they exist in the working directory -- used for things like build output, dependency folders, and local secret files that shouldn't be part of the repository's history.

`git fetch` downloads the latest changes from a remote without merging them into your current branch, letting you inspect them first; `git pull` is effectively `fetch` followed immediately by a `merge` (or `rebase`, depending on configuration) into your current branch.

Commit messages are what makes `git log`, `git blame`, and history searches actually useful later -- a vague message like 'fix stuff' gives future readers (including your future self) no way to understand why a change was made without re-reading the entire diff.

`git diff` shows the difference between your working directory and what's staged (or the last commit); `git diff --staged` (or `--cached`) shows the difference between what's staged and the last commit -- distinguishing 'what have I changed' from 'what am I about to commit.'

Committing a `.env` file or a credentials file before adding it to `.gitignore` -- once committed, that secret exists in the repository's history permanently (even if later deleted in a new commit), typically requiring history rewriting or key rotation to truly remediate.

Common mistake: Adding a real API key or password to a config file and committing it before ever adding that file to .gitignore.

A lightweight, movable pointer to a specific commit -- creating a branch doesn't copy any files, it just creates a new named reference that can advance independently as you make new commits on it, without affecting other branches.

It isolates in-progress, potentially-broken work from the stable main branch, allows code review before merging, and lets multiple people work on different features simultaneously without their incomplete changes interfering with each other.

It occurs when Git can't automatically combine two branches' changes because they modified the same lines of the same file differently -- Git pauses the merge and requires a human to manually decide which changes (or what combination) should be kept.

A fast-forward merge happens when the target branch has no new commits since the source branch diverged -- Git simply moves the pointer forward, no new commit needed. If both branches have diverged with independent commits, Git creates a new merge commit with two parents to combine the histories.

A pull request proposes merging one branch into another and provides a dedicated place for code review, automated CI checks, and discussion before the merge actually happens -- it's a collaboration/quality gate, not just a mechanical merge operation.

Merging creates a new commit combining both histories, preserving exactly how they actually diverged; rebasing rewrites the feature branch's commits to appear as if they were made starting from the latest main, producing a linear history but changing the feature branch's commit hashes in the process.

Rewriting history changes commit hashes on that branch, so anyone who already pulled the old version now has a diverged, conflicting history -- their next pull will encounter unexpected conflicts or duplicate commits unless they specifically know to reset to the rewritten branch.

Common mistake: Force-pushing a rewritten shared branch that teammates have already based their own work on, breaking their local history.

`git merge` combines an entire branch's history (all its commits) into the current branch; `git cherry-pick` applies just one specific commit from elsewhere onto the current branch, without bringing along the rest of that commit's branch history.

Open the conflicted file, look for Git's conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) delimiting the two competing versions, manually edit the file to keep the correct combined content, remove the markers, then stage and commit the resolved file.

It guarantees every change to the main branch has gone through review and passed CI checks before landing, reducing the chance of an untested or unreviewed change breaking the shared codebase that everyone builds on.

JavaScript Object Notation -- a lightweight, human-readable text format for representing structured data (objects, arrays, strings, numbers, booleans, null). It's popular for APIs because it maps naturally onto common programming-language data structures and is easy for both humans and machines to parse.

Representational State Transfer -- a core idea is modeling the API around resources (nouns, like `/users` or `/orders`) accessed via standard HTTP methods (GET, POST, PUT, DELETE) that indicate the action, rather than encoding the action into the URL itself (like `/getUser`).

PUT conventionally means replacing the entire resource with the provided representation; PATCH means applying a partial update, modifying only the specific fields included in the request while leaving the rest of the resource unchanged.

201 Created -- commonly paired with a `Location` header pointing at the newly-created resource's URL, and a response body containing the created resource's data (including its newly-assigned id).

It tells the receiver how to interpret the body's format -- a JSON request or response body typically sets `Content-Type: application/json`, letting the receiving side know to parse the body as JSON rather than plain text or form data.

Client-side validation is a UX convenience, not a security boundary -- any client-side check can be bypassed by sending a request directly (via a script, curl, or a modified client), so the server must independently enforce every validation rule that actually matters.

Pagination splits a large result set into smaller pages (e.g. via `?page=2&limit=20` or cursor-based tokens), returned across multiple requests rather than one huge response -- without it, an endpoint returning millions of rows could produce enormous, slow responses that overwhelm both server and client.

Authentication verifies WHO is making the request (proving identity, e.g. via a valid token/credentials); authorization determines WHAT that authenticated identity is actually allowed to do (e.g. can this user delete this specific resource) -- a request can be authenticated but still unauthorized for a given action.

An idempotent operation produces the same end result no matter how many times it's repeated with the same input -- GET, PUT, and DELETE are conventionally expected to be idempotent (calling DELETE on an already-deleted resource still leaves it deleted), while POST typically is not (repeating it can create duplicate resources).

For security-sensitive endpoints (like login), a generic 'invalid credentials' error prevents an attacker from distinguishing 'wrong password' from 'account doesn't exist,' which would otherwise let them enumerate valid usernames/emails by observing which error message comes back.

A column (or combination of columns) that uniquely identifies each row in a table -- without one, there's no reliable way to reference, update, or delete a single specific row, especially once duplicate-looking data exists.

It filters which rows are included in the result, based on a condition -- `SELECT * FROM users WHERE age >= 18` returns only rows where the `age` column's value is 18 or greater.

SELECT * FROM users WHERE age >= 18;

`INSERT` adds new rows to a table; `UPDATE` modifies the values of existing rows matching a condition; `DELETE` removes existing rows matching a condition -- all three, unlike `SELECT`, actually change the data stored in the table.

Without a `WHERE` clause, the statement applies to every single row in the table -- a missing `WHERE` on a `DELETE` deletes the entire table's contents, and on an `UPDATE` overwrites every row's values, both usually with no automatic undo.

Common mistake: Running an UPDATE or DELETE statement while forgetting the WHERE clause, applying the change to every row in the table.

A column in one table that references another table's primary key -- it represents a relationship between the two tables (e.g. an `orders.customer_id` column referencing `customers.id` means each order belongs to a specific customer).

It combines rows from two or more tables based on a related column between them (typically a foreign key relationship), letting a single query pull together data that's spread across normalized tables -- e.g. combining `orders` with `customers` to show each order alongside its customer's name.

SELECT orders.id, customers.name
FROM orders
JOIN customers ON orders.customer_id = customers.id;

`GROUP BY` collapses rows sharing the same value in a specified column into groups; an aggregate function then computes a single summary value per group (e.g. `SELECT customer_id, COUNT(*) FROM orders GROUP BY customer_id` counts each customer's orders) -- without an aggregate, grouping alone doesn't produce a meaningful summarized result.

Separating tables avoids duplicating a customer's information across every one of their orders, which would waste storage and create an update-consistency risk (updating the customer's address in one row but not others) -- a normalized structure keeps each fact stored exactly once.

It sorts the result set by one or more specified columns (ascending by default, or `DESC` for descending); without it, SQL makes no guarantee about the order rows will be returned in -- relying on an implicit, unspecified order is a common source of flaky-seeming query results.

Directly concatenating untrusted user input into a SQL string opens a SQL injection vulnerability, where crafted input can alter the query's actual logic (e.g. bypassing a login check or reading unintended data); parameterized queries keep the query structure fixed and treat user input strictly as data, never as executable SQL syntax.

Common mistake: Building a SQL query by concatenating raw user input directly into the query string instead of using parameterized placeholders, opening a SQL injection vulnerability.

SQL uses `NULL` to represent an unknown or missing value. `NULL` is never equal to anything, including another `NULL`, under standard SQL comparison semantics -- `column = NULL` always evaluates to unknown/false, so checking for it requires the special `IS NULL` (or `IS NOT NULL`) syntax instead.

Common mistake: Writing WHERE column = NULL instead of WHERE column IS NULL, which silently matches zero rows.

`LIKE` performs pattern-based text matching -- `%` matches any sequence of zero or more characters, and `_` matches exactly one character. `WHERE name LIKE 'A%'` matches any name starting with 'A'.

SELECT * FROM users WHERE email LIKE '%@example.com';

It removes duplicate rows from the result set, based on the selected columns -- `SELECT DISTINCT country FROM customers` returns each unique country value once, regardless of how many customer rows share that country.

`LIMIT` caps the number of rows returned -- when exploring a table you don't know well, `SELECT * FROM orders LIMIT 10` lets you preview a sample of the data without accidentally pulling back millions of rows.

An index is a separate data structure that lets the database find matching rows for a specific column's value quickly, similar to a book's index letting you find a topic without reading every page -- without an index on a filtered column, the database may have to scan every row in the table to find matches.

Restricting how many requests a single client can make within a given time window -- it protects the API's backend from being overwhelmed (accidentally or maliciously) and ensures fair usage across all clients sharing the same service.

Versioning lets an API introduce breaking changes to its shape/behavior in a new version while existing clients keep using the older, still-supported version -- without it, any breaking change would immediately break every existing client with no migration window.

Use a command-line tool like `curl`, or a GUI tool like Postman/Insomnia, to send a real HTTP request directly to the endpoint's URL and inspect the raw response (status code, headers, body) -- useful for confirming an API behaves as expected before writing code that depends on it.

curl -i https://api.example.com/users/42

A request can complete successfully at the network level while the server still returns an error status (like 404 or 500) in the response -- code that only checks for a network-level failure, without also checking the status code, can silently treat a failed request as if it succeeded.

Common mistake: Treating any HTTP response that arrives without a network error as successful, without checking whether its status code actually indicates success.

Credentials committed directly into source code end up in the repository's history (readable by anyone with repo access, and hard to fully remove later) and can't easily differ between environments (local/staging/production) -- environment variables or a dedicated secrets manager keep sensitive values out of version control entirely.